Re: [Freeipa-users] FreeIPA 3.3 and Solaris 10 Client Integration:
On 09/25/2014 05:35 PM, Traiano Welcome wrote:
Hi Martin
On Wed, Sep 24, 2014 at 2:18 PM, Martin Kosek mko...@redhat.com
mailto:mko...@redhat.com wrote:
On 09/24/2014 01:06 PM, Traiano Welcome wrote:
Hi List
I'm currently running IPA 3.3 on Centos 7, and successfully
authenticating
Linux clients (Centos 6.5).
I'd like to setup Solaris 10 as an IPA client, but this seems
problematic. I am following this guide:
http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10
I have the following setup:
Solaris client:
- Solaris 10u11 (SunOS 5.10 Generic_147148-26 i86pc i386 i86pc)
IdM Server:
- Linux kwtpocipa001.orion.local 3.10.0-123.el7.x86_64 #1 SMP Mon Jun 30
12:09:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Going through the steps in the guide: at step 3 (Create the
cn=proxyagent
account), ldapadd fails with the following error:
ldapadd: invalid format (line 6) entry:
cn=proxyagent,ou=profile,dc=orion,dc=local
---
[root@kwtpocipa001 ~]# ldapadd -h 172.16.107.102 -p 389 -D cn=directory
manager -w Cr4ckM0nk3y
dn: cn=proxyagent,ou=profile,dc=orion,dc=local
objectClass: top
objectClass: person
sn: proxyagent
cn: proxyagent
userPassword::
e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ=
ldapadd: invalid format (line 6) entry:
cn=proxyagent,ou=profile,dc=orion,dc=local
---
I've made the assumption that the extra : is a typo in the
documentation
and removed it, so the command runs successfully as follows:
---
[root@kwtpocipa001 ~]# ldapadd -h 172.16.107.102 -p 389 -D cn=directory
manager -w Cr4ckM0nk3y
dn: cn=proxyagent,ou=profile,dc=orion,dc=local
objectClass: top
objectClass: person
sn: proxyagent
cn: proxyagent
userPassword:
e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ=
adding new entry cn=proxyagent,ou=profile,dc=orion,dc=local
---
At step 9 (Configure NFS ), I get an error, seems to indicate the
des-cbc-crc encryption type is unsupported:
---
[root@kwtpocipa001 ~]# ipa-getkeytab -s kwtpocipa001.orion.local -p
nfs/kwtpocipasol10u11.orion.local -k /tmp/kwtpocipasol10u11.keytab -e
des-cbc-crc
Operation failed! All enctypes provided are unsupported
[root@kwtpocipa001 ~]#
---
(Question: How would I add support for des-cbc-crc encryption in
freeipa?). I've now worked around this by not specifying any encryption
type:
---
[root@kwtpocipa001 ~]# ipa-getkeytab -s kwtpocipa001.orion.local -p
nfs/kwtpocipasol10u11.orion.local -k /tmp/kwtpocipasol10u11.keytab
Keytab successfully retrieved and stored in:
/tmp/kwtpocipasol10u11.keytab
[root@kwtpocipa001 ~]#
---
Testing that I can see nfs mounts on the centos IPA server from the
solaris
machine:
---
bash-3.2# showmount -e kwtpocipa001.orion.local
export list for kwtpocipa001.orion.local:
/data/centos-repo 172.16.0.0/24 http://172.16.0.0/24
bash-3.2#
Checking we can kinit:
---
bash-3.2#
bash-3.2# kinit admin
Password for admin@ORION.LOCAL:
bash-3.2#
bash-3.2#
bash-3.2# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@ORION.LOCAL
Valid startingExpiresService principal
09/24/14 11:20:36 09/24/14 12:20:36 krbtgt/ORION.LOCAL@ORION.LOCAL
renew until 10/01/14 11:20:36
bash-3.2#
bash-3.2#
bash-3.2#
bash-3.2# uname -a
SunOS kwtpocipasol10u11 5.10 Generic_147148-26 i86pc i386 i86pc
bash-3.2#
---
Testing I can mount the remote FS (without Kerberos auth). This is
successful (when not using kerberos5 authentication):
---
bash-3.2# mount -F nfs 172.16.107.102:/data/centos-repo /remote/
bash-3.2# mount |grep remote
/remote on 172.16.107.102:/data/centos-repo
remote/read/write/setuid/devices/rstchown/xattr/dev=4fa on Wed Sep 24
13:45:32 2014
bash-3.2#
---
Testing with KRB5:
---
bash-3.2# mount -F nfs -o sec=krb5 172.16.107.102:/data/centos-repo
/remote/
nfs mount: mount: /remote: Permission denied
bash-3.2#
---
Looking at the krbkdc logs on the IPA master server, I get the following
error:
---
Sep 24 13:48:17 kwtpocipa001.orion.local krb5kdc[2371](info): AS_REQ (6
etypes {18 17 16 23 3 1}) 172.16.107.107 http
Re: [Freeipa-users] Virtual DIT view howto
On 09/26/2014 11:19 AM, Sandor Juhasz wrote: Hello, i want to bind applications to the ldap, via ldap connector, so this should be fine. I have made the ldif, but i have no idea how to apply it, because simple ldapmodify gives and error. I would then start with sharing the LDIF and the error with freeipa-users :-) Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa host-del not authorised
On 09/25/2014 04:11 AM, Alex Harvey wrote: Hi all I'm new to IPA and struggling a bit to automate some tasks. I am unable to delete hosts from the command line although have no problem doing this using the GUI, e.g. [root@myipaserver ~]# ipa host-del myhost.example.com ipa: ERROR: Insufficient access: not allowed to perform this command I guess I need to somehow pass the admin user's username and password? However the man page doesn't seem to provide any option for doing this. Thanks Alex Hello Alex, I assume you created a non-admin user with some permissions allow deleting a host. This error message is thrown when a virtual operation check fails. This is raised for example when a user is trying to do unathorized operation with certificates, like if user having host deletion permission does not also have permission to revoke certificates for deleted users. Does the privileged user has Revoke Certificate permission assigned through some privilege/role? The mismatch of behavior between CLI and UI is strange. They call the same code, maybe you run it with different users. Also, what is your FreeIPA version? Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Virtual DIT view howto
On 09/25/2014 01:08 PM, Sandor Juhasz wrote: Hello, i need a bit of help on how to create virtual dit structure on an existing ipa. I need it to create separate structure to authenticate users for services which don't support ldap search filters. Ah, I think you want to do what FreeIPA already does in cn=compat,dc=example,dc=com, i.e. usage of Schema Compatibility plugin (slapi-nis package). I did not find anything in the manual or any howto to start with. I would start here: https://fedorahosted.org/slapi-nis/ https://git.fedorahosted.org/cgit/slapi-nis.git/plain/doc/sch-getting-started.txt https://git.fedorahosted.org/cgit/slapi-nis.git/plain/doc/examples/sch-plugin-example.ldif.in HTH, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Disable Anonymous LDAP another way...
On 09/24/2014 01:11 AM, Tommy McNeely wrote: Hi all, I have seen the documentation on how to disable anonymous access *completely* at http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html However, I think that those base rootdse queries are probably important. I originally thought they only happened when running ipa-client-install but some quick tailing of the access log indicates to me that they happen a lot. So, instead of flipping the big switch in cn=config, has anyone considered just removing anonymous access to the *directory* data like: Oh yes, somebody indeed considered another way! This was one of the core feature of FreeIPA 4.0 which removed ACI you mentioned and replaced it with set of very targeted Read ACIs so that admin will get a fine grained control who can read what. This is the feature page: http://www.freeipa.org/page/V4/Permissions_V2 This is where you can try the new version: http://www.freeipa.org/page/Downloads#Latest_Release_-_FreeIPA_4.0.3 HTH, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA 3.3 and Solaris 10 Client Integration:
On 09/24/2014 01:06 PM, Traiano Welcome wrote:
Hi List
I'm currently running IPA 3.3 on Centos 7, and successfully authenticating
Linux clients (Centos 6.5).
I'd like to setup Solaris 10 as an IPA client, but this seems
problematic. I am following this guide:
http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10
I have the following setup:
Solaris client:
- Solaris 10u11 (SunOS 5.10 Generic_147148-26 i86pc i386 i86pc)
IdM Server:
- Linux kwtpocipa001.orion.local 3.10.0-123.el7.x86_64 #1 SMP Mon Jun 30
12:09:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Going through the steps in the guide: at step 3 (Create the cn=proxyagent
account), ldapadd fails with the following error:
ldapadd: invalid format (line 6) entry:
cn=proxyagent,ou=profile,dc=orion,dc=local
---
[root@kwtpocipa001 ~]# ldapadd -h 172.16.107.102 -p 389 -D cn=directory
manager -w Cr4ckM0nk3y
dn: cn=proxyagent,ou=profile,dc=orion,dc=local
objectClass: top
objectClass: person
sn: proxyagent
cn: proxyagent
userPassword::
e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ=
ldapadd: invalid format (line 6) entry:
cn=proxyagent,ou=profile,dc=orion,dc=local
---
I've made the assumption that the extra : is a typo in the documentation
and removed it, so the command runs successfully as follows:
---
[root@kwtpocipa001 ~]# ldapadd -h 172.16.107.102 -p 389 -D cn=directory
manager -w Cr4ckM0nk3y
dn: cn=proxyagent,ou=profile,dc=orion,dc=local
objectClass: top
objectClass: person
sn: proxyagent
cn: proxyagent
userPassword:
e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ=
adding new entry cn=proxyagent,ou=profile,dc=orion,dc=local
---
At step 9 (Configure NFS ), I get an error, seems to indicate the
des-cbc-crc encryption type is unsupported:
---
[root@kwtpocipa001 ~]# ipa-getkeytab -s kwtpocipa001.orion.local -p
nfs/kwtpocipasol10u11.orion.local -k /tmp/kwtpocipasol10u11.keytab -e
des-cbc-crc
Operation failed! All enctypes provided are unsupported
[root@kwtpocipa001 ~]#
---
(Question: How would I add support for des-cbc-crc encryption in
freeipa?). I've now worked around this by not specifying any encryption
type:
---
[root@kwtpocipa001 ~]# ipa-getkeytab -s kwtpocipa001.orion.local -p
nfs/kwtpocipasol10u11.orion.local -k /tmp/kwtpocipasol10u11.keytab
Keytab successfully retrieved and stored in: /tmp/kwtpocipasol10u11.keytab
[root@kwtpocipa001 ~]#
---
Testing that I can see nfs mounts on the centos IPA server from the solaris
machine:
---
bash-3.2# showmount -e kwtpocipa001.orion.local
export list for kwtpocipa001.orion.local:
/data/centos-repo 172.16.0.0/24
bash-3.2#
Checking we can kinit:
---
bash-3.2#
bash-3.2# kinit admin
Password for admin@ORION.LOCAL:
bash-3.2#
bash-3.2#
bash-3.2# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@ORION.LOCAL
Valid startingExpiresService principal
09/24/14 11:20:36 09/24/14 12:20:36 krbtgt/ORION.LOCAL@ORION.LOCAL
renew until 10/01/14 11:20:36
bash-3.2#
bash-3.2#
bash-3.2#
bash-3.2# uname -a
SunOS kwtpocipasol10u11 5.10 Generic_147148-26 i86pc i386 i86pc
bash-3.2#
---
Testing I can mount the remote FS (without Kerberos auth). This is
successful (when not using kerberos5 authentication):
---
bash-3.2# mount -F nfs 172.16.107.102:/data/centos-repo /remote/
bash-3.2# mount |grep remote
/remote on 172.16.107.102:/data/centos-repo
remote/read/write/setuid/devices/rstchown/xattr/dev=4fa on Wed Sep 24
13:45:32 2014
bash-3.2#
---
Testing with KRB5:
---
bash-3.2# mount -F nfs -o sec=krb5 172.16.107.102:/data/centos-repo /remote/
nfs mount: mount: /remote: Permission denied
bash-3.2#
---
Looking at the krbkdc logs on the IPA master server, I get the following
error:
---
Sep 24 13:48:17 kwtpocipa001.orion.local krb5kdc[2371](info): AS_REQ (6
etypes {18 17 16 23 3 1}) 172.16.107.107: NEEDED_PREAUTH:
host/kwtpocipasol10u11.orion.local@ORION.LOCAL for
krbtgt/ORION.LOCAL@ORION.LOCAL, Additional pre-authentication required
Sep 24 13:48:17 kwtpocipa001.orion.local krb5kdc[2373](info): DISPATCH:
repeated (retransmitted?) request from 172.16.107.107, resending previous
response
Sep 24 13:48:17 kwtpocipa001.orion.local krb5kdc[2374](info): DISPATCH:
repeated (retransmitted?) request from 172.16.107.107, resending previous
response
.
.
.
Sep 24 13:48:18 kwtpocipa001.orion.local krb5kdc[2373](info): AS_REQ (6
etypes {18 17 16 23 3 1}) 172.16.107.107: CLIENT_NOT_FOUND:
root/kwtpocipasol10u11.orion.local@ORION.LOCAL for
krbtgt/ORION.LOCAL@ORION.LOCAL, Client not found in Kerberos database
---
So it seems the host is not correctly registered.
NOTE: Via the interface ,I can see the solaris client is
not properly enrolled ( Kerberos Key Not Present), however the
Re: [Freeipa-users] Disable Anonymous LDAP another way...
On 09/24/2014 01:49 AM, Tommy McNeely wrote: DISREGARD! Sorry all, do not actually try my query, it makes authentication not work at least on CentOS6. Here is the doc I actually read the first time: http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/disabling-anon-binds.html (google search led me here) ... which says to turn it off, while the one I linked above: http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html says to set it to rootdse which allows the necessary access for detecting configuration, but blocks access to directory data. I just mis-read it on the F18 docs. Sorry for the noise :) One more note - there is a related proposal wrt to upstream guide (as you probably noticed, you are referring to guide from Fedora 15/18 times: https://www.redhat.com/archives/freeipa-users/2014-September/msg00357.html Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] New version Freeipa when?
In that case you can look forward to RHEL-7.1! Related rebase bug: https://bugzilla.redhat.com/show_bug.cgi?id=1109726 Martin On 09/24/2014 01:33 PM, Tevfik Ceydeliler wrote: Let me be more specific, I want to know that when FreeIPA 4.0.3 or above place in RHEL/CentOS official repository. (Not COPR) On 24-09-2014 14:31, Martin Kosek wrote: On 09/24/2014 01:23 PM, Tevfik Ceydeliler wrote: Hi, Do you know when new version Freeipa (v4) places on redhat or centos repository? Please define new version - do you mean FreeIPA 4.0.3? Or FreeIPA 4.1? Also, by repository, you mean official CentOS/RHEL repository or would a FreeIPA upstream repository be enough for you? Note that the latest FreeIPA stable upstream version is available as a Copr build that is also built for RHEL/CentOS 7.0: http://copr.fedoraproject.org/coprs/mkosek/freeipa/ The RHEL/CentOS version is still not completely working, though we are very close. See related thread: http://www.redhat.com/archives/freeipa-devel/2014-September/msg00530.html This is the reason why we did not announce the RHEL/CentOS build more publicly yet. HTH, Martin -- Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] PKI-CA fails to start (broken config after update?)
On 09/23/2014 03:59 AM, Ade Lee wrote: On Mon, 2014-09-22 at 13:39 -0600, swartz wrote: On 9/22/2014 9:14 AM, Ade Lee wrote: Another question - what is the output of ls -l /etc/pki-ca/CS.cfg ? ls -l /etc/pki-ca/CS.cfg -rw-r-. 1 pkiuser pkiuser 49196 Sep 19 11:29 /etc/pki-ca/CS.cfg In very rare cases, I've seen cases where the CS.cfg becomes truncated during an update. Unfortunately, we have not been able to reproduce the event. In later versions of dogtag, we make sure to save the CS.cfg just in case. Your instance sounds like a truncated CS.cfg instance, but the size is a lot larger than cases I've seen before, so I don't want to jump to that conclusion yet. JFTR, FreeIPA may have been involved as well, we had a related fix in FreeIPA 4.0.2: https://fedorahosted.org/freeipa/ticket/4166 If you scroll to the end of the CS.cfg, does it look like it has been truncated? If you have backups of the CS.cfg, that will help. Also, you could look for backups that we have created: find /var/lib/pki-ca -name CS.cfg* find /var/log -name CS.cfg* Also, do you have a replica CA? Ade I know that I did NOT change the configs myself. But something certainly did during 'yum update'. There are no .rpmsave or .rpmnew files that would typically be created if configs are properly marked in RPM spec file. There are two other files that exist though: -rw-r-. 1 pkiuser pkiuser 65869 Sep 19 11:30 CS.cfg.in.p21 -rw-rw. 1 pkiuser pkiuser 65955 Sep 5 2013 CS.cfg.in.p33 However, they are not usable either in place of current CS.cfg. The above files are templates only. They are modified during instance configuration. There have been no updates recently on rhel 6 to the pki packages. There has, however, been an update to tomcat - which broke dogtag startups. What version of tomcat6 is on your system? rpm -qa tomcat6 tomcat6-6.0.24-78.el6_5.noarch This tomcat version should still be a working one. The tomcat6 then broke things has not made it out yet, having been discovered in QE testing. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] What should we do with upstream guide?
Hello everyone! It's been over a year now since we announced [1] that the Technical Writer working on FreeIPA upstream guide [2] can no longer maintain the upstream version of it. FreeIPA project developers wanted to carry the torch and forked the outdated documentation in a new repository [3] and started the work on reviving it again [4][5]. Unfortunately, over the past year it became apparent that despite several brave contributors (special thanks to Gabe Alford and Martin Basti) helping with the guide, the project simply does not have resources to develop both FreeIPA and comprehensive documentation for it. The current FreeIPA guide is already way behind the RHEL-7 downstream guides [6][7] maintained by a new Technical Writer. In addition, old Fedora released documentation often pops up and clobbers FreeIPA upstream documentation in search engine results. This needs to change so that our users are not confused with obsolete information. Writing documentation is enormous task in itself. Currently, until a team of upstream Technical Writers joins the project to contribute alongside the developers the only viable option is to stop maintaining and reviving the upstream guide and keep only 2 main sources of documentation - design documents and articles of FreeIPA.org community wiki, and downstream documentation, from which the RHEL one [6][7] is the most complete. Upstream documentation tickets would be closed or transferred into the downstream doc Bugzillas, existing patches in [3] will be merged with the downstream RHEL documentation effort. This is the proposal. What do you think? Is it a reasonable move? Does anyone have time to be an upstream technical writer and carry the torch or should we move on with this plan? A sustainable documentation effort is needed and FreeIPA project is very much open to long term contributions. We are looking forward to your feedback, Your FreeIPA developers. [1] https://www.redhat.com/archives/freeipa-users/2013-August/msg00044.html [2] http://docs.fedoraproject.org/en-US/Fedora/18/html-single/FreeIPA_Guide/index.html [3] https://git.fedorahosted.org/cgit/freeipa-docs.git [4] https://fedorahosted.org/freeipa/milestone/Revive%20FreeIPA%20guide [5] https://fedorahosted.org/freeipa/milestone/FreeIPA%203.x%20Documentation [6] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html [7] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/index.html [8] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/ln-idp9643248.html -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] weak and null ciphers detected on ldap ports
On 09/22/2014 10:07 PM, Nathan Kinder wrote: On 09/22/2014 05:03 AM, Murty, Ajeet (US - Arlington) wrote: Security scan of FreeIPA server ports uncovered weak, medium and null ciphers on port 389 and 636. We are running ‘ipa-server-3.0.0-37.el6.i686’. How can I disable/remove these ciphers in my existing setup? This has recently been worked on in this 389-ds-base ticket: https://fedorahosted.org/389/ticket/47838 As mentioned in the initial description of that ticket, you can configure the allowed ciphers in the cn=config entry in 389-ds-base. You can edit this over LDAP, or by stopping 389-ds-base and editing /etc/dirsrv/slapd-REALM/dse.ldif. Thanks, -NGK You can also check the FreeIPA counterpart: https://fedorahosted.org/freeipa/ticket/4395 This issue is fixed in FreeIPA 4.0.3 (available in Copr build and Fedora 21+), we would very much welcome if you can verify that this setup works for you! Thanks, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] PKI-CA fails to start (broken config after update?)
On 09/20/2014 01:02 AM, swartz wrote:
Hello,
Encountered same issue as described here:
https://www.redhat.com/archives/freeipa-users/2013-July/msg00133.html
https://www.redhat.com/archives/freeipa-users/2014-August/msg00224.html
Plain vanilla IPA setup. No changes, no customizations.
Recently IPA fails to start. Error happened right after a 'yum update' and
reboot.
---
Starting pki-ca: [ OK ]
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
...
Failed to start CA Service
Shutting down
Digging into the matter further...
The line that causes the error above is in /usr/share/pki/scripts/functions
(which is loaded by pki-ca init script):
netstat -antl | grep ${port} /dev/null
The $port variable is blank so call to grep is without a search parameter.
Hence invalid call to grep and subsequent error msg I'm seeing as above.
$port is defined just a few lines above as
port=`grep '^pkicreate.unsecure_port=' ${pki_instance_configuration_file} |
cut
-b25- -`
BUT! For whatever reason there is no line that starts with
pkicreate.unsecure_port in $pki_instance_configuration_file
(/var/lib/pki-ca/conf/CS.cfg). Thus no port info is ever obtained for use in
grep.
Why there is no such line in config file where one is expected is unknown to
me...
Versions currently installed
ipa-server-3.0.0-37.el6.x86_64
pki-ca-9.0.3-32.el6.noarch
Did updates to pki packages clobber the configs? What got broken? How do I
resolve it?
Thank you.
Also please see another PKI crash on EL6 reported on freeipa-users:
https://www.redhat.com/archives/freeipa-users/2014-September/msg00331.html
This is not the first time this issue was reported, but we got no response from
PKI team, even though I CCed several members (maybe that was actually the root
case).
The PKI installation errors are piling up (7.1 too), I would like to resolve
that very soon so that we are not seen as too unstable software.
Thanks for help,
Martin
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Suggested Upgrade Path
On 09/18/2014 06:12 AM, Dmitri Pal wrote: On 09/17/2014 10:56 PM, Dan Mossor wrote: Good day, folks. I am curious what the suggested upgrade path is for FreeIPA. Currently, I am running freeipa-server-3.3.5-1.fc20.x86_64 on a virtual Fedora 20 server and am planning my upgrade to FreeIPA 4.0.3 on Fedora 21 Server. My current thought is to just build the F21 server and set it up as a replication server, then destroy the F20 VM. Will that be a seamless migration, or am I missing something? Make sure you install the replica with full CA and reconfigure this replica to be the CRL publisher and cert renewal tracker. Search this list archives and wiki on how to do it. ... or check the upstream wiki page with detailed instructions: http://www.freeipa.org/page/Howto/Migration#Migrating_existing_FreeIPA_deployment HTH, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-getcert request problem
On 09/15/2014 05:01 PM, Martin Kosek wrote: On 09/15/2014 03:31 PM, Natxo Asenjo wrote: hi, Centos 6.5. I want to create a certificate request for our mysql servers. I came up with this command line: $ sudo /usr/bin/ipa-getcert request -r -f /etc/pki/tls/certs/`hostname --fqdn`-mysql.crt -k /etc/pki/tls/private/`hostname --fqdn`-mysql.key -D `dnsdomainname` -U id-kp-serverAuth -K mysql/`hostname --fqdn` New signing request 20140915132335 added. But it gets rejected: Request ID '20140915132335': status: CA_REJECTED ca-error: Server denied our request, giving up: 2100 (RPC failed at server. Insufficient access: You need to be a member of the serviceadmin role to add services). stuck: yes key pair storage: type=FILE,location='/etc/pki/tls/private/hostname-mysql.key' certificate: type=FILE,location='/etc/pki/tls/certs/hostname-mysql.crt' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes I think I have the serviceadmin role: $ ipa role-show it specialist Role name: IT Specialist Description: IT Specialist Member groups: admins Privileges: Host Administrators, Host Group Administrators, Service Administrators, Automount Administrators The account is member of group admins. What am I doing wrong? Thanks! -- Groeten, natxo It seems you hit the same issue as Michael. See my response: https://www.redhat.com/archives/freeipa-users/2014-September/msg00256.html You will need to 1) Create host `domainname` 2) Create services * mysql/`hostname` * mysql/`domainname` 3) Run ipa service-add-host mysql/`domainname` --host mysql/`hostname` 4) Resubmit certificate It looks like we need to do better in documentationerror message... FYI - I filed https://fedorahosted.org/freeipa/ticket/4540 to improve the message. Oh and BTW, this only works with FreeIPA 4.0+, details in ticket https://fedorahosted.org/freeipa/ticket/3977. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Use of SAN's with automatic certificates in FreeIPA 4
On 09/12/2014 09:19 PM, Dmitri Pal wrote:
On 09/12/2014 02:43 PM, Michael Lasevich wrote:
That is awesome, but I am clearly missing some insight as to how this is
supposed to work. Can you point me to some more specific info on how to
accomplish this.
I tried using the ipa-getcert request with multiple -D's from the client, but
got :
** Insufficient access: You need to be a member of the serviceadmin role to
add services
Unless I am missing something, I should probably not add each host to
serviceadmins for security reasons.
4.0 has a new permissions system this might yet to be another use case that we
might have overlooked.
Not, not really - this part works well with 4.0.
I will leave to developers to review this situation on Monday morning.
So I then I tried generating a csr via openssl with SANs on the client and
then adding it using ipa cert-request file.csr --prinicple
host/${client_hostname}@DOMAIN from ipa server as admin (just to be sure)
and got this error (where ALIAS is the first SAN):
** ipa: ERROR: The service principal for subject alt name ALIAS in
certificate request does not exist
It sounds like I need to create service principal for each SAN, but I can't
seem to figure out how to do it (only allows me to create service prinicpals
for existing hosts)
You need to create an (unused) host for the SAN service first. After that you
can create the service. Dummy service/host entries with appropriate managedby
attribute are used to authorize which host/service.
I did a quick test with latest FreeIPA 4.0.3 and it worked for me:
# ipa-getcert request -d /etc/httpd/nssdb -n Server-Cert -K test/`hostname` -N
CN=`hostname`,O=EXAMPLE.COM -D san.host.example.test -g 2048
New signing request 20140915143901 added.
# ipa-getcert list -i 20140915143901
Number of certificates and requests being tracked: 8.
Request ID '20140915143901':
status: CA_REJECTED
ca-error: Server at https://ipa.mkosek-fedora20.test/ipa/xml denied our
request, giving up: 2100 (RPC failed at server. Insufficient access: You need
to be a member of the serviceadmin role to add services).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert',token='NSS
Certificate DB'
certificate:
type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert'
CA: IPA
issuer:
subject:
expires: unknown
pre-save command:
post-save command:
track: yes
auto-renew: yes
This is expected, now the authorization needs to be added:
# ipa service-add test/`hostname`
# ipa service-add test/san.host.example.test --force
# ipa service-add-host test/san.host.example.test --host `hostname`
Principal: test/san.host.example.t...@mkosek-fedora20.test
Managed by: san.host.example.test, ipa.mkosek-fedora20.test
-
Number of members added 1
-
# ipa-getcert resubmit -i 20140915143901
Resubmitting 20140915143901 to IPA.
# ipa-getcert list -i 20140915143901
Number of certificates and requests being tracked: 8.
Request ID '20140915143901':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert',token='NSS
Certificate DB'
certificate:
type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=MKOSEK-FEDORA20.TEST
subject: CN=ipa.mkosek-fedora20.test,O=MKOSEK-FEDORA20.TEST
expires: 2016-09-15 14:48:01 UTC
dns: san.host.example.test
principal name: test/ipa.mkosek-fedora20.t...@mkosek-fedora20.test
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
# certutil -L -d /etc/httpd/nssdb -n Server-Cert
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 11 (0xb)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: CN=Certificate Authority,O=MKOSEK-FEDORA20.TEST
Validity:
Not Before: Mon Sep 15 14:48:01 2014
Not After : Thu Sep 15 14:48:01 2016
Subject: CN=ipa.mkosek-fedora20.test,O=MKOSEK-FEDORA20.TEST
...
Name: Certificate Subject Alt Name
DNS name: san.host.example.test
...
I also updated
http://www.freeipa.org/page/PKI#Automated_certificate_requests_with_Certmonger
with couple hints how that works.
HTH,
Martin
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-getcert request problem
On 09/15/2014 03:31 PM, Natxo Asenjo wrote: hi, Centos 6.5. I want to create a certificate request for our mysql servers. I came up with this command line: $ sudo /usr/bin/ipa-getcert request -r -f /etc/pki/tls/certs/`hostname --fqdn`-mysql.crt -k /etc/pki/tls/private/`hostname --fqdn`-mysql.key -D `dnsdomainname` -U id-kp-serverAuth -K mysql/`hostname --fqdn` New signing request 20140915132335 added. But it gets rejected: Request ID '20140915132335': status: CA_REJECTED ca-error: Server denied our request, giving up: 2100 (RPC failed at server. Insufficient access: You need to be a member of the serviceadmin role to add services). stuck: yes key pair storage: type=FILE,location='/etc/pki/tls/private/hostname-mysql.key' certificate: type=FILE,location='/etc/pki/tls/certs/hostname-mysql.crt' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes I think I have the serviceadmin role: $ ipa role-show it specialist Role name: IT Specialist Description: IT Specialist Member groups: admins Privileges: Host Administrators, Host Group Administrators, Service Administrators, Automount Administrators The account is member of group admins. What am I doing wrong? Thanks! -- Groeten, natxo It seems you hit the same issue as Michael. See my response: https://www.redhat.com/archives/freeipa-users/2014-September/msg00256.html You will need to 1) Create host `domainname` 2) Create services * mysql/`hostname` * mysql/`domainname` 3) Run ipa service-add-host mysql/`domainname` --host mysql/`hostname` 4) Resubmit certificate It looks like we need to do better in documentationerror message... Oh and BTW, this only works with FreeIPA 4.0+, details in ticket https://fedorahosted.org/freeipa/ticket/3977. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] freeipa server install fails on fedora 20
On 09/09/2014 05:27 PM, Olga Kornievskaia wrote: On Tue, Sep 9, 2014 at 10:41 AM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Olga Kornievskaia wrote: On Mon, Sep 8, 2014 at 7:41 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com mailto:d...@redhat.com mailto:d...@redhat.com wrote: On 09/08/2014 07:29 PM, Olga Kornievskaia wrote: Thank you very much for your quick reply. It is a brand new fedora 20 vm. OK good. Can you send or share the ipa server installation log? Can you please suggest how I can do that? My original post was rejected by the administrator of this list because I've included the install log that compressed was over 5M. If you have a web/ftp server available you can put it there for download. I have put the files in google drive and they should be accessible via this link: freeipa-install-logs - https://drive.google.com/folderview?id=0B7NX-2naBL7GWXVIOS11YnZLZWMusp=sharing Please let me know if there are problems accessing it. I'd look at the catalina.* logs in /var/log/pki/pki-tomcat and debug in the ca subdirectory. Those are more likely to hold startup failures. I have included the debug, ca-spawn, and snippet of journalctl output files. Personally, I wasn't able to find any error messages in there. Thank you. I saw no updates to this thread - did you make any progress? I also did not see any obvious errors in the logs you provided. To see what happened I think you would need to zip whole /var/log/pki/pki-tomcat directory and share it with us. We may be also interested to see /var/log/httpd/error_log as it may also contain some hint why is this responder not available. It would be also nice to look for SELinux errors if you are running in enforcing mode. You can check for example with # ausearch -m AVC -ts today I am CCing PKI developers to be aware of this failure. HTH, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA Version 3.0.0 Allow Self-Signed Certificates
On 09/09/2014 06:01 PM, Eric Hart wrote: I'm trying to find a way to enable FreeIPA to allow Self-Signed Certificates. I haven't found a way to enable that capability yet.. I've manually edited configuration files within /etc/dirsrv/slapd-EXAMPLE-COM, specifically the nsslapd-ssl-check-hostname, nsslapd-validate-cert options set to off and warn respectively. Not allowing self-signed certificates has caused me to not be able to establish a replicated server or integrate a device for SSO that provides a self signed certificate. Thanks for any input or insight, Eric I do not entirely understand the use case. So you want to run FreeIPA without CA, with httpd+dirsrv running with self-signed certificates or you want FreeIPA CA to issue a self signed certificate for your service (which does not make much sense to me)? BTW relevant training material: http://www.freeipa.org/images/b/b3/FreeIPA33-blending-in-a-certificate-infrastructure.pdf HTH, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] json api docs
On 09/11/2014 02:06 AM, Dmitri Pal wrote: On 09/10/2014 07:10 PM, Tamas Papp wrote: hi All, Is there an offficial API documentation available? Unfortunately not much. You can search archives and find some recommendations that helped people in the past. https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html We also have a ticket https://fedorahosted.org/freeipa/ticket/3129 We also have a ticket https://fedorahosted.org/freeipa/ticket/4233 targeted on FreeIPA 4.1 to see the actual JSON queries that ipa command sends. It would make it easier to see how we use the API. Also is there a simple way to logon and run commands through API without a kerberos ticket? Once you authenticated with Kerberos and negotiated GSSAPI the server will issue a cookie that will be stored on the client and can be used to continue operations. But Kerberos is needed for the first connection. It is a requirement because it is a best practice. Thanks, tamas -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Max life set 0 already but still promot admin rese tpassword every 3 months
On 09/12/2014 01:22 PM, Petr Spacek wrote: On 12.9.2014 13:18, Dmitri Pal wrote: On 09/12/2014 07:13 AM, Dmitri Pal wrote: On 09/12/2014 12:13 AM, barry...@gmail.com wrote: Hi: i set max life no expiry already but still pomt reset password every 3 month any idea to disable it ??? what happening Regards Where/how did you set it and what version do you run? AFAIR the recommendation to set it to beginning of the last year of the 32 bit time epoch. The original implementation of the Unix operating system stored system time as a 32-bit signed integer representing the number of seconds past the Unix epoch: midnight UTC, 1 January 1970. This value will roll over on *19 January 2038*. Kerberos still uses 32 time. So set it to Jan 1 2038. It is the best approximation of never. I think if you set it to 0 it assumes the default which is 90 days. This sounds like matter for a small improvement ticket. It could at least print warning that 0 = default = 90 days. We have that RFE ticket filed already: https://fedorahosted.org/freeipa/ticket/2795 Please add yourself to CC to show interest in the change + get updates (or even send a patch! :-) Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] json api docs
On 09/12/2014 03:36 PM, Tamas Papp wrote: On 09/12/2014 02:47 PM, Martin Kosek wrote: On 09/11/2014 02:06 AM, Dmitri Pal wrote: On 09/10/2014 07:10 PM, Tamas Papp wrote: hi All, Is there an offficial API documentation available? Unfortunately not much. You can search archives and find some recommendations that helped people in the past. https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html We also have a ticket https://fedorahosted.org/freeipa/ticket/3129 We also have a ticket https://fedorahosted.org/freeipa/ticket/4233 targeted on FreeIPA 4.1 to see the actual JSON queries that ipa command sends. It would make it easier to see how we use the API. Actually what is the recommended way to use ipa as a simple ldap backend for a service without kerberos? In fact the service does not need kerberos and things like that, but I like the helper tools of ipa, like ipa command, web UI, easy replication etc. Can I make trouble by writing the directory directly though ldap (add/delete/modify users + groups). 10x tamas You can of course use FreeIPA only as an LDAP backend to your app, even though Kerberos brings many advantages - but this is not what you asked :-) If you are lucky and you set all the attributes correctly, you could add users via ldapadd. But we do not recommend it as one can easily miss some change, attribute or objectclass that ipa command does and other tool expects. So using the API or ipa tool itself is a recommended way of communication. However, note that we have a work in progress exactly on this feature, i.e. an ability to add users via LDAP protocol and then have them processed by ipa tools adding all required attributes and stuff. See tickets https://fedorahosted.org/freeipa/ticket/3813 https://fedorahosted.org/freeipa/ticket/4445 and design page http://www.freeipa.org/page/V4/User_Life-Cycle_Management This work is planned for FreeIPA 4.2. Martin Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Replication stopped working
On 09/04/2014 05:11 PM, Guillermo Fuentes wrote: Hello list, We’re running FreeIPA with a master and 3 replicas. The replication stopped working and currently we’re adding resources only to the master. This is the environment we have: m1: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 CA: pki-ca-9.0.3 # ipa-replica-manage list -v `hostname` m2.example.com: replica last init status: None last init ended: None last update status: 49 - LDAP error: Invalid credentials last update ended: None m3.example.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-04 14:28:44+00:00 m4.example.com: replica last init status: None last init ended: None last update status: -2 - LDAP error: Local error last update ended: None m2: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: -1 Incremental update has failed and requires administrator actionLDAP error: Can't contact LDAP server last update ended: 2014-09-03 22:53:21+00:00 m3: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-04 14:31:51+00:00 m4: OS: CentOS release 6.5 FreeIPA: 3.3.3-28 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: 49 Unable to acquire replicaLDAP error: Invalid credentials last update ended: None Note that although m3 reports “Incremental update succeeded”, users created on m1 are not replicated to m3, and users created on m3 are not replicated back to m1. We’ve tried different things including re-initializing m2. Can somebody point me in the right direction to get replication going again? Thanks in advance! Guillermo Hello, I think we would need more troubleshooting information that are available in /var/log/dirsrv/slapd-EXAMPLE-COM/errors, especially on m2, m3, m4. Few pointers what I would try myself: 1) Check that all masters have time synced (difference in matter of seconds is OK) 2) Check that DNS is all right - all replicas can resolve master's forward and reverse address. Master can resolve all replicas forward and reverse address. This is common source of replication/Kerberos errors (http://www.freeipa.org/page/Troubleshooting#Kerberos_does_not_work) The error Can't contact LDAP server may point to DNS issues. 3) Check that you can do plain ldapsearch from replica to master. Ideally even authenticated with keytab from /etc/dirsrv/ds.keytab HTH, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa user-find finds user but ipa user-del fails
On 09/04/2014 10:31 PM, Ron wrote: So I tried to delete an entry on IPA01 without success: [root@ipa01 ~]# ldapdelete -D uid=admin,cn=users,cn=accounts,dc=,dc=abc,dc=ca -W -x cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=,dc=abc,dc=ca Enter LDAP Password: ldap_delete: Server is unwilling to perform (53) additional info: Deleting a managed entry is not allowed. It needs to be manually unlinked first Same problem if I try to use ldapmodify: [root@ipa01 ~]# ldapmodify -D uid=admin,cn=users,cn=accounts,dc=,dc=abc,dc=ca -W -x Enter LDAP Password: dn: cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=,dc=abc,dc=ca changetype: modrdn newrdn: uid=19000 deleteoldrdn: 0 modifying rdn of entry cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=,dc=abc,dc=ca ldap_rename: Server is unwilling to perform (53) additional info: Renaming a managed entry is not allowed. It needs to be manually unlinked first. (19000 is just an unused uid) Would this be because of the private group associated with the user? Exactly. How do I unlink the entry? Would I use the following? ipa group-detach userxyz You would normally use it, but I am not sure it would work given that group DN is changed with the nsuniqueid RDN. However, you can manually detach the group with ldapmodify: $ kinit admin $ ipa group-show fbar --all --raw dn: cn=fbar,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test cn: fbar description: User private group for fbar gidnumber: 8264 ipaUniqueID: 2fbdbdd2-34c7-11e4-a98a-001a4a2221bf mepManagedBy: uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test objectClass: posixgroup objectClass: ipaobject objectClass: mepManagedEntry objectClass: top $ ldapmodify -Y GSSAPI -h `hostname` SASL/GSSAPI authentication started SASL username: ad...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. dn: cn=fbar,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test changetype: modify delete: objectClass objectClass: mepManagedEntry - delete: mepManagedBy mepManagedBy: uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test modifying entry cn=fbar,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test Now the ldapdelete on group should work. Thanks again for all your help! -Ron On 09/04/2014 02:48 AM, Martin Kosek wrote: Ah, ok. As Rob advised, you will need to delete it via ldapdelete CLI or via any LDAP GUI application of choice. BTW, this is upstream ticket tracking better means to resolve replication conflicts: https://fedorahosted.org/freeipa/ticket/1025 Martin On 09/03/2014 10:44 PM, Ron wrote: By the way, all three replica servers show the same: [root@ipa]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca [root@ipa01]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca [root@ipa02]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Replication stopped working
Good to hear Guillermo, I am glad you are back up and running. I am just curious, what as the root cause of your replication errors in the end? I did not catch that from the thread. Is it something we can fix in FreeIPA or is it just a configuration error? Thanks, Martin On 09/05/2014 08:06 PM, Guillermo Fuentes wrote: Update: m2 and m3 are now in sync! After making sure ldapsearch was working both ways (m1=m2 and m1=m3) using the server's keytabs (/etc/dirsrv/ds.keytab) for getting the ticket, I re-initialize both replicas and they were able to get updated: @m2 # ipa-replica-manage re-initialize --from m1.example.com @m3 # ipa-replica-manage re-initialize --from m1.example.com Thanks so much for your hint Martin! -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Search Base issues
Ok, thanks. Good to see it is working for you.
I see you actually do authorization decision based on Schema Compatibility
plugin :) Note that an alternate, preferred way of doing authorization in
FreeIPA though is HBAC where you would configure which group of users can login
to which machines.
But this is only being enforced when SSSD is on the client machine, so it may
not be working for all your machines.
Martin
On 09/03/2014 10:45 PM, Chris Whittle wrote:
Success here is my LDIF if anyone needs to do this with a MAC
dn: cn=Mac Users, cn=Schema Compatibility, cn=plugins, cn=config
objectClass: top
objectClass: extensibleObject
cn: Mac Users
schema-compat-search-base: cn=users,cn=accounts,dc=DOMAIN,dc=com
schema-compat-search-filter:
((objectClass=posixaccount)(memberOf=cn=canlogin,cn=groups,cn=accounts,dc
DOMAIN,dc=com))
schema-compat-container-group: cn=compat,dc=DOMAIN,dc=com
schema-compat-container-rdn: cn=canlogin
schema-compat-entry-rdn: cn=%{cn}
schema-compat-entry-attribute: objectclass=inetOrgPerson
schema-compat-entry-attribute: objectclass=posixAccount
schema-compat-entry-attribute: gecos=%{cn}
schema-compat-entry-attribute: cn=%{cn}
schema-compat-entry-attribute: uid=%{uid}
schema-compat-entry-attribute: uidNumber=%{uidNumber}
schema-compat-entry-attribute: gidNumber=%{gidNumber}
schema-compat-entry-attribute: loginShell=%{loginShell}
schema-compat-entry-attribute: homeDirectory=%{homeDirectory}
On Wed, Sep 3, 2014 at 1:04 PM, Chris Whittle cwhi...@gmail.com wrote:
Thanks Rob for the explanation!
I think I have it working, I just have to test a machine and verify.
On Wed, Sep 3, 2014 at 12:47 PM, Rob Crittenden rcrit...@redhat.com
wrote:
Chris Whittle wrote:
That worked, but having issues get it to work with the OSX Directory
Utility.
I'm wondering if it's because when you go against the OU normally it's
returning more info about the user versus what's being returned from the
compat view I'm going to experiment with the attributes it's returning
and see if that's it.
I'm also wondering why FreeIPA doesn't support multiple OU's natively,
this would be so much easier with multiple OUs (one for my non-users and
one for my users)
Because they are so very often used really, really poorly, resulting in
having to move entries around a lot with no real technical reason behind
it. Think about the number of times an IT department gets renamed, oops,
today they are called Global Support Services, oh no, didn't you hear,
now they are ... Each one requiring an entire subtree move. Where the
users exist in LDAP does not generally need to reflect the
organizational structure.
Your case is a bit different from most, where you want to host two
completely separate kinds of users.
rob
On Wed, Sep 3, 2014 at 9:10 AM, Martin Kosek mko...@redhat.com
mailto:mko...@redhat.com wrote:
On 09/03/2014 03:08 PM, Rob Crittenden wrote:
Martin Kosek wrote:
On 09/03/2014 09:02 AM, Martin Kosek wrote:
In the meantime, you can use the workaround that Rob sent, you
would just need
to delete it again when the fix is in, so that the permissions
do not step on
each other.
Actually, wait a minute. I think Rob's ACI example may be too
wide, it may
expose any attribute in the compat tree, including a potential
userPassword.
The ACI was on his custom cn=canlogin subtree, not all of
cn=compat.
As I see, it seems that slapi-nis plugin do not fortunately
expose that, but it
is safer to just list the attributes that one wants to display
(this is also
what we did in FreeIPA 4.0, no global wildcard allowing ACIs any
more).
I added a respective permission via Web UI (one part of it cannot
be added via
CLI, see https://fedorahosted.org/freeipa/ticket/4522) and
compat
tree now
works for me. See attached example.
Resulting permission shown in CLI:
# ipa permission-show TEMPORARY - Read compat tree
Permission name: TEMPORARY - Read compat tree
Granted rights: read, search, compare
Effective attributes: cn, description, gecos, gidnumber,
homedirectory,
loginshell, memberuid,
objectclass, uid, uidnumber
Bind rule type: all
Subtree: dc=mkosek-fedora20,dc=test
ACI target DN: cn=compat,dc=mkosek-fedora20,dc=test
It is much easier to manipulate than ACI added via ldapmodify.
I see you filed a bug on the missing CLI option. That's why I did
the
ACI, because I couldn't demonstrate how to add this ACI on the
CLI. I
hadn't gotten around to doing that last night.
rob
Right. Surprisingly, the option was available in Web UI, thus the
Web UI
screenshot I attached to the thread :) But we have the CLI option
fixed
already, will be part
Re: [Freeipa-users] ipa user-find finds user but ipa user-del fails
Ah, ok. As Rob advised, you will need to delete it via ldapdelete CLI or via any LDAP GUI application of choice. BTW, this is upstream ticket tracking better means to resolve replication conflicts: https://fedorahosted.org/freeipa/ticket/1025 Martin On 09/03/2014 10:44 PM, Ron wrote: By the way, all three replica servers show the same: [root@ipa]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca [root@ipa01]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca [root@ipa02]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca On 09/03/2014 12:26 PM, Rob Crittenden wrote: Ron wrote: And here is the result of the user-show command: [root@ipa slapd-pxxx-abc-CA]# ipa user-show --all --raw phys210e ipa: ERROR: phys210e: user not found Sorry, thinko on my part. Do ipa user-find --all --raw --login phys210e user-show is going to have the same issue as user-delete. rob On 09/03/2014 10:43 AM, Rob Crittenden wrote: Martin Kosek wrote: Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL operation and see what was the error code that DS gave when it refused to delete the user? Were I to guess the issue is that this is a replication conflict entry. If you do: # ipa user-show --all --raw phys210e |grep dn: It will likely begin with nsuniqueid=hex, ... The reason it can be found and not deleted is we create the dn to be removed, we don't search for it. So the user uid=phys210e,cn=users,... etc doesn't exist but the user nsuniqueid=hex ... does. You'll need to use ldapmodify or ldapdelete to remove the entry though I'd check your other masters to see what the state of the user is there. rob Martin On 09/03/2014 06:18 PM, Ron wrote: user-find sees a user but user-del cannot remove it. What can I do? Thanks. Regards, Ron [root@ipa]# ipa user-find --login phys210e -- 1 user matched -- User login: phys210e First name: Testing Last name: Phys210 Home directory: /home2/phys210e Login shell: /bin/bash Email address: phys2...@pxxx.abc.ca UID: 15010 GID: 15010 Account disabled: False Password: True Kerberos keys available: False Number of entries returned 1 [root@ipa]# ipa user-del phys210e --continue --- Deleted user --- Failed to remove: phys210e [root@ipa]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) [root@ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-37.el6.i686 ipa-pki-common-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-129.el6_5.4.i686 ipa-server-selinux-3.0.0-37.el6.i686 python-iniparse-0.3.1-2.1.el6.noarch libipa_hbac-python-1.9.2-129.el6_5.4.i686 ipa-server-3.0.0-37.el6.i686 ipa-python-3.0.0-37.el6.i686 ipa-client-3.0.0-37.el6.i686 389-ds-base-libs-1.2.11.15-33.el6_5.i686 389-ds-base-1.2.11.15-33.el6_5.i686 -- Ron Parachoniak Systems Manager, Department of Physics Astronomy University of British Columbia, Vancouver, B.C. V6T 1Z1 Phone: (604) 838-6437 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Filters in bind-dyndb-ldap
Actually, FreeIPAbind-dynd-ldap use idnszoneactive attribute (TRUE/FALSE) to define which zones are active and which are not. On 09/04/2014 02:23 PM, Chris Whittle wrote: Look at nsaccountlock if it's TRUE then they are disabled. On Thu, Sep 4, 2014 at 7:20 AM, Sebastian Leitz sebastian.le...@etes.de wrote: Hello, I am trying to use bind-dyndb-ldap to connect my BIND to an LDAP server for zones. I have a tiny question regarding this and both the project website and the kind people on #freeipa IRC directed me to this list. I hope someone is here who can answer my question. Sorry for intruding if I'm not asking in the correct place. For technical reasons we need to be able to filter zones in LDAP according to some flags, e.g. 'enabled'. Other services usually provide a config option to include LDAP search filters in every query, like ldap_search_filter = (enabled=1) Unfortunately, I can't find anything like this in the README file of bind-dyndb-ldap. Does anybody know of a way to pass a search filter to LDAP? Thanks in advance, Sebastian -- Sebastian Leitz Mail: sebastian.le...@etes.de ETES GmbH Fon : +49 (7 11) 48 90 83 - 14 Gablenberger Hauptstrasse 32 Fax : +49 (7 11) 48 90 83 - 50 D-70186 Stuttgart Web : http://www.etes.de/ Registergericht: Amtsgericht Stuttgart HRB 721182 Geschäftsführender Gesellschafter: Markus Espenhain Sitz der Gesellschaft: Stuttgart USt.-Id.Nr.: DE814767446 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Search Base issues
On 09/03/2014 03:08 PM, Rob Crittenden wrote: Martin Kosek wrote: On 09/03/2014 09:02 AM, Martin Kosek wrote: In the meantime, you can use the workaround that Rob sent, you would just need to delete it again when the fix is in, so that the permissions do not step on each other. Actually, wait a minute. I think Rob's ACI example may be too wide, it may expose any attribute in the compat tree, including a potential userPassword. The ACI was on his custom cn=canlogin subtree, not all of cn=compat. As I see, it seems that slapi-nis plugin do not fortunately expose that, but it is safer to just list the attributes that one wants to display (this is also what we did in FreeIPA 4.0, no global wildcard allowing ACIs any more). I added a respective permission via Web UI (one part of it cannot be added via CLI, see https://fedorahosted.org/freeipa/ticket/4522) and compat tree now works for me. See attached example. Resulting permission shown in CLI: # ipa permission-show TEMPORARY - Read compat tree Permission name: TEMPORARY - Read compat tree Granted rights: read, search, compare Effective attributes: cn, description, gecos, gidnumber, homedirectory, loginshell, memberuid, objectclass, uid, uidnumber Bind rule type: all Subtree: dc=mkosek-fedora20,dc=test ACI target DN: cn=compat,dc=mkosek-fedora20,dc=test It is much easier to manipulate than ACI added via ldapmodify. I see you filed a bug on the missing CLI option. That's why I did the ACI, because I couldn't demonstrate how to add this ACI on the CLI. I hadn't gotten around to doing that last night. rob Right. Surprisingly, the option was available in Web UI, thus the Web UI screenshot I attached to the thread :) But we have the CLI option fixed already, will be part of FreeIPA 4.0.2 which will be released very soon. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Password expiration dates are different when being resetted by the (primary) admin and a different admin
Great! Btw +1 for running on IPA 3.3.3, it has much more to offer than RHEL/CentOS 6.x one. Martin On 09/03/2014 06:08 PM, Zip Ly wrote: @Martin Ah that explains everything. We were using centos 6.5 + ipa 3.0.0 Now with a new test setup centos 7 + ipa 3.3.3, it works just as we wanted. Thank all for the help! On Tue, Sep 2, 2014 at 5:19 PM, Martin Kosek mko...@redhat.com wrote: On 09/02/2014 10:42 AM, Zip Ly wrote: @Martin The second admin is my service account. I use this account to communicate with our webapplication (it uses keytab and post/curl json to ipa). I can add users without a problem. But when it comes to changing password, the password is expired immediately. I have only one password policy and that's the 'global_policy'. The --maxlife you mentioned only affect this policy. If I use this service account to change the user password, the policy is ignored just as stated in the ipa wiki. Even if I set the --maxlife to 200, if the password is being resetted by this first admin, then the expire date is set to 90 days or expired immediately by the second admin/service account. That's why I want to know how to change this 90 days and also apply it for the service account. What version of FreeIPA do you use? Maybe you are hitting https://fedorahosted.org/freeipa/ticket/3968 that we fixed in FreeIPA 3.3.3. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa user-find finds user but ipa user-del fails
Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL operation and see what was the error code that DS gave when it refused to delete the user? Martin On 09/03/2014 06:18 PM, Ron wrote: user-find sees a user but user-del cannot remove it. What can I do? Thanks. Regards, Ron [root@ipa]# ipa user-find --login phys210e -- 1 user matched -- User login: phys210e First name: Testing Last name: Phys210 Home directory: /home2/phys210e Login shell: /bin/bash Email address: phys2...@phas.ubc.ca UID: 15010 GID: 15010 Account disabled: False Password: True Kerberos keys available: False Number of entries returned 1 [root@ipa]# ipa user-del phys210e --continue --- Deleted user --- Failed to remove: phys210e [root@ipa]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) [root@ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-37.el6.i686 ipa-pki-common-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-129.el6_5.4.i686 ipa-server-selinux-3.0.0-37.el6.i686 python-iniparse-0.3.1-2.1.el6.noarch libipa_hbac-python-1.9.2-129.el6_5.4.i686 ipa-server-3.0.0-37.el6.i686 ipa-python-3.0.0-37.el6.i686 ipa-client-3.0.0-37.el6.i686 389-ds-base-libs-1.2.11.15-33.el6_5.i686 389-ds-base-1.2.11.15-33.el6_5.i686 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Password expiration dates are different when being resetted by the (primary) admin and a different admin
On 09/02/2014 10:42 AM, Zip Ly wrote: @Martin The second admin is my service account. I use this account to communicate with our webapplication (it uses keytab and post/curl json to ipa). I can add users without a problem. But when it comes to changing password, the password is expired immediately. I have only one password policy and that's the 'global_policy'. The --maxlife you mentioned only affect this policy. If I use this service account to change the user password, the policy is ignored just as stated in the ipa wiki. Even if I set the --maxlife to 200, if the password is being resetted by this first admin, then the expire date is set to 90 days or expired immediately by the second admin/service account. That's why I want to know how to change this 90 days and also apply it for the service account. What version of FreeIPA do you use? Maybe you are hitting https://fedorahosted.org/freeipa/ticket/3968 that we fixed in FreeIPA 3.3.3. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA bind also-notify behavior.
On 09/01/2014 07:50 AM, Dmitri Pal wrote:
On 08/29/2014 09:32 PM, Matthew Sellers wrote:
Hi Everyone!
I am using FreeIPA 3.3.5 on Fedora 20 and attempting to configure FreeIPA to
send notifies to non-IPA slaves, but it seems broken on IPA ( notify packets
are never sent to to slaves ).
I have configured also-notify { nameserverip; }; in named.conf on my FreeIPA
test host in the options section and watched for notify traffic with tcpdump.
This document suggests that this is supported, and this is something I have
used in non-IPA bind servers with no issues.
https://fedoraproject.org/wiki/QA:Testcase_freeipav3_dns_zone_transfer
I wanted to ask the list before I file a bug with more details. Is anyone
using this bind feature on IPA with any success?
Thanks!
Matt
The DNS level change propagation is not supported between IPA replicas instead
it uses LDAP replication to propagate the changes.
If you want another non IPA DNS server to be a slave then you can do it. See
http://www.freeipa.org/page/V3/DNS_SOA_serial_auto-incrementation for more
information.
I thought that from F20, bind-dyndb-ldap was capable of native DNS operations
like AXFR/IXFR which can be used to actually deploy slave DNS servers. I wonder
if also-notify is something different. CCing Petr Spacek to advise.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Password expiration dates are different when being resetted by the (primary) admin and a different admin
On 08/29/2014 10:21 AM, Zip Ly wrote: @Martin 1) Yes, I did executed 8.5.3 from the wiki. Is this is reason for the systems behaviour? Yes. if so why doesnt't it applies for both admins? Because only a DN of the first admin was added. It applies only to objects bound with this DN then. And it doesn't explain the 90 days, because it is not set in the tutorial. 90 days is the password policy defined password maximum life. You can check with ipa pwpolicy-show [group]. This value is not defined in cn=ipa_pwd_extop,cn=plugins,cn=config, thus not present in the docs. Unless some params are left out of the wiki for some reason. I'm using windows LDAP admin tool to browse the LDAP tree, but couln't find this param/value so I wasn't sure if the new setting is being used. I did get a confirmation while executing the change. To set the the max password life, use ipa pwpolicy-mod --maxlife $LIFE command (or Web UI). @Dimitri 1) Yes, there are no problems with changing your own password. There is only something strange with the expiration lifetime when you are changing other users (admin or non-admin) password. The expiration lifetime of a password reset should be equal to BOTH admins like expired immediately, 90 days or the value that is set in the password policy. I prefer the value in a password policy, because this way I have it more under control. @Martin @Will 1b) Ok, I'm afraid you may say that. Most free clients like gmail, hotmail, ebay, paypal doesn't require a password reset from time to time (yes they may have set a very high value). So I was wondering why it isn't possible. I know it's bad for security, but still. I think the solution is to: 1) Change the password policy to a very high value (even in years), as Will suggested in this thread. 2) Use service accounts (service-add) with keytabs for services which do not need to change their passwords, given they authenticate with keytab which does not suffer from password complexity issues. 3) Contribute to FreeIPA and make --maxlife 0 or similar mean unlimited validity (https://fedorahosted.org/freeipa/ticket/2795) :-) On Thu, Aug 28, 2014 at 6:18 PM, Dmitri Pal d...@redhat.com wrote: On 08/28/2014 04:18 PM, Zip Ly wrote: Hi, I'm trying to change a user password without reset. If I use the (primary) admin to change the password then it doesn't need a password reset, because the expire lifetime is 90 days. But if I create a second admin, then every password change made by the second admin needs a password reset, because the password is expired immediately. 1a) Does anyone knows how I can change the policy/privilege of the second admin so every password change doesn't require a reset? 1b) and is it possible to set a different expire lifetime like zero for unlimited lifetime? You are probably changing password for the admin himself. Isn't there a different flow when admin changes his own password? It's almost the same bugreport as https://fedorahosted.org/freeipa/ticket/2795 but the difference is there should be 2 policies: one for changing your own password and another for resetting other users password. 2) Are there more differences in policies between the first (primary) admin and the second admin you just created? Kind regards, Zip -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Password expiration dates are different when being resetted by the (primary) admin and a different admin
On 08/28/2014 04:18 PM, Zip Ly wrote: Hi, I'm trying to change a user password without reset. If I use the (primary) admin to change the password then it doesn't need a password reset, because the expire lifetime is 90 days. This is strange. Did you by any chance added this admin's account DN to passSyncManagersDNs setting in ipa_pwd_extop plugin? http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/pass-sync.html#password-sync But if I create a second admin, then every password change made by the second admin needs a password reset, because the password is expired immediately. Right, this is done on purpose: http://www.freeipa.org/page/New_Passwords_Expired 1a) Does anyone knows how I can change the policy/privilege of the second admin so every password change doesn't require a reset? See docs link above. But note it is a hack and we discourage it for reasons written in the wiki link above. 1b) and is it possible to set a different expire lifetime like zero for unlimited lifetime? No (for security reasons). It's almost the same bugreport as https://fedorahosted.org/freeipa/ticket/2795 but the difference is there should be 2 policies: one for changing your own password and another for resetting other users password. Administrative password change is only subject to max password life time part of the password policy AFAIR. Thus it already uses 2 different standards for these password changes (e.g. password length is not enforced for administrative password change). 2) Are there more differences in policies between the first (primary) admin and the second admin you just created? There should not be. All members of admins groups should be equal in rights. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Migration works on 3 but not 4?
On 08/27/2014 07:47 AM, Kat wrote: Hi all... Migrating from Open LDAP and it works fine to FreeIPA to 3.x but 4.x I get migration errors? /Constraint violation: invalid password syntax - passwords with storage scheme are not allowed/ I did find one reference to this in the archives, but it references 389-ds 1.3.2.20 and i am running 1.3.2.22, so am I missing something? ~K Hello Kat, You are exactly on spot. This problem is caused by 389-ds-base not allowing hashed password, you can find details in https://fedorahosted.org/freeipa/ticket/4450 This *was* fixed with DS 1.3.2.20. Unfortunately, there was a security update in the DS and it had to be based on 1.3.2.19 again and versioned 1.3.2.22 (i.e. without the fix for 4450). Noriko, what are the time plans regarding a release of the DS based on 1.3.2.20 + the security update? Thanks, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Installing a new Cert
Thanks for sharing your (rather painful) experience, I am glad you made it working in the end. Just note that we are currently (read FreeIPA 4.0.x and FreeIPA 4.1) working making the cert operations in the installers smoother so that after so that people like you would have much easier job. Martin On 08/26/2014 05:19 PM, Chris Whittle wrote: This actually died after restart so I ended up starting over... So here is the process I did that looks like it works and also survives restart Step 1 - Before install http://stackoverflow.com/questions/23374894/mod-nss-with-apache-public-certificate-issue?noredirect=1#comment36504881_23374894-- start at Convert crt file in PEM format and do that whole section completely Step 2 - Install IPA server using the p12 file from before and also the intermediate.crt from your provider (I'm not sure why this isn't documented anywhere but I found it in my searches) ipa-server-install --http_pkcs12 DOMAIN.COM.p12 --dirsrv_pkcs12 collectivebias.com.p12 --root-ca-file intermediate.crt Step 3 - re add certs (for some reason I don't know but it's needed) (from http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP) ipa-server-certinstall -w --http_pin=PKPASSWORD DOMAIN.COM.p12 ipa-server-certinstall -d --dirsrv_pin=PKPASSWORD DOMAIN.COM.p12 Step 4 reboot Step 5 You can dance if you wanna... On Mon, Aug 25, 2014 at 2:02 PM, Chris Whittle cwhi...@gmail.com mailto:cwhi...@gmail.com wrote: I spoke a little too soon... It's working fine (browser is using new cert and also ldaps is using the new cert) except when you go to the certs page on the ui. https://DOMAIN/ipa/ui/#/e/cert/search An error has occurred (IPA Error 4301: CertificateOperationError) Certificate operation cannot be completed: Unable to communicate with CMS (Internal Server Error) On Mon, Aug 25, 2014 at 1:34 PM, Chris Whittle cwhi...@gmail.com mailto:cwhi...@gmail.com wrote: ok I think I got it again... If anyone is looking for this here is the answer that worked for me 1. Here are the steps 1. http://stackoverflow.com/questions/23374894/mod-nss-with-apache-public-certificate-issue?noredirect=1#comment36504881_23374894 -- start at Convert crt file in PEM format and do that whole section completely 2. Then with the p12 from above you get do this (skip the line about generating a new one) http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP 1. If you run across the error /etc/ipa/ca.crt contains more than one certificate you will need to go into /etc/ipa/ca.crt, back it up and then try removing one of the certs and try ipa-server-certinstall from above again (if it doesn't work revert ca.crt to the original and then remove the other) 3. Then restart the both instances (bottom of the freeipa link) and you should be good to go. On Mon, Aug 25, 2014 at 8:45 AM, Chris Whittle cwhi...@gmail.com mailto:cwhi...@gmail.com wrote: I found this but I think it's just IPA certs? http://www.freeipa.org/page/V4/CA_certificate_renewal Basically I want to use my existing wildcard cert for https and ldaps... I did this on my 3.3 install on CentOS but now I'm on a 4 install on Fedora Core. Any help would be more than appreciated! Thanks! On Mon, Aug 25, 2014 at 6:24 AM, Chris Whittle cwhi...@gmail.com mailto:cwhi...@gmail.com wrote: I have 4 installed and I get it when I try to generate the pk12 On Aug 25, 2014 3:50 AM, Jan Cholasta jchol...@redhat.com mailto:jchol...@redhat.com wrote: Hi, Dne 25.8.2014 v 03:04 Chris Whittle napsal(a): Trying to do this http://www.freeipa.org/page/__Using_3rd_part_certificates___for_HTTP/LDAP http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP And I keep getting Error unable to get local issuer certificate getting chain. Where are you getting this error? ipa-server-certinstall, or httpd, or somewhere else? What version of ipa do you have installed? I'm wondering if it's because of this from the doc The certificate in mysite.crt must be signed by the CA used when installing FreeIPA. but it might not either... In this case you should get a file.p12 is not
Re: [Freeipa-users] Ubuntu 3.3.x client vs. 3.0.0 server
On 08/22/2014 10:41 PM, Michael Lasevich wrote: Trying to use ipa command line admin tools from Ubuntu 14.04 box against 3.0.0 CentOS 6 server and running into trouble. Seems like upgrading server is not an option without upgrading the server, and 3.3.0 client is not compatible with 3.0.0 server (seems to be sending invalid fields to the server in api) I cannot seem to easily find a way to get 3.0 client on ubuntu not do I see any pre-made 3.0 deb packages. Any suggestions? Thanks, -M Please see http://www.freeipa.org/page/Client#Compatibility which describes our current compatibility constrains for ipa tool. TLDR; your 3.3 clients should work just fine regarding to FreeIPA services (identity, authentication, authorization, sudo, ...). But when you want to use the ipa tool, you would either need to use the one on the FreeIPA server or use one from other CentOS 6 FreeIPA client (or use the Web UI). Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] sudo with freeIPA
On 08/25/2014 12:51 PM, Megan . wrote: Good Morning, I'm very new to freeIPA. Welcome on board! I'm running centOS 6.5 with freeIPA v3 I have the freeIPA server up but i'm working on getting SUDO configured. Currently i'm having problems getting sudo commands to work on the client. I'm a bit unclear if i have everything configured correctly. The only thing that I can figure out might be an issue, is when i try the sudo command i see a filter search with objectclass=sudoRule but when i check the ldap server it has objectclass=sudoRole, so there are no results. According to http://www.sudo.ws/sudoers.ldap.man.html the objectclass in the schema should really read sudoRole (I know, may be confusing). Any ideas? Thank you in advance for any advice. Where do you see the filter? [tuser2@map1 ~]$ sudo /sbin/iptables -L Enter RSA PIN+token: tuser2 is not allowed to run sudo on map1. This incident will be reported. CLIENT: yum installed libsss_sudo I added nisdomainname dir1.server.example.com to /etc/rc.d/rc.local **still not sure what this is for ** This is for setting the NIS domain permanently. sudo uses NIS domains when it uses sudo rules with host groups instead of individual host names. Created a sudo user on ldap server ldappasswd -x -S -W -h dir1.server.example.com -ZZ -D cn=Directory Manager uid=sudo,cn=sysaccounts,cn=etc,dc=server,dc=example,dc=com ** [root@map1 sssd]# cat /etc/nsswitch.conf # passwd: files sss shadow: files sss group: files sss sudoers:files sss sudoers_debug: 1 #sudoers:files hosts: files dns bootparams: files ethers: files netmasks: files networks: files protocols: files rpc:files services: files sss netgroup: files sss publickey: files automount: files ldap aliases:files [root@map1 sssd]# [root@map1 sssd]# cat sssd.conf [domain/server.example.com] debug_level = 5 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = server.example.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = map1.server.example.com chpass_provider = ipa ipa_server = _srv_, dir1.server.example.com ldap_netgroup_search_base = cn=ng,cn=compat,dc=server,dc=example,dc=com ldap_tls_cacert = /etc/ipa/ca.crt sudo_provider = ldap ldap_uri = ldap://dir1.server.example.com ldap_sudo_search_base = ou=sudoers,dc=server,dc=example,dc=com ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/dir1.server.example.com ldap_sasl_realm = server.example.com krb5_server = dir1.server.example.com [sssd] services = nss, pam, ssh, sudo config_file_version = 2 domains = server.example.com [nss] [pam] [sudo] debug_level=5 [autofs] [ssh] [pac] from the sssd_sudo.log (Mon Aug 25 10:36:31 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [((objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=tuser2)(sudoUser=#107965)(sudoUser=%tuser2)(sudoUser=+*))((dataExpireTimestamp=1408962991)))] (Mon Aug 25 10:36:31 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [((objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=tuser2)(sudoUser=#107965)(sudoUser=%tuser2)(sudoUser=+*)))] (Mon Aug 25 10:36:33 2014) [sssd[sudo]] [client_recv] (0x0200): Client disconnected! I do not understand why it searches with sudorule objectclass. According to sssd-ldap man page, ldap_sudorule_object_class should default to sudoRole. Jakub or Pavel, any idea? [root@dir1 ~]# !ldaps ldapsearch -h dir1.server.example.com -x -D cn=Directory Manager -W -b dc=server,dc=example,dc=com 'objectclass=sudoRole' Enter LDAP Password: # extended LDIF # # LDAPv3 # base dc=server,dc=example,dc=com with scope subtree # filter: objectclass=sudoRole # requesting: ALL # # test, sudoers, server.example.com dn: cn=test,ou=sudoers,dc=server,dc=example,dc=com objectClass: sudoRole sudoUser: megan2 sudoUser: tuser2 sudoHost: map1.server.example.com sudoCommand: /sbin/iptables -L sudoCommand: /home/tuser1/test.sh sudoCommand: test2.sh cn: test # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@dir1 ~]# ldapsearch -h dir1.server.example.com -x -D cn=Directory Manager -W -b dc=server,dc=example,dc=com 'objectclass=sudoRule' Enter LDAP Password: # extended LDIF # # LDAPv3 # base dc=server,dc=example,dc=com with scope subtree # filter: objectclass=sudoRule # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 I do not know the root cause, but Pavel or Jakub will be able to provide help. BTW, FreeIPA 4.0+ enable SUDO via SSSD's sudo provider automatically (https://fedorahosted.org/freeipa/ticket/3358). This functionality will be also available in RHEL-6.6. Martin -- Manage your subscription for the Freeipa-users mailing list:
Re: [Freeipa-users] ipa-client-install via Kickstart in RHEL7
On 08/20/2014 05:24 PM, Rich Megginson wrote: On 08/20/2014 09:18 AM, Baird, Josh wrote: Hi, We are attempting to run ipa-client-install in the %post section of a Kickstart in order to join the host to an IPA domain (3.3/RHEL7 IdM). We are using something like: /usr/sbin/ipa-client-install -w 'one-time-password' --realm=REALM.COM -U --no-ssh --no-sshd --no-ntp --domain=realm.com The machine does indeed join the domain correctly, but the certmonger request fails. Looking at the logs, we can see this: 2014-08-19T15:02:45Z DEBUG Starting external process 2014-08-19T15:02:45Z DEBUG args=/bin/systemctl is-active certmonger.service 2014-08-19T15:02:45Z DEBUG Process finished, return code=0 2014-08-19T15:02:45Z DEBUG stdout= 2014-08-19T15:02:45Z DEBUG stderr=Running in chroot, ignoring request. The error is occurring because the certmonger service fails to start. This is because systemd is not able to manipulate services in a chrooted environment (ala the anaconda installation environment). Prior to systemd, this would work fine as services could start normally via init in a chroot/%post. Additionally, we see the error: Unable to find 'admin' user with 'getent passwd ad...@domain.com' Again, this is because systemd is unable to start sssd in the chrooted installation environment. I'm wondering if anyone else has experienced these issues with systemd unable to start these required services during installation and what you did to work around them. One option would be to move the ipa-client-install out of Kickstart and have Puppet join the host to the domain post-installation (after firstboot), but this isn't really ideal. Any advice or suggestions would be appreciated. Create a file that is run at boot, presumably after networking and certmonger are started. What I saw as the common approach in OpenStack or other projects are scripts and configurations for Cloud-init [1]. Are there people using it for this purpose or are there other (better) approaches? [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/End_User_Guide/user-data.html Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa 2 client connecting to ipa 3 server
On 08/20/2014 09:49 PM, Dmitri Pal wrote: On 08/20/2014 09:43 PM, Rob Crittenden wrote: Walid wrote: Thanks Rob, we have native python2.4, and anaconda python 2.7, so i guess if anything needs python 2.6 or greater it would not be an issue. I am just wondering if there are people using the upstream project in such a legacy system ;-) It's not just python, it's all the modules as well. In the end the issue isn't so much ipa-client as all the related dependencies. The ipa-client package just helps configure things, sssd does all the heavy lifting. If you wanted to backport anything I'd start there, and it is likely extremely non-trivial. I know that people still use RHEL-5 and the current 2.2-based client. It, and its related packages, generally works fine you just miss out on some of the newer features, particularly in sssd (like sudo and autofs). You can try to build sssd on 5.3 but I suspect it will require so many dependencies that you system would look more like a 5.10. You can try but this will be an adventurous effort. For old systems like that we recommend using what they had then and not SSSD. Users will be able to authenticate and posix data will be the same as on the more modern systems which should be sufficient for the needs of those old systems anyways. JFTR, note that you can also authenticate with users from potentially trusted AD domains by using: http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts Preso here: http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIP just stopped starting
On 08/19/2014 11:08 PM, Chris Whittle wrote: Here is what I get if I try to start it manually... Any ideas? [root@itservices /]# /usr/sbin/ipactl start Starting Directory Service Starting dirsrv: COLLECTIVEBIAS-COM... [ OK ] PKI-IPA... [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting MEMCACHE Service Starting ipa_memcached:[ OK ] Starting HTTP Service Starting httpd:[ OK ] Starting CA Service Starting pki-ca: [ OK ] Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Failed to start CA Service Shutting down Stopping Kerberos 5 KDC: [ OK ] Stopping Kerberos 5 Admin Server: [ OK ] Stopping ipa_memcached:[ OK ] Stopping httpd:[ OK ] Stopping pki-ca: [FAILED] Shutting down dirsrv: COLLECTIVEBIAS-COM... [ OK ] PKI-IPA... [ OK ] Aborting ipactl This error is new to me. PKI service start script apparently calls grep function with wrong arguments. CCing Ade and Endi from PKI team to help. What version of PKIIPA are we talking about? Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIP just stopped starting
$ rpm -q freeipa-server if you are running on Fedora. $ rpm -q ipa-server if you are running on RHEL/CentOS. FreeIPA 4.0 later also show version with $ ipa --version or in Web UI. Martin On 08/20/2014 02:54 PM, Chris Whittle wrote: How is the best way to determine the version? On Wed, Aug 20, 2014 at 2:29 AM, Martin Kosek mko...@redhat.com wrote: On 08/19/2014 11:08 PM, Chris Whittle wrote: Here is what I get if I try to start it manually... Any ideas? [root@itservices /]# /usr/sbin/ipactl start Starting Directory Service Starting dirsrv: COLLECTIVEBIAS-COM... [ OK ] PKI-IPA... [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting MEMCACHE Service Starting ipa_memcached:[ OK ] Starting HTTP Service Starting httpd:[ OK ] Starting CA Service Starting pki-ca: [ OK ] Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Failed to start CA Service Shutting down Stopping Kerberos 5 KDC: [ OK ] Stopping Kerberos 5 Admin Server: [ OK ] Stopping ipa_memcached:[ OK ] Stopping httpd:[ OK ] Stopping pki-ca: [FAILED] Shutting down dirsrv: COLLECTIVEBIAS-COM... [ OK ] PKI-IPA... [ OK ] Aborting ipactl This error is new to me. PKI service start script apparently calls grep function with wrong arguments. CCing Ade and Endi from PKI team to help. What version of PKIIPA are we talking about? Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Minimal permissions for joiner account?
On 08/18/2014 09:35 PM, Michael Lasevich wrote: I wanted to use the python ipalib directly, but like you mentioned, I found very little documentation and what I found indicated I was going to just pass cli arguments to it, it seemed to be not much better than calling the wrapper directly :-( I disagree. It *is* vastly better that calling ipa command tool from a subprocess. If not only because you receive proper Python exceptions and results in Python data types instead of having to parse it from the CLI. AFAIK, the only missing piece is the documentation for this API. For now, you need to read the plugins code (takes_options section) or deduce the call option names from CLI option names. ... As far as Host-Enrollment vs Host-Administrators privileges - it may be that I am mixing up 2 ways to enroll hosts. My original attempt was to try to have an enroller account that would add client directly from the client - but I have relented and switched to a more proper method of adding a host entrue with a generated OTP for the client followed by joining of that client from the client itself with the OTP password. This works, but when I try to add host entry with OTP password using account with only Host Enrollment privilege I get: ipa: ERROR: Insufficient access: Insufficient 'add' privilege to the 'userPassword' attribute Ah, so this is the error. What FreeIPA version do you use? This bug was fixed in FreeIPA 4.0: https://fedorahosted.org/freeipa/ticket/4252 Current permissions would still not allow you to add new Hosts with Host Enrollment privilege, one would also need to add System: Add hosts permission, IIUC. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Minimal permissions for joiner account?
On 08/14/2014 10:23 PM, Michael Lasevich wrote: Is there somewhere a documented minimum set of permissions required to create a special role/account/principal to auto-join machines to the domain? I am not all too comfortable to run this as admin user and not quite ready to set up the orchestration needed to pre-join the host. Thanks, -M You can simply create a system user or a joiner service and assign it a Host Administrators privilege: # ipa privilege-show Host Administrators Privilege name: Host Administrators Description: Host Administrators Permissions: add hosts, remove hosts, modify hosts, manage host ssh public keys, manage host keytab, enroll a host, retrieve certificates from the ca, revoke certificate, add krbprincipalname to a host Granting privilege to roles: IT Specialist HTH, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Minimal permissions for joiner account?
This may also be a bug. Host Enrollment privilege should be enough to join FreeIPA. We did many access control related fixes in FreeIPA 4.0 (like https://fedorahosted.org/freeipa/ticket/4252), it may got fixed there. If Host Enrollment permission is still failing for you in 4.0+, we would be interested to see the actual error so that we can fix it. Martin On 08/15/2014 11:27 AM, Michael Lasevich wrote: Thanks, that was actually very helpful. Host Enrollment privilege does not actually allow you to enroll hosts, not sure what that is about. But Host Administrators worked just fine. -M On Fri, Aug 15, 2014 at 1:18 AM, Martin Kosek mko...@redhat.com wrote: On 08/14/2014 10:23 PM, Michael Lasevich wrote: Is there somewhere a documented minimum set of permissions required to create a special role/account/principal to auto-join machines to the domain? I am not all too comfortable to run this as admin user and not quite ready to set up the orchestration needed to pre-join the host. Thanks, -M You can simply create a system user or a joiner service and assign it a Host Administrators privilege: # ipa privilege-show Host Administrators Privilege name: Host Administrators Description: Host Administrators Permissions: add hosts, remove hosts, modify hosts, manage host ssh public keys, manage host keytab, enroll a host, retrieve certificates from the ca, revoke certificate, add krbprincipalname to a host Granting privilege to roles: IT Specialist HTH, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Minimal permissions for joiner account?
On 08/15/2014 11:25 AM, Michael Lasevich wrote: ... The only thing that bugs me is that I am calling IPA python code from my salt reactor python code via subprocess - there has got to be a better, more direct way - but I found documentation too confusing to follow at 1 am - will be a project for another day. Would the example below help? # kinit admin Password for ad...@mkosek-fedora20.test: [root@ipa ~]# python Python 2.7.5 (default, Jun 25 2014, 10:19:55) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux2 Type help, copyright, credits or license for more information. from ipalib import api api.bootstrap(context='exporter', debug=False) api.finalize() api.Backend.rpcclient.connect() ipa: INFO: trying https://ipa.mkosek-fedora20.test/ipa/json hosts = api.Command['host_find']()['result'] ipa: INFO: Forwarding 'host_find' to json server 'https://ipa.mkosek-fedora20.test/ipa/json' for host in hosts: ...print host['fqdn'][0] ... ipa.mkosek-fedora20.test This works with FreeIPA 4.0. For older FreeIPA, you would need to switch rpcclient attribute for xmlclient. I admit we do not have the best developer documentation on how to do that. We plan to do that in the future, so far we were focusing on other things. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Replicating o=ipaca
On 08/13/2014 02:15 AM, Rob Crittenden wrote: Erinn Looney-Triggs wrote: On 08/12/2014 11:49 AM, Rob Crittenden wrote: Erinn Looney-Triggs wrote: The documentation seems to be a little fuzzy on setting up two CAs, some parts indicate this is a bad idea because the CRLs can clobber each other, other parts, such as the migration guide from RHEL 6.5 to 7 seem to indicate that it is ok, albeit maybe that is just for a short time. It isn't a bad idea to stand up clones, you just need to understand that this is one of the rare places where all masters are not equal. One has to be designated as the CRL generator and one as the CA renewal master. These don't have to be the same but it makes sense to keep them together IMHO. The reason to limit CRL generation to one master is the small chance that you could end up with two CRLs with the same serial number but containing different certificates. Remember that a CRL is just a signed snapshot in time of revoked certificates. Similarly for renewal it is vastly easier to do it on one host than try to manage the race condition of them trying to renew at the same time. What I am wondering, because I get a little nervous when all my data for the CA is on one host (backups aside), is whether there is a value, assuming that having two concurrent dogtag instances is a bad thing, to replicating the ipaca data in ldap. Just the data I mean, would it be possible, having just the LDAP data and whatever certs are in the replica file to basically reconstruct a CA? Right, you want at least two CAs for redundancy. Some dogtag guru could probably stand up a new CA using just the LDAP data and the certs but I can't imagine it would be easy, even for them. rob Ok, are there manual steps involved in that or does the --setup-ca on the replica just take care of everything. I certainly hope I am not looking in the wrong place, I just can't seem to find anything definitive in the docs. --setup-ca does it all for you. Dogtag actually handles the creation of the replication agreement so we don't do a lot other than to tell it the remote server and provide the initial certs/keys. You can use ipa-csreplica-manage to view/manage CA replication agreements. rob Also, in case you choose to for example decommission your current CRL generator, you can switch that role to other machine using this HOWTO: http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Adding permissions to a service account.
On 08/13/2014 02:27 AM, William wrote: On Tue, 2014-08-12 at 13:51 -0400, Rob Crittenden wrote: William wrote: Hi, I am trying to allow a radius service account the ability to read ipaNTHash. I carried out the following steps: You can't delegate permissions to a service. See https://fedorahosted.org/freeipa/ticket/3644 rob For now, should I just add the service DN as a member of the role to enable this? Rob used a wrong ticket, this is the one: https://fedorahosted.org/freeipa/ticket/3164 It is currently planned for FreeIPA 4.1. If you are interested in contributing a patch, please feel free to do so, this would be a simple one :-) Anyway, to fix your permission delegation problem, check this: # ipa service-show foo/`hostname` --all --raw | grep dn: dn: krbprincipalname=foo/ipa.mkosek-fedora20.t...@mkosek-fedora20.test,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test # ipa role-show test_role --all --raw | grep dn: dn: cn=test_role,cn=roles,cn=accounts,dc=mkosek-fedora20,dc=test # kinit admin Password for ad...@mkosek-fedora20.test: # ldapmodify -Y GSSAPI SASL/GSSAPI authentication started SASL username: ad...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. dn: cn=test_role,cn=roles,cn=accounts,dc=mkosek-fedora20,dc=test changetype: modify add: member member: krbprincipalname=foo/ipa.mkosek-fedora20.t...@mkosek-fedora20.test,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test modifying entry cn=test_role,cn=roles,cn=accounts,dc=mkosek-fedora20,dc=test # ipa role-show test_role --all --raw ... member: krbprincipalname=foo/ipa.mkosek-fedora20.t...@mkosek-fedora20.test,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test ... Then, the role and assigned privileges/permissions should work for this service. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Trying To Connect FreeIPA with OKTA/OneLogin/Bitium
Thank you! I liked this page to http://www.freeipa.org/page/HowTos#Authentication and also improved formatting of the page. I am not sure about the role section though, we do not use role objectclass, so Okta's search probably returns no results anyway. It may be better to keep that blank IMO. Martin On 08/12/2014 03:46 PM, Chris Whittle wrote: http://www.freeipa.org/page/HowTo/Integrate_With_Okta On Sat, Aug 9, 2014 at 11:31 PM, Dmitri Pal d...@redhat.com wrote: On 08/08/2014 04:26 PM, Chris Whittle wrote: Hey Dimitri, What do you mean? Both of them gave me the same answer and it worked. Right, now you have the knowledge which is burred in a mail thread and would be hard to find for others that might want to follow your steps. I was hoping you would find some time to summarize your setup and experience and share with others via a HOWTO page on the FreeIPA site [1]. [1] http://www.freeipa.org/page/HowTos Thanks Dmitri On Aug 8, 2014 3:25 PM, Dmitri Pal d...@redhat.com wrote: On 08/07/2014 02:21 PM, Chris Whittle wrote: Thanks guys that works! And what about HOWTO? ;-) On Thu, Aug 7, 2014 at 12:22 PM, Lucas Yamanishi lyamani...@sesda3.com wrote: On 08/07/2014 12:18 PM, Chris Whittle wrote: I'm currently working on a trial with OKTA and have installed their server agent with no issues. Now I'm trying to map FreeIPA attributes with OKTA's I'm getting no entries found, which leads me to think I'm missing something [image: Inline image 1] [image: Inline image 2] [image: Inline image 3] Thanks! The objectClass values look incorrect. Try posixAccount and posixGroup for users and groups. Roles are groupOfNames, but that’s a little less specific and will match non-role entries without a search base. You can easily look up raw entries to check your mappings with commands like these (the —all and —raw options are available for all *-show commands, afaik): ipa user-show --all --raw $USER_NAME ipa group-show --all --raw $GROUP ipa role-show --all --raw $ROLE Or pure ldaputils: ldapsearch -LLL -YGSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com' 'uid=$USER_NAME' -- - *question everything*learn something*answer nothing* Lucas Yamanishi -- Systems Administrator, ADNET Systems, Inc. NASA Space and Earth Science Data Analysis (606.9) 7515 Mission Drive, Suite A100 Lanham, MD 20706 * 301-352-4646 * 0xD354B2CB -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] WebUI krbprincipal expiration calendar widegt
On 08/10/2014 01:58 PM, James James wrote: Hello, Is there a way to patch my ipa .3.0.0 with this patch: https://www.mail-archive.com/freeipa-devel@redhat.com/msg20528.html ? The DateTime data type will be very useful ! Regards It would be quite difficult, if not only because of the API versioning problem we have with parallel branches of FreeIPA, like RHEL-6.x/CentOS-6.x is (judging based on your version). There is an upstream ticket filed: https://fedorahosted.org/freeipa/ticket/4427 But I do not think it would help in your case. Especially as this is just a convenience fix, the best advise I can give is either to a) Hack this around in your IPA codebase, making sure that the capability API version is correct b) Live with old string variant c) Upgrade to newer IPA, like 3.3 in RHEL-7.0 or 4.0 in Fedora 20! :-) Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] MinSSF suggestions?
On 08/11/2014 04:24 PM, Jakub Hrozek wrote: On Mon, Aug 11, 2014 at 05:18:03PM +0300, Alexander Bokovoy wrote: On Sat, 09 Aug 2014, Erinn Looney-Triggs wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 It would seem to be prudent to set the minssf setting for 389 to 56, however I am wondering why this isn't done by default, and if there is any reason why I shouldn't do it? Anonymous connection to LDAP wouldn't work. I think we use it for rootdse access when enrolling IPA clients where we don't yet have a CA certificate. I may be wrong, though. Also old (RHEL-5) SSSD versions rely on anonymous access to be able to retrieve rootDSE. Newer (RHEL-6.3+) clients are able to re-try fetching rootDSE once the authenticated connection is established. Also, older FreeIPA clients were not able to join those severs due to bug in ipa-client-install: https://fedorahosted.org/freeipa/ticket/4459 This will be fixed in FreeIPA 4.0.2. Note that this only affects if you are changing MinSSF for whole DS by nsslapd-minssf. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Building previous release rpms are failing
On 08/07/2014 01:39 PM, Curtis L. Knight wrote: On Tue, Aug 5, 2014 at 11:26 PM, Rob Crittenden rcrit...@redhat.com wrote: Curtis L. Knight wrote: On Tue, Aug 5, 2014 at 7:21 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 08/05/2014 12:32 PM, Martin Kosek wrote: On 08/05/2014 12:05 PM, Curtis L. Knight wrote: ... #./make-lint $(LINT_OPTIONS) run 'make rpms' again to get beyond lint errors shown below cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi ./make-lint Traceback (most recent call last): File ./make-lint, line 272, in module sys.exit(main()) File ./make-lint, line 243, in main linter.check(files) File /usr/lib/python2.7/site-packages/pylint/lint.py, line 626, in check self.check_astroid_module(astroid, walker, rawcheckers, tokencheckers) File /usr/lib/python2.7/site-packages/pylint/lint.py, line 712, in check_astroid_module walker.walk(astroid) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 715, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 715, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 712, in walk cb(astroid) File /usr/lib/python2.7/site-packages/pylint/checkers/newstyle.py, line 135, in visit_function args=(call.args[0].name, )) AttributeError: 'Getattr' object has no attribute 'name' make: *** [lint] Error 1 This is new, I created upstream ticket to timely fix it: https://fedorahosted.org/freeipa/ticket/4475 Ticket 4475 is now fixed, thanks to Jan Cholasta. ipa-3-3 branch should now build OK again. Martin Hey Martin, Tested ipa-3-3 and generated rpms from that branch. Many thanks for the resolution. Just a note, but I verified that ipa-3-2 and ipa-3-1 are in need of the same ipa-3-3 dependency patch. Both also complained that make-lint needed pylint installed which it already was. With the lint failure and rhino patch, ipa-3-2 did generate rpms. With the lint failure and rhino patch, ipa-3-1 did not generate rpms and gave the following logs. I guess it becomes a bit fuzzy, especially with these versions. We don't usually offer any guarantees that older releases will build against more modern distros, but both 3.1.5 and 3.2.0 crossed that line, with Fedora builds in two releases (F18/19 and F19/20 respectively). Do you have a requirement to use these older releases or are you just offering this data point in case anyone else runs into this? regards rob Hello Rob, Yes this is additional information and is not any requirement for me. I was not sure which branches were being maintained for F20. My interest was to see if I could help the freeipa developers build rpms easily from git with Docker images/containers. That is just about finished. My next thought was about using a Docker containers to test code from a git working directory quickly. That workflow could be a) to build rpms from a git commit, install the generated rpms or b) push changed code into an existing freeipa installation (probably not recommended but maybe necessary for testing). I did read a couple of places that it seems to take less time and or RAM to build code within Docker then other methods. Overall there does not seem to be enough people that are doing it yet for a lot of data points. Does any of that sound beneficial to the team? Regards, Curtis Your efforts do sound interesting for the development team. I would like to encourage you to send your results to the freeipa-devel list, so that developers can give you proper feedback. I was already pondering whether containers could be utilized for our integration tests: http://www.freeipa.org/page/Testing#Integration_tests Currently, we use full VMs and that is obviously not so fast. If containers could be utilized, things could get much faster (I hope). Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica Cert failed to renew ...
Right, the processing route may not seem obvious. certmonger uses the server from /etc/ipa/default.conf. This server does not necessarily need to also run CA, we count with that option. When certmonger wants to renew or request a certificate, it calls cert-request API call on that server. The API call calls Dogtag backend which checks if the server is a CA powered IPA. If it is not, it picks any other master where CA *is* installed and connects that for the certificate operation. Check _select_any_master in ipaserver/plugins/dogtag.py if you are interested about the code. Does that help? Martin On 08/06/2014 12:16 AM, Matt Bryant wrote: Hmmm so question here .. our domain was originally installed as a 2.x and upgraded to 3.x .. I installed the replicas using the ipa-replica-prepare etc but the CA dirsrv instance was never copied over or started on the replicas (ie no slapd-PKI-* around) .. yet /etc/ipa/defaults.conf points to the replica itself for certmonger - so not sure how that will work given there is no CA copy running on the replica .. In the end the process followed was to change the xmlrpc_uri to the original master and delete and resubit the cert request for Server-Cert for slapd httpd/alias we get an up to date cert ... not sure if anything else broken by doing that though ... I assume maybe the replcia install/mgmt under 2.x was slightly or perhaps majorly different ... rgds Matt On 31/07/2014 6:21 pm, Martin Kosek wrote: (Adding back the users list as this may be interesting for everyone) Ok, the steps suggested below should help. If the DS does not want to start at all because of the expired certificate, you can also edit /etc/dirsrv/slapd-YOUR-REALM/dse.ldif and edit it manually (only when dirsrv service is stopped). Martin On 07/31/2014 09:53 AM, Matt Bryant wrote: Martin, Correct in that the replica does not have a CA and the version being run is $ rpm -qa ipa-server ipa-server-3.0.0-25.el6.x86_64 restarted the services and get Starting dirsrv: SERVER-IPA...[31/Jul/2014:18:00:15 +1000] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 - Peer's Certificate has expired.) so I think it is just dealing with an expired cert ... so will try the other steps suggested .. rgds Matt Bryant On 31/07/14 17:33, Martin Kosek wrote: On 07/31/2014 07:49 AM, Matt Bryant wrote: All, Got an issue with an IPA replica in that the certs in /etc/httpd/alias /etc/dirsrv/slapd-IPA-REALM have expired. I assume that this replica does not have a CA and we are only dealing with service HTTPD and DIRSRV service certificates. Have tried setting date back before expiry on the replica and doing an 'ipa-getcert resubmit -i id' but that hasn't worked it looks like the CA master is actually rejecting it since the havent set the date back on that server. Error am getting on replica is ... Request ID '20120719044839': status: CA_UNREACHABLE ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. Peer certificate cannot be authenticated with known CA certificates). Isn't this rather a problem that the replica does not trust the master server HTTPD certificate because it's certificates are not valid from replica POV? is there any way of forcing a re-newel or manual process for updating these certs .. ??? If this is just a replica without PKI, I would suggest synchronizing the time back with the master CA server and restarting all the services. If the HTTPD service does not want to start, follow chapter 25.2.2. Starting IdM with Expired Certificates in https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/cas.html and then try to resubmit the certificates so that they can be renewed on the master. Do not forget to revert the above configuration changes when you are done. Also, what version of FreeIPA are you running? HTH, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Centos7, selinux, certmonger, and openldap
On 08/04/2014 07:06 PM, Nordgren, Bryce L -FS wrote: Hmm, sorry for incomplete instructions then. I updated the instructions to cope with that situation better (details in https://fedorahosted.org/freeipa/ticket/4466#comment:2). Please feel free to report more findings or even better help us enhance the page even further :-) Hmm, I thought it looked like your wiki, but when there was no login in the upper-right corner, I assumed it was an online version of your manual. That always gets me, even when I'm looking at a page I know I created myself. Ah, that's a useful UXD feedback as it seems. BTW, to log in, check Log in / create account with OpenID in the LOWER right corner... In this case, tho, I was definitely not qualified to provide a fix. New to both certmonger and that Mozilla certificate database thing. Don't worry, you will get there. Made a comment on the talk page about the related OpenLDAP selinux issues (more than one cert_t defined). Dunno if you get notifications. Ok. IMO this is a valid bug, system policy should allow certmonger to manage other cert types. Thanks for filing it. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] RHEL 7 Upgrade experience so far
On 08/05/2014 12:03 AM, Erinn Looney-Triggs wrote: On 08/04/2014 01:51 PM, Ade Lee wrote: OK - I suspect you may be running into an issue with serial number generation. Each time we install a clone, we end up allocating a new range of serial numbers for the clone. The idea is to keep separate ranges for each CA replica so that no two replicas can issue certs with the same serial number. The problem is that you've probably retried the install a whole bunch of times and now perhaps the serial number range is too high. This is just a guess - but you can see what ranges have been assigned by looking in : 1, ou-ranges, o=ipaca (on the master directory server) 2. CS.cfg for the master (look for the attributes dbs.* 3. The value of the attribute nextRange on : ou=certificateRepository, o=ipaca and ou=Requests, o=ipaca Please send me that info, and I'll explain how to clean that up. Ade On Mon, 2014-08-04 at 12:10 -0700, Erinn Looney-Triggs wrote: On 08/04/2014 11:48 AM, Ade Lee wrote: OK - so its not really even getting started on the install. My guess is there is some cruft from previous installs/uninstalls that was not cleaned up. Is there anything in the directory server logs on the RHEL7 machine? What operation is being attempted that the server is refusing to perform? Ade Ok I moved on past this issue. Problem was minssf was set to 56 on the RHEL 7 dirsrv instance, setting it to 0 resolved this issue. Thanks for having me check the dir on the RHEL 7 instance I was assuming it was hitting against the RHEL 6.5 instance and was finding basically nothing there. This run looks like it pulled a lot more information in but it still errored out. ipa : DEBUGstderr=pkispawn: WARNING ... unable to validate security domain user/password through REST interface. Interface not available pkispawn: ERROR... Exception from Java Configuration Servlet: Error in confguring system certificatesjava.security.cert.CertificateException: Unable to initialize, java.io.IOException: DerInput.getLength(): lengthTag=127, too big. ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpbTnSRM' returned non-zero exit status 1 From the /var/log/pki/pki-tomcat/ca/debug log on the RHEL 7 instance: [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: initializing with mininum 3 and maximum 15 connections to host ipa2.abaqis.com port 389, secure connection, false, authentication type 1 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: increasing minimum connections by 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new total available connections 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new number of connections 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: In LdapBoundConnFactory::getConn() [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: masterConn is connected: true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: getConn: conn is connected true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: getConn: mNumConns now 2 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS: param=preop.internaldb.post_ldif [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif file = /usr/share/pki/ca/conf/vlv.ldif [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif file copy to /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): LDAP Errors in importing /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allExpiredCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allInvalidCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allInValidCertsNotBefore-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allNonRevokedCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allRevokedCaCerts-pki-tomcat, cn=ipaca, cn=ldbm database,
Re: [Freeipa-users] RHEL 7 Upgrade experience so far
On 08/04/2014 10:41 PM, Erinn Looney-Triggs wrote:
On 08/04/2014 08:46 AM, Rob Crittenden wrote:
Erinn Looney-Triggs wrote:
On 08/04/2014 04:01 AM, Martin Kosek wrote:
On 08/04/2014 04:45 AM, Erinn Looney-Triggs wrote:
Whether related or not I am getting the following in my
RHEL 6.5 IPA instance /var/log/dirsrv/slapd-PKI-CA/debug
log:
[26/Jul/2014:20:23:23 +] slapi_ldap_bind - Error:
could not send startTLS re quest: error -1 (Can't contact
LDAP server) errno 107 (Transport endpoint is not
connected) [26/Jul/2014:20:23:23 +]
NSMMReplicationPlugin - agmt=cn=masterAgreement1-i
pa2.example.com-pki-ca (ipa2:7389): Replication bind with
SIMPLE auth failed: LD AP error -1 (Can't contact LDAP
server) ((null)) [26/Jul/2014:20:23:37 +]
slapi_ldap_bind - Error: could not send startTLS re quest:
error -1 (Can't contact LDAP server) errno 107 (Transport
endpoint is not connected) [26/Jul/2014:20:23:48 +]
slapi_ldap_bind - Error: could not send startTLS re quest:
error -1 (Can't contact LDAP server) errno 107 (Transport
endpoint is not connected)
And these errors just continue to be logged.
When attempting to run ipa-ca-install -d on the RHEL 7
replica (all other services are on there running fine) I
receive the following:
ipa : CRITICAL failed to configure ca instance
Command '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqd0WwF'
returned non-zero exit status 1 ipa : DEBUG
File
/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,
line 638, in run_script
return_value = main_function()
File /usr/sbin/ipa-ca-install, line 179, in main CA =
cainstance.install_replica_ca(config, postinstall=True)
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 1678, in install_replica_ca
subject_base=config.subject_base)
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 478, in configure_instance
self.start_creation(runtime=210)
File
/usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 364, in start_creation method()
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 604, in __spawn_instance
raise RuntimeError('Configuration of CA failed')
ipa : DEBUGThe ipa-ca-install command failed,
exception: RuntimeError: Configuration of CA failed
Your system may be partly configured. Run
/usr/sbin/ipa-server-install --uninstall to clean up.
Configuration of CA failed
So this behavior changed after restarting the IPA service
on the RHEL 6.5 system.
So at this point I have a RHEL 6.5 system and a RHEL 7
replica of everything except the CA. The RHEL 6.5 system,
when the IPA service is restarted throws an error, perhaps
from schema change?
Any ideas?
-Erinn
I went in and debugged this a bit further by changing the
verbosity for nsslapd-errorlog-level. It appears that the
rhel 6.5 system is attempting to connect to the RHEL 7 system
on port 7389 and since the RHEL 7 system does not have the CA
installed this would obviously fail. This leads me to believe
that there is cruft in the directory that is pointing to the
wrong place. I don't think this will fix my second group of
errors, but how does one view the replication agreements
specifically for the ca?
As well I omitted to lines from the ipa-ca-install error
which are probably pertinent:
ERROR: Unable to access directory server: Server is
unwilling to perform
ipa : DEBUGstderr=
-Erinn
This is strange. ipa-ca-install/ipa-replica-install --setup-ca
should create the replication agreement pointing at port 389
on RHEL-7.0, given that the 2 originally separated DS databases
were merged.
It looks like this is some replication agreement left over
from previous tests.
Anyway, to list all hosts with PKI, try:
# ipa-csreplica-manage list Directory Manager password:
vm-089.idm.lab.bos.redhat.com: master
vm-086.idm.lab.bos.redhat.com: master
master means that this server has PKI service installed. It
will show different value if there is no PKI service.
To check PKI replication agreements for specific hostname,
run:
# ipa-csreplica-manage list `hostname` Directory Manager
password:
vm-089.idm.lab.bos.redhat.com
Check man ipa-csreplica-manage for advise how to delete or
create the PKI agreements.
HTH, Martin
Yeah here is what I get: ipa-csreplica-manage list Directory
Manager password:
ipa2.example.com: CA not configured ipa.example.com: master
ipa2 is my rhel7 instance, ipa is the rhel 6.5 instance.
ipa-csreplica-manage list ipa2.example.com Directory Manager
password:
Can't contact LDAP server
Which I guess makes sense, however: ipa-csreplica-manage list -v
ipa.example.com Directory Manager password:
ipa2.example.com last init status: None last init ended: None
last update status: -1 - LDAP error: Can't contact LDAP server
last update ended: None ipa2.example.com
Re: [Freeipa-users] Building previous release rpms are failing
On 08/05/2014 12:05 PM, Curtis L. Knight wrote: Hey, I have been trying to build rpms from different releases without much success. I can build 4.0+ rpms but I have not tested them. Going backward like with release-3-3-5, it fails on lint/pylint routine. I comment out the lint call in the Makefile and further along it cannot find some ui files. You could also run $ make rpms DEVELOPER_MODE=1 to have the lint run, but ignored it's results (though fixing the bug it is better of course). I got this setup to use docker to generate the rpms. Included below are the sequences and commands. for current release that does build without intervention: # docker run -ti --name freeipa-devel-rpms-container knighcl/freeipa-devel-rpms:fedora-20 release-4-0-1 or for master # docker run -ti --name freeipa-devel-rpms-container knighcl/freeipa-devel-rpms:fedora-20 for previous release # docker run -ti --name freeipa-devel-rpms-container knighcl/freeipa-devel-rpms:fedora-20 release-3-3-5 Once dropped into the terminal upon finishing, I edit the Makefile to comment out the make-lint line within the lint stanza #./make-lint $(LINT_OPTIONS) run 'make rpms' again to get beyond lint errors shown below cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi ./make-lint Traceback (most recent call last): File ./make-lint, line 272, in module sys.exit(main()) File ./make-lint, line 243, in main linter.check(files) File /usr/lib/python2.7/site-packages/pylint/lint.py, line 626, in check self.check_astroid_module(astroid, walker, rawcheckers, tokencheckers) File /usr/lib/python2.7/site-packages/pylint/lint.py, line 712, in check_astroid_module walker.walk(astroid) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 715, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 715, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 712, in walk cb(astroid) File /usr/lib/python2.7/site-packages/pylint/checkers/newstyle.py, line 135, in visit_function args=(call.args[0].name, )) AttributeError: 'Getattr' object has no attribute 'name' make: *** [lint] Error 1 This is new, I created upstream ticket to timely fix it: https://fedorahosted.org/freeipa/ticket/4475 The final errors from the build are below. I tried to find the jdennis building/ci script to see if there is something I am missing but I am guessing it is on the build system. This was an exercise on building rpms and learning docker to possibly help the developers out with a new process. I do not need to do this successfully but thought you might want to know that something might not be proper. Regards, Curtis rpm 3.3.5 log /usr/bin/mkdir -p '/freeipa/rpmbuild/BUILDROOT/freeipa-3.3.5GITd366595-0.fc20.x86_64/usr/share/ipa/ui/js/dojo' /usr/bin/install -c -m 644 -p dojo.js '/freeipa/rpmbuild/BUILDROOT/freeipa-3.3.5GITd366595-0.fc20.x86_64/usr/share/ipa/ui/js/dojo' make[6]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/dojo' make[5]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/dojo' Making install in freeipa make[5]: Entering directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/freeipa' ../../util/make-ui.sh Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/compile.sh: line 114: pushd: /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa: No such file or directory Invalid build dir: /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa make[6]: Entering directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/freeipa' make[6]: Nothing to be done for `install-exec-am'. ../../util/make-ui.sh Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/compile.sh: line 114: pushd: /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa: No such file or directory Invalid build dir: /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa /usr/bin/mkdir -p '/freeipa/rpmbuild/BUILDROOT/freeipa-3.3.5GITd366595-0.fc20.x86_64/usr/share/ipa/ui/js/freeipa' /usr/bin/install -c -m 644 -p ./app.js
Re: [Freeipa-users] Building previous release rpms are failing
On 08/05/2014 12:32 PM, Martin Kosek wrote: On 08/05/2014 12:05 PM, Curtis L. Knight wrote: ... #./make-lint $(LINT_OPTIONS) run 'make rpms' again to get beyond lint errors shown below cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi ./make-lint Traceback (most recent call last): File ./make-lint, line 272, in module sys.exit(main()) File ./make-lint, line 243, in main linter.check(files) File /usr/lib/python2.7/site-packages/pylint/lint.py, line 626, in check self.check_astroid_module(astroid, walker, rawcheckers, tokencheckers) File /usr/lib/python2.7/site-packages/pylint/lint.py, line 712, in check_astroid_module walker.walk(astroid) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 715, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 715, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 712, in walk cb(astroid) File /usr/lib/python2.7/site-packages/pylint/checkers/newstyle.py, line 135, in visit_function args=(call.args[0].name, )) AttributeError: 'Getattr' object has no attribute 'name' make: *** [lint] Error 1 This is new, I created upstream ticket to timely fix it: https://fedorahosted.org/freeipa/ticket/4475 Ticket 4475 is now fixed, thanks to Jan Cholasta. ipa-3-3 branch should now build OK again. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] RHEL 7 Upgrade experience so far
On 08/04/2014 04:45 AM, Erinn Looney-Triggs wrote:
Whether related or not I am getting the following in my RHEL 6.5
IPA instance /var/log/dirsrv/slapd-PKI-CA/debug log:
[26/Jul/2014:20:23:23 +] slapi_ldap_bind - Error: could not
send startTLS re quest: error -1 (Can't contact LDAP server) errno
107 (Transport endpoint is not connected) [26/Jul/2014:20:23:23
+] NSMMReplicationPlugin - agmt=cn=masterAgreement1-i
pa2.example.com-pki-ca (ipa2:7389): Replication bind with SIMPLE
auth failed: LD AP error -1 (Can't contact LDAP server) ((null))
[26/Jul/2014:20:23:37 +] slapi_ldap_bind - Error: could not
send startTLS re quest: error -1 (Can't contact LDAP server) errno
107 (Transport endpoint is not connected) [26/Jul/2014:20:23:48
+] slapi_ldap_bind - Error: could not send startTLS re quest:
error -1 (Can't contact LDAP server) errno 107 (Transport endpoint
is not connected)
And these errors just continue to be logged.
When attempting to run ipa-ca-install -d on the RHEL 7 replica
(all other services are on there running fine) I receive the
following:
ipa : CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqd0WwF' returned non-zero
exit status 1 ipa : DEBUG File
/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,
line 638, in run_script
return_value = main_function()
File /usr/sbin/ipa-ca-install, line 179, in main CA =
cainstance.install_replica_ca(config, postinstall=True)
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 1678, in install_replica_ca
subject_base=config.subject_base)
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 478, in configure_instance
self.start_creation(runtime=210)
File
/usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 364, in start_creation method()
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 604, in __spawn_instance
raise RuntimeError('Configuration of CA failed')
ipa : DEBUGThe ipa-ca-install command failed,
exception: RuntimeError: Configuration of CA failed
Your system may be partly configured. Run
/usr/sbin/ipa-server-install --uninstall to clean up.
Configuration of CA failed
So this behavior changed after restarting the IPA service on the
RHEL 6.5 system.
So at this point I have a RHEL 6.5 system and a RHEL 7 replica of
everything except the CA. The RHEL 6.5 system, when the IPA service
is restarted throws an error, perhaps from schema change?
Any ideas?
-Erinn
I went in and debugged this a bit further by changing the verbosity
for nsslapd-errorlog-level. It appears that the rhel 6.5 system is
attempting to connect to the RHEL 7 system on port 7389 and since the
RHEL 7 system does not have the CA installed this would obviously
fail. This leads me to believe that there is cruft in the directory
that is pointing to the wrong place. I don't think this will fix my
second group of errors, but how does one view the replication
agreements specifically for the ca?
As well I omitted to lines from the ipa-ca-install error which are
probably pertinent:
ERROR: Unable to access directory server: Server is unwilling to perform
ipa : DEBUGstderr=
-Erinn
This is strange. ipa-ca-install/ipa-replica-install --setup-ca should create
the replication agreement pointing at port 389 on RHEL-7.0, given that the 2
originally separated DS databases were merged.
It looks like this is some replication agreement left over from previous tests.
Anyway, to list all hosts with PKI, try:
# ipa-csreplica-manage list
Directory Manager password:
vm-089.idm.lab.bos.redhat.com: master
vm-086.idm.lab.bos.redhat.com: master
master means that this server has PKI service installed. It will show
different value if there is no PKI service.
To check PKI replication agreements for specific hostname, run:
# ipa-csreplica-manage list `hostname`
Directory Manager password:
vm-089.idm.lab.bos.redhat.com
Check man ipa-csreplica-manage for advise how to delete or create the PKI
agreements.
HTH,
Martin
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Centos7, selinux, certmonger, and openldap
On 08/04/2014 01:36 AM, Nordgren, Bryce L -FS wrote: Spoke too soon. I needed the following extra selinux policy module to make all the AVCs go away. BTW: the instructions on http://www.freeipa.org/page/PKI really only work if you leave the password blank when you create a new database with certutil. Otherwise, the ipa-getcert request command creates tracking requests which get stuck. Databases with passwords cause certmonger to error with a Cert storage slot still needs user PIN to be set.. This took me a couple of hours to track down. Hmm, sorry for incomplete instructions then. I updated the instructions to cope with that situation better (details in https://fedorahosted.org/freeipa/ticket/4466#comment:2). Please feel free to report more findings or even better help us enhance the page even further :-) HTH, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] memberof plugin?
On 08/01/2014 12:40 AM, Kat wrote: Hi, I must be missing something obvious in getting memberof plugin to work.. Any ideas? Thanks in advance... ~K -- ./fixup-memberof.pl -D 'cn=Directory Manager' -b 'dc=red,dc=lemon,dc=com' -w - -v ldap_initialize( ldap://localhost:7389 ) add objectclass: top extensibleObject add cn: memberOf_fixup_2014_7_26_22_33_31 add basedn: dc=red,dc=lemon,dc=com adding new entry cn=memberOf_fixup_2014_7_26_22_33_31, cn=memberOf task, cn=tasks, cn=config ldap_add: No such object (32) Are you using FreeIPA or just standalone 389-ds-base instance? Does the memberOf task object exist? $ ldapsearch -x -D cn=Directory Manager -w Secret123 -b cn=memberOf task, cn=tasks, cn=config Is the MemberOf plugin enabled? (cn=MemberOf Plugin,cn=plugins,cn=config) Are there any /var/log/dirsrv/slapd-YOUR-REALM/errors? HTH, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Possible to extract password of ldap
On 08/01/2014 08:23 AM, barry...@gmail.com wrote:
Hi :
Is it possible to read clear text of password of ipa users by admin ?
No. Admin can't even read the hash
# ldapsearch -Y GSSAPI -b
uid=fbar,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com uid
userPassword
SASL/GSSAPI authentication started
SASL username: ad...@idm.lab.bos.redhat.com
SASL SSF: 56
SASL data security layer installed.
...
# fbar, users, accounts, idm.lab.bos.redhat.com
dn: uid=fbar,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
uid: fbar
...
Directory Manager can read the user password hash:
# ldapsearch -D cn=Directory Manager -x -W -b
uid=fbar,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com uid
userPassword
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base uid=fbar,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
with scope subtree
# filter: (objectclass=*)
# requesting: uid userPassword
#
# fbar, users, accounts, idm.lab.bos.redhat.com
dn: uid=fbar,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
uid: fbar
userPassword:: e1NTSEF9Vnp6VDdBbDlQUVMrUHJTK1NsNnNlN1pNYU5oRnRxT2J2L3dtNUE9PQ=
=
# echo e1NTSEF9Vnp6VDdBbDlQUVMrUHJTK1NsNnNlN1pNYU5oRnRxT2J2L3dtNUE9PQ== |
base64 --decode
{SSHA}VzzT7Al9PQS+PrS+Sl6se7ZMaNhFtqObv/wm5A==
That's all, no clear passwords - by design.
I m facing the issue of half rollout as half vol.of users changed
password already.
And if i deploy and reset all password then it may make issue for this half
and we dont have records which user password sent .
I am not sure if I understand the question, but if your users have problems
with their passwords, you can administratively reset them and send the new ones
to them (they will be then forced to set their own
(http://www.freeipa.org/page/New_Passwords_Expired)).
Martin
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Troubleshooting a webui login error
On 07/30/2014 07:16 PM, Robert Walker wrote: Hi, I've got 2 IPA servers running in a relationship. One is ok as far as logging into the webui and the other will only let me kinit admin on the console of the server. When I try to login into the webui Your session has expired. Please re-login. and Please re-enter your username or password The password or username you entered is incorrect. Please try again (make sure your caps lock is off). If the problem persists, contact your administrator. The server still seems to authenticate users by remote LDAP requests ok. Any pointers much appreciated. Thanks Hello, Could you please check the advice in http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_to_Web_UI ? I would suspect that ipa_memcached service is not running for some reason. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica Cert failed to renew ...
On 07/31/2014 07:49 AM, Matt Bryant wrote: All, Got an issue with an IPA replica in that the certs in /etc/httpd/alias /etc/dirsrv/slapd-IPA-REALM have expired. I assume that this replica does not have a CA and we are only dealing with service HTTPD and DIRSRV service certificates. Have tried setting date back before expiry on the replica and doing an 'ipa-getcert resubmit -i id' but that hasn't worked it looks like the CA master is actually rejecting it since the havent set the date back on that server. Error am getting on replica is ... Request ID '20120719044839': status: CA_UNREACHABLE ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. Peer certificate cannot be authenticated with known CA certificates). Isn't this rather a problem that the replica does not trust the master server HTTPD certificate because it's certificates are not valid from replica POV? is there any way of forcing a re-newel or manual process for updating these certs .. ??? If this is just a replica without PKI, I would suggest synchronizing the time back with the master CA server and restarting all the services. If the HTTPD service does not want to start, follow chapter 25.2.2. Starting IdM with Expired Certificates in https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/cas.html and then try to resubmit the certificates so that they can be renewed on the master. Do not forget to revert the above configuration changes when you are done. Also, what version of FreeIPA are you running? HTH, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA + Ipsilon
Without this package for your platform, you cannot move further. So you would either need to switch to some platform that has this package available (RHEL, CentOS, Fedora) or take the source bits and build it for your platform yourselves. Maybe you would get lucky with rebuilding the source RPM from Fedora 20 (http://koji.fedoraproject.org/koji/buildinfo?buildID=489924), but there might be some build dependencies that are not available on Scientific Linux... HTH, Martin On 07/31/2014 09:53 AM, Luca Tartarini wrote: Hi, Thanks for the reply, unfortunately I can not find the package on Scientific Linux, is there a workaround? Thanks. Luca Tartarini 2014-07-30 15:00 GMT+02:00 Simo Sorce sso...@redhat.com: On Tue, 2014-07-29 at 15:58 +0200, Martin Kosek wrote: On 07/29/2014 03:47 PM, Luca Tartarini wrote: Hi everyone, I am new in FreeIPA, I am trying to configure FreeIPA with Ipsilon. The configuration is the following: Service Provider (host with Scientific Linux 6) with ipsilon-client and Identity Provider (another host with Scientific Linux 6) with FreeIPA and ipsilon-server, is the configuration feasible and/or correct? If it is, then I am stuck in the installation of ipsilon-client because after I installed lasso-2.3.6 and all the ipsilon-client prerequisites, when I finally run: ipsilon-client-install --saml-idp-metadata https://myidp.example.org/idp/saml2/metadata --saml-auth /wiki I get this error about lasso: Traceback (most recent call last): File /usr/bin/ipsilon-client-install, line 20, in module from ipsilon.tools.saml2metadata import Metadata File /usr/lib/python2.6/site-packages/ipsilon/tools/saml2metadata.py, line 22, in module import lasso File /usr/lib/python2.6/site-packages/lasso.py, line 3, in module import _lasso ImportError: No module named _lasso Does anyone know if it's a problem about lasso's configuration or I forgot something about ipsilon-client? Thanks in advance. Luca Tartarini Not sure, _lasso.so should be provided by lasso-python package: # rpm -qf /usr/lib64/python2.6/site-packages/_lasso.so lasso-python-2.4.0-4.el6.x86_64 CCing Simo to advise. Sounds like lasso-python is missing indeed. Simo. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica Cert failed to renew ...
(Adding back the users list as this may be interesting for everyone) Ok, the steps suggested below should help. If the DS does not want to start at all because of the expired certificate, you can also edit /etc/dirsrv/slapd-YOUR-REALM/dse.ldif and edit it manually (only when dirsrv service is stopped). Martin On 07/31/2014 09:53 AM, Matt Bryant wrote: Martin, Correct in that the replica does not have a CA and the version being run is $ rpm -qa ipa-server ipa-server-3.0.0-25.el6.x86_64 restarted the services and get Starting dirsrv: SERVER-IPA...[31/Jul/2014:18:00:15 +1000] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 - Peer's Certificate has expired.) so I think it is just dealing with an expired cert ... so will try the other steps suggested .. rgds Matt Bryant On 31/07/14 17:33, Martin Kosek wrote: On 07/31/2014 07:49 AM, Matt Bryant wrote: All, Got an issue with an IPA replica in that the certs in /etc/httpd/alias /etc/dirsrv/slapd-IPA-REALM have expired. I assume that this replica does not have a CA and we are only dealing with service HTTPD and DIRSRV service certificates. Have tried setting date back before expiry on the replica and doing an 'ipa-getcert resubmit -i id' but that hasn't worked it looks like the CA master is actually rejecting it since the havent set the date back on that server. Error am getting on replica is ... Request ID '20120719044839': status: CA_UNREACHABLE ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. Peer certificate cannot be authenticated with known CA certificates). Isn't this rather a problem that the replica does not trust the master server HTTPD certificate because it's certificates are not valid from replica POV? is there any way of forcing a re-newel or manual process for updating these certs .. ??? If this is just a replica without PKI, I would suggest synchronizing the time back with the master CA server and restarting all the services. If the HTTPD service does not want to start, follow chapter 25.2.2. Starting IdM with Expired Certificates in https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/cas.html and then try to resubmit the certificates so that they can be renewed on the master. Do not forget to revert the above configuration changes when you are done. Also, what version of FreeIPA are you running? HTH, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] freeipa-client installation(debug) on Ubuntu 10.04 12.04
On 07/28/2014 07:29 PM, jaseywang wrote:
Hi
I tried to install freeipa-client on Ubuntu 10.04 12.04, but none of them
worked :-(
At the moment, only 12.04 ships the apt repo so that I can use apt to
install the freeipa-client(2.1.4-0ubuntu1). Although I can installed the
package successfully, I can't make it work during my ipa-client-install
process, I just follow the instruction as the below docs says:
https://ashbyte.com/ashbyte/wiki/FreeIPA/Ubuntu
http://ubuntuforums.org/showthread.php?t=2207956
But failed with --debug options on, below is the message it produced during
installation:
---
# ipa-client-install --domain=example.com --mkhomedir --realm=EXAMPLE.COM
--server=ad25.example.com --no-ntp --hostname=dp40.example.com --debug
root: DEBUG/usr/sbin/ipa-client-install was invoked with
options: {'conf_ntp': False, 'domain': 'example.com', 'uninstall': False,
'force': False, 'sssd': True, 'krb5_offline_passwords': True, 'hostname': '
dp40.example.com', 'preserve_sssd': False, 'server': 'ad25.example.com',
'prompt_password': False, 'mkhomedir': True, 'dns_updates': False,
'permit': False, 'debug': True, 'on_master': False, 'ntp_server': None,
'realm_name': 'EXAMPLE.COM', 'unattended': None, 'principal': None}
root: DEBUGmissing options might be asked for interactively
later
root: DEBUGLoading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
root: DEBUGLoading StateFile from
'/var/lib/ipa-client/sysrestore/sysrestore.state'
root: DEBUG[ipadnssearchkrb]
root: DEBUG[ipacheckldap]
root: DEBUGargs=/usr/bin/wget -O /tmp/tmp_gTNxY/ca.crt -T 15 -t
2 http://ad25.example.com/ipa/config/ca.crt
root: DEBUGstdout=
root: DEBUGstderr=--2014-07-29 01:00:16--
http://ad25.example.com/ipa/config/ca.crt
Resolving ad25.example.com (ad25.example.com)... 10.11.50.5
Connecting to ad25.example.com (ad25.example.com)|10.11.50.5|:80...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 1295 (1.3K) [application/x-x509-ca-cert]
Saving to: `/tmp/tmp_gTNxY/ca.crt'
0K . 100% 109M=0s
2014-07-29 01:00:16 (109 MB/s) - `/tmp/tmp_gTNxY/ca.crt' saved [1295/1295]
root: DEBUGInit ldap with: ldap://ad25.example.com:389
root: DEBUGSearch LDAP server for IPA base DN
root: DEBUGCheck if naming context 'dc=example,dc=com' is for
IPA
root: DEBUGNaming context 'dc=example,dc=com' is a valid IPA
context
root: DEBUGSearch for (objectClass=krbRealmContainer) in
dc=example,dc=com(sub)
root: DEBUGFound: [('cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=us',
{'krbSubTrees': ['dc=example,dc=com'], 'cn': ['EXAMPLE.COM'],
'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special',
'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top',
'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope': ['2'],
'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special',
'aes128-cts:normal', 'aes128-cts:special', 'des3-hmac-sha1:normal',
'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special',
'des-hmac-sha1:normal', 'des-cbc-md5:normal', 'des-cbc-crc:normal',
'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'],
'krbMaxRenewableAge': ['604800']})]
root: DEBUGwill use domain: example.com
root: DEBUGwill use server: ad25.example.com
DNS domain 'example.com' is not configured for automatic KDC address lookup.
KDC address will be set to fixed value.
Discovery was successful!
root: DEBUGwill use cli_realm: EXAMPLE.COM
root: DEBUGwill use cli_basedn: dc=example,dc=com
Hostname: dp40.example.com
Realm: EXAMPLE.COM
DNS Domain: example.com
IPA Server: ad25.example.com
BaseDN: dc=example,dc=com
Continue to configure the system with these values? [no]: yes
root: DEBUGBacking up system configuration file '/etc/hostname'
root: DEBUGSaving Index File to
'/var/lib/ipa-client/sysrestore/sysrestore.index'
root: DEBUGargs=/bin/hostname dp40.example.com
root: DEBUGstdout=
root: DEBUGstderr=
User authorized to enroll computers: admin
root: DEBUGwill use principal: admin
root: DEBUGargs=/usr/bin/wget -O /etc/ipa/ca.crt
http://ad25.example.com/ipa/config/ca.crt
root: DEBUGstdout=
root: DEBUGstderr=--2014-07-29 01:00:29--
http://ad25.example.com/ipa/config/ca.crt
Resolving ad25.example.com (ad25.example.com)... 10.11.50.5
Connecting to ad25.example.com (ad25.example.com)|10.11.50.5|:80...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 1295 (1.3K) [application/x-x509-ca-cert]
Saving to: `/etc/ipa/ca.crt'
0K .
Re: [Freeipa-users] FreeIPA + Ipsilon
On 07/29/2014 03:47 PM, Luca Tartarini wrote: Hi everyone, I am new in FreeIPA, I am trying to configure FreeIPA with Ipsilon. The configuration is the following: Service Provider (host with Scientific Linux 6) with ipsilon-client and Identity Provider (another host with Scientific Linux 6) with FreeIPA and ipsilon-server, is the configuration feasible and/or correct? If it is, then I am stuck in the installation of ipsilon-client because after I installed lasso-2.3.6 and all the ipsilon-client prerequisites, when I finally run: ipsilon-client-install --saml-idp-metadata https://myidp.example.org/idp/saml2/metadata --saml-auth /wiki I get this error about lasso: Traceback (most recent call last): File /usr/bin/ipsilon-client-install, line 20, in module from ipsilon.tools.saml2metadata import Metadata File /usr/lib/python2.6/site-packages/ipsilon/tools/saml2metadata.py, line 22, in module import lasso File /usr/lib/python2.6/site-packages/lasso.py, line 3, in module import _lasso ImportError: No module named _lasso Does anyone know if it's a problem about lasso's configuration or I forgot something about ipsilon-client? Thanks in advance. Luca Tartarini Not sure, _lasso.so should be provided by lasso-python package: # rpm -qf /usr/lib64/python2.6/site-packages/_lasso.so lasso-python-2.4.0-4.el6.x86_64 CCing Simo to advise. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA 4.0.0 and CentOS release 6.5
On 07/24/2014 07:04 PM, Nordgren, Bryce L -FS wrote: One of our larger users was in a similar situation a few years ago and ended up running Fedora until RHEL caught up and then migrating the servers. I'm running it on F20 because it seemed like the dependencies would make running it on CentOS 7 a pile of pain I didn't need. I do think RHEL catching up will probably be a 3-4 year proposition (i.e., RHEL 8), so the ability to run FreeIPA 4.0.0 is likely to be a moot point by then. Or are you thinking that it might be part of 7.1? It might, wait and see :-) Alternatively, you as Lukas pointed out below, preparing a (COPR) repo on top of RHEL-7.0 should be much easier than preparing it on top of RHEL-6.x. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Announcing FreeIPA 4.0.1
if permission in a privilege * webui: fix disabled state of service's PAC type * baseldap: return 'none' attr level right as unicode string === Tomáš Babej (3) === * trusts: Validate missing trust secret properly * ipatests: tasks: Fix dns configuration for trusts * trusts: Make cn=adtrust agents sysaccount nestedgroup -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA Replication Status
On 07/23/2014 01:36 PM, Choudhury, Suhail wrote: Hi, I'm finding that on all IPA servers in 1 cluster the replication status shows as either busy or started, but no succeeded status is being reported: [root@recsds2 ~]# ipa-replica-manage list -v $HOSTNAME recsds1.bskyb.com: replica last init status: None last init ended: None last update status: 1 Can't acquire busy replica last update ended: 2014-07-23 11:29:48+00:00 recsds3.bskyb.com: replica last init status: None last init ended: None last update status: 1 Can't acquire busy replica last update ended: 2014-07-23 11:29:46+00:00 [root@recsds2 ~]# ipa-replica-manage list -v $HOSTNAME recsds1.bskyb.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update started last update ended: None recsds3.bskyb.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update started last update ended: None This is as opposed to another IPA cluster: /home/sch # ipa-replica-manage list -v $HOSTNAME ipa01.ath.skycdc.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-07-23 11:24:22+00:00 ipa01.hhe.skycdc.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-07-23 11:24:22+00:00 ipa02.ath.skycdc.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-07-23 11:24:22+00:00 ipa02.hhe.skycdc.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-07-23 11:24:22+00:00 ipa02.slu.skycdc.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-07-23 11:24:21+00:00 Do you know what may be causing this? It is difficult to advise with just this information, you would need to check for errors in DS log (/var/log/dirsrv/slapd-YOUR-REALM/errors). Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA Replication Status
On 07/23/2014 01:58 PM, Choudhury, Suhail wrote: I have the following errors on different boxes: [root@recsds1 sch32]# tail -f /var/log/dirsrv/slapd-RECS-BSKYB-COM/errors [23/Jul/2014:12:28:54 +0100] NSMMReplicationPlugin - CleanAllRUV Task: Replicas have not been cleaned yet, retrying in 10 seconds [23/Jul/2014:12:29:06 +0100] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to finish cleaning... [23/Jul/2014:12:29:06 +0100] NSMMReplicationPlugin - CleanAllRUV Task: Not all replicas finished cleaning, retrying in 10 seconds [23/Jul/2014:12:29:16 +0100] NSMMReplicationPlugin - CleanAllRUV Task: Not all replicas finished cleaning, retrying in 20 seconds [23/Jul/2014:12:29:36 +0100] NSMMReplicationPlugin - CleanAllRUV Task: Not all replicas finished cleaning, retrying in 40 seconds [root@recsds3 sch32]# tail -f /var/log/dirsrv/slapd-RECS-BSKYB-COM/errors [23/Jul/2014:12:52:10 +0100] agmt=cn=meTorecsds2.bskyb.com (recsds2:389) - Can't locate CSN 53c7ba270010 in the changelog (DB rc=-30988). The consumer may need to be reinitialized. [23/Jul/2014:12:52:10 +0100] NSMMReplicationPlugin - agmt=cn=meTorecsds2.bskyb.com (recsds2:389): changelog iteration code returned a dummy entry with csn 53c7c6b100020010, skipping ... [23/Jul/2014:12:52:13 +0100] agmt=cn=meTorecsds4.bskyb.com (recsds4:389) - Can't locate CSN 53c7ba7500040010 in the changelog (DB rc=-30988). The consumer may need to be reinitialized. [23/Jul/2014:12:52:13 +0100] NSMMReplicationPlugin - agmt=cn=meTorecsds4.bskyb.com (recsds4:389): changelog iteration code returned a dummy entry with csn 53c7c6b100020010, skipping ... [23/Jul/2014:12:52:13 +0100] agmt=cn=meTorecsds2.bskyb.com (recsds2:389) - Can't locate CSN 53c7ba270010 in the changelog (DB rc=-30988). The consumer may need to be reinitialized. [root@recsds4 ~]# tail -f /var/log/dirsrv/slapd-RECS-BSKYB-COM/errors [23/Jul/2014:12:52:03 +0100] ldbm_back_modify - Attempt to modify a tombstone entry nsuniqueid=b0838195-0da911e4-9433f833-313b8581,krbprincipalname=DNS/recsds1.bskyb@recs.bskyb.com,cn=services,cn=accounts,dc=recs,dc=bskyb,dc=com [23/Jul/2014:12:52:03 +0100] ldbm_back_modify - Attempt to modify a tombstone entry nsuniqueid=85992d8b-0da911e4-9433f833-313b8581,fqdn=recsds1.bskyb.com,cn=computers,cn=accounts,dc=recs,dc=bskyb,dc=com [23/Jul/2014:12:52:06 +0100] ldbm_back_modify - Attempt to modify a tombstone entry nsuniqueid=b0838195-0da911e4-9433f833-313b8581,krbprincipalname=DNS/recsds1.bskyb@recs.bskyb.com,cn=services,cn=accounts,dc=recs,dc=bskyb,dc=com [root@recsds5 sch32]# tail -f /var/log/dirsrv/slapd-RECS-BSKYB-COM/errors [23/Jul/2014:12:52:08 +0100] NSMMReplicationPlugin - agmt=cn=meTorecsds4.bskyb.com (recsds4:389): Consumer failed to replay change (uniqueid 85992d8b-0da911e4-9433f833-313b8581, CSN 53c7ba7e00030010): Server is unwilling to perform (53). Will retry later. [23/Jul/2014:12:52:08 +0100] NSMMReplicationPlugin - agmt=cn=meTorecsds4.bskyb.com (recsds4:389): Consumer failed to replay change (uniqueid b0838197-0da911e4-9433f833-313b8581, CSN 53c7ba900010): Server is unwilling to perform (53). Will retry later. [23/Jul/2014:12:52:16 +0100] NSMMReplicationPlugin - agmt=cn=meTorecsds4.bskyb.com (recsds4:389): Consumer failed to replay change (uniqueid b0838195-0da911e4-9433f833-313b8581, CSN 53c7ba7500050010): Server is unwilling to perform (53). Will retry later. The background to this is a storage crash caused the master CA IAP to get fudged, and I then proceeded to promote a replica to master CA, re-added crashed IPAs and trying to sync them all up again and clean old orphaned RUVs. Regards, Suhail Choudhury. DevOps | Recommendations Team | BSkyB Somebody from DS may have a better idea, but it seems to me that the fastest way to recover is to either ipa-replica-manage re-initialize the replicas from the new CA IPA master (I am assuming this one is running more or less fine) or even to uninstall, ipa-replica-manage del it and install again to get a clean environment. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Missing /var/lib/ipa/ca_serialno
Ah, so this is all a matter of old docs. --selfsign installation are deprecated, we now use CA-less instead. I updated http://www.freeipa.org/page/Howto/Promoting_a_self-signed_FreeIPA_CA and added a warning with links to appropriate resources. HTH, Martin On 07/23/2014 05:54 PM, John Moyer wrote: http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/promoting-replica.html http://www.freeipa.org/page/Howto/Promoting_a_self-signed_FreeIPA_CA On 7/23/14, 11:21 AM, Rob Crittenden wrote: John Moyer wrote: Hello All, I was going to promote one of my newer replica IPA servers to be the master of our IPA environment and noticed when following the procedures to do this that I'm apparently missing this file from my master IPA server: /var/lib/ipa/ca_serialno Is there a way to regenerate this file? I just made a replica like 3 weeks ago, so it definitely is the master, I'm just not sure why this file doesn't exist. Looked at my backups from the last 3 months and it hasn't existed in that time period. That file was the source of serial numbers for what was called selfsign mode (now deprecated in 3.3+). It installed a file-based CA on the initial IPA master. You needed to pass --selfsign to the installer What docs are you working from that say you need to worry about this file? They are likely ancient. rob Thanks, John Moyer Director, IT Operations 901 N. Stuart St. STE 904A Arlington,VA 22203 703.678.2311 Office 240.460.0023 Cell 703.678.2312 Fax -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] 4.0.0 password migration trouble
On 07/19/2014 01:08 AM, Nordgren, Bryce L -FS wrote:
So if I understand the 389-ds ticket correctly, I can add pre-hashed
passwords
via ldapmodify to the 389 server using directory manager as the bind dn? I
just can't use the ipa command line tool/script.
The short answer is no. Trying to add the userPassword attribute with
ldapmodify binding as cn=directory manager fails with operation error.
Error log attached to the ticket Rob made:
https://fedorahosted.org/freeipa/ticket/4450
To summarize:
No password migration via ipa migrate-ds; No password migration via ipa
user-add --setattr userPassword={SHA}...; No password migration via
'ldapmodify -D cn=directory manager'. Do you think a solution will be
forthcoming, or is it a ways off? I can leave my old ldap directory up for a
little while.
I did couple tests with a custom build of 389-ds-base and I made the migration
working after switching the new configuration option. See details and the
transcript in the ticket:
https://fedorahosted.org/freeipa/ticket/4450#comment:5
I will work with DS team to backport the switch option to Fedora 20 389-ds-base
and to release FreeIPA 4.0.1 with appropriate patch to fix this problem ASAP,
ideally this week.
Thanks for your patience,
Martin
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] ldap modify
On 07/21/2014 01:30 PM, Atanas Bachvaroff wrote:
Martin Kosek wrote:
On 07/21/2014 01:04 PM, Atanas Bachvaroff wrote:
Hello,
I've been experiencing strange problems trying to manually modify the
userPassword attributes in the FreeIPA's 389 directory (FreeIPA 3.3.4 on
Fedora 20). I'm using the following script:
CUT
[nasko@ipa ~]$ cat change_pass.sh
#!/bin/sh
if test -z ${1}; then
echo no dn supplied
exit 1
fi
if test -z ${2}; then
PASS=`pwgen 10 1`
else
PASS=${2}
fi
echo ${PASS}
PASS_HASH=`pwdhash ${PASS}`
(
echo dn: ${1}
echo changetype: modify
echo replace: userPassword
echo userPassword: ${PASS_HASH}
) | ldapmodify -h localhost -p 389 -D cn=directory manager -w
[nasko@ipa ~]$ ./change_pass.sh
'uid=,cn=users,cn=accounts,dc=uni-sofia,dc=bg'
nohshohwoo
modifying entry uid=,cn=users,cn=accounts,dc=uni-sofia,dc=bg
ldap_modify: Operations error (1)
[nasko@ipa ~]$
CUT
and so on and so on, ldapmodify returing the same error every time, on
any
dn. Any suggestions?
P.S.
The server is in migration mode at this time.
Hello Atanas,
This issue is already discussed in
https://fedorahosted.org/freeipa/ticket/4450
and thread [Freeipa-users] 4.0.0 password migration trouble, you will
find
some information there. Ludwig, this issue is completely different than
nsslapd-allow-hashed-passwords, correct?
But anyway, changing password via ldapmodify and supplying pre-hashed
password
will not work well and you will need to run through the migration mode
even
after ticket 4450 is fixed.
If you have a clear text available (which I assume based on `pwdhash
${PASS}`
construct), I would rather suggest changing it via ldappasswd script so
that
FreeIPA can also generate all the Kerberos attributes.
HTH,
Martin
Unfortunately, I don't have access to the cleartext passwords ('coz I'm
migrating from existing 389 / OpenLDAP directories) and ipa migrate-ds
failed miserably with hashed passwords constraint violations, so I cloned
the 389s etc., deleted the the userPassword attributes and tried to
restore 'em with the script above, taking the PASS=${2} branch, which
failed.
It appears that #4450 is very close to my issues.
Ok. When 4450 is fixed (I would like to get it done this week), you should be
able to just run migrate-ds and have pre-hashed user passwords stored.
Given you are running on 3.3.4 (why not the latest 3.3.5?), we should also
release fixed FreeIPA build in Fedora 20.
Martin
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Disable AES256 Encryption
On 07/21/2014 03:38 PM, Eldo Joseph wrote: Is it possible to disable AES256 Encryption from IPA, while making Kerberos principals... -Eldo- I think you would need to hand update krbDefaultEncSaltTypes in cn=YOUR-REALM,cn=kerberos,SUFFIX (via ldapmodify) to make this working. Can you share what is the motivation for this change? I see requests to rather add additional (older) encryption types, not removing the current ones. Thanks, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Disable AES256 Encryption
Ok, though in that case the application has 3 other encryption types to kinit with (in default configuration) Martin On 07/21/2014 04:28 PM, Eldo Joseph wrote: Martin, Application compatible issue, AES256 is not been supported. Thanks, Eldo On 21/07/2014 7:15 pm, Martin Kosek mko...@redhat.com wrote: On 07/21/2014 03:38 PM, Eldo Joseph wrote: Is it possible to disable AES256 Encryption from IPA, while making Kerberos principals... -Eldo- I think you would need to hand update krbDefaultEncSaltTypes in cn=YOUR-REALM,cn=kerberos,SUFFIX (via ldapmodify) to make this working. Can you share what is the motivation for this change? I see requests to rather add additional (older) encryption types, not removing the current ones. Thanks, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] attribute dnaremotebindmethod not allowed
On 07/17/2014 04:56 PM, Anthony Messina wrote: After upgrading to Fedora 20's stable 389-ds-base-1.3.2.19-1.fc20.x86_64, I noticed the following errors during the restart cycle. I have a simple 2 host MMR setup. Should I be concerned about these? If so, I'd be open to recommendations. Thanks. -A [17/Jul/2014:07:51:50 -0500] - Entry dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix- ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com -- attribute dnaremotebindmethod not allowed [17/Jul/2014:07:51:50 -0500] dna-plugin - dna_update_shared_config: Unable to update shared config entry: dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix- ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com [error 65] CC-ing Ludwig and Thierry. Is it possible that 389 DS schema was not updated during it's upgrade? (Maybe related to https://fedorahosted.org/389/ticket/47779?) FreeIPA itself does not touch these attributes (yet). Thanks, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] PatternFly questions
On 07/18/2014 03:12 PM, Dmitri Pal wrote: On 07/18/2014 08:17 AM, Innes, Duncan wrote: Hi Petr, On 18/07/2014 11:24, Petr Vobornik wrote: Hello Duncan, thank you for the input. If you or somebody else have any Web UI ideas/RFEs, feel free to write them down. I would like to know what people don't like or would like to have. On 18.7.2014 10:21, Innes, Duncan wrote: Just poking around the new 4.0 demo page and very much liking what I see. This will make a big difference in use on large estates. A couple PatternFly related questions though: 1. The tables don't sort by column if I click on a column header. Is this not available in PatternFly yet, or have FreeIPA decided against implementing it? First just a note about PatternFly. It's not really a widget library, it is(or should be) more of a set of patterns and styles. But the referential implementation is built on Bootstrap 3, so it is very easy to adopt. PatternFly doesn't have an official pattern for table sorting yet, but it has styles for DataTables (jQuery table plugin) which can do it. I don't remember any decision against it - could be implemented if there is enough will and user demand. Sorting can be done on client side and on server side. Client side is limited to issue #2 - only 20 items, so it is not really helpful. And server side (IPA API) doesn't support specifying a sort attribute atm. You would like the server-side sorting, right? Hadn't considered there to be an option. When I looked at the PatternFly demos I hadn't thought about it, but the speed that FreeIPA pulls data out for rendering, I suppose it would have to be. Even our modest estate (at a few hundred users and hosts) would slow down far too much if the full dataset was sent. The other possibilities thrown up by PatternFly are also interesting; add/remove columns, resize columns etc. I know some of these are still on the drawing board, but there are demo pages available already. 2. Browsing the screen on a large monitor still leaves the user page (at least) limited to around 22 rows. This leaves the bottom third of my browser empty. The table uses the full width of the browser, can it not use the full height too? I have and idea/plan to make it configurable - to specify the number of items and also to allow disabling of paging. The more rows the slower the UI is. Also paging has its own issues which are not straightforward to solve: - http://www.redhat.com/archives/freeipa-devel/2012-August/msg00295.html True. What's the biggest time factor in loading large tables? When admining estates with tens of thousands of entries, however, much emphasis needs to be placed on the table filters. No admin in their right mind is going to be performing actions on all entries simultaneously. Similar to Foreman's filters, could FreeIPA allow (example) in the hosts screen a filter of hostgroup = groupX to show only hosts belonging to that group? Or filtering users with manager = 'Duncan Innes'? Please open RFEs. This is really a valuable feedback. I think we are somewhat talking about this RFE: https://fedorahosted.org/freeipa/ticket/2388 Maybe it is time to resurrect it from Ticket Deferred milestone given it would bring big value for large user deployments. The API and the mighty LDAP search engine is already there: ipa user-add --first=Test --last=User manager ipa user-add --first=Test --last=User employee --manager manager ipa user-add --first=Test --last=User employee2 --manager manager ipa group-add testgroup --desc test ipa group-add-member testgroup --users employee2 # ipa user-find --manager manager --pkey-only --- 2 users matched --- User login: employee User login: employee2 Number of entries returned 2 # ipa user-find --manager manager --in-group testgroup --pkey-only -- 1 user matched -- User login: employee2 Number of entries returned 1 So we would just need to utilize it in our Web UI. I personally really like the simple search tags like below manager: manager X in groups: testgroup X that can be seen in some web apps or eshops and which are pretty easy to control. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Add user principal with admin privilege
On 07/18/2014 03:16 PM, Eldo Joseph wrote: Hi, Is it possible to add a user principal with admin privileges. like kadmin: addprinc -randkey user1/ad...@domain.com when ever tried I got this Kerberos database constraints violated Thanks, Eldo We do not allow adding principals by kadmin on purpose. Kerberos principals of FreeIPA user/service/host are being added via FreeIPA commands which fills all required and expected attributes. We are considering allowing adding external realm principal though, ticket filed: https://fedorahosted.org/freeipa/ticket/4059 https://bugzilla.redhat.com/show_bug.cgi?id=1035494#c3 HTH, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Error comes out at command prompt after add Godaddy cert
On 06/17/2014 03:39 AM, barry...@gmail.com wrote: Now cannot use ipa command line like ipa passwd, any missing ? need reimport back the ipa cert? ipa: ERROR: did not receive Kerberos credentials certutil -d /etc/dirsrv/slapd-ABC-COM -L Go Daddy Secure Certification Authority - The Go Daddy Group, Inc. ,, Go Daddy Class 2 Certification Authority - The Go Daddy Group, Inc. CT,C,C *.abc.com - GoDaddy.com, Inc. u,u,u Hello, I would recommend following this page: http://www.freeipa.org/page/Troubleshooting#Authentication.2FKerberos ... and providing more information so that people on the list can help. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Error comes out at command prompt after add Godaddy cert - SOLVED
On 06/17/2014 09:35 AM, Martin Kosek wrote: On 06/17/2014 03:39 AM, barry...@gmail.com wrote: Now cannot use ipa command line like ipa passwd, any missing ? need reimport back the ipa cert? ipa: ERROR: did not receive Kerberos credentials certutil -d /etc/dirsrv/slapd-ABC-COM -L Go Daddy Secure Certification Authority - The Go Daddy Group, Inc. ,, Go Daddy Class 2 Certification Authority - The Go Daddy Group, Inc. CT,C,C *.abc.com - GoDaddy.com, Inc. u,u,u Hello, I would recommend following this page: http://www.freeipa.org/page/Troubleshooting#Authentication.2FKerberos ... and providing more information so that people on the list can help. Martin Resending private mail from barrykfl to close this thread: Original Message Subject: Re: [Freeipa-users] Error comes out at command prompt after add Godaddy cert Date: Tue, 17 Jun 2014 15:39:31 +0800 From: barry...@gmail.com To: Martin Kosek mko...@redhat.com solved ... add goddaddy cert in nssdb it it a bit complicated if using external cert ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] FreeIPA public demo available
Hello all FreeIPA users and enthusiasts! I would like to invite everyone to try our new public FreeIPA demo instance running on Red Hat OpenStack platform: http://www.freeipa.org/page/Demo The demo will always hold the latest stable version of FreeIPA or a Beta version of a next major release (e.g. when 4.0 Beta is available). The demo is great for: * Testing changes and enhancements in the most recent CLI/Web UI/API * Testing integration in the OS - FreeIPA clients can be enrolled * Testing web applications with LDAP/Kerberos authentication and advanced integration with FreeIPA You can read all the details in the page referred above. Feedback welcome! -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Setting up FreeIPA with replicas without DNS
No worries. Note that at the end of ipa-server-install, you get a list of DNS records (SRV, A) required to be added (in a BIND zone format). Additional required updates caused by new/removed FreeIPA replicas are on your own though. Martin On 05/28/2014 10:44 AM, rob.har...@stfc.ac.uk wrote: Well, after sending my query I started going back over the FreeIPA documentation again and found information that I should probably be using SRV records in DNS to handle the load balancing. I will look into this and figure out what I need to request of the site network team. Apologies for cluttering up your inboxes! Rob -Original Message- From: rob.har...@stfc.ac.uk [mailto:rob.har...@stfc.ac.uk] Sent: 28 May 2014 09:14 To: freeipa-users@redhat.com Subject: [Freeipa-users] Setting up FreeIPA with replicas without DNS Hi all, I am wanting to set up a FreeIPA domain for controlling a group of machines on our network, and want to use replica servers for resilience. However, I do not have control over DNS: our site prefers to use a central DNS service, which I can easily request changes in, but I don't have flexibility there. I will, at this point, admit to not knowing a great deal about the workings of DNS, so if I am asking dumb questions, please feel free to point me at an RFC, howto or other documentation so I can get educated. So I am trying to work out the best way to set things up. My initial hunch was that I should get A-records set up to provide a DNS round robin for the service. The problem appears to be that if I install FreeIPA on the servers using their own hostnames, their host certificates won't match the A-record, and if I set up FreeIPA to use the round robin hostname, it just doesn't look right to me. I hope I have managed to explain my situation appropriately. I haven't been able to find documentation to help me with this (I suspect I just need to understand a few different aspects better than I do already), so can someone point me in the right direction, please? Many thanks, Rob -- Scanned by iCritical. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Stock with a Master in read-only mode
On 05/26/2014 09:00 PM, Davis Goodman wrote: On Mon, May 26, 2014 at 1:17 PM, Davis Goodman davis.good...@digital-district.ca wrote: On Mon, May 26, 2014 at 4:22 AM, Martin Kosek mko...@redhat.com wrote: On 05/25/2014 09:44 PM, Davis Goodman wrote: On Wed, May 21, 2014 at 12:06 PM, Martin Kosek mko...@redhat.com wrote: On 05/21/2014 01:31 PM, Davis Goodman wrote: http://www.digital-district.ca/ On May 21, 2014, at 6:54 , Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 05/21/2014 09:12 AM, Davis Goodman wrote: On May 21, 2014, at 2:45 , Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 05/21/2014 08:36 AM, Davis Goodman wrote: Hi, Lately I’ve been having issues of replication between my server and my 2 replicas. I decided I was going to delete my 2 replicas and start over keeping my master intact. I wasn`t successfull in getting all 3 servers to replicate to each other. ( it used to work) I tried deleting 1 replica after the other one to always keep one of the two available. I had to delete manually the replica host on the master with a bunch of ldapdelete command which worked fine. But after many unsuccessful trials of getting everyone to sync I decided to delete my two replicas. I went back to my master to use the ldapdelete to remove both host`s records so that I could start over. Unfortunately now I’m getting this error. ldapdelete -x -D cn=Directory Manager -W cn=DNS,cn=freeipa02.mtl.domain.int ,cn=masters,cn=ipa,cn=etc,dc=domain,dc=int Enter LDAP Password: ldap_delete: Server is unwilling to perform (53) additional info: database is read-only I’m kinda stuck now with no replicas and no DNS. I could restore the backup prior to the start of the operation but with a master in read-only mode it wouldn’t of much help. Any insights would be more than welcome. Davis Hi Davis, did maybe some of your ipa-replica-manage crashed in a middle of an operation or an upgrade was interrupted and left the database put in read only mode? You can find out with this ldapsearch: ldapsearch -h `hostname` -D cn=Directory Manager -x -w kokos123 -b 'cn=userRoot,cn=ldbm database,cn=plugins,cn=config' -s base Check for nsslapd-readonly, it should be put to off in normal operation. Martin Ok finally managed to modify the read-only flag. Could prepare my replicas and get them going. Everything seems fine but I’m getting this error while setting up the replicas. Should I be concerned about this one: Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Update succeeded [23/31]: adding replication acis [24/31]: setting Auto Member configuration [25/31]: enabling S4U2Proxy delegation ipa : CRITICAL Failed to load replica-s4u2proxy.ldif: Command '/usr/bin/ldapmodify -v -f /tmp/tmplpfMNG -H ldap://freeipa02.mtl.ddistrict.int:389 -x -D cn=Directory Manager -y /tmp/tmp4Svn9k' returned non-zero exit status 20 [26/31]: initializing group membership [27/31]: adding master entry [28/31]: configuring Posix uid/gid generation the rest seems to work fine. You need to check ipareplica-install.log to see the real error. I wonder if cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,YOUR-SUFFIX and cn=ipa-ldap-delegation,cn=s4u2proxy,cn=etc,YOUR-SUFFIX exist. Martin The first one is there: ldapsearch -D cn=Directory Manager” -W -LLL -x -b cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=ddistrict,dc=int dn: cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=ddistrict,dc=int ipaAllowedTarget: cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,dc=ddistr ict,dc=int ipaAllowedTarget: cn=ipa-cifs-delegation-targets,cn=s4u2proxy,cn=etc,dc=ddistr ict,dc=int memberPrincipal: HTTP/freeipa01.prs.ddistrict@ddistrict.int mailto:HTTP/freeipa01.prs.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa02.prs.ddistrict@ddistrict.int mailto:HTTP/freeipa02.prs.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa02.mtl.ddistrict@ddistrict.int mailto:HTTP/freeipa02.mtl.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa01.chr.ddistrict@ddistrict.int mailto:HTTP/freeipa01.chr.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa01.bxl.ddistrict@ddistrict.int mailto:HTTP/freeipa01.bxl.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa01.mtl.ddistrict@ddistrict.int mailto:HTTP/freeipa01.mtl.ddistrict@ddistrict.int cn: ipa-http-delegation objectClass: ipaKrb5DelegationACL objectClass: groupOfPrincipals objectClass: top But not the second one: ldapsearch -D cn=Directory Manager” -W -LLL -x -b cn=ipa-ldap-delegation,cn=s4u2proxy,cn=etc,dc=ddistrict,dc=int No such object (32) Matched DN: cn=s4u2proxy,cn=etc,dc=ddistrict,dc=int Also what is strange is that I got the error only on one of the replicas, the other one went through without
Re: [Freeipa-users] Stock with a Master in read-only mode - SOLVED
On 05/27/2014 01:12 PM, Martin Kosek wrote: On 05/26/2014 09:00 PM, Davis Goodman wrote: On Mon, May 26, 2014 at 1:17 PM, Davis Goodman davis.good...@digital-district.ca wrote: On Mon, May 26, 2014 at 4:22 AM, Martin Kosek mko...@redhat.com wrote: On 05/25/2014 09:44 PM, Davis Goodman wrote: On Wed, May 21, 2014 at 12:06 PM, Martin Kosek mko...@redhat.com wrote: On 05/21/2014 01:31 PM, Davis Goodman wrote: http://www.digital-district.ca/ On May 21, 2014, at 6:54 , Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 05/21/2014 09:12 AM, Davis Goodman wrote: On May 21, 2014, at 2:45 , Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 05/21/2014 08:36 AM, Davis Goodman wrote: Hi, Lately I’ve been having issues of replication between my server and my 2 replicas. I decided I was going to delete my 2 replicas and start over keeping my master intact. I wasn`t successfull in getting all 3 servers to replicate to each other. ( it used to work) I tried deleting 1 replica after the other one to always keep one of the two available. I had to delete manually the replica host on the master with a bunch of ldapdelete command which worked fine. But after many unsuccessful trials of getting everyone to sync I decided to delete my two replicas. I went back to my master to use the ldapdelete to remove both host`s records so that I could start over. Unfortunately now I’m getting this error. ldapdelete -x -D cn=Directory Manager -W cn=DNS,cn=freeipa02.mtl.domain.int ,cn=masters,cn=ipa,cn=etc,dc=domain,dc=int Enter LDAP Password: ldap_delete: Server is unwilling to perform (53) additional info: database is read-only I’m kinda stuck now with no replicas and no DNS. I could restore the backup prior to the start of the operation but with a master in read-only mode it wouldn’t of much help. Any insights would be more than welcome. Davis Hi Davis, did maybe some of your ipa-replica-manage crashed in a middle of an operation or an upgrade was interrupted and left the database put in read only mode? You can find out with this ldapsearch: ldapsearch -h `hostname` -D cn=Directory Manager -x -w kokos123 -b 'cn=userRoot,cn=ldbm database,cn=plugins,cn=config' -s base Check for nsslapd-readonly, it should be put to off in normal operation. Martin Ok finally managed to modify the read-only flag. Could prepare my replicas and get them going. Everything seems fine but I’m getting this error while setting up the replicas. Should I be concerned about this one: Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Update succeeded [23/31]: adding replication acis [24/31]: setting Auto Member configuration [25/31]: enabling S4U2Proxy delegation ipa : CRITICAL Failed to load replica-s4u2proxy.ldif: Command '/usr/bin/ldapmodify -v -f /tmp/tmplpfMNG -H ldap://freeipa02.mtl.ddistrict.int:389 -x -D cn=Directory Manager -y /tmp/tmp4Svn9k' returned non-zero exit status 20 [26/31]: initializing group membership [27/31]: adding master entry [28/31]: configuring Posix uid/gid generation the rest seems to work fine. You need to check ipareplica-install.log to see the real error. I wonder if cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,YOUR-SUFFIX and cn=ipa-ldap-delegation,cn=s4u2proxy,cn=etc,YOUR-SUFFIX exist. Martin The first one is there: ldapsearch -D cn=Directory Manager” -W -LLL -x -b cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=ddistrict,dc=int dn: cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=ddistrict,dc=int ipaAllowedTarget: cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,dc=ddistr ict,dc=int ipaAllowedTarget: cn=ipa-cifs-delegation-targets,cn=s4u2proxy,cn=etc,dc=ddistr ict,dc=int memberPrincipal: HTTP/freeipa01.prs.ddistrict@ddistrict.int mailto:HTTP/freeipa01.prs.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa02.prs.ddistrict@ddistrict.int mailto:HTTP/freeipa02.prs.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa02.mtl.ddistrict@ddistrict.int mailto:HTTP/freeipa02.mtl.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa01.chr.ddistrict@ddistrict.int mailto:HTTP/freeipa01.chr.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa01.bxl.ddistrict@ddistrict.int mailto:HTTP/freeipa01.bxl.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa01.mtl.ddistrict@ddistrict.int mailto:HTTP/freeipa01.mtl.ddistrict@ddistrict.int cn: ipa-http-delegation objectClass: ipaKrb5DelegationACL objectClass: groupOfPrincipals objectClass: top But not the second one: ldapsearch -D cn=Directory Manager” -W -LLL -x -b cn=ipa-ldap-delegation,cn=s4u2proxy,cn=etc,dc=ddistrict,dc=int No such object (32) Matched DN: cn=s4u2proxy,cn=etc,dc=ddistrict,dc=int Also what is strange is that I got the error only on one
Re: [Freeipa-users] Stock with a Master in read-only mode
On 05/25/2014 09:44 PM, Davis Goodman wrote: On Wed, May 21, 2014 at 12:06 PM, Martin Kosek mko...@redhat.com wrote: On 05/21/2014 01:31 PM, Davis Goodman wrote: http://www.digital-district.ca/ On May 21, 2014, at 6:54 , Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 05/21/2014 09:12 AM, Davis Goodman wrote: On May 21, 2014, at 2:45 , Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 05/21/2014 08:36 AM, Davis Goodman wrote: Hi, Lately I’ve been having issues of replication between my server and my 2 replicas. I decided I was going to delete my 2 replicas and start over keeping my master intact. I wasn`t successfull in getting all 3 servers to replicate to each other. ( it used to work) I tried deleting 1 replica after the other one to always keep one of the two available. I had to delete manually the replica host on the master with a bunch of ldapdelete command which worked fine. But after many unsuccessful trials of getting everyone to sync I decided to delete my two replicas. I went back to my master to use the ldapdelete to remove both host`s records so that I could start over. Unfortunately now I’m getting this error. ldapdelete -x -D cn=Directory Manager -W cn=DNS,cn=freeipa02.mtl.domain.int ,cn=masters,cn=ipa,cn=etc,dc=domain,dc=int Enter LDAP Password: ldap_delete: Server is unwilling to perform (53) additional info: database is read-only I’m kinda stuck now with no replicas and no DNS. I could restore the backup prior to the start of the operation but with a master in read-only mode it wouldn’t of much help. Any insights would be more than welcome. Davis Hi Davis, did maybe some of your ipa-replica-manage crashed in a middle of an operation or an upgrade was interrupted and left the database put in read only mode? You can find out with this ldapsearch: ldapsearch -h `hostname` -D cn=Directory Manager -x -w kokos123 -b 'cn=userRoot,cn=ldbm database,cn=plugins,cn=config' -s base Check for nsslapd-readonly, it should be put to off in normal operation. Martin Ok finally managed to modify the read-only flag. Could prepare my replicas and get them going. Everything seems fine but I’m getting this error while setting up the replicas. Should I be concerned about this one: Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Update succeeded [23/31]: adding replication acis [24/31]: setting Auto Member configuration [25/31]: enabling S4U2Proxy delegation ipa : CRITICAL Failed to load replica-s4u2proxy.ldif: Command '/usr/bin/ldapmodify -v -f /tmp/tmplpfMNG -H ldap://freeipa02.mtl.ddistrict.int:389 -x -D cn=Directory Manager -y /tmp/tmp4Svn9k' returned non-zero exit status 20 [26/31]: initializing group membership [27/31]: adding master entry [28/31]: configuring Posix uid/gid generation the rest seems to work fine. You need to check ipareplica-install.log to see the real error. I wonder if cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,YOUR-SUFFIX and cn=ipa-ldap-delegation,cn=s4u2proxy,cn=etc,YOUR-SUFFIX exist. Martin The first one is there: ldapsearch -D cn=Directory Manager” -W -LLL -x -b cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=ddistrict,dc=int dn: cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=ddistrict,dc=int ipaAllowedTarget: cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,dc=ddistr ict,dc=int ipaAllowedTarget: cn=ipa-cifs-delegation-targets,cn=s4u2proxy,cn=etc,dc=ddistr ict,dc=int memberPrincipal: HTTP/freeipa01.prs.ddistrict@ddistrict.int mailto:HTTP/freeipa01.prs.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa02.prs.ddistrict@ddistrict.int mailto:HTTP/freeipa02.prs.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa02.mtl.ddistrict@ddistrict.int mailto:HTTP/freeipa02.mtl.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa01.chr.ddistrict@ddistrict.int mailto:HTTP/freeipa01.chr.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa01.bxl.ddistrict@ddistrict.int mailto:HTTP/freeipa01.bxl.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa01.mtl.ddistrict@ddistrict.int mailto:HTTP/freeipa01.mtl.ddistrict@ddistrict.int cn: ipa-http-delegation objectClass: ipaKrb5DelegationACL objectClass: groupOfPrincipals objectClass: top But not the second one: ldapsearch -D cn=Directory Manager” -W -LLL -x -b cn=ipa-ldap-delegation,cn=s4u2proxy,cn=etc,dc=ddistrict,dc=int No such object (32) Matched DN: cn=s4u2proxy,cn=etc,dc=ddistrict,dc=int Also what is strange is that I got the error only on one of the replicas, the other one went through without any hiccups. Ok, I think I misguided you with the second DN, the real DN should be cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,dc=ddistrict,dc=int, see /usr/share/ipa/replica-s4u2proxy.ldif for the LDIF that is being
Re: [Freeipa-users] Export user and host list to a csv or text file
On 05/23/2014 06:42 AM, Sanju A wrote: Dear All, Is there any command to export the user and host list to a csv or text format There is no such command out of the shelf, I would personally just write a short Python script to export the hosts (or anything else) in a format I need. Example for host: ~ #!/usr/bin/python2 from ipalib import api api.bootstrap(context='exporter', debug=False) api.finalize() api.Backend.xmlclient.connect() hosts = api.Command['host_find']()['result'] for host in hosts: print host['fqdn'][0] ~ This will print one host for each new line. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Wildcard DNS record supported ?
On 05/23/2014 12:15 PM, Matt . wrote: Hi All, Is a wildcard DNS record supported at the moment ? If so, how to accomplish this ? Thanks! Matt It is not supported at the moment, but it will be supported from FreeIPA 4.0 (currently planned to be released at the end of June) Upstream ticket: https://fedorahosted.org/freeipa/ticket/3148 Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Wildcard DNS record supported ?
On 05/23/2014 03:44 PM, Petr Spacek wrote: On 23.5.2014 13:59, Matt . wrote: Hi Martin, I have seen it indeed and discusses on #freeipa Is it not possible to install bind-dyndb-ldap 4.0 manually on CentOS 6.5 ? In theory yes, but nobody tested that. Please note that new bind-dyndb-ldap will allow you to use wildcards but you will have to use use LDAP editor to add wildcard records manually. Old FreeIPA will refuse to add wildcard records (because the validator is not inside bind-dyndb-ldap but inside FreeIPA). Anyway, feel free to download http://kojipkgs.fedoraproject.org//packages/bind-dyndb-ldap/4.3/1.fc20/src/bind-dyndb-ldap-4.3-1.fc20.src.rpm and rebuild it on CentOS 6.5. You will have to lower required version of BIND in SPEC file. Please note that it is completely untested. Let me know if you have any further questions. Petr Spacek Wouldn't Matt also need to rebuild BIND and it's libraries? bind-dyndb-ldap and BIND are pretty bound together. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Export user and host list to a csv or text file
Right, that's a good suggestion and should work in many use cases. You will just miss attributes or modifications done inside FreeIPA server framework plugins (e.g. conversion of DNS IDN name from punycode to unicode). Martin On 05/23/2014 02:39 PM, Chris Swingler wrote: Another alternative is to use Apache Directory Studio; it can dump most objects out into a CSV, and you should be able to filter out only the data you want. On May 23, 2014, at 7:33 AM, Petr Vobornik pvobo...@redhat.com wrote: On 23.5.2014 14:02, Bret Wortman wrote: Is the Python API documented anywhere? I've looked around without success. Not yet. For now, you can use IPA CLI for inspection: CLI commands are basically API commands, where `_` is replaced by `-`. List objects: `ipa help topics` List object commands: `ipa help $object`, e.g., `ipa help user` List command CLI options and parameters: `ipa $command --help`, e.g., `ipa user-mod --help` Map command params and options names to API option names: `ipa show-mappings $command`, e.g., `ipa show-mappings user-add` More can be read from code or by observing Web UI communication in browser developer tools - network tab. Then the python syntax is ~ args = ['arg1', 'arg2'] options = dict(option1=foo, option2=bar) api.Command['command_name'](*args, **options) HTH On 05/23/2014 07:54 AM, Martin Kosek wrote: On 05/23/2014 06:42 AM, Sanju A wrote: Dear All, Is there any command to export the user and host list to a csv or text format There is no such command out of the shelf, I would personally just write a short Python script to export the hosts (or anything else) in a format I need. Example for host: ~ #!/usr/bin/python2 from ipalib import api api.bootstrap(context='exporter', debug=False) api.finalize() api.Backend.xmlclient.connect() hosts = api.Command['host_find']()['result'] for host in hosts: print host['fqdn'][0] ~ This will print one host for each new line. Martin -- Petr Vobornik ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Stock with a Master in read-only mode
On 05/21/2014 08:36 AM, Davis Goodman wrote: Hi, Lately I’ve been having issues of replication between my server and my 2 replicas. I decided I was going to delete my 2 replicas and start over keeping my master intact. I wasn`t successfull in getting all 3 servers to replicate to each other. ( it used to work) I tried deleting 1 replica after the other one to always keep one of the two available. I had to delete manually the replica host on the master with a bunch of ldapdelete command which worked fine. But after many unsuccessful trials of getting everyone to sync I decided to delete my two replicas. I went back to my master to use the ldapdelete to remove both host`s records so that I could start over. Unfortunately now I’m getting this error. ldapdelete -x -D cn=Directory Manager -W cn=DNS,cn=freeipa02.mtl.domain.int,cn=masters,cn=ipa,cn=etc,dc=domain,dc=int Enter LDAP Password: ldap_delete: Server is unwilling to perform (53) additional info: database is read-only I’m kinda stuck now with no replicas and no DNS. I could restore the backup prior to the start of the operation but with a master in read-only mode it wouldn’t of much help. Any insights would be more than welcome. Davis Hi Davis, did maybe some of your ipa-replica-manage crashed in a middle of an operation or an upgrade was interrupted and left the database put in read only mode? You can find out with this ldapsearch: ldapsearch -h `hostname` -D cn=Directory Manager -x -w kokos123 -b 'cn=userRoot,cn=ldbm database,cn=plugins,cn=config' -s base Check for nsslapd-readonly, it should be put to off in normal operation. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Stock with a Master in read-only mode
On 05/21/2014 09:12 AM, Davis Goodman wrote: On May 21, 2014, at 2:45 , Martin Kosek mko...@redhat.com wrote: On 05/21/2014 08:36 AM, Davis Goodman wrote: Hi, Lately I’ve been having issues of replication between my server and my 2 replicas. I decided I was going to delete my 2 replicas and start over keeping my master intact. I wasn`t successfull in getting all 3 servers to replicate to each other. ( it used to work) I tried deleting 1 replica after the other one to always keep one of the two available. I had to delete manually the replica host on the master with a bunch of ldapdelete command which worked fine. But after many unsuccessful trials of getting everyone to sync I decided to delete my two replicas. I went back to my master to use the ldapdelete to remove both host`s records so that I could start over. Unfortunately now I’m getting this error. ldapdelete -x -D cn=Directory Manager -W cn=DNS,cn=freeipa02.mtl.domain.int,cn=masters,cn=ipa,cn=etc,dc=domain,dc=int Enter LDAP Password: ldap_delete: Server is unwilling to perform (53) additional info: database is read-only I’m kinda stuck now with no replicas and no DNS. I could restore the backup prior to the start of the operation but with a master in read-only mode it wouldn’t of much help. Any insights would be more than welcome. Davis Hi Davis, did maybe some of your ipa-replica-manage crashed in a middle of an operation or an upgrade was interrupted and left the database put in read only mode? You can find out with this ldapsearch: ldapsearch -h `hostname` -D cn=Directory Manager -x -w kokos123 -b 'cn=userRoot,cn=ldbm database,cn=plugins,cn=config' -s base Check for nsslapd-readonly, it should be put to off in normal operation. Martin Ok finally managed to modify the read-only flag. Could prepare my replicas and get them going. Everything seems fine but I’m getting this error while setting up the replicas. Should I be concerned about this one: Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Update succeeded [23/31]: adding replication acis [24/31]: setting Auto Member configuration [25/31]: enabling S4U2Proxy delegation ipa : CRITICAL Failed to load replica-s4u2proxy.ldif: Command '/usr/bin/ldapmodify -v -f /tmp/tmplpfMNG -H ldap://freeipa02.mtl.ddistrict.int:389 -x -D cn=Directory Manager -y /tmp/tmp4Svn9k' returned non-zero exit status 20 [26/31]: initializing group membership [27/31]: adding master entry [28/31]: configuring Posix uid/gid generation the rest seems to work fine. You need to check ipareplica-install.log to see the real error. I wonder if cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,YOUR-SUFFIX and cn=ipa-ldap-delegation,cn=s4u2proxy,cn=etc,YOUR-SUFFIX exist. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Stock with a Master in read-only mode
On 05/21/2014 01:31 PM, Davis Goodman wrote: http://www.digital-district.ca/ On May 21, 2014, at 6:54 , Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 05/21/2014 09:12 AM, Davis Goodman wrote: On May 21, 2014, at 2:45 , Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 05/21/2014 08:36 AM, Davis Goodman wrote: Hi, Lately I’ve been having issues of replication between my server and my 2 replicas. I decided I was going to delete my 2 replicas and start over keeping my master intact. I wasn`t successfull in getting all 3 servers to replicate to each other. ( it used to work) I tried deleting 1 replica after the other one to always keep one of the two available. I had to delete manually the replica host on the master with a bunch of ldapdelete command which worked fine. But after many unsuccessful trials of getting everyone to sync I decided to delete my two replicas. I went back to my master to use the ldapdelete to remove both host`s records so that I could start over. Unfortunately now I’m getting this error. ldapdelete -x -D cn=Directory Manager -W cn=DNS,cn=freeipa02.mtl.domain.int,cn=masters,cn=ipa,cn=etc,dc=domain,dc=int Enter LDAP Password: ldap_delete: Server is unwilling to perform (53) additional info: database is read-only I’m kinda stuck now with no replicas and no DNS. I could restore the backup prior to the start of the operation but with a master in read-only mode it wouldn’t of much help. Any insights would be more than welcome. Davis Hi Davis, did maybe some of your ipa-replica-manage crashed in a middle of an operation or an upgrade was interrupted and left the database put in read only mode? You can find out with this ldapsearch: ldapsearch -h `hostname` -D cn=Directory Manager -x -w kokos123 -b 'cn=userRoot,cn=ldbm database,cn=plugins,cn=config' -s base Check for nsslapd-readonly, it should be put to off in normal operation. Martin Ok finally managed to modify the read-only flag. Could prepare my replicas and get them going. Everything seems fine but I’m getting this error while setting up the replicas. Should I be concerned about this one: Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Update succeeded [23/31]: adding replication acis [24/31]: setting Auto Member configuration [25/31]: enabling S4U2Proxy delegation ipa : CRITICAL Failed to load replica-s4u2proxy.ldif: Command '/usr/bin/ldapmodify -v -f /tmp/tmplpfMNG -H ldap://freeipa02.mtl.ddistrict.int:389 -x -D cn=Directory Manager -y /tmp/tmp4Svn9k' returned non-zero exit status 20 [26/31]: initializing group membership [27/31]: adding master entry [28/31]: configuring Posix uid/gid generation the rest seems to work fine. You need to check ipareplica-install.log to see the real error. I wonder if cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,YOUR-SUFFIX and cn=ipa-ldap-delegation,cn=s4u2proxy,cn=etc,YOUR-SUFFIX exist. Martin The first one is there: ldapsearch -D cn=Directory Manager” -W -LLL -x -b cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=ddistrict,dc=int dn: cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=ddistrict,dc=int ipaAllowedTarget: cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,dc=ddistr ict,dc=int ipaAllowedTarget: cn=ipa-cifs-delegation-targets,cn=s4u2proxy,cn=etc,dc=ddistr ict,dc=int memberPrincipal: HTTP/freeipa01.prs.ddistrict@ddistrict.int mailto:HTTP/freeipa01.prs.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa02.prs.ddistrict@ddistrict.int mailto:HTTP/freeipa02.prs.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa02.mtl.ddistrict@ddistrict.int mailto:HTTP/freeipa02.mtl.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa01.chr.ddistrict@ddistrict.int mailto:HTTP/freeipa01.chr.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa01.bxl.ddistrict@ddistrict.int mailto:HTTP/freeipa01.bxl.ddistrict@ddistrict.int memberPrincipal: HTTP/freeipa01.mtl.ddistrict@ddistrict.int mailto:HTTP/freeipa01.mtl.ddistrict@ddistrict.int cn: ipa-http-delegation objectClass: ipaKrb5DelegationACL objectClass: groupOfPrincipals objectClass: top But not the second one: ldapsearch -D cn=Directory Manager” -W -LLL -x -b cn=ipa-ldap-delegation,cn=s4u2proxy,cn=etc,dc=ddistrict,dc=int No such object (32) Matched DN: cn=s4u2proxy,cn=etc,dc=ddistrict,dc=int Also what is strange is that I got the error only on one of the replicas, the other one went through without any hiccups. Ok, I think I misguided you with the second DN, the real DN should be cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,dc=ddistrict,dc=int, see /usr/share/ipa/replica-s4u2proxy.ldif for the LDIF that is being loaded. The key here is to check the error message of ldapmodify that was run
Re: [Freeipa-users] Have existing wildcard SSL from RapidSSL how to implement?
On 05/17/2014 04:22 AM, Chris Whittle wrote: I have an existing key and crt that has be successfully installed on other subdomain servers... Where is the best place to start? To start what? :-) Without knowing what you want to achieve, I would like to point you to our training presentation describing different FreeIPA Certificate infrastructure integration procedures: http://www.freeipa.org/images/b/b3/FreeIPA33-blending-in-a-certificate-infrastructure.pdf I would like to especially point you to the CA-less integration type. HTH, Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Theming FreeIPA
On 05/17/2014 04:27 PM, Christopher Swingler wrote: Short and to the point, but I have the same question. :) On May 16, 2014, at 9:08 PM, Chris Whittle cwhi...@gmail.com wrote: Is there a doc anywhere? CC-ing Petr Vobornik to help with that. You can already achieve some theming with overriding the CSS + utilizing Web UI plugins we already have in FreeIPA Web UI. Note that Web UI in FreeIPA 4.0 will change extensively as it migrated to Patternfly project, I wonder if there are more theming options then. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Best practices for core servers
On 04/28/2014 01:03 PM, Bret Wortman wrote: We are planning to reconfigure our core Freeipa servers, basically building a replacement infrastructure and migrating to it. What we're planning right now is a core of three Freeipa servers each of which has a CA, with as much distribution of replication as we can manage. I imagine that means one of them replicates to the other two but am open to other ideas. You can configure them to replica to each other. For remote locations, we're planning to stand up caching-only DNS servers, as authenticating back to the main IPA servers works extremely well; it's just DNS that needs a little help. Any thoughts before I start setting these servers (VMs, most likely) up? You may want to read our upstream Deployment Recommendations article, it may save you some bad decisions from the start: http://www.freeipa.org/page/Deployment_Recommendations If we see that we missed anything in this article, it would be great to enhance it. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Hardening freeipa on the internet
On 04/28/2014 05:16 PM, Simo Sorce wrote: On Mon, 2014-04-28 at 16:11 +0100, Andrew Holway wrote: I realized that you probably want to disable anonymous access to LDAP. It will prevent random strangers to enumerate all users in your database... This sounds like a bug no? anonymous access to LDAP? Historically many Linux and Unix OSs did not authenticate to LDAP to download POSIX info, so we allow by default to access a lot of the tree anonymously. We are in the process of changing how the permissions work in 4.0, and will contextually close down a lot more of the tree letting the admin more easily configure access. So, no it is not technically a bug, but it is something you want to look out for as an admin. Simo. Let me just advertise the core feature of upcoming FreeIPA 4.0 which contains re-design of ACIs and permissions in FreeIPA: http://www.freeipa.org/page/V4/Permissions_V2 With this feature, it will be very easy to control visibility of different parts of FreeIPA DIT - i.e. for example allow POSIX user attributes for anonymous bot allow other attributes to authenticated only, same with groups, HBAC rules, ... Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA + Foreman 1.5
On 04/24/2014 10:46 PM, Dmitri Pal wrote: On 04/23/2014 07:23 PM, Stephen Benjamin wrote: ... I am not sure it is doing the right thing. In the blog you specify bindpw for SUDO, this means you are configuring SUDO without SSSD integration. If you use IPA it is a command switch on the ipa-client-install command to enable sudo, ssh or automount integration (at least in the latest versions of IPA). I think we should focus on that. I'm very interested in this... I wrote the ipaclient module a year ago to suit a specific need for me. I have some consulting customers who use it, but I haven't had much feedback about it from anyone. Suggestions for changes to how I do things would be much appreciated. The way ipaclient is doing things works on *everything*, from a 2-year old release of RH IdM, to the 3.4 nightly I tested not too long ago. Right. So this is where instead of relying on the command switches it might make sense to run commands (if they are available). I do not recall what the commands and switches are. This is where I need help from Martin and Honza. I know there is ipa-client-automount but I do not remember the names of the similar commands for SSH, SUDO and SELinux integration. I updated FreeIPA.org Client article to hold the integration information: http://www.freeipa.org/page/Client#Integration It's used in the wild, so I can't just break the compatability there -- but, can I use SSSD setup even on the older versions of IPA? Do you have some info about how to get that working? If so, I'll gladly go to that. I need help here. Martin? I am not sure I understand the question. FreeIPA client compatibility is described on the wiki: http://www.freeipa.org/page/Client#Compatibility Are we talking about ipa-client-install options compatibility, or sssd.conf compatibility or even FreeIPA API compatibility? https://fedorahosted.org/freeipa/ticket/3740 This is just a convenient command to ipa-client-install. Separate ipa-client-automount is there since FreeIPA 3.0. https://fedorahosted.org/freeipa/ticket/3358 - but one can run command after install to enable integration with SUDO Honza, martin can you please add the details about SSH and SELinux integration Sorry I did not spot the question earlier, please see the referred article I just wrote. If there are question, ask. I haven't investigated automount, maybe it's something I can consider adding to the ipaclient puppet module. I see it more as apart of the initial client setup and check boxes: do you want SUDO integration y/n; do you want automount y/n; do you want SELinux user mapping y/n; Do you want SSH integration y/n. Once you deploy you usually do not change these things because they are dictated by general policy rather than something that you turn on and off. Right, for this we'd need to extend the freeipa_snippet, and use Foreman parameters for these options. I think it's a great idea, and something I'd gladly implement. For Foreman 1.5, we've really fixed the templates now for the release, but this is something that could probably go into 1.5.1 if the details are hammered out. Martin Honza please suggest how this can be accomplished using our commands. I would assume we can assume we are dealing with 6.4 and later, right? If talking about IPA in 6.4 and older: automount - run ipa-client-automount after ipa-client-install SUDO - configure manually (details in https://fedorahosted.org/freeipa/ticket/3358). Though I am afraid that sssd in 6.4 does not have ipa sudo provider. SSH - ready after ipa-client-install SELinux - this comes with ipa-client-install automatically, though I think it was very limited before 6.5 (https://bugzilla.redhat.com/show_bug.cgi?id=914433) I'd really appreciate an issue opened about this. Where? How do older versions of IPA respond to unknown options (say, if they don't support sudoers)? I guess I need some kind of matrix of what's supported for each version, so that I can do the appropriate things. ipa-client-install will fail if unknown option is passed. # ipa-client-install --foo Usage: ipa-client-install [options] ipa-client-install: error: no such option: --foo Yes we should pass right options to the right clients but may be we can do some kind of introspaction based on the package version. Something like: if ipa-client package version is greater than X: add options k, l, m otherwise log that options k, l, m are not supported on the version if ipa-client package version is greater than Y: add options n, o, q, p otherwise log that options n, o, q, p are not supported on the version That might be a script that is run on the system rather than a part of the template and it would check the package version available and use only applicable options. Again here I would like to hear the opinion of the list. It seems to me that all integration options are available in 6.4 (see above). The only
Re: [Freeipa-users] Free IPA and Google Apps
On 04/25/2014 01:59 AM, Chris Whittle wrote: I am wanting to use Free IPA as the authentication source for Google Apps. I can't seem to find any documentation on how to accomplish this. Anyone have any experience they would be willing to share? Or install is on CentOS 6.5 fyi. I did a brief googling and it seems to me that Google Apps should be capable of LDAP based auth/synchronization: http://www.google.com/support/enterprise/static/gapps/docs/admin/en/gads/admin/config_ldap_auth.html Even better solution would be probably to use SAML: https://developers.google.com/google-apps/sso/saml_reference_implementation by utilizing a project Ipsilon that Simo (CCed) is working on. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
