From Less at imagine-sw.com Wed Oct 1 08:19:11 2014 From: Less at imagine-sw.com (Les Stott) Date: Wed, 1 Oct 2014 08:19:11 +0000 Subject: [Freeipa-users] can ipa-client-install be updated to call username/password from a file? Message-ID: <4ED173A868981548967B4FCA2707222627FE845C@AACMBXP04.exchserver.com> Hi, I am using freeipa in a rhel6 environment with ipa-3.0.0-37.el6 client. I am working on doing an unattended ipa client installation. I have it working with the following.... /usr/sbin/ipa-client-install -p admin -w -U --no-ntp While this works, while it runs, the value is visable in the output of a ps -ef command on the host when installing the ipa client. # ps -ef |grep ipa root 30284 30283 43 03:31 ? 00:00:01 /usr/bin/python -E /usr/sbin/ipa-client-install -p admin -w -U --no-ntp This represents a challenge to security, even though its only minor (as in its only there for a minute or so), but its still there and it is the admin password. Can ipa-client-install be updated to include a parameter to retrieve the admin password from a file? i.e. /usr/bin/python -E /usr/sbin/ipa-client-install -p admin -from-file /tmp/credentials -U --no-ntp That would then protect the admin password. I am not familiar with python coding. Thanks in advance, Les -------------- next part -------------- An HTML attachment was scrubbed... URL: From tompos at martos.bme.hu Wed Oct 1 08:37:33 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 01 Oct 2014 10:37:33 +0200 Subject: [Freeipa-users] can ipa-client-install be updated to call username/password from a file? In-Reply-To: <4ED173A868981548967B4FCA2707222627FE845C@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222627FE845C@AACMBXP04.exchserver.com> Message-ID: <542BBD4D.4000501@martos.bme.hu> On 10/01/2014 10:19 AM, Les Stott wrote: > > Hi, > > I am using freeipa in a rhel6 environment with ipa-3.0.0-37.el6 client. > > I am working on doing an unattended ipa client installation. I have it > working with the following?. > > /usr/sbin/ipa-client-install -p admin -w -U --no-ntp > > While this works, while it runs, the value is visable > in the output of a ps ?ef command on the host when installing the ipa > client. > > # ps -ef |grep ipa > > root 30284 30283 43 03:31 ? 00:00:01 /usr/bin/python -E > /usr/sbin/ipa-client-install -p admin -w -U --no-ntp > > This represents a challenge to security, even though its only minor > (as in its only there for a minute or so), but its still there and it > is the admin password. > > Can ipa-client-install be updated to include a parameter to retrieve > the admin password from a file? i.e. > Try it with '-W < pwfile'. t -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Wed Oct 1 09:01:24 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 01 Oct 2014 11:01:24 +0200 Subject: [Freeipa-users] can ipa-client-install be updated to call username/password from a file? In-Reply-To: <542BBD4D.4000501@martos.bme.hu> References: <4ED173A868981548967B4FCA2707222627FE845C@AACMBXP04.exchserver.com> <542BBD4D.4000501@martos.bme.hu> Message-ID: <542BC2E4.6010708@redhat.com> On 10/01/2014 10:37 AM, Tamas Papp wrote: > > On 10/01/2014 10:19 AM, Les Stott wrote: >> >> Hi, >> >> I am using freeipa in a rhel6 environment with ipa-3.0.0-37.el6 client. >> >> I am working on doing an unattended ipa client installation. I have it >> working with the following?. >> >> /usr/sbin/ipa-client-install -p admin -w -U --no-ntp >> >> While this works, while it runs, the value is visable >> in the output of a ps ?ef command on the host when installing the ipa >> client. >> >> # ps -ef |grep ipa >> >> root 30284 30283 43 03:31 ? 00:00:01 /usr/bin/python -E >> /usr/sbin/ipa-client-install -p admin -w -U --no-ntp >> >> This represents a challenge to security, even though its only minor >> (as in its only there for a minute or so), but its still there and it >> is the admin password. >> >> Can ipa-client-install be updated to include a parameter to retrieve >> the admin password from a file? i.e. >> > > Try it with '-W < pwfile'. > > t Right, you can just pipe the password to the installer. More obvious ways to specify passwords for installers are planned for 4.2: https://fedorahosted.org/freeipa/ticket/4040 -- Petr? From yiorgos-lists at stamoulis.eu Wed Oct 1 09:44:27 2014 From: yiorgos-lists at stamoulis.eu (Yiorgos Stamoulis) Date: Wed, 01 Oct 2014 09:44:27 +0000 Subject: [Freeipa-users] can ipa-client-install be updated to call username/password from a file? In-Reply-To: <4ED173A868981548967B4FCA2707222627FE845C@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222627FE845C@AACMBXP04.exchserver.com> Message-ID: <38655c79.DSq.Fz0.cS.11asNmAIf7@mailjet.com> On 01/10/14 08:19, Les Stott wrote: > > Hi, > > > > I am using freeipa in a rhel6 environment with ipa-3.0.0-37.el6 client. > > > > I am working on doing an unattended ipa client installation. I have it > working with the following?. > > > > /usr/sbin/ipa-client-install -p admin -w -U --no-ntp > > > > While this works, while it runs, the value is visable > in the output of a ps ?ef command on the host when installing the ipa > client. > > > > # ps -ef |grep ipa > > root 30284 30283 43 03:31 ? 00:00:01 /usr/bin/python -E > /usr/sbin/ipa-client-install -p admin -w -U --no-ntp > > > > This represents a challenge to security, even though its only minor > (as in its only there for a minute or so), but its still there and it > is the admin password. > > > > Can ipa-client-install be updated to include a parameter to retrieve > the admin password from a file? i.e. > > > > /usr/bin/python -E /usr/sbin/ipa-client-install -p admin ?from-file > /tmp/credentials -U --no-ntp > > > > That would then protect the admin password. > > > > I am not familiar with python coding. > > > > Thanks in advance, > > > > Les > > > Hi Les, in addition to the answers you have already received, you can create a user with the 'host enrollment' permission only, so even if the credentials are compromised the damage is minimized. I am using this on 4.0.3 but looking at an older installation the same seems available in 3.0 too. Best Regards Yiorgos -------------- next part -------------- An HTML attachment was scrubbed... URL: From yiorgos-lists at stamoulis.eu Wed Oct 1 12:11:23 2014 From: yiorgos-lists at stamoulis.eu (Yiorgos Stamoulis) Date: Wed, 01 Oct 2014 12:11:23 +0000 Subject: [Freeipa-users] freeipa 4.0.3 on RHEL/Centos7 calls fedora-domainname.service instead of rhel-domainname.service Message-ID: <7e7d0ee5.DSq.Fz0.gj.11asNnaUf5@mailjet.com> Hi Martin, not sure where to file a bug report as this is in limbo between Fedora & RHEL, so here it is: enrolling a 4.0.3 RHEL/Centos7 server fails with: Configuring example.com as NIS domain. Traceback (most recent call last): File "/usr/sbin/ipa-client-install", line 2790, in sys.exit(main()) File "/usr/sbin/ipa-client-install", line 2771, in main rval = install(options, env, fstore, statestore) File "/usr/sbin/ipa-client-install", line 2735, in install configure_nisdomain(options=options, domain=cli_domain) File "/usr/sbin/ipa-client-install", line 1391, in configure_nisdomain services.knownservices.domainname.restart() File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py", line 270, in restart capture_output=capture_output) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 346, in run raise CalledProcessError(p.returncode, arg_string, stdout) subprocess.CalledProcessError: Command ''/bin/systemctl' 'restart' 'fedora-domainname.service'' returned non-zero exit status 6 substituting fedora-domainname.service with rhel-domainname.service in /usr/lib/python2.7/site-packages/ipaplatform/fedora/services.py and /usr/lib/python2.7/site-packages/ipaplatform/services.py allows the installation to proceed. Cheers, Yiorgos -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Oct 1 13:16:59 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 01 Oct 2014 15:16:59 +0200 Subject: [Freeipa-users] freeipa 4.0.3 on RHEL/Centos7 calls fedora-domainname.service instead of rhel-domainname.service In-Reply-To: <0755465a.DSq.Fz0.gi.11asNnaUf6@mailjet.com> References: <0755465a.DSq.Fz0.gi.11asNnaUf6@mailjet.com> Message-ID: <542BFECB.3060708@redhat.com> On 10/01/2014 02:11 PM, Yiorgos Stamoulis wrote: > Hi Martin, > > not sure where to file a bug report as this is in limbo between Fedora & > RHEL, so here it is: > > enrolling a 4.0.3 RHEL/Centos7 server fails with: > > Configuring example.com as NIS domain. > Traceback (most recent call last): > File "/usr/sbin/ipa-client-install", line 2790, in > sys.exit(main()) > File "/usr/sbin/ipa-client-install", line 2771, in main > rval = install(options, env, fstore, statestore) > File "/usr/sbin/ipa-client-install", line 2735, in install > configure_nisdomain(options=options, domain=cli_domain) > File "/usr/sbin/ipa-client-install", line 1391, in configure_nisdomain > services.knownservices.domainname.restart() > File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py", > line 270, in restart > capture_output=capture_output) > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line > 346, in run > raise CalledProcessError(p.returncode, arg_string, stdout) > subprocess.CalledProcessError: Command ''/bin/systemctl' 'restart' > 'fedora-domainname.service'' returned non-zero exit status 6 > > substituting fedora-domainname.service with rhel-domainname.service in > /usr/lib/python2.7/site-packages/ipaplatform/fedora/services.py and > /usr/lib/python2.7/site-packages/ipaplatform/services.py allows the > installation to proceed. > > Cheers, > > Yiorgos > Hello Yiorgos, Yes, this is a known issue that the upstream FreeIPA Copr build for CentOS/RHEL 7.0 has. We track it in this ticket: https://fedorahosted.org/freeipa/ticket/4562 We would like to fix it within October. If you will be able to help with patches or testing, we would of course welcome it! HTH, Martin From janellenicole80 at gmail.com Wed Oct 1 13:26:55 2014 From: janellenicole80 at gmail.com (Janelle) Date: Wed, 01 Oct 2014 06:26:55 -0700 Subject: [Freeipa-users] 4.0.3 on *EL/CentOS 7? Message-ID: <542C011F.5070105@gmail.com> Hi again, Just wondering if anyone has gotten past dependency issues with getting 4.0.3 server running on RHEL/OEL/CentOS 7? Even using COPR - it wants several packages that seem to come from the Fedora stream? Thoughts? Janelle From yiorgos-lists at stamoulis.eu Wed Oct 1 13:45:02 2014 From: yiorgos-lists at stamoulis.eu (Yiorgos Stamoulis) Date: Wed, 01 Oct 2014 13:45:02 +0000 Subject: [Freeipa-users] freeipa 4.0.3 on RHEL/Centos7 calls fedora-domainname.service instead of rhel-domainname.service In-Reply-To: <542BFECB.3060708@redhat.com> References: <0755465a.DSq.Fz0.gi.11asNnaUf6@mailjet.com> <542BFECB.3060708@redhat.com> Message-ID: <22447d9b.DSq.Fz0.cS.11asNnjNJN@mailjet.com> On 01/10/14 13:16, Martin Kosek wrote: > Hello Yiorgos, > > Yes, this is a known issue that the upstream FreeIPA Copr build for CentOS/RHEL > 7.0 has. We track it in this ticket: > > https://fedorahosted.org/freeipa/ticket/4562 > > We would like to fix it within October. If you will be able to help with > patches or testing, we would of course welcome it! > > HTH, > Martin Hi Martin, Thank you for your reply and pointer. Yes, I would like to contribute to the best of my {avail,}ability. I am interested in making v4 work in EL7 as I am working towards deploying FreeIPA the coming months and I would like to avoid starting with a version that is about to be superseded or doing it on Fedora for a production environment. Best Regards, Yiorgos From shashi.dahal at spilgames.com Wed Oct 1 14:20:40 2014 From: shashi.dahal at spilgames.com (Shashi Dahal) Date: Wed, 1 Oct 2014 14:20:40 +0000 Subject: [Freeipa-users] error trying to re-setup ipa replica Message-ID: Hi, This is what I have. ipa01 - master ipa02 - replica ipa03 - replica ipa02 crashed, and re-setup I used the gpg file from master and trying to re-create the replica: ipa-replica-install ipa02.gpg gives: The host ipa02.local.zone already exists on the master server. You should remove it before proceeding: % ipa host-del ipa02.local.zone I login to the master server and if I do ipa-replica-manage list , it shows: ipa02.local.zone: master Trying to delete it with ipa host-del ipa02.local.zone fails saying: ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted or disabled ipa-replica-manage del ipa02.local.zone fails saying: 'ipa01.local.zone' has no replication agreement for 'ipa02.local.zone' I searched the mailing list and it was suggested that I should do a ldapsearch and ldapdelete. here is the search: ldapsearch -LLL -x -b cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01 dn: cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01 objectClass: top objectClass: nsContainer cn: ipa02.local.zone dn: cn=KDC,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01 objectClass: nsContainer objectClass: ipaConfigObject objectClass: top ipaConfigString: enabledService ipaConfigString: startOrder 10 cn: KDC dn: cn=KPASSWD,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=sp il objectClass: nsContainer objectClass: ipaConfigObject objectClass: top ipaConfigString: enabledService ipaConfigString: startOrder 20 cn: KPASSWD dn: cn=MEMCACHE,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=s pil objectClass: nsContainer objectClass: ipaConfigObject objectClass: top ipaConfigString: enabledService ipaConfigString: startOrder 39 cn: MEMCACHE dn: cn=HTTP,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01 objectClass: nsContainer objectClass: ipaConfigObject objectClass: top ipaConfigString: enabledService ipaConfigString: startOrder 40 cn: HTTP dn: cn=DNS,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01 objectClass: nsContainer objectClass: ipaConfigObject objectClass: top ipaConfigString: enabledService ipaConfigString: startOrder 30 cn: DNS I tried delete, but I get: ldapdelete -x -D 'cn=KDC,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01' ldap_bind: Server is unwilling to perform (53) additional info: Unauthenticated binds are not allowed I have located that there is -W ldapdelete -x -D 'cn=KDC,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01' -W it askes for LDAP Password: Entering the password gives: ldap_bind: Inappropriate authentication (48) Can anyone who faced similar issues help me on how do I fix it ? Cheers, Shashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Oct 1 16:53:01 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 01 Oct 2014 12:53:01 -0400 Subject: [Freeipa-users] error trying to re-setup ipa replica In-Reply-To: References: Message-ID: <542C316D.1010507@redhat.com> On 10/01/2014 10:20 AM, Shashi Dahal wrote: > Hi, > > This is what I have. > > ipa01 - master > ipa02 - replica > ipa03 - replica > > ipa02 crashed, and re-setup > > I used the gpg file from master and trying to re-create the replica: > ipa-replica-install ipa02.gpg > > gives: > > The host ipa02.local.zone already exists on the master server. > You should remove it before proceeding: > % ipa host-del ipa02.local.zone > > > I login to the master server and if I do ipa-replica-manage list , it > shows: ipa02.local.zone: master > Trying to delete it with ipa host-del ipa02.local.zone fails saying: > ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted > or disabled > > ipa-replica-manage del ipa02.local.zone fails saying: > 'ipa01.local.zone' has no replication agreement for 'ipa02.local.zone' > > > I searched the mailing list and it was suggested that I should do a > ldapsearch and ldapdelete. > > here is the search: > > ldapsearch -LLL -x -b > cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01 > > dn: cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01 > objectClass: top > objectClass: nsContainer > cn: ipa02.local.zone > > dn: cn=KDC,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01 > objectClass: nsContainer > objectClass: ipaConfigObject > objectClass: top > ipaConfigString: enabledService > ipaConfigString: startOrder 10 > cn: KDC > > dn: cn=KPASSWD,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=sp > il > objectClass: nsContainer > objectClass: ipaConfigObject > objectClass: top > ipaConfigString: enabledService > ipaConfigString: startOrder 20 > cn: KPASSWD > > dn: cn=MEMCACHE,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=s > pil > objectClass: nsContainer > objectClass: ipaConfigObject > objectClass: top > ipaConfigString: enabledService > ipaConfigString: startOrder 39 > cn: MEMCACHE > > dn: cn=HTTP,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01 > objectClass: nsContainer > objectClass: ipaConfigObject > objectClass: top > ipaConfigString: enabledService > ipaConfigString: startOrder 40 > cn: HTTP > > dn: cn=DNS,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01 > objectClass: nsContainer > objectClass: ipaConfigObject > objectClass: top > ipaConfigString: enabledService > ipaConfigString: startOrder 30 > cn: DNS > > > I tried delete, but I get: > > ldapdelete -x -D > 'cn=KDC,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01' > > ldap_bind: Server is unwilling to perform (53) > additional info: Unauthenticated binds are not allowed > > I have located that there is -W > > ldapdelete -x -D > 'cn=KDC,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01' -W > it askes for LDAP Password: > > Entering the password gives: ldap_bind: Inappropriate authentication (48) > > > Can anyone who faced similar issues help me on how do I fix it ? > > > Cheers, > Shashi > > > > I think you need to use Directory Manager's or admin's DN as a bind DN. The bind DN above seems wrong. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Oct 1 17:08:50 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 01 Oct 2014 13:08:50 -0400 Subject: [Freeipa-users] can ipa-client-install be updated to call username/password from a file? In-Reply-To: <38655c79.DSq.Fz0.cS.11asNmAIf7@mailjet.com> References: <4ED173A868981548967B4FCA2707222627FE845C@AACMBXP04.exchserver.com> <38655c79.DSq.Fz0.cS.11asNmAIf7@mailjet.com> Message-ID: <542C3522.3070408@redhat.com> On 10/01/2014 05:44 AM, Yiorgos Stamoulis wrote: > > On 01/10/14 08:19, Les Stott wrote: >> >> Hi, >> >> I am using freeipa in a rhel6 environment with ipa-3.0.0-37.el6 client. >> >> I am working on doing an unattended ipa client installation. I have >> it working with the following.... >> >> /usr/sbin/ipa-client-install -p admin -w -U --no-ntp >> >> While this works, while it runs, the value is >> visable in the output of a ps --ef command on the host when >> installing the ipa client. >> >> # ps -ef |grep ipa >> >> root 30284 30283 43 03:31 ? 00:00:01 /usr/bin/python -E >> /usr/sbin/ipa-client-install -p admin -w -U >> --no-ntp >> >> This represents a challenge to security, even though its only minor >> (as in its only there for a minute or so), but its still there and it >> is the admin password. >> >> Can ipa-client-install be updated to include a parameter to retrieve >> the admin password from a file? i.e. >> >> /usr/bin/python -E /usr/sbin/ipa-client-install -p admin --from-file >> /tmp/credentials -U --no-ntp >> >> That would then protect the admin password. >> >> I am not familiar with python coding. >> >> Thanks in advance, >> >> Les >> >> >> > Hi Les, > > in addition to the answers you have already received, you can create a > user with the 'host enrollment' permission only, so even if the > credentials are compromised the damage is minimized. > > I am using this on 4.0.3 but looking at an older installation the same > seems available in 3.0 too. > > Best Regards > > Yiorgos > > Or you can use OTPs. The OTPs were actually invented for exactly this use case. You register host and generate OTP at that time. Then you pass it to your enrollment script and it is used once. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From licause at hp.com Wed Oct 1 16:28:44 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Wed, 1 Oct 2014 16:28:44 +0000 Subject: [Freeipa-users] Problems and questions installing Identity Manager on RHEL V7 Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1C0E@G6W2496.americas.hpqcorp.net> We are trying to install Identity Manager for testing and learning purposes in a test lab environment. We have successfully installed the base product but have run into problems when trying to setup a domain trust to an AD server. We are somewhat limited as to how we can change these systems and since they must function for replication of many different problems, we need to be cautious as to what we change. But they are crash and burn systems. Both the RHEL V7 IdM server system and the W2008 R2 AD server are in the same subnet and the same dns zone. So that is the first question....can we create a domain trust between these two systems without placing one or the other in a different address subnet or changing the domain name ? I have tried changing the realm name for the linux server from lab.us.com for example to ipa.lab.us.com and then leaving the AD server in lab.us.com. That gets us a bit further but then we run into problems with what I believe is the kerberos configuration. I have tried to deinstall and reinstall the ipa server but the installation is now failing. The ipa-server-install is failing with the following: [37/38]: tuning directory server [38/38]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/22]: creating certificate server user [2/22]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpLb1CmI' returned non-zero exit status 1 Configuration of CA failed This happens each time I try to uninstall and reinstall the ipa server on RHEL V7. Looking at the latest log in /var/log/pki, I see this at the end of the log: 2014-10-01 11:53:10 pkispawn : INFO BEGIN spawning subsystem 'CA' of instance 'pki-tomcat' . . . 2014-10-01 11:53:10 pkispawn : INFO ... initializing 'pki.deployment.initialization' 2014-10-01 11:53:10 pkispawn : ERROR ....... PKI subsystem 'CA' for instance 'pki-tomcat' already exists! 2014-10-01 11:53:10 pkispawn : DEBUG ....... Error Type: SystemExit 2014-10-01 11:53:10 pkispawn : DEBUG ....... Error Message: 1 2014-10-01 11:53:10 pkispawn : DEBUG ....... File "/usr/sbin/pkispawn", line 374, in main rv = instance.spawn() File "/usr/lib/python2.7/site-packages/pki/deployment/initialization.py", line 56, in spawn util.instance.verify_subsystem_does_not_exist() File "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py", line 990, in verify_subsystem_does_not_exist sys.exit(1) I am no python expert by any means and I'm not sure what this is telling us so any help would be greatly appreciated. Al Licause CSC Americas BCS Technical Specialist HP Customer Support Center Hours 5am-2pm Pacific time USA Manager: mark.bailey at hp.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2051 bytes Desc: image001.gif URL: From abokovoy at redhat.com Wed Oct 1 17:46:22 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 1 Oct 2014 20:46:22 +0300 Subject: [Freeipa-users] Problems and questions installing Identity Manager on RHEL V7 In-Reply-To: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1C0E@G6W2496.americas.hpqcorp.net> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1C0E@G6W2496.americas.hpqcorp.net> Message-ID: <20141001174622.GB6186@redhat.com> On Wed, 01 Oct 2014, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > > >We are trying to install Identity Manager for testing and learning purposes in a test lab >environment. We have successfully installed the base product but have run into problems >when trying to setup a domain trust to an AD server. > >We are somewhat limited as to how we can change these systems and since they must function >for replication of many different problems, we need to be cautious as to what we change. >But they are crash and burn systems. > >Both the RHEL V7 IdM server system and the W2008 R2 AD server are in the same subnet >and the same dns zone. > > >So that is the first question....can we create a domain trust between these two systems >without placing one or the other in a different address subnet or changing the domain name ? No. AD forest by design owns DNS domain of its forest root domain. I'd put it in an example.com case: OK: AD as example.com, IPA as ipa.example.com subdomain OK: AD as ad.example.com subdomain, IPA as example.com OK: AD as example.com, IPA as example.org Anything else would mean tripping over authority of one or another forest root domain and thus will not work. >I have tried changing the realm name for the linux server from lab.us.com for example to >ipa.lab.us.com and then leaving the AD server in lab.us.com. That gets us a bit further >but then we run into problems with what I believe is the kerberos configuration. Right, this should work as long as ipa.lab.us.com DNS domain has proper SRV records for IPA, as well as lab.us.com has proper SRV records for AD forest root domain. >I have tried to deinstall and reinstall the ipa server but the installation is now failing. > > >The ipa-server-install is failing with the following: > > [37/38]: tuning directory server > [38/38]: configuring directory to start on boot >Done configuring directory server (dirsrv). >Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds > [1/22]: creating certificate server user > [2/22]: configuring certificate server instance >ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpLb1CmI' returned non-zero exit status 1 >Configuration of CA failed > >This happens each time I try to uninstall and reinstall the ipa server on RHEL V7. > > >Looking at the latest log in /var/log/pki, I see this at the end of the log: > >2014-10-01 11:53:10 pkispawn : INFO BEGIN spawning subsystem 'CA' of instance 'pki-tomcat' . . . >2014-10-01 11:53:10 pkispawn : INFO ... initializing 'pki.deployment.initialization' >2014-10-01 11:53:10 pkispawn : ERROR ....... PKI subsystem 'CA' for instance 'pki-tomcat' already exists! >2014-10-01 11:53:10 pkispawn : DEBUG ....... Error Type: SystemExit >2014-10-01 11:53:10 pkispawn : DEBUG ....... Error Message: 1 >2014-10-01 11:53:10 pkispawn : DEBUG ....... File "/usr/sbin/pkispawn", line 374, in main > rv = instance.spawn() > File "/usr/lib/python2.7/site-packages/pki/deployment/initialization.py", line 56, in spawn > util.instance.verify_subsystem_does_not_exist() > File "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py", line 990, in verify_subsystem_does_not_exist > sys.exit(1) > >I am no python expert by any means and I'm not sure what this is telling us so any help >would be greatly appreciated. This issue is known -- when CA install fails, we rollback but since CA isn't installed, we miss rolling it back. There is a ticket for eventually fixing this issue. Following sequence should clean up all the bits: pkidestroy -s CA -i pki-tomcat rm -rf /var/log/pki/pki-tomcat rm -rf /etc/sysconfig/pki-tomcat rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat rm -rf /var/lib/pki/pki-tomcat rm -rf /etc/pki/pki-tomcat It also helps to reboot between multiple reinstalls on a single machine. -- / Alexander Bokovoy From rcritten at redhat.com Wed Oct 1 18:02:28 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 01 Oct 2014 14:02:28 -0400 Subject: [Freeipa-users] error trying to re-setup ipa replica [SOLVED] In-Reply-To: <542C316D.1010507@redhat.com> References: <542C316D.1010507@redhat.com> Message-ID: <542C41B4.5020807@redhat.com> Dmitri Pal wrote: > On 10/01/2014 10:20 AM, Shashi Dahal wrote: >> Hi, >> >> This is what I have. >> >> ipa01 - master >> ipa02 - replica >> ipa03 - replica >> >> ipa02 crashed, and re-setup >> >> I used the gpg file from master and trying to re-create the replica: >> ipa-replica-install ipa02.gpg >> >> gives: >> >> The host ipa02.local.zone already exists on the master server. >> You should remove it before proceeding: >> % ipa host-del ipa02.local.zone >> >> >> I login to the master server and if I do ipa-replica-manage list , it >> shows: ipa02.local.zone: master >> Trying to delete it with ipa host-del ipa02.local.zone fails saying: >> ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted >> or disabled >> >> ipa-replica-manage del ipa02.local.zone fails saying: >> 'ipa01.local.zone' has no replication agreement for 'ipa02.local.zone' >> >> >> I searched the mailing list and it was suggested that I should do a >> ldapsearch and ldapdelete. >> >> here is the search: >> >> ldapsearch -LLL -x -b >> cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01 >> >> dn: cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01 >> objectClass: top >> objectClass: nsContainer >> cn: ipa02.local.zone >> >> dn: cn=KDC,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01 >> objectClass: nsContainer >> objectClass: ipaConfigObject >> objectClass: top >> ipaConfigString: enabledService >> ipaConfigString: startOrder 10 >> cn: KDC >> >> dn: cn=KPASSWD,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=sp >> il >> objectClass: nsContainer >> objectClass: ipaConfigObject >> objectClass: top >> ipaConfigString: enabledService >> ipaConfigString: startOrder 20 >> cn: KPASSWD >> >> dn: cn=MEMCACHE,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=s >> pil >> objectClass: nsContainer >> objectClass: ipaConfigObject >> objectClass: top >> ipaConfigString: enabledService >> ipaConfigString: startOrder 39 >> cn: MEMCACHE >> >> dn: cn=HTTP,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01 >> objectClass: nsContainer >> objectClass: ipaConfigObject >> objectClass: top >> ipaConfigString: enabledService >> ipaConfigString: startOrder 40 >> cn: HTTP >> >> dn: cn=DNS,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01 >> objectClass: nsContainer >> objectClass: ipaConfigObject >> objectClass: top >> ipaConfigString: enabledService >> ipaConfigString: startOrder 30 >> cn: DNS >> >> >> I tried delete, but I get: >> >> ldapdelete -x -D >> 'cn=KDC,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01' >> >> ldap_bind: Server is unwilling to perform (53) >> additional info: Unauthenticated binds are not allowed >> >> I have located that there is -W >> >> ldapdelete -x -D >> 'cn=KDC,cn=ipa02.local.zone,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=dc01' -W >> it askes for LDAP Password: >> >> Entering the password gives: ldap_bind: Inappropriate authentication (48) >> >> >> Can anyone who faced similar issues help me on how do I fix it ? >> >> >> Cheers, >> Shashi >> >> >> >> > I think you need to use Directory Manager's or admin's DN as a bind DN. > The bind DN above seems wrong. Well, that is a brute-force way of fixing it and not recommended anyway. I'm glad the bind failed. I chatted with him over IRC and we resolved it. He still had a replication agreement for ipa02 on ipa03 so he removed that and was able to re-install ipa02. One needs to be careful when deleting a master to be sure that it is completely gone. If 389-ds still thinks there is a master floating around there it will accumulate a changelog for it. rob From Less at imagine-sw.com Wed Oct 1 22:21:24 2014 From: Less at imagine-sw.com (Les Stott) Date: Wed, 1 Oct 2014 22:21:24 +0000 Subject: [Freeipa-users] can ipa-client-install be updated to call username/password from a file? In-Reply-To: <542C3522.3070408@redhat.com> References: <4ED173A868981548967B4FCA2707222627FE845C@AACMBXP04.exchserver.com> <38655c79.DSq.Fz0.cS.11asNmAIf7@mailjet.com> <542C3522.3070408@redhat.com> Message-ID: <4ED173A868981548967B4FCA2707222627FE8B3A@AACMBXP04.exchserver.com> Thanks to Dmitri, Petr, Tamas and Yiorgos for all your suggestions. I will try them out today. Regards, Les From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Thursday, 2 October 2014 3:09 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] can ipa-client-install be updated to call username/password from a file? On 10/01/2014 05:44 AM, Yiorgos Stamoulis wrote: On 01/10/14 08:19, Les Stott wrote: Hi, I am using freeipa in a rhel6 environment with ipa-3.0.0-37.el6 client. I am working on doing an unattended ipa client installation. I have it working with the following.... /usr/sbin/ipa-client-install -p admin -w -U --no-ntp While this works, while it runs, the value is visable in the output of a ps -ef command on the host when installing the ipa client. # ps -ef |grep ipa root 30284 30283 43 03:31 ? 00:00:01 /usr/bin/python -E /usr/sbin/ipa-client-install -p admin -w -U --no-ntp This represents a challenge to security, even though its only minor (as in its only there for a minute or so), but its still there and it is the admin password. Can ipa-client-install be updated to include a parameter to retrieve the admin password from a file? i.e. /usr/bin/python -E /usr/sbin/ipa-client-install -p admin -from-file /tmp/credentials -U --no-ntp That would then protect the admin password. I am not familiar with python coding. Thanks in advance, Les Hi Les, in addition to the answers you have already received, you can create a user with the 'host enrollment' permission only, so even if the credentials are compromised the damage is minimized. I am using this on 4.0.3 but looking at an older installation the same seems available in 3.0 too. Best Regards Yiorgos Or you can use OTPs. The OTPs were actually invented for exactly this use case. You register host and generate OTP at that time. Then you pass it to your enrollment script and it is used once. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From timdiab at gmail.com Thu Oct 2 14:36:11 2014 From: timdiab at gmail.com (Hatim Diab) Date: Thu, 2 Oct 2014 10:36:11 -0400 Subject: [Freeipa-users] Client not installing Message-ID: <9B144334-00FF-4CE9-AC05-4B0992483ABB@gmail.com> Hi All, I have a new installation of freeipa ipa-server-3.0.0-37.el6.x86_64 on CentOS 6.5 one of my clients stopped authentication last night, I performed a ipa-client-install ?uninstall from the client then on trying to delete the the host # ipa host-del client.x.y.z ipa: ERROR: Certificate format error: [Errno -5925] error (-5925) unknown /var/log/krb5kdc.log Oct 02 10:27:07 krb5kdc[30623](info): TGS_REQ (4 etypes {18 17 16 23}) : ISSUE: authtime 1412221207, etypes {rep=18 tkt=18 ses=18}, HTTP/@ for ldap/@ Oct 02 10:27:07 krb5kdc[30623](info): ... CONSTRAINED-DELEGATION s4u-client=admin@ trying to add back the client [root at client ~]# ipa-client-install --domain= --server= Autodiscovery of servers for failover cannot work with this configuration. If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure. Proceed with fixed values and no DNS discovery? [no]: yes Hostname: Realm: DNS Domain: IPA Server: BaseDN: dc= Continue to configure the system with these values? [no]: yes User authorized to enroll computers: admin Synchronizing time with KDC... Password for admin@: Successfully retrieved CA cert Subject: CN=Certificate Authority,O= Issuer: CN=Certificate Authority,O= Valid From: Sun Sep 21 20:42:12 2014 UTC Valid Until: Thu Sep 21 20:42:12 2034 UTC Joining realm failed: RPC failed at server. Certificate format error: [Errno -5925] error (-5925) unknown Installation failed. Rolling back changes. IPA client is not configured on this system. Cheers, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From licause at hp.com Thu Oct 2 17:05:10 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Thu, 2 Oct 2014 17:05:10 +0000 Subject: [Freeipa-users] named and IpA Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> We have IdM running on a RHEL V7 system and have configured a local DNS server in our test lab. We have loaded the various SRV and TXT records needed by the IdM server. PROBLEM: >From the IdM server we can only lookup local records. The name resolver will not attempt to look to another other name servers or domains defined in /etc/resolv.conf If I shutdown IdM using ipactl stop and then restart named, the name resolver works for local and remote hosts, addresses and domains as well as serving up the SRV records defined on the local host. Am I correct in assuming that while IdM is up and running, the only other systems it will communicate with at least with regard to name services is another host also running IdM defined either as a server or a client ? If this is case, is there anyone to better integrate some of these common services such as named into an existing network such that you are not limited by the IdM components ? Al Licause -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2051 bytes Desc: image001.gif URL: From Less at imagine-sw.com Thu Oct 2 21:10:35 2014 From: Less at imagine-sw.com (Les Stott) Date: Thu, 2 Oct 2014 21:10:35 +0000 Subject: [Freeipa-users] can ipa-client-install be updated to call username/password from a file? In-Reply-To: <4ED173A868981548967B4FCA2707222627FE8B3A@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222627FE845C@AACMBXP04.exchserver.com> <38655c79.DSq.Fz0.cS.11asNmAIf7@mailjet.com> <542C3522.3070408@redhat.com> <4ED173A868981548967B4FCA2707222627FE8B3A@AACMBXP04.exchserver.com> Message-ID: <4ED173A868981548967B4FCA2707222627FE94C4@AACMBXP04.exchserver.com> FYI... I used OTP for this. Works a treat! Thanks again Dmitri. Regards, Les From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Les Stott Sent: Thursday, 2 October 2014 8:21 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] can ipa-client-install be updated to call username/password from a file? Thanks to Dmitri, Petr, Tamas and Yiorgos for all your suggestions. I will try them out today. Regards, Les From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Thursday, 2 October 2014 3:09 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] can ipa-client-install be updated to call username/password from a file? On 10/01/2014 05:44 AM, Yiorgos Stamoulis wrote: On 01/10/14 08:19, Les Stott wrote: Hi, I am using freeipa in a rhel6 environment with ipa-3.0.0-37.el6 client. I am working on doing an unattended ipa client installation. I have it working with the following.... /usr/sbin/ipa-client-install -p admin -w -U --no-ntp While this works, while it runs, the value is visable in the output of a ps -ef command on the host when installing the ipa client. # ps -ef |grep ipa root 30284 30283 43 03:31 ? 00:00:01 /usr/bin/python -E /usr/sbin/ipa-client-install -p admin -w -U --no-ntp This represents a challenge to security, even though its only minor (as in its only there for a minute or so), but its still there and it is the admin password. Can ipa-client-install be updated to include a parameter to retrieve the admin password from a file? i.e. /usr/bin/python -E /usr/sbin/ipa-client-install -p admin -from-file /tmp/credentials -U --no-ntp That would then protect the admin password. I am not familiar with python coding. Thanks in advance, Les Hi Les, in addition to the answers you have already received, you can create a user with the 'host enrollment' permission only, so even if the credentials are compromised the damage is minimized. I am using this on 4.0.3 but looking at an older installation the same seems available in 3.0 too. Best Regards Yiorgos Or you can use OTPs. The OTPs were actually invented for exactly this use case. You register host and generate OTP at that time. Then you pass it to your enrollment script and it is used once. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig at paragon.net.uk Thu Oct 2 22:52:42 2014 From: craig at paragon.net.uk (Craig Parker) Date: Thu, 2 Oct 2014 23:52:42 +0100 Subject: [Freeipa-users] Client not installing In-Reply-To: <9B144334-00FF-4CE9-AC05-4B0992483ABB@gmail.com> References: <9B144334-00FF-4CE9-AC05-4B0992483ABB@gmail.com> Message-ID: <542DD73A.6060308@paragon.net.uk> On 02/10/14 15:36, Hatim Diab wrote: > Hi All, > > I have a new installation of freeipa > > ipa-server-3.0.0-37.el6.x86_64 > on CentOS 6.5 > > one of my clients stopped authentication last night, I performed a ipa-client-install ?uninstall from the client then on trying to delete the the host > > # ipa host-del client.x.y.z > ipa: ERROR: Certificate format error: [Errno -5925] error (-5925) unknown > > /var/log/krb5kdc.log > Oct 02 10:27:07 krb5kdc[30623](info): TGS_REQ (4 etypes {18 17 16 23}) : ISSUE: authtime 1412221207, etypes {rep=18 tkt=18 ses=18}, HTTP/@ for ldap/@ > Oct 02 10:27:07 krb5kdc[30623](info): ... CONSTRAINED-DELEGATION s4u-client=admin@ > > trying to add back the client > [root at client ~]# ipa-client-install --domain= --server= > Autodiscovery of servers for failover cannot work with this configuration. > If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure. > Proceed with fixed values and no DNS discovery? [no]: yes > Hostname: > Realm: > DNS Domain: > IPA Server: > BaseDN: dc= > > Continue to configure the system with these values? [no]: yes > User authorized to enroll computers: admin > Synchronizing time with KDC... > Password for admin@: > Successfully retrieved CA cert > Subject: CN=Certificate Authority,O= > Issuer: CN=Certificate Authority,O= > Valid From: Sun Sep 21 20:42:12 2014 UTC > Valid Until: Thu Sep 21 20:42:12 2034 UTC > > Joining realm failed: RPC failed at server. Certificate format error: [Errno -5925] error (-5925) unknown > > Installation failed. Rolling back changes. > IPA client is not configured on this system. > > Cheers, > Tim > > It could be related to this bug - https://bugzilla.redhat.com/show_bug.cgi?id=738456 as I ran into an issue where I was getting an "error (-5925)", downgrading nss fixed it for me. Unless error 5925 applies to many things, in which case ignore me. :) -- Craig Parker Senior Systems Administrator | Paragon Internet Group -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Oct 3 00:24:25 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 02 Oct 2014 20:24:25 -0400 Subject: [Freeipa-users] named and IpA In-Reply-To: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> Message-ID: <542DECB9.7090301@redhat.com> On 10/02/2014 01:05 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > > We have IdM running on a RHEL V7 system and have configured a local > DNS server > > in our test lab. > > We have loaded the various SRV and TXT records needed by the IdM server. > > PROBLEM: > > From the IdM server we can only lookup local records. The name > resolver will not > > attempt to look to another other name servers or domains defined in > /etc/resolv.conf > > If I shutdown IdM using ipactl stop and then restart named, the name > resolver works > > for local and remote hosts, addresses and domains as well as serving > up the SRV records > > defined on the local host. > > Am I correct in assuming that while IdM is up and running, the only > other systems it > > will communicate with at least with regard to name services is another > host also > > running IdM defined either as a server or a client ? > > If this is case, is there anyone to better integrate some of these > common services such > > as named into an existing network such that you are not limited by the > IdM components ? > > *Al Licause * > > > If DNS is running on IdM the DNS lookups might be forwarded to different DNS servers depending on your DNS cofiguration. Based on what you describe it seems that there is some sort of DNS misconfiguration. I would leave to gurus to help you with that. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2051 bytes Desc: not available URL: From edewata at redhat.com Fri Oct 3 02:38:43 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 02 Oct 2014 21:38:43 -0500 Subject: [Freeipa-users] Problems and questions installing Identity Manager on RHEL V7 In-Reply-To: <20141001174622.GB6186@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1C0E@G6W2496.americas.hpqcorp.net> <20141001174622.GB6186@redhat.com> Message-ID: <542E0C33.60300@redhat.com> On 10/1/2014 12:46 PM, Alexander Bokovoy wrote: > On Wed, 01 Oct 2014, Licause, Al (CSC AMS BCS - UNIX/Linux Network > Support) wrote: >> I have tried to deinstall and reinstall the ipa server but the >> installation is now failing. >> >> >> The ipa-server-install is failing with the following: >> >> [37/38]: tuning directory server >> [38/38]: configuring directory to start on boot >> Done configuring directory server (dirsrv). >> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes >> 30 seconds >> [1/22]: creating certificate server user >> [2/22]: configuring certificate server instance >> ipa : CRITICAL failed to configure ca instance Command >> '/usr/sbin/pkispawn -s CA -f /tmp/tmpLb1CmI' returned non-zero exit >> status 1 >> Configuration of CA failed >> >> This happens each time I try to uninstall and reinstall the ipa server >> on RHEL V7. >> >> >> Looking at the latest log in /var/log/pki, I see this at the end of >> the log: >> >> 2014-10-01 11:53:10 pkispawn : INFO BEGIN spawning subsystem >> 'CA' of instance 'pki-tomcat' . . . >> 2014-10-01 11:53:10 pkispawn : INFO ... initializing >> 'pki.deployment.initialization' >> 2014-10-01 11:53:10 pkispawn : ERROR ....... PKI subsystem 'CA' >> for instance 'pki-tomcat' already exists! >> 2014-10-01 11:53:10 pkispawn : DEBUG ....... Error Type: SystemExit >> 2014-10-01 11:53:10 pkispawn : DEBUG ....... Error Message: 1 >> 2014-10-01 11:53:10 pkispawn : DEBUG ....... File >> "/usr/sbin/pkispawn", line 374, in main >> rv = instance.spawn() >> File >> "/usr/lib/python2.7/site-packages/pki/deployment/initialization.py", >> line 56, in spawn >> util.instance.verify_subsystem_does_not_exist() >> File "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py", >> line 990, in verify_subsystem_does_not_exist >> sys.exit(1) >> >> I am no python expert by any means and I'm not sure what this is >> telling us so any help >> would be greatly appreciated. > This issue is known -- when CA install fails, we rollback but since CA > isn't installed, we miss rolling it back. There is a ticket for > eventually fixing this issue. Which ticket is this? The rollback was actually disabled to allow troubleshooting the failed installation: https://fedorahosted.org/freeipa/ticket/3990 > Following sequence should clean up all the bits: > > pkidestroy -s CA -i pki-tomcat > rm -rf /var/log/pki/pki-tomcat > rm -rf /etc/sysconfig/pki-tomcat > rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat > rm -rf /var/lib/pki/pki-tomcat > rm -rf /etc/pki/pki-tomcat It's not official, but we call this step pki-nuke. > It also helps to reboot between multiple reinstalls on a single machine. Rather than rolling back the installation automatically (and delete all files needed to troubleshoot the problem), it would be better to provide an option to the uninstall command to forcibly remove all installed files regardless whether the installation was successful or not, just like the pki-nuke above. -- Endi S. Dewata From rcritten at redhat.com Fri Oct 3 03:22:51 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 Oct 2014 23:22:51 -0400 Subject: [Freeipa-users] Client not installing In-Reply-To: <542DD73A.6060308@paragon.net.uk> References: <9B144334-00FF-4CE9-AC05-4B0992483ABB@gmail.com> <542DD73A.6060308@paragon.net.uk> Message-ID: <542E168B.5060507@redhat.com> Craig Parker wrote: > On 02/10/14 15:36, Hatim Diab wrote: >> Hi All, >> >> I have a new installation of freeipa >> >> ipa-server-3.0.0-37.el6.x86_64 >> on CentOS 6.5 >> >> one of my clients stopped authentication last night, I performed a ipa-client-install ?uninstall from the client then on trying to delete the the host >> >> # ipa host-del client.x.y.z >> ipa: ERROR: Certificate format error: [Errno -5925] error (-5925) unknown >> >> /var/log/krb5kdc.log >> Oct 02 10:27:07 krb5kdc[30623](info): TGS_REQ (4 etypes {18 17 16 23}) : ISSUE: authtime 1412221207, etypes {rep=18 tkt=18 ses=18}, HTTP/@ for ldap/@ >> Oct 02 10:27:07 krb5kdc[30623](info): ... CONSTRAINED-DELEGATION s4u-client=admin@ >> >> trying to add back the client >> [root at client ~]# ipa-client-install --domain= --server= >> Autodiscovery of servers for failover cannot work with this configuration. >> If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure. >> Proceed with fixed values and no DNS discovery? [no]: yes >> Hostname: >> Realm: >> DNS Domain: >> IPA Server: >> BaseDN: dc= >> >> Continue to configure the system with these values? [no]: yes >> User authorized to enroll computers: admin >> Synchronizing time with KDC... >> Password for admin@: >> Successfully retrieved CA cert >> Subject: CN=Certificate Authority,O= >> Issuer: CN=Certificate Authority,O= >> Valid From: Sun Sep 21 20:42:12 2014 UTC >> Valid Until: Thu Sep 21 20:42:12 2034 UTC >> >> Joining realm failed: RPC failed at server. Certificate format error: [Errno -5925] error (-5925) unknown >> >> Installation failed. Rolling back changes. >> IPA client is not configured on this system. >> >> Cheers, >> Tim >> >> > > It could be related to this bug - > https://bugzilla.redhat.com/show_bug.cgi?id=738456 as I ran into an > issue where I was getting an "error (-5925)", downgrading nss fixed it > for me. > > Unless error 5925 applies to many things, in which case ignore me. :) I think in this case a certificate (or something) is stored in LDAP that is unreadable by NSS. It would be handy to know what is in there so we can handle this more gracefully. You'll probably need to use ldapsearch to get the entry since IPA is throwing up on it. Something like: $ kinit admin $ ldapsearch -Y GSSAPI -b fqdn=client.x.y.z,cn=computers,cn=accounts,dc=x,dc=y,dc=z This should just be a public cert, but feel free to send this to me directly if you'd like. To delete the value do something like: $ ldapmodify -Y GSSAPI dn: fqdn=client.x.y.z,cn=computers,cn=accounts,dc=x,dc=y,dc=z changetype: modify delete: userCertificate ^D Then ipa host-del should work. rob From jpazdziora at redhat.com Fri Oct 3 06:22:59 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 3 Oct 2014 08:22:59 +0200 Subject: [Freeipa-users] named and IpA In-Reply-To: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> Message-ID: <20141003062259.GY18414@redhat.com> On Thu, Oct 02, 2014 at 05:05:10PM +0000, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > > >From the IdM server we can only lookup local records. The name resolver will not > attempt to look to another other name servers or domains defined in /etc/resolv.conf What exactly is in your /etc/resolv.conf? Just the IP address of the IPA server (localhost), or some other records? > If I shutdown IdM using ipactl stop and then restart named, the name resolver works > for local and remote hosts, addresses and domains as well as serving up the SRV records > defined on the local host. So if all IdM services are running, you do not seem to have named observing forwarders settings but if you only run named on the IdM machine and nothing else, it starts to observe them? Can you show dig output for one of the problematic records to see which DNS server is answering the query? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From abokovoy at redhat.com Fri Oct 3 07:30:09 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 3 Oct 2014 10:30:09 +0300 Subject: [Freeipa-users] Problems and questions installing Identity Manager on RHEL V7 In-Reply-To: <542E0C33.60300@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1C0E@G6W2496.americas.hpqcorp.net> <20141001174622.GB6186@redhat.com> <542E0C33.60300@redhat.com> Message-ID: <20141003073009.GA4683@redhat.com> On Thu, 02 Oct 2014, Endi Sukma Dewata wrote: >On 10/1/2014 12:46 PM, Alexander Bokovoy wrote: >>On Wed, 01 Oct 2014, Licause, Al (CSC AMS BCS - UNIX/Linux Network >>Support) wrote: > >>>I have tried to deinstall and reinstall the ipa server but the >>>installation is now failing. >>> >>> >>>The ipa-server-install is failing with the following: >>> >>> [37/38]: tuning directory server >>> [38/38]: configuring directory to start on boot >>>Done configuring directory server (dirsrv). >>>Configuring certificate server (pki-tomcatd): Estimated time 3 minutes >>>30 seconds >>> [1/22]: creating certificate server user >>> [2/22]: configuring certificate server instance >>>ipa : CRITICAL failed to configure ca instance Command >>>'/usr/sbin/pkispawn -s CA -f /tmp/tmpLb1CmI' returned non-zero exit >>>status 1 >>>Configuration of CA failed >>> >>>This happens each time I try to uninstall and reinstall the ipa server >>>on RHEL V7. >>> >>> >>>Looking at the latest log in /var/log/pki, I see this at the end of >>>the log: >>> >>>2014-10-01 11:53:10 pkispawn : INFO BEGIN spawning subsystem >>>'CA' of instance 'pki-tomcat' . . . >>>2014-10-01 11:53:10 pkispawn : INFO ... initializing >>>'pki.deployment.initialization' >>>2014-10-01 11:53:10 pkispawn : ERROR ....... PKI subsystem 'CA' >>>for instance 'pki-tomcat' already exists! >>>2014-10-01 11:53:10 pkispawn : DEBUG ....... Error Type: SystemExit >>>2014-10-01 11:53:10 pkispawn : DEBUG ....... Error Message: 1 >>>2014-10-01 11:53:10 pkispawn : DEBUG ....... File >>>"/usr/sbin/pkispawn", line 374, in main >>> rv = instance.spawn() >>> File >>>"/usr/lib/python2.7/site-packages/pki/deployment/initialization.py", >>>line 56, in spawn >>> util.instance.verify_subsystem_does_not_exist() >>> File "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py", >>>line 990, in verify_subsystem_does_not_exist >>> sys.exit(1) >>> >>>I am no python expert by any means and I'm not sure what this is >>>telling us so any help >>>would be greatly appreciated. > >>This issue is known -- when CA install fails, we rollback but since CA >>isn't installed, we miss rolling it back. There is a ticket for >>eventually fixing this issue. > >Which ticket is this? The rollback was actually disabled to allow >troubleshooting the failed installation: >https://fedorahosted.org/freeipa/ticket/3990 I think this ticket is unrelated -- its solution only affects ipa-client-install --on-master, not what ipa-server-install does when it rolls back configuration for dirsrv and other servers. I can't find the exact ticket though. >>Following sequence should clean up all the bits: >> >>pkidestroy -s CA -i pki-tomcat >>rm -rf /var/log/pki/pki-tomcat >>rm -rf /etc/sysconfig/pki-tomcat >>rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat >>rm -rf /var/lib/pki/pki-tomcat >>rm -rf /etc/pki/pki-tomcat > >It's not official, but we call this step pki-nuke. > >>It also helps to reboot between multiple reinstalls on a single machine. > >Rather than rolling back the installation automatically (and delete >all files needed to troubleshoot the problem), it would be better to >provide an option to the uninstall command to forcibly remove all >installed files regardless whether the installation was successful or >not, just like the pki-nuke above. We simply have no information about the fact what pkicreate did before it failed. -- / Alexander Bokovoy From pspacek at redhat.com Fri Oct 3 08:26:23 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 03 Oct 2014 10:26:23 +0200 Subject: [Freeipa-users] named and IpA In-Reply-To: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> Message-ID: <542E5DAF.2090706@redhat.com> On 2.10.2014 19:05, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > We have IdM running on a RHEL V7 system and have configured a local DNS server > in our test lab. > > We have loaded the various SRV and TXT records needed by the IdM server. > > > PROBLEM: > >>From the IdM server we can only lookup local records. The name resolver will not > attempt to look to another other name servers or domains defined in /etc/resolv.conf > > If I shutdown IdM using ipactl stop and then restart named, the name resolver works > for local and remote hosts, addresses and domains as well as serving up the SRV records > defined on the local host. > > Am I correct in assuming that while IdM is up and running, the only other systems it > will communicate with at least with regard to name services is another host also > running IdM defined either as a server or a client ? > > If this is case, is there anyone to better integrate some of these common services such > as named into an existing network such that you are not limited by the IdM components ? I would like to get additional information about your environment: - Is the IPA server is installed with DNS or not? Did you use option --setup-dns during ipa-server-install? - Which DNS zones do you have defined on IPA server? You can use command "ipa dnszone-find" to list all zones. - Is there any other DNS servers serving same DNS zones? - Did you configure forwarders in /etc/named.conf or via ipa command line tools (ipa dnsconfig-mod or --forwarder option during ipa-server-install)? - Please attach result of DNS lookups using "dig" command: One output when it doesn't work (i.e. with IPA running) and the other when it works as you expect (i.e. after "ipactl stop" and "service named restart"). Thank you. -- Petr^2 Spacek From mkosek at redhat.com Fri Oct 3 13:08:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 Oct 2014 15:08:17 +0200 Subject: [Freeipa-users] What should we do with upstream guide? In-Reply-To: <54218C86.3000901@redhat.com> References: <54218C86.3000901@redhat.com> Message-ID: <542E9FC1.4030300@redhat.com> On 09/23/2014 05:06 PM, Martin Kosek wrote: > 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 > Hello list! I did not see any further comments, objections or offers in this thread. In that case, we should then soon follow with the proposed path, i.e. to deprecate FreeIPA upstream guide and it's repository, publish upstream information on the FreeIPA.org wiki and have the full Guides managed only by (RHEL) downstream. What we may do though is to publish a mirror of downstream RHEL guide git repo so that interested people can contribute to the downstream guide in form of patches and not just bug reports. I know that at least Gabe liked that idea. Thanks, Martin From licause at hp.com Fri Oct 3 14:32:42 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Fri, 3 Oct 2014 14:32:42 +0000 Subject: [Freeipa-users] FW: named and IpA References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <20141003062259.GY18414@redhat.com> Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1FC5@G6W2496.americas.hpqcorp.net> -----Original Message----- From: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) Sent: Friday, October 03, 2014 6:31 AM To: 'Jan Pazdziora' Subject: RE: [Freeipa-users] named and IpA Jan, After submitting this request and since these are crash and burn lab systems, I reran the ipa-server-install --uninstall and ran the installation script again this time without allowing a local dns server to be created. Once we got all of our zone files corrected the system was able to resolve names and addresses but I have rerun the configurator again today so I can try to answer your questions. Just after running the configurator and setting up a new IdM server, the resolve.conf contains the following: search osn.cxo.cpqcorp.net nameserver 16.112.240.59 This is the domain in which this server resides and this is the servers ip address. By default, the /etc/named.conf file that is created only loads the root servers zone and the dynamic-db "ipa" data. It also contains the following forwarder information which includes the two forwarders as requested in the installation script. forward first; forwarders { 16.112.240.27; 16.112.240.40; }; These forwarders are the two primary dns servers in the domain. Given that information, the only host that can be resolved at the moment is the local servers name which is linux: [root at linux named]# nslookup linux Server: 16.112.240.59 Address: 16.112.240.59#53 Name: linux.osn.cxo.cpqcorp.net Address: 16.112.240.59 [root at linux named]# [root at linux named]# [root at linux named]# [root at linux named]# nslookup denali Server: 16.112.240.59 Address: 16.112.240.59#53 ** server can't find denali: NXDOMAIN [root at linux named]# nslookup denali.osn.cxo.cpqcorp.net Server: 16.112.240.59 Address: 16.112.240.59#53 ** server can't find denali.osn.cxo.cpqcorp.net: NXDOMAIN [root at linux named]# nslookup 16.112.240.27 Server: 16.112.240.59 Address: 16.112.240.59#53 ** server can't find 27.240.112.16.in-addr.arpa.: NXDOMAIN [root at linux named]# nslookup www.pbs.org Server: 16.112.240.59 Address: 16.112.240.59#53 Non-authoritative answer: www.pbs.org canonical name = r53-vip.pbs.org. Name: r53-vip.pbs.org Address: 54.160.180.54 As you can see from above, only the local host was successfully resolved using nslookup. Attempts to look up any other host within our own address space fails. We can lookup hosts and addresses that are in the public space from the hints zone in the named.conf file. # dig denali ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> denali ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30298 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;denali. IN A ;; AUTHORITY SECTION: . 10564 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2014100300 1800 900 604800 86400 ;; Query time: 0 msec ;; SERVER: 16.112.240.59#53(16.112.240.59) ;; WHEN: Fri Oct 03 09:23:13 EDT 2014 ;; MSG SIZE rcvd: 110 As you can see from the dig command, the request is not going past the local host. But now if I stop ipa and then restart named on this host, the forwarders appear to work just fine: [root at linux named]# ipactl stop Stopping Directory Service Stopping ipa-otpd Service Stopping pki-tomcatd Service Stopping httpd Service Stopping ipa_memcached Service Stopping named Service Stopping kadmin Service Stopping krb5kdc Service ipa: INFO: The ipactl command was successful [root at linux named]# [root at linux named]# [root at linux named]# systemctl start named [root at linux named]# [root at linux named]# [root at linux named]# systemctl status named.service named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service; disabled) Active: active (running) since Fri 2014-10-03 09:24:26 EDT; 8s ago Process: 7801 ExecStop=/bin/sh -c /usr/sbin/rndc stop > /dev/null 2>&1 || /bin/kill -TERM $MAINPID (code=exited, status=0/SUCCESS) Process: 7820 ExecStart=/usr/sbin/named -u named $OPTIONS (code=exited, status=0/SUCCESS) Process: 7818 ExecStartPre=/usr/sbin/named-checkconf -z /etc/named.conf (code=exited, status=0/SUCCESS) Main PID: 7823 (named) CGroup: /system.slice/named.service ??7823 /usr/sbin/named -u named Oct 03 09:24:26 linux.ipa.osn.cxo.cpqcorp.net named[7823]: managed-keys-zone:... Oct 03 09:24:26 linux.ipa.osn.cxo.cpqcorp.net named[7823]: zone 0.in-addr.arp... Oct 03 09:24:26 linux.ipa.osn.cxo.cpqcorp.net named[7823]: zone 1.0.0.127.in-... Oct 03 09:24:26 linux.ipa.osn.cxo.cpqcorp.net named[7823]: zone 1.0.0.0.0.0.0... Oct 03 09:24:26 linux.ipa.osn.cxo.cpqcorp.net named[7823]: zone localhost/IN:... Oct 03 09:24:26 linux.ipa.osn.cxo.cpqcorp.net named[7823]: zone localhost.loc... Oct 03 09:24:26 linux.ipa.osn.cxo.cpqcorp.net named[7823]: all zones loaded Oct 03 09:24:26 linux.ipa.osn.cxo.cpqcorp.net named[7823]: running Oct 03 09:24:26 linux.ipa.osn.cxo.cpqcorp.net named[7823]: ldap_psearch_watch... Oct 03 09:24:26 linux.ipa.osn.cxo.cpqcorp.net systemd[1]: Started Berkeley In... Hint: Some lines were ellipsized, use -l to show in full. [root at linux named]# dig denali ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> denali ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14741 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;denali. IN A ;; AUTHORITY SECTION: . 10473 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2014100300 1800 900 604800 86400 ;; Query time: 4 msec ;; SERVER: 16.112.240.59#53(16.112.240.59) ;; WHEN: Fri Oct 03 09:24:44 EDT 2014 ;; MSG SIZE rcvd: 110 [root at linux named]# [root at linux named]# [root at linux named]# nslookup denali Server: 16.112.240.59 Address: 16.112.240.59#53 Non-authoritative answer: Name: denali.osn.cxo.cpqcorp.net Address: 16.112.240.40 [root at linux named]# nslookup dl160a Server: 16.112.240.59 Address: 16.112.240.59#53 Non-authoritative answer: Name: dl160a.osn.cxo.cpqcorp.net Address: 16.112.240.191 So I have to ask what is IdM doing internally that prevents the name service from correctly forwarding requests to other local name servers ? Or....what have I failed to configure to get this to work correctly ? I did notice the following text displayed toward the end of the ipa-server-install script run that states this: Global DNS configuration in LDAP server is empty You can use 'dnsconfig-mod' command to set global DNS options that would override settings in local named.conf files Could it be that once we use dnsconfig-mod to add some dns information to the local 389 directory server that this will repair this problem ? And if so, what specifically needs to be added ? Thanks Al -----Original Message----- From: Jan Pazdziora [mailto:jpazdziora at redhat.com] Sent: Thursday, October 02, 2014 11:23 PM To: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] named and IpA On Thu, Oct 02, 2014 at 05:05:10PM +0000, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > > >From the IdM server we can only lookup local records. The name > >resolver will not > attempt to look to another other name servers or domains defined in > /etc/resolv.conf What exactly is in your /etc/resolv.conf? Just the IP address of the IPA server (localhost), or some other records? > If I shutdown IdM using ipactl stop and then restart named, the name > resolver works for local and remote hosts, addresses and domains as > well as serving up the SRV records defined on the local host. So if all IdM services are running, you do not seem to have named observing forwarders settings but if you only run named on the IdM machine and nothing else, it starts to observe them? Can you show dig output for one of the problematic records to see which DNS server is answering the query? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From licause at hp.com Fri Oct 3 14:32:59 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Fri, 3 Oct 2014 14:32:59 +0000 Subject: [Freeipa-users] FW: named and IpA References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <20141003062259.GY18414@redhat.com> Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1FCC@G6W2496.americas.hpqcorp.net> -----Original Message----- From: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) Sent: Friday, October 03, 2014 7:11 AM To: 'Jan Pazdziora' Subject: RE: [Freeipa-users] named and IpA Jan, Just for kicks, I tried to use the ipa dnsconfig-mod command to add information about the local name server. I was able to set the forwarding policy but I was only able to set a single forwarder. If I issued a second forwarder, the previous entry was replaced by the new one and only one forwarder shows as active: [root at linux named]# ipa dnsconfig-show Global forwarders: 16.112.240.40 Forward policy: first [root at linux named]# ipa dnsconfig-mod --forwarder=16.112.240.27 Global forwarders: 16.112.240.27 Forward policy: first [root at linux named]# ipa dnsconfig-show Global forwarders: 16.112.240.27 Forward policy: first If I attempt to place more than one forwarder in the arguments, I get an error: [root at linux named]# ipa dnsconfig-mod --forwarder=16.112.240.27;16.112.240.40 ipa: ERROR: no modifications to be performed bash: 16.112.240.40: command not found... The Fedora documentation only gives examples for adding a single forwarder.....so this seems to be a shortcoming in the current implementation. However, having performed these steps, it still did not allow the local name server to look at anything past the local database or use the designated forwarders. Al -----Original Message----- From: Jan Pazdziora [mailto:jpazdziora at redhat.com] Sent: Thursday, October 02, 2014 11:23 PM To: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] named and IpA On Thu, Oct 02, 2014 at 05:05:10PM +0000, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > > >From the IdM server we can only lookup local records. The name > >resolver will not > attempt to look to another other name servers or domains defined in > /etc/resolv.conf What exactly is in your /etc/resolv.conf? Just the IP address of the IPA server (localhost), or some other records? > If I shutdown IdM using ipactl stop and then restart named, the name > resolver works for local and remote hosts, addresses and domains as > well as serving up the SRV records defined on the local host. So if all IdM services are running, you do not seem to have named observing forwarders settings but if you only run named on the IdM machine and nothing else, it starts to observe them? Can you show dig output for one of the problematic records to see which DNS server is answering the query? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From licause at hp.com Fri Oct 3 14:51:48 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Fri, 3 Oct 2014 14:51:48 +0000 Subject: [Freeipa-users] FW: named and IpA In-Reply-To: <542DECB9.7090301@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <542DECB9.7090301@redhat.com> Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1FFC@G6W2496.americas.hpqcorp.net> Dmitri, Thanks for the input, but I tend to think the problem is further down within IM. If it were a pure name misconfiguration why would it work when IM is shut down and named restarted, with no change to the dns records ? I'll keep monitoring this discussion for further input. Al From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Thursday, October 02, 2014 5:24 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] named and IpA On 10/02/2014 01:05 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: [cid:part1.05000104.02080200 at redhat.com] We have IdM running on a RHEL V7 system and have configured a local DNS server in our test lab. We have loaded the various SRV and TXT records needed by the IdM server. PROBLEM: >From the IdM server we can only lookup local records. The name resolver will not attempt to look to another other name servers or domains defined in /etc/resolv.conf If I shutdown IdM using ipactl stop and then restart named, the name resolver works for local and remote hosts, addresses and domains as well as serving up the SRV records defined on the local host. Am I correct in assuming that while IdM is up and running, the only other systems it will communicate with at least with regard to name services is another host also running IdM defined either as a server or a client ? If this is case, is there anyone to better integrate some of these common services such as named into an existing network such that you are not limited by the IdM components ? Al Licause If DNS is running on IdM the DNS lookups might be forwarded to different DNS servers depending on your DNS cofiguration. Based on what you describe it seems that there is some sort of DNS misconfiguration. I would leave to gurus to help you with that. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ATT00001.gif Type: image/gif Size: 2051 bytes Desc: ATT00001.gif URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00002.txt URL: From licause at hp.com Fri Oct 3 14:55:56 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Fri, 3 Oct 2014 14:55:56 +0000 Subject: [Freeipa-users] FW: Problems and questions installing Identity Manager on RHEL V7 In-Reply-To: <20141003073009.GA4683@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1C0E@G6W2496.americas.hpqcorp.net> <20141001174622.GB6186@redhat.com> <542E0C33.60300@redhat.com> <20141003073009.GA4683@redhat.com> Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C201C@G6W2496.americas.hpqcorp.net> The steps recommended by Alexander did work for me, but should it happen again, is there anything that can be gathered/submitted to help debug this ? Al -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: Friday, October 03, 2014 12:30 AM To: Endi Sukma Dewata Cc: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support); freeipa-users at redhat.com Subject: Re: [Freeipa-users] Problems and questions installing Identity Manager on RHEL V7 On Thu, 02 Oct 2014, Endi Sukma Dewata wrote: >On 10/1/2014 12:46 PM, Alexander Bokovoy wrote: >>On Wed, 01 Oct 2014, Licause, Al (CSC AMS BCS - UNIX/Linux Network >>Support) wrote: > >>>I have tried to deinstall and reinstall the ipa server but the >>>installation is now failing. >>> >>> >>>The ipa-server-install is failing with the following: >>> >>> [37/38]: tuning directory server >>> [38/38]: configuring directory to start on boot Done configuring >>>directory server (dirsrv). >>>Configuring certificate server (pki-tomcatd): Estimated time 3 >>>minutes >>>30 seconds >>> [1/22]: creating certificate server user >>> [2/22]: configuring certificate server instance >>>ipa : CRITICAL failed to configure ca instance Command >>>'/usr/sbin/pkispawn -s CA -f /tmp/tmpLb1CmI' returned non-zero exit >>>status 1 Configuration of CA failed >>> >>>This happens each time I try to uninstall and reinstall the ipa >>>server on RHEL V7. >>> >>> >>>Looking at the latest log in /var/log/pki, I see this at the end of >>>the log: >>> >>>2014-10-01 11:53:10 pkispawn : INFO BEGIN spawning subsystem >>>'CA' of instance 'pki-tomcat' . . . >>>2014-10-01 11:53:10 pkispawn : INFO ... initializing >>>'pki.deployment.initialization' >>>2014-10-01 11:53:10 pkispawn : ERROR ....... PKI subsystem 'CA' >>>for instance 'pki-tomcat' already exists! >>>2014-10-01 11:53:10 pkispawn : DEBUG ....... Error Type: SystemExit >>>2014-10-01 11:53:10 pkispawn : DEBUG ....... Error Message: 1 >>>2014-10-01 11:53:10 pkispawn : DEBUG ....... File >>>"/usr/sbin/pkispawn", line 374, in main >>> rv = instance.spawn() >>> File >>>"/usr/lib/python2.7/site-packages/pki/deployment/initialization.py", >>>line 56, in spawn >>> util.instance.verify_subsystem_does_not_exist() >>> File "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py", >>>line 990, in verify_subsystem_does_not_exist >>> sys.exit(1) >>> >>>I am no python expert by any means and I'm not sure what this is >>>telling us so any help would be greatly appreciated. > >>This issue is known -- when CA install fails, we rollback but since CA >>isn't installed, we miss rolling it back. There is a ticket for >>eventually fixing this issue. > >Which ticket is this? The rollback was actually disabled to allow >troubleshooting the failed installation: >https://fedorahosted.org/freeipa/ticket/3990 I think this ticket is unrelated -- its solution only affects ipa-client-install --on-master, not what ipa-server-install does when it rolls back configuration for dirsrv and other servers. I can't find the exact ticket though. >>Following sequence should clean up all the bits: >> >>pkidestroy -s CA -i pki-tomcat >>rm -rf /var/log/pki/pki-tomcat >>rm -rf /etc/sysconfig/pki-tomcat >>rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat >>rm -rf /var/lib/pki/pki-tomcat >>rm -rf /etc/pki/pki-tomcat > >It's not official, but we call this step pki-nuke. > >>It also helps to reboot between multiple reinstalls on a single machine. > >Rather than rolling back the installation automatically (and delete all >files needed to troubleshoot the problem), it would be better to >provide an option to the uninstall command to forcibly remove all >installed files regardless whether the installation was successful or >not, just like the pki-nuke above. We simply have no information about the fact what pkicreate did before it failed. -- / Alexander Bokovoy From rmeggins at redhat.com Fri Oct 3 15:03:24 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 03 Oct 2014 09:03:24 -0600 Subject: [Freeipa-users] FW: named and IpA In-Reply-To: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1FCC@G6W2496.americas.hpqcorp.net> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <20141003062259.GY18414@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1FCC@G6W2496.americas.hpqcorp.net> Message-ID: <542EBABC.4060904@redhat.com> On 10/03/2014 08:32 AM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > > -----Original Message----- > From: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) > Sent: Friday, October 03, 2014 7:11 AM > To: 'Jan Pazdziora' > Subject: RE: [Freeipa-users] named and IpA > > Jan, > > Just for kicks, I tried to use the ipa dnsconfig-mod command to add information about the local name server. > > I was able to set the forwarding policy but I was only able to set a single forwarder. > > If I issued a second forwarder, the previous entry was replaced by the new one and only one forwarder shows as active: > > [root at linux named]# ipa dnsconfig-show > Global forwarders: 16.112.240.40 > Forward policy: first > > [root at linux named]# ipa dnsconfig-mod --forwarder=16.112.240.27 > Global forwarders: 16.112.240.27 > Forward policy: first > > [root at linux named]# ipa dnsconfig-show > Global forwarders: 16.112.240.27 > Forward policy: first > > If I attempt to place more than one forwarder in the arguments, I get an error: > > [root at linux named]# ipa dnsconfig-mod --forwarder=16.112.240.27;16.112.240.40 > ipa: ERROR: no modifications to be performed > bash: 16.112.240.40: command not found... You cannot use an unescaped semicolon $ man bash ... DEFINITIONS ... metacharacter A character that, when unquoted, separates words. One of the following: | & ; ( ) < > space tab > > The Fedora documentation only gives examples for adding a single forwarder.....so this seems to be a shortcoming in the current implementation. > > However, having performed these steps, it still did not allow the local name server to look at anything past the local database or use the designated forwarders. > > Al > > > -----Original Message----- > From: Jan Pazdziora [mailto:jpazdziora at redhat.com] > Sent: Thursday, October 02, 2014 11:23 PM > To: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] named and IpA > > On Thu, Oct 02, 2014 at 05:05:10PM +0000, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: >> >From the IdM server we can only lookup local records. The name >>> resolver will not >> attempt to look to another other name servers or domains defined in >> /etc/resolv.conf > What exactly is in your /etc/resolv.conf? Just the IP address of the IPA server (localhost), or some other records? > >> If I shutdown IdM using ipactl stop and then restart named, the name >> resolver works for local and remote hosts, addresses and domains as >> well as serving up the SRV records defined on the local host. > So if all IdM services are running, you do not seem to have named observing forwarders settings but if you only run named on the IdM machine and nothing else, it starts to observe them? > > Can you show dig output for one of the problematic records to see which DNS server is answering the query? > > -- > Jan Pazdziora > Principal Software Engineer, Identity Management Engineering, Red Hat > From licause at hp.com Fri Oct 3 15:13:04 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Fri, 3 Oct 2014 15:13:04 +0000 Subject: [Freeipa-users] FW: named and IpA In-Reply-To: <542E5DAF.2090706@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <542E5DAF.2090706@redhat.com> Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2057@G6W2496.americas.hpqcorp.net> -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek Sent: Friday, October 03, 2014 1:26 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] named and IpA On 2.10.2014 19:05, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > We have IdM running on a RHEL V7 system and have configured a local > DNS server in our test lab. > > We have loaded the various SRV and TXT records needed by the IdM server. > > > PROBLEM: > >>From the IdM server we can only lookup local records. The name >>resolver will not > attempt to look to another other name servers or domains defined in > /etc/resolv.conf > > If I shutdown IdM using ipactl stop and then restart named, the name > resolver works for local and remote hosts, addresses and domains as > well as serving up the SRV records defined on the local host. > > Am I correct in assuming that while IdM is up and running, the only > other systems it will communicate with at least with regard to name > services is another host also running IdM defined either as a server or a client ? > > If this is case, is there anyone to better integrate some of these > common services such as named into an existing network such that you are not limited by the IdM components ? I would like to get additional information about your environment: - Is the IPA server is installed with DNS or not? Did you use option --setup-dns during ipa-server-install? >> I have tried it both ways, but the most current in which we see this behavior I ran ipa-server-install with >> no arguments and said yes to the question about installing DNS. I then replied with two valid forwarders. >> In a previous installation, we added two of our local zones from one of the other dns server >> and then added the sample zone provided by the installation which contained the various SRV and TXT >> records. But for current reporting of this problem, we did not add/load the other zone files. - Which DNS zones do you have defined on IPA server? You can use command "ipa dnszone-find" to list all zones. [root at linux named]# ipa dnsconfig-mod --forwarder=16.112.240.27;16.112.240.40 ipa: ERROR: no modifications to be performed bash: 16.112.240.40: command not found... [root at linux named]# ipa dnszone-find Zone name: 240.112.16.in-addr.arpa. Authoritative nameserver: linux.osn.cxo.cpqcorp.net. Administrator e-mail address: hostmaster.osn.cxo.cpqcorp.net. SOA serial: 1412344406 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Active zone: TRUE Allow query: any; Allow transfer: none; Zone name: osn.cxo.cpqcorp.net Authoritative nameserver: linux.osn.cxo.cpqcorp.net. Administrator e-mail address: hostmaster.osn.cxo.cpqcorp.net. SOA serial: 1412344406 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Active zone: TRUE Allow query: any; Allow transfer: none; ---------------------------- Number of entries returned 2 ---------------------------- - Is there any other DNS servers serving same DNS zones? >> Yes....we left the other two existing DNS servers in place as they are our primary name servers for this lab segment. >> Those are the two systems we have entered as forwarders. - Did you configure forwarders in /etc/named.conf or via ipa command line tools (ipa dnsconfig-mod or --forwarder option during ipa-server-install)? >> The forwarders were placed in the /etc/named.conf file by the ipa-server-install script or one of its subordinate scripts >> I did try entering the forward policy and forwarders using ipa dnsconfig-mod but they didn't seem to change the behavior. >> One thing I did notice was that ipa dnsconfig-mod --forwarder= only allowed one forwarder to be entered.....adding >> a second entry on the line resulted in an error. If entered with a second --forwarders command, the previous forwarder >> was replaced by the new one. So if there is a particular syntax that would allow more than one entry, can you please >> post same ? - Please attach result of DNS lookups using "dig" command: One output when it doesn't work (i.e. with IPA running) and the other when it works as you expect (i.e. after "ipactl stop" and "service named restart"). >> with ipa running: [root at linux named]# nslookup dl160a.osn.cxo.cpqcorp.net Server: 16.112.240.59 Address: 16.112.240.59#53 ** server can't find dl160a.osn.cxo.cpqcorp.net: NXDOMAIN [root at linux named]# dig dl160a.osn.cxo.cpqcorp.net ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> dl160a.osn.cxo.cpqcorp.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6571 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;dl160a.osn.cxo.cpqcorp.net. IN A ;; AUTHORITY SECTION: osn.cxo.cpqcorp.net. 3600 IN SOA linux.osn.cxo.cpqcorp.net. hostmaster.osn.cxo.cpqcorp.net. 1412344406 3600 900 1209600 3600 ;; Query time: 1 msec ;; SERVER: 16.112.240.59#53(16.112.240.59) ;; WHEN: Fri Oct 03 11:08:35 EDT 2014 ;; MSG SIZE rcvd: 108 [root at linux named]# ipactl stop Stopping Directory Service Stopping ipa-otpd Service Stopping pki-tomcatd Service Stopping httpd Service Stopping ipa_memcached Service Stopping named Service Stopping kadmin Service Stopping krb5kdc Service ipa: INFO: The ipactl command was successful [root at linux named]# systemctl start named [root at linux named]# [root at linux named]# [root at linux named]# dig dl160a.osn.cxo.cpqcorp.net ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> dl160a.osn.cxo.cpqcorp.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28446 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;dl160a.osn.cxo.cpqcorp.net. IN A ;; ANSWER SECTION: dl160a.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.191 ;; AUTHORITY SECTION: osn.cxo.cpqcorp.net. 43200 IN NS cluster.osn.cxo.cpqcorp.net. osn.cxo.cpqcorp.net. 43200 IN NS win2008.osn.cxo.cpqcorp.net. osn.cxo.cpqcorp.net. 43200 IN NS denali.osn.cxo.cpqcorp.net. ;; ADDITIONAL SECTION: win2008.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.55 cluster.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.27 denali.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.40 ;; Query time: 4 msec ;; SERVER: 16.112.240.59#53(16.112.240.59) ;; WHEN: Fri Oct 03 11:10:54 EDT 2014 ;; MSG SIZE rcvd: 184 Thank you. -- Petr^2 Spacek -- 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 From licause at hp.com Fri Oct 3 15:22:35 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Fri, 3 Oct 2014 15:22:35 +0000 Subject: [Freeipa-users] FW: FW: named and IpA In-Reply-To: <542EBABC.4060904@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <20141003062259.GY18414@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1FCC@G6W2496.americas.hpqcorp.net> <542EBABC.4060904@redhat.com> Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2083@G6W2496.americas.hpqcorp.net> -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson Sent: Friday, October 03, 2014 8:03 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] FW: named and IpA On 10/03/2014 08:32 AM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > > -----Original Message----- > From: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) > Sent: Friday, October 03, 2014 7:11 AM > To: 'Jan Pazdziora' > Subject: RE: [Freeipa-users] named and IpA > > Jan, > > Just for kicks, I tried to use the ipa dnsconfig-mod command to add information about the local name server. > > I was able to set the forwarding policy but I was only able to set a single forwarder. > > If I issued a second forwarder, the previous entry was replaced by the new one and only one forwarder shows as active: > > [root at linux named]# ipa dnsconfig-show > Global forwarders: 16.112.240.40 > Forward policy: first > > [root at linux named]# ipa dnsconfig-mod --forwarder=16.112.240.27 > Global forwarders: 16.112.240.27 > Forward policy: first > > [root at linux named]# ipa dnsconfig-show > Global forwarders: 16.112.240.27 > Forward policy: first > > If I attempt to place more than one forwarder in the arguments, I get an error: > > [root at linux named]# ipa dnsconfig-mod > --forwarder=16.112.240.27;16.112.240.40 > ipa: ERROR: no modifications to be performed > bash: 16.112.240.40: command not found... You cannot use an unescaped semicolon $ man bash ... DEFINITIONS ... metacharacter A character that, when unquoted, separates words. One of the following: | & ; ( ) < > space tab >> Thanks for the reply. If it is possible to enter more than one forwarder with the ipa dnsconfig-mod command, can >> you show an example ? I have tried variations with no luck. Al > > The Fedora documentation only gives examples for adding a single forwarder.....so this seems to be a shortcoming in the current implementation. > > However, having performed these steps, it still did not allow the local name server to look at anything past the local database or use the designated forwarders. > > Al > > > -----Original Message----- > From: Jan Pazdziora [mailto:jpazdziora at redhat.com] > Sent: Thursday, October 02, 2014 11:23 PM > To: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] named and IpA > > On Thu, Oct 02, 2014 at 05:05:10PM +0000, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: >> >From the IdM server we can only lookup local records. The name >>> resolver will not >> attempt to look to another other name servers or domains defined in >> /etc/resolv.conf > What exactly is in your /etc/resolv.conf? Just the IP address of the IPA server (localhost), or some other records? > >> If I shutdown IdM using ipactl stop and then restart named, the name >> resolver works for local and remote hosts, addresses and domains as >> well as serving up the SRV records defined on the local host. > So if all IdM services are running, you do not seem to have named observing forwarders settings but if you only run named on the IdM machine and nothing else, it starts to observe them? > > Can you show dig output for one of the problematic records to see which DNS server is answering the query? > > -- > Jan Pazdziora > Principal Software Engineer, Identity Management Engineering, Red Hat > -- 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 From rmeggins at redhat.com Fri Oct 3 16:43:38 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 03 Oct 2014 10:43:38 -0600 Subject: [Freeipa-users] FW: FW: named and IpA In-Reply-To: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2083@G6W2496.americas.hpqcorp.net> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <20141003062259.GY18414@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1FCC@G6W2496.americas.hpqcorp.net> <542EBABC.4060904@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2083@G6W2496.americas.hpqcorp.net> Message-ID: <542ED23A.90104@redhat.com> On 10/03/2014 09:22 AM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson > Sent: Friday, October 03, 2014 8:03 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FW: named and IpA > > On 10/03/2014 08:32 AM, Licause, Al (CSC AMS BCS - UNIX/Linux Network > Support) wrote: >> -----Original Message----- >> From: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) >> Sent: Friday, October 03, 2014 7:11 AM >> To: 'Jan Pazdziora' >> Subject: RE: [Freeipa-users] named and IpA >> >> Jan, >> >> Just for kicks, I tried to use the ipa dnsconfig-mod command to add information about the local name server. >> >> I was able to set the forwarding policy but I was only able to set a single forwarder. >> >> If I issued a second forwarder, the previous entry was replaced by the new one and only one forwarder shows as active: >> >> [root at linux named]# ipa dnsconfig-show >> Global forwarders: 16.112.240.40 >> Forward policy: first >> >> [root at linux named]# ipa dnsconfig-mod --forwarder=16.112.240.27 >> Global forwarders: 16.112.240.27 >> Forward policy: first >> >> [root at linux named]# ipa dnsconfig-show >> Global forwarders: 16.112.240.27 >> Forward policy: first >> >> If I attempt to place more than one forwarder in the arguments, I get an error: >> >> [root at linux named]# ipa dnsconfig-mod >> --forwarder=16.112.240.27;16.112.240.40 >> ipa: ERROR: no modifications to be performed >> bash: 16.112.240.40: command not found... > You cannot use an unescaped semicolon > $ man bash > ... > DEFINITIONS > ... > metacharacter > A character that, when unquoted, separates words. One of the > following: > | & ; ( ) < > space tab > >>> Thanks for the reply. If it is possible to enter more than one forwarder with the ipa dnsconfig-mod command, can >>> you show an example ? I have tried variations with no luck. > Al Have you tried multiple --forwarder flags? e.g. # ipa dnsconfig-mod --forwarder=16.112.240.27 --forwarder=16.112.240.40 ... > > >> The Fedora documentation only gives examples for adding a single forwarder.....so this seems to be a shortcoming in the current implementation. >> >> However, having performed these steps, it still did not allow the local name server to look at anything past the local database or use the designated forwarders. >> >> Al >> >> >> -----Original Message----- >> From: Jan Pazdziora [mailto:jpazdziora at redhat.com] >> Sent: Thursday, October 02, 2014 11:23 PM >> To: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] named and IpA >> >> On Thu, Oct 02, 2014 at 05:05:10PM +0000, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: >>> >From the IdM server we can only lookup local records. The name >>>> resolver will not >>> attempt to look to another other name servers or domains defined in >>> /etc/resolv.conf >> What exactly is in your /etc/resolv.conf? Just the IP address of the IPA server (localhost), or some other records? >> >>> If I shutdown IdM using ipactl stop and then restart named, the name >>> resolver works for local and remote hosts, addresses and domains as >>> well as serving up the SRV records defined on the local host. >> So if all IdM services are running, you do not seem to have named observing forwarders settings but if you only run named on the IdM machine and nothing else, it starts to observe them? >> >> Can you show dig output for one of the problematic records to see which DNS server is answering the query? >> >> -- >> Jan Pazdziora >> Principal Software Engineer, Identity Management Engineering, Red Hat >> > -- > 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 > From dpal at redhat.com Fri Oct 3 17:16:17 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 03 Oct 2014 13:16:17 -0400 Subject: [Freeipa-users] FW: named and IpA In-Reply-To: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2057@G6W2496.americas.hpqcorp.net> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <542E5DAF.2090706@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2057@G6W2496.americas.hpqcorp.net> Message-ID: <542ED9E1.1050401@redhat.com> On 10/03/2014 11:13 AM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek > Sent: Friday, October 03, 2014 1:26 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] named and IpA > > On 2.10.2014 19:05, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: >> We have IdM running on a RHEL V7 system and have configured a local >> DNS server in our test lab. >> >> We have loaded the various SRV and TXT records needed by the IdM server. >> >> >> PROBLEM: >> >> >From the IdM server we can only lookup local records. The name >>> resolver will not >> attempt to look to another other name servers or domains defined in >> /etc/resolv.conf >> >> If I shutdown IdM using ipactl stop and then restart named, the name >> resolver works for local and remote hosts, addresses and domains as >> well as serving up the SRV records defined on the local host. >> >> Am I correct in assuming that while IdM is up and running, the only >> other systems it will communicate with at least with regard to name >> services is another host also running IdM defined either as a server or a client ? >> >> If this is case, is there anyone to better integrate some of these >> common services such as named into an existing network such that you are not limited by the IdM components ? > I would like to get additional information about your environment: > - Is the IPA server is installed with DNS or not? Did you use option --setup-dns during ipa-server-install? > >>> I have tried it both ways, but the most current in which we see this behavior I ran ipa-server-install with >>> no arguments and said yes to the question about installing DNS. I then replied with two valid forwarders. >>> In a previous installation, we added two of our local zones from one of the other dns server >>> and then added the sample zone provided by the installation which contained the various SRV and TXT >>> records. But for current reporting of this problem, we did not add/load the other zone files. > - Which DNS zones do you have defined on IPA server? You can use command "ipa dnszone-find" to list all zones. > > [root at linux named]# ipa dnsconfig-mod --forwarder=16.112.240.27;16.112.240.40 > ipa: ERROR: no modifications to be performed > bash: 16.112.240.40: command not found... > [root at linux named]# ipa dnszone-find > Zone name: 240.112.16.in-addr.arpa. > Authoritative nameserver: linux.osn.cxo.cpqcorp.net. > Administrator e-mail address: hostmaster.osn.cxo.cpqcorp.net. > SOA serial: 1412344406 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > Active zone: TRUE > Allow query: any; > Allow transfer: none; > > Zone name: osn.cxo.cpqcorp.net > Authoritative nameserver: linux.osn.cxo.cpqcorp.net. > Administrator e-mail address: hostmaster.osn.cxo.cpqcorp.net. > SOA serial: 1412344406 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > Active zone: TRUE > Allow query: any; > Allow transfer: none; > ---------------------------- > Number of entries returned 2 > ---------------------------- > > - Is there any other DNS servers serving same DNS zones? > >>> Yes....we left the other two existing DNS servers in place as they are our primary name servers for this lab segment. >>> Those are the two systems we have entered as forwarders. > - Did you configure forwarders in /etc/named.conf or via ipa command line tools (ipa dnsconfig-mod or --forwarder option during ipa-server-install)? > >>> The forwarders were placed in the /etc/named.conf file by the ipa-server-install script or one of its subordinate scripts >>> I did try entering the forward policy and forwarders using ipa dnsconfig-mod but they didn't seem to change the behavior. >>> One thing I did notice was that ipa dnsconfig-mod --forwarder= only allowed one forwarder to be entered.....adding >>> a second entry on the line resulted in an error. If entered with a second --forwarders command, the previous forwarder >>> was replaced by the new one. So if there is a particular syntax that would allow more than one entry, can you please >>> post same ? > - Please attach result of DNS lookups using "dig" command: One output when it doesn't work (i.e. with IPA running) and the other when it works as you expect (i.e. after "ipactl stop" and "service named restart"). > >>> with ipa running: > [root at linux named]# nslookup dl160a.osn.cxo.cpqcorp.net > Server: 16.112.240.59 > Address: 16.112.240.59#53 > > ** server can't find dl160a.osn.cxo.cpqcorp.net: NXDOMAIN > > [root at linux named]# dig dl160a.osn.cxo.cpqcorp.net > > ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> dl160a.osn.cxo.cpqcorp.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6571 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;dl160a.osn.cxo.cpqcorp.net. IN A > > ;; AUTHORITY SECTION: > osn.cxo.cpqcorp.net. 3600 IN SOA linux.osn.cxo.cpqcorp.net. hostmaster.osn.cxo.cpqcorp.net. 1412344406 3600 900 1209600 3600 > > ;; Query time: 1 msec > ;; SERVER: 16.112.240.59#53(16.112.240.59) > ;; WHEN: Fri Oct 03 11:08:35 EDT 2014 > ;; MSG SIZE rcvd: 108 > > > [root at linux named]# ipactl stop > Stopping Directory Service > Stopping ipa-otpd Service > Stopping pki-tomcatd Service > Stopping httpd Service > Stopping ipa_memcached Service > Stopping named Service > Stopping kadmin Service > Stopping krb5kdc Service > ipa: INFO: The ipactl command was successful > > [root at linux named]# systemctl start named > [root at linux named]# > [root at linux named]# > [root at linux named]# dig dl160a.osn.cxo.cpqcorp.net > > ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> dl160a.osn.cxo.cpqcorp.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28446 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;dl160a.osn.cxo.cpqcorp.net. IN A > > ;; ANSWER SECTION: > dl160a.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.191 > > ;; AUTHORITY SECTION: > osn.cxo.cpqcorp.net. 43200 IN NS cluster.osn.cxo.cpqcorp.net. > osn.cxo.cpqcorp.net. 43200 IN NS win2008.osn.cxo.cpqcorp.net. > osn.cxo.cpqcorp.net. 43200 IN NS denali.osn.cxo.cpqcorp.net. > > ;; ADDITIONAL SECTION: > win2008.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.55 > cluster.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.27 > denali.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.40 > > ;; Query time: 4 msec > ;; SERVER: 16.112.240.59#53(16.112.240.59) > ;; WHEN: Fri Oct 03 11:10:54 EDT 2014 > ;; MSG SIZE rcvd: 184 > > > Thank you. > > -- > Petr^2 Spacek > > -- > 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 > I am not a specialist but can it be that when you run just named it uses files and when you start IPA it uses LDAP database and the issue that the forwarders are correctly recorded in files (manually?) but not in the LDAP database? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From licause at hp.com Fri Oct 3 17:20:51 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Fri, 3 Oct 2014 17:20:51 +0000 Subject: [Freeipa-users] FW: FW: FW: named and IpA In-Reply-To: <542ED23A.90104@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <20141003062259.GY18414@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1FCC@G6W2496.americas.hpqcorp.net> <542EBABC.4060904@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2083@G6W2496.americas.hpqcorp.net> <542ED23A.90104@redhat.com> Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C213C@G6W2496.americas.hpqcorp.net> Ah....excellent suggestion ! Thanks very much that worked..... [root at linux named]# ipa dnsconfig-mod --forwarder=16.112.240.27 --forwarder=16.112.240.40 Global forwarders: 16.112.240.27, 16.112.240.40 Forward policy: first Unfortunately it didn't fix the problem......while IdM is running the local name server still can't resolve any hosts or addresses out unknown to the local name server. Al -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson Sent: Friday, October 03, 2014 9:44 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] FW: FW: named and IpA On 10/03/2014 09:22 AM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson > Sent: Friday, October 03, 2014 8:03 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FW: named and IpA > > On 10/03/2014 08:32 AM, Licause, Al (CSC AMS BCS - UNIX/Linux Network > Support) wrote: >> -----Original Message----- >> From: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) >> Sent: Friday, October 03, 2014 7:11 AM >> To: 'Jan Pazdziora' >> Subject: RE: [Freeipa-users] named and IpA >> >> Jan, >> >> Just for kicks, I tried to use the ipa dnsconfig-mod command to add information about the local name server. >> >> I was able to set the forwarding policy but I was only able to set a single forwarder. >> >> If I issued a second forwarder, the previous entry was replaced by the new one and only one forwarder shows as active: >> >> [root at linux named]# ipa dnsconfig-show >> Global forwarders: 16.112.240.40 >> Forward policy: first >> >> [root at linux named]# ipa dnsconfig-mod --forwarder=16.112.240.27 >> Global forwarders: 16.112.240.27 >> Forward policy: first >> >> [root at linux named]# ipa dnsconfig-show >> Global forwarders: 16.112.240.27 >> Forward policy: first >> >> If I attempt to place more than one forwarder in the arguments, I get an error: >> >> [root at linux named]# ipa dnsconfig-mod >> --forwarder=16.112.240.27;16.112.240.40 >> ipa: ERROR: no modifications to be performed >> bash: 16.112.240.40: command not found... > You cannot use an unescaped semicolon > $ man bash > ... > DEFINITIONS > ... > metacharacter > A character that, when unquoted, separates words. One of the > following: > | & ; ( ) < > space tab > >>> Thanks for the reply. If it is possible to enter more than one forwarder with the ipa dnsconfig-mod command, can >>> you show an example ? I have tried variations with no luck. > Al Have you tried multiple --forwarder flags? e.g. # ipa dnsconfig-mod --forwarder=16.112.240.27 --forwarder=16.112.240.40 ... > > >> The Fedora documentation only gives examples for adding a single forwarder.....so this seems to be a shortcoming in the current implementation. >> >> However, having performed these steps, it still did not allow the local name server to look at anything past the local database or use the designated forwarders. >> >> Al >> >> >> -----Original Message----- >> From: Jan Pazdziora [mailto:jpazdziora at redhat.com] >> Sent: Thursday, October 02, 2014 11:23 PM >> To: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] named and IpA >> >> On Thu, Oct 02, 2014 at 05:05:10PM +0000, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: >>> >From the IdM server we can only lookup local records. The name >>>> resolver will not >>> attempt to look to another other name servers or domains defined in >>> /etc/resolv.conf >> What exactly is in your /etc/resolv.conf? Just the IP address of the IPA server (localhost), or some other records? >> >>> If I shutdown IdM using ipactl stop and then restart named, the name >>> resolver works for local and remote hosts, addresses and domains as >>> well as serving up the SRV records defined on the local host. >> So if all IdM services are running, you do not seem to have named observing forwarders settings but if you only run named on the IdM machine and nothing else, it starts to observe them? >> >> Can you show dig output for one of the problematic records to see which DNS server is answering the query? >> >> -- >> Jan Pazdziora >> Principal Software Engineer, Identity Management Engineering, Red Hat >> > -- > 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 From licause at hp.com Fri Oct 3 17:30:20 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Fri, 3 Oct 2014 17:30:20 +0000 Subject: [Freeipa-users] FW: FW: named and IpA In-Reply-To: <542ED9E1.1050401@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <542E5DAF.2090706@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2057@G6W2496.americas.hpqcorp.net> <542ED9E1.1050401@redhat.com> Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2171@G6W2496.americas.hpqcorp.net> I am not a specialist but can it be that when you run just named it uses files and when you start IPA it uses LDAP database and the issue that the forwarders are correctly recorded in files (manually?) but not in the LDAP database? >> This certainly makes sense.....but then having entered the forwarders using ipa dnsconfig-mod --forwarders=...... >> didn't seem to make a difference. I assume the ipa dnsconfig-mod command places those forwarders >> in the ldap database ? >> But having done so, does anything have to be restarted to get this to work or is the effect immediate ? Al -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Friday, October 03, 2014 10:16 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] FW: named and IpA On 10/03/2014 11:13 AM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek > Sent: Friday, October 03, 2014 1:26 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] named and IpA > > On 2.10.2014 19:05, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: >> We have IdM running on a RHEL V7 system and have configured a local >> DNS server in our test lab. >> >> We have loaded the various SRV and TXT records needed by the IdM server. >> >> >> PROBLEM: >> >> >From the IdM server we can only lookup local records. The name >>> resolver will not >> attempt to look to another other name servers or domains defined in >> /etc/resolv.conf >> >> If I shutdown IdM using ipactl stop and then restart named, the name >> resolver works for local and remote hosts, addresses and domains as >> well as serving up the SRV records defined on the local host. >> >> Am I correct in assuming that while IdM is up and running, the only >> other systems it will communicate with at least with regard to name >> services is another host also running IdM defined either as a server or a client ? >> >> If this is case, is there anyone to better integrate some of these >> common services such as named into an existing network such that you are not limited by the IdM components ? > I would like to get additional information about your environment: > - Is the IPA server is installed with DNS or not? Did you use option --setup-dns during ipa-server-install? > >>> I have tried it both ways, but the most current in which we see this behavior I ran ipa-server-install with >>> no arguments and said yes to the question about installing DNS. I then replied with two valid forwarders. >>> In a previous installation, we added two of our local zones from one of the other dns server >>> and then added the sample zone provided by the installation which contained the various SRV and TXT >>> records. But for current reporting of this problem, we did not add/load the other zone files. > - Which DNS zones do you have defined on IPA server? You can use command "ipa dnszone-find" to list all zones. > > [root at linux named]# ipa dnsconfig-mod > --forwarder=16.112.240.27;16.112.240.40 > ipa: ERROR: no modifications to be performed > bash: 16.112.240.40: command not found... > [root at linux named]# ipa dnszone-find > Zone name: 240.112.16.in-addr.arpa. > Authoritative nameserver: linux.osn.cxo.cpqcorp.net. > Administrator e-mail address: hostmaster.osn.cxo.cpqcorp.net. > SOA serial: 1412344406 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > Active zone: TRUE > Allow query: any; > Allow transfer: none; > > Zone name: osn.cxo.cpqcorp.net > Authoritative nameserver: linux.osn.cxo.cpqcorp.net. > Administrator e-mail address: hostmaster.osn.cxo.cpqcorp.net. > SOA serial: 1412344406 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > Active zone: TRUE > Allow query: any; > Allow transfer: none; > ---------------------------- > Number of entries returned 2 > ---------------------------- > > - Is there any other DNS servers serving same DNS zones? > >>> Yes....we left the other two existing DNS servers in place as they are our primary name servers for this lab segment. >>> Those are the two systems we have entered as forwarders. > - Did you configure forwarders in /etc/named.conf or via ipa command line tools (ipa dnsconfig-mod or --forwarder option during ipa-server-install)? > >>> The forwarders were placed in the /etc/named.conf file by the ipa-server-install script or one of its subordinate scripts >>> I did try entering the forward policy and forwarders using ipa dnsconfig-mod but they didn't seem to change the behavior. >>> One thing I did notice was that ipa dnsconfig-mod --forwarder= only allowed one forwarder to be entered.....adding >>> a second entry on the line resulted in an error. If entered with a second --forwarders command, the previous forwarder >>> was replaced by the new one. So if there is a particular syntax that would allow more than one entry, can you please >>> post same ? > - Please attach result of DNS lookups using "dig" command: One output when it doesn't work (i.e. with IPA running) and the other when it works as you expect (i.e. after "ipactl stop" and "service named restart"). > >>> with ipa running: > [root at linux named]# nslookup dl160a.osn.cxo.cpqcorp.net > Server: 16.112.240.59 > Address: 16.112.240.59#53 > > ** server can't find dl160a.osn.cxo.cpqcorp.net: NXDOMAIN > > [root at linux named]# dig dl160a.osn.cxo.cpqcorp.net > > ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> dl160a.osn.cxo.cpqcorp.net > ;; global options: +cmd ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6571 ;; flags: qr > aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;dl160a.osn.cxo.cpqcorp.net. IN A > > ;; AUTHORITY SECTION: > osn.cxo.cpqcorp.net. 3600 IN SOA linux.osn.cxo.cpqcorp.net. hostmaster.osn.cxo.cpqcorp.net. 1412344406 3600 900 1209600 3600 > > ;; Query time: 1 msec > ;; SERVER: 16.112.240.59#53(16.112.240.59) ;; WHEN: Fri Oct 03 > 11:08:35 EDT 2014 ;; MSG SIZE rcvd: 108 > > > [root at linux named]# ipactl stop > Stopping Directory Service > Stopping ipa-otpd Service > Stopping pki-tomcatd Service > Stopping httpd Service > Stopping ipa_memcached Service > Stopping named Service > Stopping kadmin Service > Stopping krb5kdc Service > ipa: INFO: The ipactl command was successful > > [root at linux named]# systemctl start named [root at linux named]# > [root at linux named]# [root at linux named]# dig dl160a.osn.cxo.cpqcorp.net > > ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> dl160a.osn.cxo.cpqcorp.net > ;; global options: +cmd ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28446 ;; flags: qr > rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;dl160a.osn.cxo.cpqcorp.net. IN A > > ;; ANSWER SECTION: > dl160a.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.191 > > ;; AUTHORITY SECTION: > osn.cxo.cpqcorp.net. 43200 IN NS cluster.osn.cxo.cpqcorp.net. > osn.cxo.cpqcorp.net. 43200 IN NS win2008.osn.cxo.cpqcorp.net. > osn.cxo.cpqcorp.net. 43200 IN NS denali.osn.cxo.cpqcorp.net. > > ;; ADDITIONAL SECTION: > win2008.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.55 > cluster.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.27 > denali.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.40 > > ;; Query time: 4 msec > ;; SERVER: 16.112.240.59#53(16.112.240.59) ;; WHEN: Fri Oct 03 > 11:10:54 EDT 2014 ;; MSG SIZE rcvd: 184 > > > Thank you. > > -- > Petr^2 Spacek > > -- > 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 > I am not a specialist but can it be that when you run just named it uses files and when you start IPA it uses LDAP database and the issue that the forwarders are correctly recorded in files (manually?) but not in the LDAP database? -- 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 From dpal at redhat.com Fri Oct 3 17:42:48 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 03 Oct 2014 13:42:48 -0400 Subject: [Freeipa-users] FW: FW: named and IpA In-Reply-To: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2171@G6W2496.americas.hpqcorp.net> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <542E5DAF.2090706@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2057@G6W2496.americas.hpqcorp.net> <542ED9E1.1050401@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2171@G6W2496.americas.hpqcorp.net> Message-ID: <542EE018.20608@redhat.com> On 10/03/2014 01:30 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > I am not a specialist but can it be that when you run just named it uses files and when you start IPA it uses LDAP database and the issue that the forwarders are correctly recorded in files (manually?) but not in the LDAP database? > >>> This certainly makes sense.....but then having entered the forwarders using ipa dnsconfig-mod --forwarders=...... >>> didn't seem to make a difference. I assume the ipa dnsconfig-mod command places those forwarders >>> in the ldap database ? >>> But having done so, does anything have to be restarted to get this to work or is the effect immediate ? I am not sure, I think you might need to restart named when you add forwarders. I vaguely remember a ticket about it. But it seems that there might be something going on with the configuration of named. Did you touch anything manually in named.conf? Again trying to help but not a specialist by any means. :-) > Al > > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal > Sent: Friday, October 03, 2014 10:16 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FW: named and IpA > > On 10/03/2014 11:13 AM, Licause, Al (CSC AMS BCS - UNIX/Linux Network > Support) wrote: >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek >> Sent: Friday, October 03, 2014 1:26 AM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] named and IpA >> >> On 2.10.2014 19:05, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: >>> We have IdM running on a RHEL V7 system and have configured a local >>> DNS server in our test lab. >>> >>> We have loaded the various SRV and TXT records needed by the IdM server. >>> >>> >>> PROBLEM: >>> >>> >From the IdM server we can only lookup local records. The name >>>> resolver will not >>> attempt to look to another other name servers or domains defined in >>> /etc/resolv.conf >>> >>> If I shutdown IdM using ipactl stop and then restart named, the name >>> resolver works for local and remote hosts, addresses and domains as >>> well as serving up the SRV records defined on the local host. >>> >>> Am I correct in assuming that while IdM is up and running, the only >>> other systems it will communicate with at least with regard to name >>> services is another host also running IdM defined either as a server or a client ? >>> >>> If this is case, is there anyone to better integrate some of these >>> common services such as named into an existing network such that you are not limited by the IdM components ? >> I would like to get additional information about your environment: >> - Is the IPA server is installed with DNS or not? Did you use option --setup-dns during ipa-server-install? >> >>>> I have tried it both ways, but the most current in which we see this behavior I ran ipa-server-install with >>>> no arguments and said yes to the question about installing DNS. I then replied with two valid forwarders. >>>> In a previous installation, we added two of our local zones from one of the other dns server >>>> and then added the sample zone provided by the installation which contained the various SRV and TXT >>>> records. But for current reporting of this problem, we did not add/load the other zone files. >> - Which DNS zones do you have defined on IPA server? You can use command "ipa dnszone-find" to list all zones. >> >> [root at linux named]# ipa dnsconfig-mod >> --forwarder=16.112.240.27;16.112.240.40 >> ipa: ERROR: no modifications to be performed >> bash: 16.112.240.40: command not found... >> [root at linux named]# ipa dnszone-find >> Zone name: 240.112.16.in-addr.arpa. >> Authoritative nameserver: linux.osn.cxo.cpqcorp.net. >> Administrator e-mail address: hostmaster.osn.cxo.cpqcorp.net. >> SOA serial: 1412344406 >> SOA refresh: 3600 >> SOA retry: 900 >> SOA expire: 1209600 >> SOA minimum: 3600 >> Active zone: TRUE >> Allow query: any; >> Allow transfer: none; >> >> Zone name: osn.cxo.cpqcorp.net >> Authoritative nameserver: linux.osn.cxo.cpqcorp.net. >> Administrator e-mail address: hostmaster.osn.cxo.cpqcorp.net. >> SOA serial: 1412344406 >> SOA refresh: 3600 >> SOA retry: 900 >> SOA expire: 1209600 >> SOA minimum: 3600 >> Active zone: TRUE >> Allow query: any; >> Allow transfer: none; >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- >> >> - Is there any other DNS servers serving same DNS zones? >> >>>> Yes....we left the other two existing DNS servers in place as they are our primary name servers for this lab segment. >>>> Those are the two systems we have entered as forwarders. >> - Did you configure forwarders in /etc/named.conf or via ipa command line tools (ipa dnsconfig-mod or --forwarder option during ipa-server-install)? >> >>>> The forwarders were placed in the /etc/named.conf file by the ipa-server-install script or one of its subordinate scripts >>>> I did try entering the forward policy and forwarders using ipa dnsconfig-mod but they didn't seem to change the behavior. >>>> One thing I did notice was that ipa dnsconfig-mod --forwarder= only allowed one forwarder to be entered.....adding >>>> a second entry on the line resulted in an error. If entered with a second --forwarders command, the previous forwarder >>>> was replaced by the new one. So if there is a particular syntax that would allow more than one entry, can you please >>>> post same ? >> - Please attach result of DNS lookups using "dig" command: One output when it doesn't work (i.e. with IPA running) and the other when it works as you expect (i.e. after "ipactl stop" and "service named restart"). >> >>>> with ipa running: >> [root at linux named]# nslookup dl160a.osn.cxo.cpqcorp.net >> Server: 16.112.240.59 >> Address: 16.112.240.59#53 >> >> ** server can't find dl160a.osn.cxo.cpqcorp.net: NXDOMAIN >> >> [root at linux named]# dig dl160a.osn.cxo.cpqcorp.net >> >> ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> dl160a.osn.cxo.cpqcorp.net >> ;; global options: +cmd ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6571 ;; flags: qr >> aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;dl160a.osn.cxo.cpqcorp.net. IN A >> >> ;; AUTHORITY SECTION: >> osn.cxo.cpqcorp.net. 3600 IN SOA linux.osn.cxo.cpqcorp.net. hostmaster.osn.cxo.cpqcorp.net. 1412344406 3600 900 1209600 3600 >> >> ;; Query time: 1 msec >> ;; SERVER: 16.112.240.59#53(16.112.240.59) ;; WHEN: Fri Oct 03 >> 11:08:35 EDT 2014 ;; MSG SIZE rcvd: 108 >> >> >> [root at linux named]# ipactl stop >> Stopping Directory Service >> Stopping ipa-otpd Service >> Stopping pki-tomcatd Service >> Stopping httpd Service >> Stopping ipa_memcached Service >> Stopping named Service >> Stopping kadmin Service >> Stopping krb5kdc Service >> ipa: INFO: The ipactl command was successful >> >> [root at linux named]# systemctl start named [root at linux named]# >> [root at linux named]# [root at linux named]# dig dl160a.osn.cxo.cpqcorp.net >> >> ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> dl160a.osn.cxo.cpqcorp.net >> ;; global options: +cmd ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28446 ;; flags: qr >> rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;dl160a.osn.cxo.cpqcorp.net. IN A >> >> ;; ANSWER SECTION: >> dl160a.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.191 >> >> ;; AUTHORITY SECTION: >> osn.cxo.cpqcorp.net. 43200 IN NS cluster.osn.cxo.cpqcorp.net. >> osn.cxo.cpqcorp.net. 43200 IN NS win2008.osn.cxo.cpqcorp.net. >> osn.cxo.cpqcorp.net. 43200 IN NS denali.osn.cxo.cpqcorp.net. >> >> ;; ADDITIONAL SECTION: >> win2008.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.55 >> cluster.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.27 >> denali.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.40 >> >> ;; Query time: 4 msec >> ;; SERVER: 16.112.240.59#53(16.112.240.59) ;; WHEN: Fri Oct 03 >> 11:10:54 EDT 2014 ;; MSG SIZE rcvd: 184 >> >> >> Thank you. >> >> -- >> Petr^2 Spacek >> >> -- >> 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 >> > I am not a specialist but can it be that when you run just named it uses files and when you start IPA it uses LDAP database and the issue that the forwarders are correctly recorded in files (manually?) but not in the LDAP database? > > -- > 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. From edewata at redhat.com Fri Oct 3 18:13:05 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 03 Oct 2014 13:13:05 -0500 Subject: [Freeipa-users] Problems and questions installing Identity Manager on RHEL V7 In-Reply-To: <20141003073009.GA4683@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1C0E@G6W2496.americas.hpqcorp.net> <20141001174622.GB6186@redhat.com> <542E0C33.60300@redhat.com> <20141003073009.GA4683@redhat.com> Message-ID: <542EE731.8060605@redhat.com> On 10/3/2014 2:30 AM, Alexander Bokovoy wrote: >>> This issue is known -- when CA install fails, we rollback but since CA >>> isn't installed, we miss rolling it back. There is a ticket for >>> eventually fixing this issue. >> >> Which ticket is this? The rollback was actually disabled to allow >> troubleshooting the failed installation: >> https://fedorahosted.org/freeipa/ticket/3990 > I think this ticket is unrelated -- its solution only affects > ipa-client-install --on-master, not what ipa-server-install does when it > rolls back configuration for dirsrv and other servers. I think the idea can be expanded to the entire server installation. > I can't find the exact ticket though. > >>> Following sequence should clean up all the bits: >>> >>> pkidestroy -s CA -i pki-tomcat >>> rm -rf /var/log/pki/pki-tomcat >>> rm -rf /etc/sysconfig/pki-tomcat >>> rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat >>> rm -rf /var/lib/pki/pki-tomcat >>> rm -rf /etc/pki/pki-tomcat >> >> It's not official, but we call this step pki-nuke. >> >>> It also helps to reboot between multiple reinstalls on a single machine. >> >> Rather than rolling back the installation automatically (and delete >> all files needed to troubleshoot the problem), it would be better to >> provide an option to the uninstall command to forcibly remove all >> installed files regardless whether the installation was successful or >> not, just like the pki-nuke above. > We simply have no information about the fact what pkicreate did before > it failed. It shouldn't matter. The forced removal should clean up anything that might have been created during the installation. That way the next installation should be able to run without any possibility of conflicts with residual files. I created this Dogtag ticket: https://fedorahosted.org/pki/ticket/1172 When that's implemented, the IPA uninstall script can do this: try: # forcibly remove Dogtag instance pkidestroy -i pki-tomcat except Exception: # ignore error pass try: # forcibly remove DS instance remove-ds.pl -f -i slapd-pki-tomcat except Exception: # ignore error pass ... and so on ... If we use an automatic rollback, in addition to the lost debugging info, sometimes the rollback itself can be buggy so the machine is left in an inconsistent/unusable state. With a separate forced removal like above, we can debug the failed installation, and also debug the failed removal if necessary. -- Endi S. Dewata From licause at hp.com Fri Oct 3 19:43:26 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Fri, 3 Oct 2014 19:43:26 +0000 Subject: [Freeipa-users] FW: FW: named and IpA References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <542E5DAF.2090706@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2057@G6W2496.americas.hpqcorp.net> <542ED9E1.1050401@redhat.com> Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C220E@G6W2496.americas.hpqcorp.net> -----Original Message----- From: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) Sent: Friday, October 03, 2014 10:30 AM To: 'freeipa-users at redhat.com' Subject: FW: [Freeipa-users] FW: named and IpA I am not a specialist but can it be that when you run just named it uses files and when you start IPA it uses LDAP database and the issue that the forwarders are correctly recorded in files (manually?) but not in the LDAP database? >> This certainly makes sense.....but then having entered the forwarders using ipa dnsconfig-mod --forwarders=...... >> didn't seem to make a difference. I assume the ipa dnsconfig-mod command places those forwarders >> in the ldap database ? >> But having done so, does anything have to be restarted to get this to work or is the effect immediate ? >>> Actually I just tried ipactl restart which should restart all components including named and I am still unable >>> to resolve any hostnames or ip addresses off this system other than something from the root servers.....so >>> I supposed it could be a named configuration issue....but then why does that issue resolve itself when >>> the IdM components are removed from the picture ? Al -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Friday, October 03, 2014 10:16 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] FW: named and IpA On 10/03/2014 11:13 AM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek > Sent: Friday, October 03, 2014 1:26 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] named and IpA > > On 2.10.2014 19:05, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: >> We have IdM running on a RHEL V7 system and have configured a local >> DNS server in our test lab. >> >> We have loaded the various SRV and TXT records needed by the IdM server. >> >> >> PROBLEM: >> >> >From the IdM server we can only lookup local records. The name >>> resolver will not >> attempt to look to another other name servers or domains defined in >> /etc/resolv.conf >> >> If I shutdown IdM using ipactl stop and then restart named, the name >> resolver works for local and remote hosts, addresses and domains as >> well as serving up the SRV records defined on the local host. >> >> Am I correct in assuming that while IdM is up and running, the only >> other systems it will communicate with at least with regard to name >> services is another host also running IdM defined either as a server or a client ? >> >> If this is case, is there anyone to better integrate some of these >> common services such as named into an existing network such that you are not limited by the IdM components ? > I would like to get additional information about your environment: > - Is the IPA server is installed with DNS or not? Did you use option --setup-dns during ipa-server-install? > >>> I have tried it both ways, but the most current in which we see this behavior I ran ipa-server-install with >>> no arguments and said yes to the question about installing DNS. I then replied with two valid forwarders. >>> In a previous installation, we added two of our local zones from one of the other dns server >>> and then added the sample zone provided by the installation which contained the various SRV and TXT >>> records. But for current reporting of this problem, we did not add/load the other zone files. > - Which DNS zones do you have defined on IPA server? You can use command "ipa dnszone-find" to list all zones. > > [root at linux named]# ipa dnsconfig-mod > --forwarder=16.112.240.27;16.112.240.40 > ipa: ERROR: no modifications to be performed > bash: 16.112.240.40: command not found... > [root at linux named]# ipa dnszone-find > Zone name: 240.112.16.in-addr.arpa. > Authoritative nameserver: linux.osn.cxo.cpqcorp.net. > Administrator e-mail address: hostmaster.osn.cxo.cpqcorp.net. > SOA serial: 1412344406 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > Active zone: TRUE > Allow query: any; > Allow transfer: none; > > Zone name: osn.cxo.cpqcorp.net > Authoritative nameserver: linux.osn.cxo.cpqcorp.net. > Administrator e-mail address: hostmaster.osn.cxo.cpqcorp.net. > SOA serial: 1412344406 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > Active zone: TRUE > Allow query: any; > Allow transfer: none; > ---------------------------- > Number of entries returned 2 > ---------------------------- > > - Is there any other DNS servers serving same DNS zones? > >>> Yes....we left the other two existing DNS servers in place as they are our primary name servers for this lab segment. >>> Those are the two systems we have entered as forwarders. > - Did you configure forwarders in /etc/named.conf or via ipa command line tools (ipa dnsconfig-mod or --forwarder option during ipa-server-install)? > >>> The forwarders were placed in the /etc/named.conf file by the ipa-server-install script or one of its subordinate scripts >>> I did try entering the forward policy and forwarders using ipa dnsconfig-mod but they didn't seem to change the behavior. >>> One thing I did notice was that ipa dnsconfig-mod --forwarder= only allowed one forwarder to be entered.....adding >>> a second entry on the line resulted in an error. If entered with a second --forwarders command, the previous forwarder >>> was replaced by the new one. So if there is a particular syntax that would allow more than one entry, can you please >>> post same ? > - Please attach result of DNS lookups using "dig" command: One output when it doesn't work (i.e. with IPA running) and the other when it works as you expect (i.e. after "ipactl stop" and "service named restart"). > >>> with ipa running: > [root at linux named]# nslookup dl160a.osn.cxo.cpqcorp.net > Server: 16.112.240.59 > Address: 16.112.240.59#53 > > ** server can't find dl160a.osn.cxo.cpqcorp.net: NXDOMAIN > > [root at linux named]# dig dl160a.osn.cxo.cpqcorp.net > > ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> dl160a.osn.cxo.cpqcorp.net > ;; global options: +cmd ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6571 ;; flags: qr > aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;dl160a.osn.cxo.cpqcorp.net. IN A > > ;; AUTHORITY SECTION: > osn.cxo.cpqcorp.net. 3600 IN SOA linux.osn.cxo.cpqcorp.net. hostmaster.osn.cxo.cpqcorp.net. 1412344406 3600 900 1209600 3600 > > ;; Query time: 1 msec > ;; SERVER: 16.112.240.59#53(16.112.240.59) ;; WHEN: Fri Oct 03 > 11:08:35 EDT 2014 ;; MSG SIZE rcvd: 108 > > > [root at linux named]# ipactl stop > Stopping Directory Service > Stopping ipa-otpd Service > Stopping pki-tomcatd Service > Stopping httpd Service > Stopping ipa_memcached Service > Stopping named Service > Stopping kadmin Service > Stopping krb5kdc Service > ipa: INFO: The ipactl command was successful > > [root at linux named]# systemctl start named [root at linux named]# > [root at linux named]# [root at linux named]# dig dl160a.osn.cxo.cpqcorp.net > > ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> dl160a.osn.cxo.cpqcorp.net > ;; global options: +cmd ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28446 ;; flags: qr > rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;dl160a.osn.cxo.cpqcorp.net. IN A > > ;; ANSWER SECTION: > dl160a.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.191 > > ;; AUTHORITY SECTION: > osn.cxo.cpqcorp.net. 43200 IN NS cluster.osn.cxo.cpqcorp.net. > osn.cxo.cpqcorp.net. 43200 IN NS win2008.osn.cxo.cpqcorp.net. > osn.cxo.cpqcorp.net. 43200 IN NS denali.osn.cxo.cpqcorp.net. > > ;; ADDITIONAL SECTION: > win2008.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.55 > cluster.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.27 > denali.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.40 > > ;; Query time: 4 msec > ;; SERVER: 16.112.240.59#53(16.112.240.59) ;; WHEN: Fri Oct 03 > 11:10:54 EDT 2014 ;; MSG SIZE rcvd: 184 > > > Thank you. > > -- > Petr^2 Spacek > > -- > 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 > I am not a specialist but can it be that when you run just named it uses files and when you start IPA it uses LDAP database and the issue that the forwarders are correctly recorded in files (manually?) but not in the LDAP database? -- 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 From dpal at redhat.com Fri Oct 3 21:00:32 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 03 Oct 2014 17:00:32 -0400 Subject: [Freeipa-users] FW: FW: named and IpA In-Reply-To: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C220E@G6W2496.americas.hpqcorp.net> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <542E5DAF.2090706@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2057@G6W2496.americas.hpqcorp.net> <542ED9E1.1050401@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C220E@G6W2496.americas.hpqcorp.net> Message-ID: <542F0E70.1030304@redhat.com> On 10/03/2014 03:43 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > > -----Original Message----- > From: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) > Sent: Friday, October 03, 2014 10:30 AM > To: 'freeipa-users at redhat.com' > Subject: FW: [Freeipa-users] FW: named and IpA > > I am not a specialist but can it be that when you run just named it uses files and when you start IPA it uses LDAP database and the issue that the forwarders are correctly recorded in files (manually?) but not in the LDAP database? > >>> This certainly makes sense.....but then having entered the forwarders using ipa dnsconfig-mod --forwarders=...... >>> didn't seem to make a difference. I assume the ipa dnsconfig-mod command places those forwarders >>> in the ldap database ? >>> But having done so, does anything have to be restarted to get this to work or is the effect immediate ? >>>> Actually I just tried ipactl restart which should restart all components including named and I am still unable >>>> to resolve any hostnames or ip addresses off this system other than something from the root servers.....so >>>> I supposed it could be a named configuration issue....but then why does that issue resolve itself when >>>> the IdM components are removed from the picture ? is there one named.conf? May be there some env variable that redirects it or there is symlink and in one case it uses one and in another case another. I am just speculating. I do not know for sure. Something is strange and may be differen in this setup. Have you tried a different machine or VM and a clean install there? > Al > > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal > Sent: Friday, October 03, 2014 10:16 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FW: named and IpA > > On 10/03/2014 11:13 AM, Licause, Al (CSC AMS BCS - UNIX/Linux Network > Support) wrote: >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek >> Sent: Friday, October 03, 2014 1:26 AM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] named and IpA >> >> On 2.10.2014 19:05, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: >>> We have IdM running on a RHEL V7 system and have configured a local >>> DNS server in our test lab. >>> >>> We have loaded the various SRV and TXT records needed by the IdM server. >>> >>> >>> PROBLEM: >>> >>> >From the IdM server we can only lookup local records. The name >>>> resolver will not >>> attempt to look to another other name servers or domains defined in >>> /etc/resolv.conf >>> >>> If I shutdown IdM using ipactl stop and then restart named, the name >>> resolver works for local and remote hosts, addresses and domains as >>> well as serving up the SRV records defined on the local host. >>> >>> Am I correct in assuming that while IdM is up and running, the only >>> other systems it will communicate with at least with regard to name >>> services is another host also running IdM defined either as a server or a client ? >>> >>> If this is case, is there anyone to better integrate some of these >>> common services such as named into an existing network such that you are not limited by the IdM components ? >> I would like to get additional information about your environment: >> - Is the IPA server is installed with DNS or not? Did you use option --setup-dns during ipa-server-install? >> >>>> I have tried it both ways, but the most current in which we see this behavior I ran ipa-server-install with >>>> no arguments and said yes to the question about installing DNS. I then replied with two valid forwarders. >>>> In a previous installation, we added two of our local zones from one of the other dns server >>>> and then added the sample zone provided by the installation which contained the various SRV and TXT >>>> records. But for current reporting of this problem, we did not add/load the other zone files. >> - Which DNS zones do you have defined on IPA server? You can use command "ipa dnszone-find" to list all zones. >> >> [root at linux named]# ipa dnsconfig-mod >> --forwarder=16.112.240.27;16.112.240.40 >> ipa: ERROR: no modifications to be performed >> bash: 16.112.240.40: command not found... >> [root at linux named]# ipa dnszone-find >> Zone name: 240.112.16.in-addr.arpa. >> Authoritative nameserver: linux.osn.cxo.cpqcorp.net. >> Administrator e-mail address: hostmaster.osn.cxo.cpqcorp.net. >> SOA serial: 1412344406 >> SOA refresh: 3600 >> SOA retry: 900 >> SOA expire: 1209600 >> SOA minimum: 3600 >> Active zone: TRUE >> Allow query: any; >> Allow transfer: none; >> >> Zone name: osn.cxo.cpqcorp.net >> Authoritative nameserver: linux.osn.cxo.cpqcorp.net. >> Administrator e-mail address: hostmaster.osn.cxo.cpqcorp.net. >> SOA serial: 1412344406 >> SOA refresh: 3600 >> SOA retry: 900 >> SOA expire: 1209600 >> SOA minimum: 3600 >> Active zone: TRUE >> Allow query: any; >> Allow transfer: none; >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- >> >> - Is there any other DNS servers serving same DNS zones? >> >>>> Yes....we left the other two existing DNS servers in place as they are our primary name servers for this lab segment. >>>> Those are the two systems we have entered as forwarders. >> - Did you configure forwarders in /etc/named.conf or via ipa command line tools (ipa dnsconfig-mod or --forwarder option during ipa-server-install)? >> >>>> The forwarders were placed in the /etc/named.conf file by the ipa-server-install script or one of its subordinate scripts >>>> I did try entering the forward policy and forwarders using ipa dnsconfig-mod but they didn't seem to change the behavior. >>>> One thing I did notice was that ipa dnsconfig-mod --forwarder= only allowed one forwarder to be entered.....adding >>>> a second entry on the line resulted in an error. If entered with a second --forwarders command, the previous forwarder >>>> was replaced by the new one. So if there is a particular syntax that would allow more than one entry, can you please >>>> post same ? >> - Please attach result of DNS lookups using "dig" command: One output when it doesn't work (i.e. with IPA running) and the other when it works as you expect (i.e. after "ipactl stop" and "service named restart"). >> >>>> with ipa running: >> [root at linux named]# nslookup dl160a.osn.cxo.cpqcorp.net >> Server: 16.112.240.59 >> Address: 16.112.240.59#53 >> >> ** server can't find dl160a.osn.cxo.cpqcorp.net: NXDOMAIN >> >> [root at linux named]# dig dl160a.osn.cxo.cpqcorp.net >> >> ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> dl160a.osn.cxo.cpqcorp.net >> ;; global options: +cmd ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6571 ;; flags: qr >> aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;dl160a.osn.cxo.cpqcorp.net. IN A >> >> ;; AUTHORITY SECTION: >> osn.cxo.cpqcorp.net. 3600 IN SOA linux.osn.cxo.cpqcorp.net. hostmaster.osn.cxo.cpqcorp.net. 1412344406 3600 900 1209600 3600 >> >> ;; Query time: 1 msec >> ;; SERVER: 16.112.240.59#53(16.112.240.59) ;; WHEN: Fri Oct 03 >> 11:08:35 EDT 2014 ;; MSG SIZE rcvd: 108 >> >> >> [root at linux named]# ipactl stop >> Stopping Directory Service >> Stopping ipa-otpd Service >> Stopping pki-tomcatd Service >> Stopping httpd Service >> Stopping ipa_memcached Service >> Stopping named Service >> Stopping kadmin Service >> Stopping krb5kdc Service >> ipa: INFO: The ipactl command was successful >> >> [root at linux named]# systemctl start named [root at linux named]# >> [root at linux named]# [root at linux named]# dig dl160a.osn.cxo.cpqcorp.net >> >> ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> dl160a.osn.cxo.cpqcorp.net >> ;; global options: +cmd ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28446 ;; flags: qr >> rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;dl160a.osn.cxo.cpqcorp.net. IN A >> >> ;; ANSWER SECTION: >> dl160a.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.191 >> >> ;; AUTHORITY SECTION: >> osn.cxo.cpqcorp.net. 43200 IN NS cluster.osn.cxo.cpqcorp.net. >> osn.cxo.cpqcorp.net. 43200 IN NS win2008.osn.cxo.cpqcorp.net. >> osn.cxo.cpqcorp.net. 43200 IN NS denali.osn.cxo.cpqcorp.net. >> >> ;; ADDITIONAL SECTION: >> win2008.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.55 >> cluster.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.27 >> denali.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.40 >> >> ;; Query time: 4 msec >> ;; SERVER: 16.112.240.59#53(16.112.240.59) ;; WHEN: Fri Oct 03 >> 11:10:54 EDT 2014 ;; MSG SIZE rcvd: 184 >> >> >> Thank you. >> >> -- >> Petr^2 Spacek >> >> -- >> 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 >> > I am not a specialist but can it be that when you run just named it uses files and when you start IPA it uses LDAP database and the issue that the forwarders are correctly recorded in files (manually?) but not in the LDAP database? > > -- > 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. From licause at hp.com Fri Oct 3 21:09:20 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Fri, 3 Oct 2014 21:09:20 +0000 Subject: [Freeipa-users] FW: FW: FW: named and IpA In-Reply-To: <542F0E70.1030304@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <542E5DAF.2090706@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2057@G6W2496.americas.hpqcorp.net> <542ED9E1.1050401@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C220E@G6W2496.americas.hpqcorp.net> <542F0E70.1030304@redhat.com> Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C22EB@G6W2496.americas.hpqcorp.net> -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Friday, October 03, 2014 2:01 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] FW: FW: named and IpA On 10/03/2014 03:43 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > > -----Original Message----- > From: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) > Sent: Friday, October 03, 2014 10:30 AM > To: 'freeipa-users at redhat.com' > Subject: FW: [Freeipa-users] FW: named and IpA > > I am not a specialist but can it be that when you run just named it uses files and when you start IPA it uses LDAP database and the issue that the forwarders are correctly recorded in files (manually?) but not in the LDAP database? > >>> This certainly makes sense.....but then having entered the forwarders using ipa dnsconfig-mod --forwarders=...... >>> didn't seem to make a difference. I assume the ipa dnsconfig-mod command places those forwarders >>> in the ldap database ? >>> But having done so, does anything have to be restarted to get this to work or is the effect immediate ? >>>> Actually I just tried ipactl restart which should restart all components including named and I am still unable >>>> to resolve any hostnames or ip addresses off this system other than something from the root servers.....so >>>> I supposed it could be a named configuration issue....but then why does that issue resolve itself when >>>> the IdM components are removed from the picture ? is there one named.conf? >>> yes...from all I can tell: >>> [root at linux named]# ls -l /etc/named.conf >>> -rw-r----- 1 root named 1317 Oct 3 09:07 /etc/named.conf May be there some env variable that redirects it or there is symlink and in one case it uses one and in another case another. I am just speculating. I do not know for sure. >>> did a printenv and found nothing related to named. Something is strange and may be differen in this setup. >>> I would agree.....but I wish I could figure out what it is. Have you tried a different machine or VM and a clean install there? >>> Unfortunately we have a limited number of test systems and this is our only RHEL V7 system at the moment. >>> Should another one become available, I'll try to install the IdM sets on that and see if we get the same results. Al > Al > > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal > Sent: Friday, October 03, 2014 10:16 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FW: named and IpA > > On 10/03/2014 11:13 AM, Licause, Al (CSC AMS BCS - UNIX/Linux Network > Support) wrote: >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek >> Sent: Friday, October 03, 2014 1:26 AM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] named and IpA >> >> On 2.10.2014 19:05, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: >>> We have IdM running on a RHEL V7 system and have configured a local >>> DNS server in our test lab. >>> >>> We have loaded the various SRV and TXT records needed by the IdM server. >>> >>> >>> PROBLEM: >>> >>> >From the IdM server we can only lookup local records. The name >>>> resolver will not >>> attempt to look to another other name servers or domains defined in >>> /etc/resolv.conf >>> >>> If I shutdown IdM using ipactl stop and then restart named, the name >>> resolver works for local and remote hosts, addresses and domains as >>> well as serving up the SRV records defined on the local host. >>> >>> Am I correct in assuming that while IdM is up and running, the only >>> other systems it will communicate with at least with regard to name >>> services is another host also running IdM defined either as a server or a client ? >>> >>> If this is case, is there anyone to better integrate some of these >>> common services such as named into an existing network such that you are not limited by the IdM components ? >> I would like to get additional information about your environment: >> - Is the IPA server is installed with DNS or not? Did you use option --setup-dns during ipa-server-install? >> >>>> I have tried it both ways, but the most current in which we see this behavior I ran ipa-server-install with >>>> no arguments and said yes to the question about installing DNS. I then replied with two valid forwarders. >>>> In a previous installation, we added two of our local zones from one of the other dns server >>>> and then added the sample zone provided by the installation which contained the various SRV and TXT >>>> records. But for current reporting of this problem, we did not add/load the other zone files. >> - Which DNS zones do you have defined on IPA server? You can use command "ipa dnszone-find" to list all zones. >> >> [root at linux named]# ipa dnsconfig-mod >> --forwarder=16.112.240.27;16.112.240.40 >> ipa: ERROR: no modifications to be performed >> bash: 16.112.240.40: command not found... >> [root at linux named]# ipa dnszone-find >> Zone name: 240.112.16.in-addr.arpa. >> Authoritative nameserver: linux.osn.cxo.cpqcorp.net. >> Administrator e-mail address: hostmaster.osn.cxo.cpqcorp.net. >> SOA serial: 1412344406 >> SOA refresh: 3600 >> SOA retry: 900 >> SOA expire: 1209600 >> SOA minimum: 3600 >> Active zone: TRUE >> Allow query: any; >> Allow transfer: none; >> >> Zone name: osn.cxo.cpqcorp.net >> Authoritative nameserver: linux.osn.cxo.cpqcorp.net. >> Administrator e-mail address: hostmaster.osn.cxo.cpqcorp.net. >> SOA serial: 1412344406 >> SOA refresh: 3600 >> SOA retry: 900 >> SOA expire: 1209600 >> SOA minimum: 3600 >> Active zone: TRUE >> Allow query: any; >> Allow transfer: none; >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- >> >> - Is there any other DNS servers serving same DNS zones? >> >>>> Yes....we left the other two existing DNS servers in place as they are our primary name servers for this lab segment. >>>> Those are the two systems we have entered as forwarders. >> - Did you configure forwarders in /etc/named.conf or via ipa command line tools (ipa dnsconfig-mod or --forwarder option during ipa-server-install)? >> >>>> The forwarders were placed in the /etc/named.conf file by the ipa-server-install script or one of its subordinate scripts >>>> I did try entering the forward policy and forwarders using ipa dnsconfig-mod but they didn't seem to change the behavior. >>>> One thing I did notice was that ipa dnsconfig-mod --forwarder= only allowed one forwarder to be entered.....adding >>>> a second entry on the line resulted in an error. If entered with a second --forwarders command, the previous forwarder >>>> was replaced by the new one. So if there is a particular syntax that would allow more than one entry, can you please >>>> post same ? >> - Please attach result of DNS lookups using "dig" command: One output when it doesn't work (i.e. with IPA running) and the other when it works as you expect (i.e. after "ipactl stop" and "service named restart"). >> >>>> with ipa running: >> [root at linux named]# nslookup dl160a.osn.cxo.cpqcorp.net >> Server: 16.112.240.59 >> Address: 16.112.240.59#53 >> >> ** server can't find dl160a.osn.cxo.cpqcorp.net: NXDOMAIN >> >> [root at linux named]# dig dl160a.osn.cxo.cpqcorp.net >> >> ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> dl160a.osn.cxo.cpqcorp.net >> ;; global options: +cmd ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6571 ;; flags: >> qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: >> ;dl160a.osn.cxo.cpqcorp.net. IN A >> >> ;; AUTHORITY SECTION: >> osn.cxo.cpqcorp.net. 3600 IN SOA linux.osn.cxo.cpqcorp.net. hostmaster.osn.cxo.cpqcorp.net. 1412344406 3600 900 1209600 3600 >> >> ;; Query time: 1 msec >> ;; SERVER: 16.112.240.59#53(16.112.240.59) ;; WHEN: Fri Oct 03 >> 11:08:35 EDT 2014 ;; MSG SIZE rcvd: 108 >> >> >> [root at linux named]# ipactl stop >> Stopping Directory Service >> Stopping ipa-otpd Service >> Stopping pki-tomcatd Service >> Stopping httpd Service >> Stopping ipa_memcached Service >> Stopping named Service >> Stopping kadmin Service >> Stopping krb5kdc Service >> ipa: INFO: The ipactl command was successful >> >> [root at linux named]# systemctl start named [root at linux named]# >> [root at linux named]# [root at linux named]# dig >> dl160a.osn.cxo.cpqcorp.net >> >> ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> dl160a.osn.cxo.cpqcorp.net >> ;; global options: +cmd ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28446 ;; flags: >> qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: >> ;dl160a.osn.cxo.cpqcorp.net. IN A >> >> ;; ANSWER SECTION: >> dl160a.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.191 >> >> ;; AUTHORITY SECTION: >> osn.cxo.cpqcorp.net. 43200 IN NS cluster.osn.cxo.cpqcorp.net. >> osn.cxo.cpqcorp.net. 43200 IN NS win2008.osn.cxo.cpqcorp.net. >> osn.cxo.cpqcorp.net. 43200 IN NS denali.osn.cxo.cpqcorp.net. >> >> ;; ADDITIONAL SECTION: >> win2008.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.55 >> cluster.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.27 >> denali.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.40 >> >> ;; Query time: 4 msec >> ;; SERVER: 16.112.240.59#53(16.112.240.59) ;; WHEN: Fri Oct 03 >> 11:10:54 EDT 2014 ;; MSG SIZE rcvd: 184 >> >> >> Thank you. >> >> -- >> Petr^2 Spacek >> >> -- >> 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 >> > I am not a specialist but can it be that when you run just named it uses files and when you start IPA it uses LDAP database and the issue that the forwarders are correctly recorded in files (manually?) but not in the LDAP database? > > -- > 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 From mail at willsheldon.com Sat Oct 4 17:16:14 2014 From: mail at willsheldon.com (Will Sheldon) Date: Sat, 4 Oct 2014 10:16:14 -0700 Subject: [Freeipa-users] DNS: Possible to set a CNAME for bare domain? Message-ID: Hello everyone : ) Is it possible to configure a CNAME for a bare domain with freeIPA?? We would like to move our site over to an Amazon ELB, but to do so we have to point our domain (foo.com, not www.foo.com) at an was A record with a CNAME (something like xxxxxxxxxxxx.eu-west-1.elb.amazonaws.com)? This is technically possible, but IPA complains:? "invalid 'cnamerecord': CNAME record is not allowed to coexist with any other records except PTR" I?m guessing this is because of the @ NS record. Is there any way to override this behaviour? Can I make manual modifications to the zone file? ? Will Sheldon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlasevich at gmail.com Sat Oct 4 17:20:43 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Sat, 4 Oct 2014 10:20:43 -0700 Subject: [Freeipa-users] DNS: Possible to set a CNAME for bare domain? In-Reply-To: References: Message-ID: You cannot have cname for a bare domain in IPA or in any DNS service, it violates DNS rfc's. On Oct 4, 2014 10:19 AM, "Will Sheldon" wrote: > > Hello everyone : ) > > > Is it possible to configure a CNAME for a bare domain with freeIPA? > > We would like to move our site over to an Amazon ELB, but to do so we have > to point our domain (foo.com, not www.foo.com) at an was A record with a > CNAME (something like xxxxxxxxxxxx.eu-west-1.elb.amazonaws.com) > > This is technically possible, but IPA complains: > > "invalid 'cnamerecord': CNAME record is not allowed to coexist with any > other records except PTR" > > I?m guessing this is because of the @ NS record. > > > Is there any way to override this behaviour? Can I make manual > modifications to the zone file? > > > > > Will Sheldon > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at willsheldon.com Sat Oct 4 17:28:29 2014 From: mail at willsheldon.com (Will Sheldon) Date: Sat, 4 Oct 2014 10:28:29 -0700 Subject: [Freeipa-users] DNS: Possible to set a CNAME for bare domain? In-Reply-To: References: Message-ID: Thanks Michael, it seems you are correct. I knew I?d seen it done though - turns out that if you use route53 for your DNS amazon has a way of making it work with a virtual record type called an alias. I guess we?ll just have to use route53. At least alias lookups are free. On October 4, 2014 at 10:20:43 AM, Michael Lasevich (mlasevich at gmail.com) wrote: You cannot have cname for a bare domain in IPA or in any DNS service, it violates DNS rfc's. On Oct 4, 2014 10:19 AM, "Will Sheldon" wrote: Hello everyone : ) Is it possible to configure a CNAME for a bare domain with freeIPA?? We would like to move our site over to an Amazon ELB, but to do so we have to point our domain (foo.com, not www.foo.com) at an was A record with a CNAME (something like xxxxxxxxxxxx.eu-west-1.elb.amazonaws.com)? This is technically possible, but IPA complains:? "invalid 'cnamerecord': CNAME record is not allowed to coexist with any other records except PTR" I?m guessing this is because of the @ NS record. Is there any way to override this behaviour? Can I make manual modifications to the zone file? ? Will Sheldon -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mvmagbero at gmail.com Thu Oct 2 14:54:30 2014 From: mvmagbero at gmail.com (Mark Vincent Magbero) Date: Thu, 2 Oct 2014 22:54:30 +0800 Subject: [Freeipa-users] running freeipa inside container Message-ID: Host OS: Centos 6.5 x86_64 Guest OS: Centos 6.5 x86_64 SELinux status: permissive libvirt-0.10.2-29.el6_5.12.x86_64 2014-10-02T13:55:20Z DEBUG calling setup-ds.pl 2014-10-02T14:06:00Z DEBUG args=/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmpY_By3t 2014-10-02T14:06:00Z DEBUG stdout=Server failed to start !!! Please check errors log for problems [14/10/02:10:06:00] - [Setup] Info Could not start the directory server using command '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line from the error log was '[02/Oct/2014:09:56:01 -0400] - Failed to create semaphore for stats file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied) '. Error: Unknown error 256 Could not start the directory server using command '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line from the error log was '[02/Oct/2014:09:56:01 -0400] - Failed to create semaphore for stats file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied) '. Error: Unknown error 256 [14/10/02:10:06:00] - [Setup] Fatal Error: Could not create directory server instance 'PKI-IPA'. Error: Could not create directory server instance 'PKI-IPA'. [14/10/02:10:06:00] - [Setup] Fatal Exiting . . . I have a rather lengthy logfile, but i'd rather not post it all as of the moment if it's simply not possible to run freeipa inside an LXC container. Has anybody successfully installed and run freeipa inside a container? -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Sat Oct 4 19:43:36 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 4 Oct 2014 22:43:36 +0300 Subject: [Freeipa-users] running freeipa inside container In-Reply-To: References: Message-ID: <20141004194336.GK4683@redhat.com> On Thu, 02 Oct 2014, Mark Vincent Magbero wrote: >Host OS: Centos 6.5 x86_64 >Guest OS: Centos 6.5 x86_64 >SELinux status: permissive >libvirt-0.10.2-29.el6_5.12.x86_64 > >2014-10-02T13:55:20Z DEBUG calling setup-ds.pl >2014-10-02T14:06:00Z DEBUG args=/usr/sbin/setup-ds.pl --silent --logfile - >-f /tmp/tmpY_By3t >2014-10-02T14:06:00Z DEBUG stdout=Server failed to start !!! Please check >errors log for problems >[14/10/02:10:06:00] - [Setup] Info Could not start the directory server >using command '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line >from the error log was '[02/Oct/2014:09:56:01 -0400] - Failed to create >semaphore for stats file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error >13.(Permission denied) >'. Error: Unknown error 256 >Could not start the directory server using command >'/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line from the >error log was '[02/Oct/2014:09:56:01 -0400] - Failed to create semaphore >for stats file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission >denied) >'. Error: Unknown error 256 >[14/10/02:10:06:00] - [Setup] Fatal Error: Could not create directory >server instance 'PKI-IPA'. >Error: Could not create directory server instance 'PKI-IPA'. >[14/10/02:10:06:00] - [Setup] Fatal Exiting . . . > > >I have a rather lengthy logfile, but i'd rather not post it all as of the >moment if it's simply not possible to run freeipa inside an LXC container. >Has anybody successfully installed and run freeipa inside a container? LXC containers are not supported. So far we have proof of concept of FreeIPA running in Docker: http://www.freeipa.org/page/Docker There are too many moving parts to get it all working in a general case. Your help is welcome. -- / Alexander Bokovoy From pspacek at redhat.com Mon Oct 6 06:59:12 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 06 Oct 2014 08:59:12 +0200 Subject: [Freeipa-users] DNS: Possible to set a CNAME for bare domain? In-Reply-To: References: Message-ID: <54323DC0.4020904@redhat.com> Hello, I will add few more details: "ALIAS" virtual record and its derivatives are not standardized yet and AFAIK there is no implementation which works with DNSSEC. IPA uses BIND 9.9 as DNS backend and BINDitself doesn't support any variant of ALIAS record at the moment. As a result, IPA doesn't have any means to provide this feature. If you are interested in details please see dnsop mailing list archives [1] and look for "ALIAS" keyword in subjects. [1] http://www.ietf.org/mail-archive/web/dnsop/current/maillist.html Petr^2 Spacek On 4.10.2014 19:28, Will Sheldon wrote: > Thanks Michael, it seems you are correct. > > I knew I?d seen it done though - turns out that if you use route53 for your DNS amazon has a way of making it work with a virtual record type called an alias. I guess we?ll just have to use route53. At least alias lookups are free. > > > On October 4, 2014 at 10:20:43 AM, Michael Lasevich (mlasevich at gmail.com) wrote: > > You cannot have cname for a bare domain in IPA or in any DNS service, it violates DNS rfc's. > > On Oct 4, 2014 10:19 AM, "Will Sheldon" wrote: > > Hello everyone : ) > > > Is it possible to configure a CNAME for a bare domain with freeIPA? > > We would like to move our site over to an Amazon ELB, but to do so we have to point our domain (foo.com, not www.foo.com) at an was A record with a CNAME (something like xxxxxxxxxxxx.eu-west-1.elb.amazonaws.com) > > This is technically possible, but IPA complains: > > "invalid 'cnamerecord': CNAME record is not allowed to coexist with any other records except PTR" > > I?m guessing this is because of the @ NS record. > > > Is there any way to override this behaviour? Can I make manual modifications to the zone file? > > > > > Will Sheldon From pspacek at redhat.com Mon Oct 6 07:57:04 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 06 Oct 2014 09:57:04 +0200 Subject: [Freeipa-users] FW: named and IpA In-Reply-To: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2057@G6W2496.americas.hpqcorp.net> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <542E5DAF.2090706@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2057@G6W2496.americas.hpqcorp.net> Message-ID: <54324B50.2050907@redhat.com> Hello, let me summarize the environment so we can be sure that I understood it correctly: - there are (at least) two non-IPA DNS servers 16.112.240.27 and 16.112.240.40 - non-IPA servers are authoritative for DNS zone osn.cxo.cpqcorp.net - IPA server is *also* configured to be authoritative for DNS zone osn.cxo.cpqcorp.net (as shown by ipa dnszone-find command). I hope that this summary is correct, please let me know if it doesn't. This configuration cannot reliably work because there is a clash between sets of authoritative servers. IPA server claim authority over domain osn.cxo.cpqcorp.net (set 1) and at the same time non-IPA servers (set 2) deem themselves to be authoritative for domain osn.cxo.cpqcorp.net. Unfortunately IPA installer is not clever enough to detect this situation and warn you at the right time. We have a ticket for adding this check to new versions of IPA. https://fedorahosted.org/freeipa/ticket/3681 The solution is to decide which set of servers (IPA or non-IPA) should be really authoritative and change configuration appropriately. If you want to use non-IPA servers as authoritative: - Install IPA *without* DNS component - Add required DNS records generated by IPA installed to non-IPA servers. If you want to use IPA server as authoritative: - Install IPA with DNS component - Remove DNS zones from non-IPA servers or change configuration so non-IPA servers are *slaves* of IPA - Change NS records in parent zone (presumably cxo.cpqcorp.net) so they point to IPA. Don't hesitate to ask if you have further questions. Petr^2 Spacek On 3.10.2014 17:13, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek > Sent: Friday, October 03, 2014 1:26 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] named and IpA > > On 2.10.2014 19:05, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: >> We have IdM running on a RHEL V7 system and have configured a local >> DNS server in our test lab. >> >> We have loaded the various SRV and TXT records needed by the IdM server. >> >> >> PROBLEM: >> >> >From the IdM server we can only lookup local records. The name >>> resolver will not >> attempt to look to another other name servers or domains defined in >> /etc/resolv.conf >> >> If I shutdown IdM using ipactl stop and then restart named, the name >> resolver works for local and remote hosts, addresses and domains as >> well as serving up the SRV records defined on the local host. >> >> Am I correct in assuming that while IdM is up and running, the only >> other systems it will communicate with at least with regard to name >> services is another host also running IdM defined either as a server or a client ? >> >> If this is case, is there anyone to better integrate some of these >> common services such as named into an existing network such that you are not limited by the IdM components ? > > I would like to get additional information about your environment: > - Is the IPA server is installed with DNS or not? Did you use option --setup-dns during ipa-server-install? > >>> I have tried it both ways, but the most current in which we see this behavior I ran ipa-server-install with >>> no arguments and said yes to the question about installing DNS. I then replied with two valid forwarders. >>> In a previous installation, we added two of our local zones from one of the other dns server >>> and then added the sample zone provided by the installation which contained the various SRV and TXT >>> records. But for current reporting of this problem, we did not add/load the other zone files. > > - Which DNS zones do you have defined on IPA server? You can use command "ipa dnszone-find" to list all zones. > > [root at linux named]# ipa dnsconfig-mod --forwarder=16.112.240.27;16.112.240.40 > ipa: ERROR: no modifications to be performed > bash: 16.112.240.40: command not found... > [root at linux named]# ipa dnszone-find > Zone name: 240.112.16.in-addr.arpa. > Authoritative nameserver: linux.osn.cxo.cpqcorp.net. > Administrator e-mail address: hostmaster.osn.cxo.cpqcorp.net. > SOA serial: 1412344406 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > Active zone: TRUE > Allow query: any; > Allow transfer: none; > > Zone name: osn.cxo.cpqcorp.net > Authoritative nameserver: linux.osn.cxo.cpqcorp.net. > Administrator e-mail address: hostmaster.osn.cxo.cpqcorp.net. > SOA serial: 1412344406 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > Active zone: TRUE > Allow query: any; > Allow transfer: none; > ---------------------------- > Number of entries returned 2 > ---------------------------- > > - Is there any other DNS servers serving same DNS zones? > >>> Yes....we left the other two existing DNS servers in place as they are our primary name servers for this lab segment. >>> Those are the two systems we have entered as forwarders. > > - Did you configure forwarders in /etc/named.conf or via ipa command line tools (ipa dnsconfig-mod or --forwarder option during ipa-server-install)? > >>> The forwarders were placed in the /etc/named.conf file by the ipa-server-install script or one of its subordinate scripts >>> I did try entering the forward policy and forwarders using ipa dnsconfig-mod but they didn't seem to change the behavior. >>> One thing I did notice was that ipa dnsconfig-mod --forwarder= only allowed one forwarder to be entered.....adding >>> a second entry on the line resulted in an error. If entered with a second --forwarders command, the previous forwarder >>> was replaced by the new one. So if there is a particular syntax that would allow more than one entry, can you please >>> post same ? > > - Please attach result of DNS lookups using "dig" command: One output when it doesn't work (i.e. with IPA running) and the other when it works as you expect (i.e. after "ipactl stop" and "service named restart"). > >>> with ipa running: > > [root at linux named]# nslookup dl160a.osn.cxo.cpqcorp.net > Server: 16.112.240.59 > Address: 16.112.240.59#53 > > ** server can't find dl160a.osn.cxo.cpqcorp.net: NXDOMAIN > > [root at linux named]# dig dl160a.osn.cxo.cpqcorp.net > > ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> dl160a.osn.cxo.cpqcorp.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6571 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;dl160a.osn.cxo.cpqcorp.net. IN A > > ;; AUTHORITY SECTION: > osn.cxo.cpqcorp.net. 3600 IN SOA linux.osn.cxo.cpqcorp.net. hostmaster.osn.cxo.cpqcorp.net. 1412344406 3600 900 1209600 3600 > > ;; Query time: 1 msec > ;; SERVER: 16.112.240.59#53(16.112.240.59) > ;; WHEN: Fri Oct 03 11:08:35 EDT 2014 > ;; MSG SIZE rcvd: 108 > > > [root at linux named]# ipactl stop > Stopping Directory Service > Stopping ipa-otpd Service > Stopping pki-tomcatd Service > Stopping httpd Service > Stopping ipa_memcached Service > Stopping named Service > Stopping kadmin Service > Stopping krb5kdc Service > ipa: INFO: The ipactl command was successful > > [root at linux named]# systemctl start named > [root at linux named]# > [root at linux named]# > [root at linux named]# dig dl160a.osn.cxo.cpqcorp.net > > ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> dl160a.osn.cxo.cpqcorp.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28446 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;dl160a.osn.cxo.cpqcorp.net. IN A > > ;; ANSWER SECTION: > dl160a.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.191 > > ;; AUTHORITY SECTION: > osn.cxo.cpqcorp.net. 43200 IN NS cluster.osn.cxo.cpqcorp.net. > osn.cxo.cpqcorp.net. 43200 IN NS win2008.osn.cxo.cpqcorp.net. > osn.cxo.cpqcorp.net. 43200 IN NS denali.osn.cxo.cpqcorp.net. > > ;; ADDITIONAL SECTION: > win2008.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.55 > cluster.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.27 > denali.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.40 > > ;; Query time: 4 msec > ;; SERVER: 16.112.240.59#53(16.112.240.59) > ;; WHEN: Fri Oct 03 11:10:54 EDT 2014 > ;; MSG SIZE rcvd: 184 -- Petr^2 Spacek From Adam.Bishop at ja.net Mon Oct 6 10:09:51 2014 From: Adam.Bishop at ja.net (Adam Bishop) Date: Mon, 6 Oct 2014 10:09:51 +0000 Subject: [Freeipa-users] Config applied to SSSd Message-ID: <73AD8E27-AA5C-426A-AC1E-B59515A52C93@ja.net> ipa-client-install on RHEL6-ish distro's configures SSSd as follows: [domain/MYDOMAIN] ... ipa_server = _srv_, ldap01.my.domain ... The man page isn't too clear on what is this value used for (or how ipa-client-install derives it in a multi-server deployment), or what would happen if ldap01 went offline. Is anyone able to clarify the how the defaults behave? Regards, Adam Bishop Systems Development Specialist gpg: 0x6609D460 t: +44 (0)1235 822 245 xmpp: adamb at jabber.dev.ja.net Janet, the UK's research and education network. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From jhrozek at redhat.com Mon Oct 6 10:23:21 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 6 Oct 2014 12:23:21 +0200 Subject: [Freeipa-users] Config applied to SSSd In-Reply-To: <73AD8E27-AA5C-426A-AC1E-B59515A52C93@ja.net> References: <73AD8E27-AA5C-426A-AC1E-B59515A52C93@ja.net> Message-ID: <20141006102321.GD13001@hendrix.brq.redhat.com> On Mon, Oct 06, 2014 at 10:09:51AM +0000, Adam Bishop wrote: > ipa-client-install on RHEL6-ish distro's configures SSSd as follows: > > [domain/MYDOMAIN] > > ... > ipa_server = _srv_, ldap01.my.domain > ... > > The man page isn't too clear on what is this value used for (or how ipa-client-install derives it in a multi-server deployment), or what would happen if ldap01 went offline. > > Is anyone able to clarify the how the defaults behave? Hi, See the 'failover' section in the sssd-ipa man pages, does it answer your questions? From abokovoy at redhat.com Mon Oct 6 10:27:38 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 6 Oct 2014 13:27:38 +0300 Subject: [Freeipa-users] Config applied to SSSd In-Reply-To: <73AD8E27-AA5C-426A-AC1E-B59515A52C93@ja.net> References: <73AD8E27-AA5C-426A-AC1E-B59515A52C93@ja.net> Message-ID: <20141006102738.GL4683@redhat.com> On Mon, 06 Oct 2014, Adam Bishop wrote: >ipa-client-install on RHEL6-ish distro's configures SSSd as follows: > > [domain/MYDOMAIN] > > ... > ipa_server = _srv_, ldap01.my.domain > ... > >The man page isn't too clear on what is this value used for (or how >ipa-client-install derives it in a multi-server deployment), or what >would happen if ldap01 went offline. _srv_ means using all servers from the SRV record _ldap._tcp.domain, taking next one is previous one failed. Adding an explicit hostname will extend this list to include the one if DNS resolution of SRV record or any of servers the advertised in the SRV record fails. If all of them will fail, SSSD will go offline and try them again after it considers going online. The hostname put by ipa-client-install corresponds to the server to which this client is enrolled. You enroll with a single server, after all. -- / Alexander Bokovoy From licause at hp.com Mon Oct 6 13:17:23 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Mon, 6 Oct 2014 13:17:23 +0000 Subject: [Freeipa-users] FW: FW: named and IpA In-Reply-To: <54324B50.2050907@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <542E5DAF.2090706@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2057@G6W2496.americas.hpqcorp.net> <54324B50.2050907@redhat.com> Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C243C@G6W2496.americas.hpqcorp.net> Thanks very much for the additional input. The configuration as you describe it is correct with a minor detail correction that I didn't notice earlier. 16.112.240.27 is the master for the osn.cxo.cpqcorp.net zone while 16.112.240.40 is a slave for that zone. But as you have said, both are authoritative for that zone. I won't belabor the point and will move on to try a different configuration as my ultimate goal here is to create trust domains between a linux and an AD domain. To that end I will reconfigure the current IdM server such that it is in a different subnet and domain. I just find it odd that when ipa is shutdown and named is restarted on the system designated as the IdM server, that dns works and the forwarders are not ignored as they are when ipa is running. Al -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek Sent: Monday, October 06, 2014 12:57 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] FW: named and IpA Hello, let me summarize the environment so we can be sure that I understood it correctly: - there are (at least) two non-IPA DNS servers 16.112.240.27 and 16.112.240.40 - non-IPA servers are authoritative for DNS zone osn.cxo.cpqcorp.net - IPA server is *also* configured to be authoritative for DNS zone osn.cxo.cpqcorp.net (as shown by ipa dnszone-find command). I hope that this summary is correct, please let me know if it doesn't. This configuration cannot reliably work because there is a clash between sets of authoritative servers. IPA server claim authority over domain osn.cxo.cpqcorp.net (set 1) and at the same time non-IPA servers (set 2) deem themselves to be authoritative for domain osn.cxo.cpqcorp.net. Unfortunately IPA installer is not clever enough to detect this situation and warn you at the right time. We have a ticket for adding this check to new versions of IPA. https://fedorahosted.org/freeipa/ticket/3681 The solution is to decide which set of servers (IPA or non-IPA) should be really authoritative and change configuration appropriately. If you want to use non-IPA servers as authoritative: - Install IPA *without* DNS component - Add required DNS records generated by IPA installed to non-IPA servers. If you want to use IPA server as authoritative: - Install IPA with DNS component - Remove DNS zones from non-IPA servers or change configuration so non-IPA servers are *slaves* of IPA - Change NS records in parent zone (presumably cxo.cpqcorp.net) so they point to IPA. Don't hesitate to ask if you have further questions. Petr^2 Spacek On 3.10.2014 17:13, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek > Sent: Friday, October 03, 2014 1:26 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] named and IpA > > On 2.10.2014 19:05, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: >> We have IdM running on a RHEL V7 system and have configured a local >> DNS server in our test lab. >> >> We have loaded the various SRV and TXT records needed by the IdM server. >> >> >> PROBLEM: >> >> >From the IdM server we can only lookup local records. The name >>> resolver will not >> attempt to look to another other name servers or domains defined in >> /etc/resolv.conf >> >> If I shutdown IdM using ipactl stop and then restart named, the name >> resolver works for local and remote hosts, addresses and domains as >> well as serving up the SRV records defined on the local host. >> >> Am I correct in assuming that while IdM is up and running, the only >> other systems it will communicate with at least with regard to name >> services is another host also running IdM defined either as a server or a client ? >> >> If this is case, is there anyone to better integrate some of these >> common services such as named into an existing network such that you are not limited by the IdM components ? > > I would like to get additional information about your environment: > - Is the IPA server is installed with DNS or not? Did you use option --setup-dns during ipa-server-install? > >>> I have tried it both ways, but the most current in which we see this behavior I ran ipa-server-install with >>> no arguments and said yes to the question about installing DNS. I then replied with two valid forwarders. >>> In a previous installation, we added two of our local zones from one of the other dns server >>> and then added the sample zone provided by the installation which contained the various SRV and TXT >>> records. But for current reporting of this problem, we did not add/load the other zone files. > > - Which DNS zones do you have defined on IPA server? You can use command "ipa dnszone-find" to list all zones. > > [root at linux named]# ipa dnsconfig-mod > --forwarder=16.112.240.27;16.112.240.40 > ipa: ERROR: no modifications to be performed > bash: 16.112.240.40: command not found... > [root at linux named]# ipa dnszone-find > Zone name: 240.112.16.in-addr.arpa. > Authoritative nameserver: linux.osn.cxo.cpqcorp.net. > Administrator e-mail address: hostmaster.osn.cxo.cpqcorp.net. > SOA serial: 1412344406 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > Active zone: TRUE > Allow query: any; > Allow transfer: none; > > Zone name: osn.cxo.cpqcorp.net > Authoritative nameserver: linux.osn.cxo.cpqcorp.net. > Administrator e-mail address: hostmaster.osn.cxo.cpqcorp.net. > SOA serial: 1412344406 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > Active zone: TRUE > Allow query: any; > Allow transfer: none; > ---------------------------- > Number of entries returned 2 > ---------------------------- > > - Is there any other DNS servers serving same DNS zones? > >>> Yes....we left the other two existing DNS servers in place as they are our primary name servers for this lab segment. >>> Those are the two systems we have entered as forwarders. > > - Did you configure forwarders in /etc/named.conf or via ipa command line tools (ipa dnsconfig-mod or --forwarder option during ipa-server-install)? > >>> The forwarders were placed in the /etc/named.conf file by the ipa-server-install script or one of its subordinate scripts >>> I did try entering the forward policy and forwarders using ipa dnsconfig-mod but they didn't seem to change the behavior. >>> One thing I did notice was that ipa dnsconfig-mod --forwarder= only allowed one forwarder to be entered.....adding >>> a second entry on the line resulted in an error. If entered with a second --forwarders command, the previous forwarder >>> was replaced by the new one. So if there is a particular syntax that would allow more than one entry, can you please >>> post same ? > > - Please attach result of DNS lookups using "dig" command: One output when it doesn't work (i.e. with IPA running) and the other when it works as you expect (i.e. after "ipactl stop" and "service named restart"). > >>> with ipa running: > > [root at linux named]# nslookup dl160a.osn.cxo.cpqcorp.net > Server: 16.112.240.59 > Address: 16.112.240.59#53 > > ** server can't find dl160a.osn.cxo.cpqcorp.net: NXDOMAIN > > [root at linux named]# dig dl160a.osn.cxo.cpqcorp.net > > ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> dl160a.osn.cxo.cpqcorp.net > ;; global options: +cmd ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6571 ;; flags: qr > aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;dl160a.osn.cxo.cpqcorp.net. IN A > > ;; AUTHORITY SECTION: > osn.cxo.cpqcorp.net. 3600 IN SOA linux.osn.cxo.cpqcorp.net. hostmaster.osn.cxo.cpqcorp.net. 1412344406 3600 900 1209600 3600 > > ;; Query time: 1 msec > ;; SERVER: 16.112.240.59#53(16.112.240.59) ;; WHEN: Fri Oct 03 > 11:08:35 EDT 2014 ;; MSG SIZE rcvd: 108 > > > [root at linux named]# ipactl stop > Stopping Directory Service > Stopping ipa-otpd Service > Stopping pki-tomcatd Service > Stopping httpd Service > Stopping ipa_memcached Service > Stopping named Service > Stopping kadmin Service > Stopping krb5kdc Service > ipa: INFO: The ipactl command was successful > > [root at linux named]# systemctl start named [root at linux named]# > [root at linux named]# [root at linux named]# dig dl160a.osn.cxo.cpqcorp.net > > ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> dl160a.osn.cxo.cpqcorp.net > ;; global options: +cmd ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28446 ;; flags: qr > rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;dl160a.osn.cxo.cpqcorp.net. IN A > > ;; ANSWER SECTION: > dl160a.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.191 > > ;; AUTHORITY SECTION: > osn.cxo.cpqcorp.net. 43200 IN NS cluster.osn.cxo.cpqcorp.net. > osn.cxo.cpqcorp.net. 43200 IN NS win2008.osn.cxo.cpqcorp.net. > osn.cxo.cpqcorp.net. 43200 IN NS denali.osn.cxo.cpqcorp.net. > > ;; ADDITIONAL SECTION: > win2008.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.55 > cluster.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.27 > denali.osn.cxo.cpqcorp.net. 43200 IN A 16.112.240.40 > > ;; Query time: 4 msec > ;; SERVER: 16.112.240.59#53(16.112.240.59) ;; WHEN: Fri Oct 03 > 11:10:54 EDT 2014 ;; MSG SIZE rcvd: 184 -- Petr^2 Spacek -- 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 From pspacek at redhat.com Mon Oct 6 14:35:13 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 06 Oct 2014 16:35:13 +0200 Subject: [Freeipa-users] FW: FW: named and IpA In-Reply-To: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C243C@G6W2496.americas.hpqcorp.net> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <542E5DAF.2090706@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2057@G6W2496.americas.hpqcorp.net> <54324B50.2050907@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C243C@G6W2496.americas.hpqcorp.net> Message-ID: <5432A8A1.2040707@redhat.com> On 6.10.2014 15:17, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > Thanks very much for the additional input. The configuration as you describe it is correct with a minor detail > correction that I didn't notice earlier. 16.112.240.27 is the master for the osn.cxo.cpqcorp.net zone while > 16.112.240.40 is a slave for that zone. But as you have said, both are authoritative for that zone. > > I won't belabor the point and will move on to try a different configuration as my ultimate goal here is to create > trust domains between a linux and an AD domain. To that end I will reconfigure the current IdM server such that > it is in a different subnet and domain. > > I just find it odd that when ipa is shutdown and named is restarted on the system designated as the IdM > server, that dns works and the forwarders are not ignored as they are when ipa is running. The reason is that authoritative data are stored in LDAP but global forwarding configuration (specified on ipa-server-install command line) is stored in /etc/named.conf. LDAP server is not reachable when IPA is down so BIND cannot see zones in LDAP and "global" forwarding in named.conf causes that it accidentally works for you. Forwarding is evil :-) -- Petr^2 Spacek From licause at hp.com Mon Oct 6 15:22:10 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Mon, 6 Oct 2014 15:22:10 +0000 Subject: [Freeipa-users] FW: FW: FW: named and IpA In-Reply-To: <5432A8A1.2040707@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <542E5DAF.2090706@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2057@G6W2496.americas.hpqcorp.net> <54324B50.2050907@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C243C@G6W2496.americas.hpqcorp.net> <5432A8A1.2040707@redhat.com> Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C24C8@G6W2496.americas.hpqcorp.net> Thanks for the additional data. It starts to make sense now, but I'm wondering if that could possibly be a weakness in the IdM model ? Al -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek Sent: Monday, October 06, 2014 7:35 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] FW: FW: named and IpA On 6.10.2014 15:17, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > Thanks very much for the additional input. The configuration as you describe it is correct with a minor detail > correction that I didn't notice earlier. 16.112.240.27 is the master for the osn.cxo.cpqcorp.net zone while > 16.112.240.40 is a slave for that zone. But as you have said, both are authoritative for that zone. > > I won't belabor the point and will move on to try a different configuration as my ultimate goal here is to create > trust domains between a linux and an AD domain. To that end I will reconfigure the current IdM server such that > it is in a different subnet and domain. > > I just find it odd that when ipa is shutdown and named is restarted on > the system designated as the IdM server, that dns works and the forwarders are not ignored as they are when ipa is running. The reason is that authoritative data are stored in LDAP but global forwarding configuration (specified on ipa-server-install command line) is stored in /etc/named.conf. LDAP server is not reachable when IPA is down so BIND cannot see zones in LDAP and "global" forwarding in named.conf causes that it accidentally works for you. Forwarding is evil :-) -- Petr^2 Spacek -- 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 From pspacek at redhat.com Mon Oct 6 16:38:59 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 06 Oct 2014 18:38:59 +0200 Subject: [Freeipa-users] FW: FW: FW: named and IpA In-Reply-To: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C24C8@G6W2496.americas.hpqcorp.net> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <542E5DAF.2090706@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2057@G6W2496.americas.hpqcorp.net> <54324B50.2050907@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C243C@G6W2496.americas.hpqcorp.net> <5432A8A1.2040707@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C24C8@G6W2496.americas.hpqcorp.net> Message-ID: <5432C5A3.4060003@redhat.com> On 6.10.2014 17:22, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > Thanks for the additional data. It starts to make sense now, but I'm wondering if that could possibly be a weakness > in the IdM model ? Well, define a weakness :-) Whole IPA server is built around LDAP database so LDAP is single point of failure *for one particular* IPA server. IPA offers a solution called "replicas". You can have multiple IPA servers with (two-way) replicated LDAP database so outage on N-1 servers will not affect your clients as long as clients are able to fail-over to the last functional server. I hope I understood you question :-) Petr^2 Spacek > > Al > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek > Sent: Monday, October 06, 2014 7:35 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FW: FW: named and IpA > > On 6.10.2014 15:17, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: >> Thanks very much for the additional input. The configuration as you describe it is correct with a minor detail >> correction that I didn't notice earlier. 16.112.240.27 is the master for the osn.cxo.cpqcorp.net zone while >> 16.112.240.40 is a slave for that zone. But as you have said, both are authoritative for that zone. >> >> I won't belabor the point and will move on to try a different configuration as my ultimate goal here is to create >> trust domains between a linux and an AD domain. To that end I will reconfigure the current IdM server such that >> it is in a different subnet and domain. >> >> I just find it odd that when ipa is shutdown and named is restarted on >> the system designated as the IdM server, that dns works and the forwarders are not ignored as they are when ipa is running. > > The reason is that authoritative data are stored in LDAP but global forwarding configuration (specified on ipa-server-install command line) is stored in /etc/named.conf. > > LDAP server is not reachable when IPA is down so BIND cannot see zones in LDAP and "global" forwarding in named.conf causes that it accidentally works for you. > > Forwarding is evil :-) > > -- > Petr^2 Spacek > > -- > 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 > -- Petr^2 Spacek From bnordgren at fs.fed.us Mon Oct 6 17:54:08 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Mon, 6 Oct 2014 17:54:08 +0000 Subject: [Freeipa-users] Enrolling with multiple IPA servers Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7339CC@001FSN2MPN1-045.001f.mgd2.msft.net> > The hostname put by ipa-client-install corresponds to the server to which this > client is enrolled. You enroll with a single server, after all. How would one enroll with multiple IPA servers? For instance, a standard configuration for a Rocks HPC cluster is to have at least two and usually three networks active, with different DNS zones for each. The "public" network is "company.example.com", "private" is typically an isolated GbE network named "local", and there's usually a fast network for real work (Infiniband or 10GbE); let's name it "ipoib" for IP over Infiniband. There may also be a slow 100bT network for management. A few machines have access to all three networks (headnode.company.example.com, headnode.local, and headnode.ipoib). Compute nodes have access to two (compute-0-0.local, compute-0-0.ipoib). Is it possible to make a single IPA instance manage the two isolated networks (local and ipoib)? Would multiple IPA servers and multiple enrollments be required? Once an IPA solution is defined, how does one configure openssh/sssd/krb5 on the compute nodes such that Kerberos SSO (and NFS server access) works regardless of which isolated network is used for communication? Would the compute nodes' two-network configuration be extensible to the headnode's three-network configuration? Thanks, Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From dpal at redhat.com Mon Oct 6 18:41:51 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 06 Oct 2014 14:41:51 -0400 Subject: [Freeipa-users] Enrolling with multiple IPA servers In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E7339CC@001FSN2MPN1-045.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7339CC@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: <5432E26F.6050000@redhat.com> On 10/06/2014 01:54 PM, Nordgren, Bryce L -FS wrote: >> The hostname put by ipa-client-install corresponds to the server to which this >> client is enrolled. You enroll with a single server, after all. > How would one enroll with multiple IPA servers? For instance, a standard configuration for a Rocks HPC cluster is to have at least two and usually three networks active, with different DNS zones for each. The "public" network is "company.example.com", "private" is typically an isolated GbE network named "local", and there's usually a fast network for real work (Infiniband or 10GbE); let's name it "ipoib" for IP over Infiniband. There may also be a slow 100bT network for management. > > A few machines have access to all three networks (headnode.company.example.com, headnode.local, and headnode.ipoib). Compute nodes have access to two (compute-0-0.local, compute-0-0.ipoib). > > Is it possible to make a single IPA instance manage the two isolated networks (local and ipoib)? Would multiple IPA servers and multiple enrollments be required? Once an IPA solution is defined, how does one configure openssh/sssd/krb5 on the compute nodes such that Kerberos SSO (and NFS server access) works regardless of which isolated network is used for communication? > Would the compute nodes' two-network configuration be extensible to the headnode's three-network configuration? IPA can manage several DNS zones but so far clients can only be a part of one DNS zone. I am not sure how the name resolution would work in case the client is accessible via several networks. I suspect the kerberos client would need to have some sort of setting that would indicate that despite how it is resolved via net A, B, or C it should map to the same principal and key. I would be surprised if there is not such override in the krb5.conf but I do not know for sure. > > Thanks, > Bryce > > > > > This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From abokovoy at redhat.com Mon Oct 6 18:43:40 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 6 Oct 2014 21:43:40 +0300 Subject: [Freeipa-users] Enrolling with multiple IPA servers In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E7339CC@001FSN2MPN1-045.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7339CC@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: <20141006184340.GU4683@redhat.com> On Mon, 06 Oct 2014, Nordgren, Bryce L -FS wrote: >> The hostname put by ipa-client-install corresponds to the server to which this >> client is enrolled. You enroll with a single server, after all. > >How would one enroll with multiple IPA servers? For instance, a >standard configuration for a Rocks HPC cluster is to have at least two >and usually three networks active, with different DNS zones for each. >The "public" network is "company.example.com", "private" is typically >an isolated GbE network named "local", and there's usually a fast >network for real work (Infiniband or 10GbE); let's name it "ipoib" for >IP over Infiniband. There may also be a slow 100bT network for >management. I don't think this has anything to do with 'enroll with multiple IPA servers'. 'Enrolling a host' in IPA terms means: 1. creating a host record + Kerberos principal for host/`hostname` 2. configuring the client to provide identity information, with host/`hostname` as an originator when talking to LDAP and other servers. As all IPA masters are equal and only differs in additional services like hosting CA or DNS, a record created at one of them will be propagated to all of others in the topology. So (1) can be done at any accessible IPA master. By default (2) is configured against the server used at (1). If discovery of IPA master using SRV records was successful, SSSD will have its configuration pointed to use _srv_ (meaning do dynamic discovery using SRV records at run time) and using the server this host was enrolled to as a server of last hope. If you want to use another strategy, you are welcome to change the generated configuration to something different. If you have some masters that are accessible by these isolated nodes, enroll isolated nodes against these masters. Nobody prevents you to select your deployment strategy and manipulate configuration files afterwards. Purpleidea's puppet module even allows you to define IPA masters' topology right in puppet scripts, if puppet is in use. >A few machines have access to all three networks >(headnode.company.example.com, headnode.local, and headnode.ipoib). >Compute nodes have access to two (compute-0-0.local, >compute-0-0.ipoib). > >Is it possible to make a single IPA instance manage the two isolated >networks (local and ipoib)? Would multiple IPA servers and multiple >enrollments be required? Once an IPA solution is defined, how does one >configure openssh/sssd/krb5 on the compute nodes such that Kerberos SSO >(and NFS server access) works regardless of which isolated network is >used for communication? Would the compute nodes' two-network >configuration be extensible to the headnode's three-network >configuration? If you want to make IPA masters available through several interfaces, you need to select one of that interfaces as primary and add SAN names to the certificates (LDAP, HTTP) of that server so that any node enrolled to this master will be able to use it. Think of those nodes as IPA masters in the isolated network, then enroll your isolated computing nodes to those masters. As long as you have means to uniquely identify DNS names of all hosts and your local IPA master can give you a ticket to a host/`hostname` of a host in question, things will work on Kerberos level. -- / Alexander Bokovoy From licause at hp.com Mon Oct 6 18:48:16 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Mon, 6 Oct 2014 18:48:16 +0000 Subject: [Freeipa-users] FW: FW: FW: FW: named and IpA In-Reply-To: <5432C5A3.4060003@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <542E5DAF.2090706@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2057@G6W2496.americas.hpqcorp.net> <54324B50.2050907@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C243C@G6W2496.americas.hpqcorp.net> <5432A8A1.2040707@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C24C8@G6W2496.americas.hpqcorp.net> <5432C5A3.4060003@redhat.com> Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C257C@G6W2496.americas.hpqcorp.net> I'm sure my doubts from from my lack of experience with IM at this time. Perhaps with a bit more driving time I'll come to appreciate the package a bit more. Thanks again for your patience and explainations. Al -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek Sent: Monday, October 06, 2014 9:39 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] FW: FW: FW: named and IpA On 6.10.2014 17:22, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > Thanks for the additional data. It starts to make sense now, but I'm wondering if that could possibly be a weakness > in the IdM model ? Well, define a weakness :-) Whole IPA server is built around LDAP database so LDAP is single point of failure *for one particular* IPA server. IPA offers a solution called "replicas". You can have multiple IPA servers with (two-way) replicated LDAP database so outage on N-1 servers will not affect your clients as long as clients are able to fail-over to the last functional server. I hope I understood you question :-) Petr^2 Spacek > > Al > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek > Sent: Monday, October 06, 2014 7:35 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FW: FW: named and IpA > > On 6.10.2014 15:17, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: >> Thanks very much for the additional input. The configuration as you describe it is correct with a minor detail >> correction that I didn't notice earlier. 16.112.240.27 is the master for the osn.cxo.cpqcorp.net zone while >> 16.112.240.40 is a slave for that zone. But as you have said, both are authoritative for that zone. >> >> I won't belabor the point and will move on to try a different configuration as my ultimate goal here is to create >> trust domains between a linux and an AD domain. To that end I will reconfigure the current IdM server such that >> it is in a different subnet and domain. >> >> I just find it odd that when ipa is shutdown and named is restarted >> on the system designated as the IdM server, that dns works and the forwarders are not ignored as they are when ipa is running. > > The reason is that authoritative data are stored in LDAP but global forwarding configuration (specified on ipa-server-install command line) is stored in /etc/named.conf. > > LDAP server is not reachable when IPA is down so BIND cannot see zones in LDAP and "global" forwarding in named.conf causes that it accidentally works for you. > > Forwarding is evil :-) > > -- > Petr^2 Spacek > > -- > 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 > -- Petr^2 Spacek -- 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 From licause at hp.com Mon Oct 6 20:55:26 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Mon, 6 Oct 2014 20:55:26 +0000 Subject: [Freeipa-users] IdM failing to install after reconfiguring server. Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2634@G6W2496.americas.hpqcorp.net> My appologies if this is a repeat but for some reason Outlook has seen fit to delete or possibly hide the folder in which have saved my entries from this subject. I have reconfigured a RHEL V7 system so as to exist in a different subnet and domain from our AD server to allow us to create trust domains between a linux and a windows domain. I have rebooted the system and now when I try to run a fresh install using ipa-system-install --uninstall followed by ipa-system-install I get the following error: Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/22]: creating certificate server user [2/22]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpMmhbtg' returned non-zero exit status 1 Configuration of CA failed Can anyone suggest what is failing and how we can go about fixing this ? Thanks Al Al Licause CSC Americas BCS Technical Specialist HP Customer Support Center Hours 5am-2pm Pacific time USA Manager: mark.bailey at hp.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2051 bytes Desc: image001.gif URL: From rcritten at redhat.com Mon Oct 6 21:09:50 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 06 Oct 2014 17:09:50 -0400 Subject: [Freeipa-users] IdM failing to install after reconfiguring server. In-Reply-To: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2634@G6W2496.americas.hpqcorp.net> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2634@G6W2496.americas.hpqcorp.net> Message-ID: <5433051E.7070005@redhat.com> Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > > > My appologies if this is a repeat but for some reason Outlook has seen > fit to delete or > > possibly hide the folder in which have saved my entries from this subject. > > > > I have reconfigured a RHEL V7 system so as to exist in a different > subnet and domain > > from our AD server to allow us to create trust domains between a linux > and a windows > > domain. > > > > I have rebooted the system and now when I try to run a fresh install using > > ipa-system-install --uninstall followed by ipa-system-install I get the > following error: > > > > > > Done configuring directory server (dirsrv). > > Configuring certificate server (pki-tomcatd): Estimated time 3 minutes > 30 seconds > > [1/22]: creating certificate server user > > [2/22]: configuring certificate server instance > > ipa : CRITICAL failed to configure ca instance Command > '/usr/sbin/pkispawn -s CA -f /tmp/tmpMmhbtg' returned non-zero exit status 1 > > Configuration of CA failed > > > > Can anyone suggest what is failing and how we can go about fixing this ? You need to look in /var/log/ipaserver-install.log and perhaps /var/log/pki/pki-tomcat/ca/debug for more details. rob From dpal at redhat.com Mon Oct 6 23:08:17 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 06 Oct 2014 19:08:17 -0400 Subject: [Freeipa-users] IdM failing to install after reconfiguring server. In-Reply-To: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2634@G6W2496.americas.hpqcorp.net> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2634@G6W2496.americas.hpqcorp.net> Message-ID: <543320E1.5010206@redhat.com> On 10/06/2014 04:55 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > > My appologies if this is a repeat but for some reason Outlook has seen > fit to delete or > > possibly hide the folder in which have saved my entries from this subject. > > I have reconfigured a RHEL V7 system so as to exist in a different > subnet and domain > > from our AD server to allow us to create trust domains between a linux > and a windows > > domain. > > I have rebooted the system and now when I try to run a fresh install > using > > ipa-system-install --uninstall followed by ipa-system-install I get > the following error: > > Done configuring directory server (dirsrv). > > Configuring certificate server (pki-tomcatd): Estimated time 3 minutes > 30 seconds > > [1/22]: creating certificate server user > > [2/22]: configuring certificate server instance > > ipa : CRITICAL failed to configure ca instance Command > '/usr/sbin/pkispawn -s CA -f /tmp/tmpMmhbtg' returned non-zero exit > status 1 > > Configuration of CA failed > > Can anyone suggest what is failing and how we can go about fixing this ? > I think you hit this before in the other mail thread and it was recommended to do: pkidestroy -s CA -i pki-tomcat rm -rf /var/log/pki/pki-tomcat rm -rf /etc/sysconfig/pki-tomcat rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat rm -rf /var/lib/pki/pki-tomcat rm -rf /etc/pki/pki-tomcat > Thanks > > Al > > *Al Licause* > > *CSC Americas BCS Technical Specialist* > > *HP Customer Support Center* > > *Hours 5am-2pm Pacific time USA* > > *Manager: mark.bailey at hp.com* > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2051 bytes Desc: not available URL: From pspacek at redhat.com Tue Oct 7 08:19:31 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 07 Oct 2014 10:19:31 +0200 Subject: [Freeipa-users] Enrolling with multiple IPA servers In-Reply-To: <20141006184340.GU4683@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7339CC@001FSN2MPN1-045.001f.mgd2.msft.net> <20141006184340.GU4683@redhat.com> Message-ID: <5433A213.8060608@redhat.com> On 6.10.2014 20:43, Alexander Bokovoy wrote: > On Mon, 06 Oct 2014, Nordgren, Bryce L -FS wrote: >>> The hostname put by ipa-client-install corresponds to the server to which this >>> client is enrolled. You enroll with a single server, after all. >> >> How would one enroll with multiple IPA servers? For instance, a >> standard configuration for a Rocks HPC cluster is to have at least two >> and usually three networks active, with different DNS zones for each. >> The "public" network is "company.example.com", "private" is typically >> an isolated GbE network named "local", and there's usually a fast >> network for real work (Infiniband or 10GbE); let's name it "ipoib" for >> IP over Infiniband. There may also be a slow 100bT network for >> management. > I don't think this has anything to do with 'enroll with multiple IPA servers'. > > 'Enrolling a host' in IPA terms means: > 1. creating a host record + Kerberos principal for host/`hostname` > 2. configuring the client to provide identity information, with > host/`hostname` as an originator when talking to LDAP and other > servers. > > As all IPA masters are equal and only differs in additional services > like hosting CA or DNS, a record created at one of them will be > propagated to all of others in the topology. So (1) can be done at any > accessible IPA master. > > By default (2) is configured against the server used at (1). If > discovery of IPA master using SRV records was successful, SSSD will have > its configuration pointed to use _srv_ (meaning do dynamic discovery > using SRV records at run time) and using the server this host was > enrolled to as a server of last hope. > > If you want to use another strategy, you are welcome to change the > generated configuration to something different. > > If you have some masters that are accessible by these isolated nodes, > enroll isolated nodes against these masters. Nobody prevents you to > select your deployment strategy and manipulate configuration files > afterwards. Purpleidea's puppet module even allows you to define IPA > masters' topology right in puppet scripts, if puppet is in use. > > >> A few machines have access to all three networks >> (headnode.company.example.com, headnode.local, and headnode.ipoib). >> Compute nodes have access to two (compute-0-0.local, >> compute-0-0.ipoib). >> >> Is it possible to make a single IPA instance manage the two isolated >> networks (local and ipoib)? Would multiple IPA servers and multiple >> enrollments be required? Once an IPA solution is defined, how does one >> configure openssh/sssd/krb5 on the compute nodes such that Kerberos SSO >> (and NFS server access) works regardless of which isolated network is >> used for communication? Would the compute nodes' two-network >> configuration be extensible to the headnode's three-network >> configuration? > If you want to make IPA masters available through several interfaces, > you need to select one of that interfaces as primary and add SAN names > to the certificates (LDAP, HTTP) of that server so that any node > enrolled to this master will be able to use it. Think of those nodes as > IPA masters in the isolated network, then enroll your isolated computing > nodes to those masters. > > As long as you have means to uniquely identify DNS names of all hosts > and your local IPA master can give you a ticket to a host/`hostname` of > a host in question, things will work on Kerberos level. I agree with Alexander so I will only mention one nit from DNS's point of view: Do not use 'local.' TLD, it is reserved for mDNS [1]. It is much better to use name 'compute-0-0.local.company.example.com' instead of 'compute-0-0.local'. The fact parent DNS name is in public sub-tree (company.example.com) doesn't force you to make all children also public. The name server can have private IP address or you can drop all queries from outside on firewall. This approach has two benefits: - You will not get naming conflicts when companies merge. - Things will not break when DNSSEC validation is enabled. Naturally you will not change host names now but it is a thing to keep in mind for future. Have a nice day! [1] http://tools.ietf.org/html/rfc6762 -- Petr^2 Spacek From amurty at deloitte.com Tue Oct 7 09:35:50 2014 From: amurty at deloitte.com (Murty, Ajeet (US - Arlington)) Date: Tue, 7 Oct 2014 09:35:50 +0000 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <54218E89.2060800@redhat.com> References: <013068C38BB187448B7AB350AE98B35B38D3AD93@USNDC1453.us.deloitte.com> <54208167.2040508@redhat.com> <54218E89.2060800@redhat.com> Message-ID: <013068C38BB187448B7AB350AE98B35B38D56F3A@USNDC1453.us.deloitte.com> Hi Martin and Nathan, Thank you for providing that info. Unfortunately, my IPA server is running on CentOS, and the latest IPA version available through YUM is - 'ipa-server.i686 3.0.0-37.el6'. The latest version of 389-DS through YUM is - '389-ds-base.i686 1.2.11.15-34.el6_5 '. Nessus scan had detected this null cipher - TLSv1 NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 I found 2 'dse.ldif' files on disk - /etc/dirsrv/slapd-PKI-IPA/dse.ldif /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif In each of them, I found this - nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs a_export1024_with_des_cbc_sha So to disable null cipher, I removed 'rsa_null_md5' from that list - nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs a_export1024_with_des_cbc_sha I restarted the entire IPA stack, and ran the scan again, I am still seeing that Null Cipher. Any ideas on how to resolve this? Thanks. This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. v.E.1 -----Original Message----- From: Martin Kosek [mailto:mkosek at redhat.com] Sent: Tuesday, September 23, 2014 11:15 AM To: Nathan Kinder; freeipa-users at redhat.com; Murty, Ajeet (US - Arlington) Subject: 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-/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 From abokovoy at redhat.com Tue Oct 7 09:46:14 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 7 Oct 2014 12:46:14 +0300 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <013068C38BB187448B7AB350AE98B35B38D56F3A@USNDC1453.us.deloitte.com> References: <013068C38BB187448B7AB350AE98B35B38D3AD93@USNDC1453.us.deloitte.com> <54208167.2040508@redhat.com> <54218E89.2060800@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F3A@USNDC1453.us.deloitte.com> Message-ID: <20141007094614.GX4683@redhat.com> On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >Hi Martin and Nathan, > >Thank you for providing that info. >Unfortunately, my IPA server is running on CentOS, and the latest IPA version available through YUM is - 'ipa-server.i686 3.0.0-37.el6'. >The latest version of 389-DS through YUM is - '389-ds-base.i686 1.2.11.15-34.el6_5 '. > >Nessus scan had detected this null cipher - > TLSv1 > NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 > >I found 2 'dse.ldif' files on disk - > /etc/dirsrv/slapd-PKI-IPA/dse.ldif > /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif > >In each of them, I found this - >nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo > rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > a_export1024_with_des_cbc_sha > > >So to disable null cipher, I removed 'rsa_null_md5' from that list - >nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo > rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > a_export1024_with_des_cbc_sha > >I restarted the entire IPA stack, and ran the scan again, I am still seeing that Null Cipher. > >Any ideas on how to resolve this? I can see also fortezza_null in the above list, maybe you are getting into that one? > >-----Original Message----- >From: Martin Kosek [mailto:mkosek at redhat.com] >Sent: Tuesday, September 23, 2014 11:15 AM >To: Nathan Kinder; freeipa-users at redhat.com; Murty, Ajeet (US - Arlington) >Subject: 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-/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 -- / Alexander Bokovoy From abokovoy at redhat.com Tue Oct 7 09:58:09 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 7 Oct 2014 12:58:09 +0300 Subject: [Freeipa-users] GNOME Project moved to FreeIPA for managing its account information Message-ID: <20141007095809.GY4683@redhat.com> Hi! As Andrea Veri describes in the blog[1], GNOME Project's infrastructure is now powered by FreeIPA. While GNOME was already using SSSD since very early days of SSSD project, move to FreeIPA on the server side took more time. [1] https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/ -- / Alexander Bokovoy From amurty at deloitte.com Tue Oct 7 10:02:23 2014 From: amurty at deloitte.com (Murty, Ajeet (US - Arlington)) Date: Tue, 7 Oct 2014 10:02:23 +0000 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <20141007094614.GX4683@redhat.com> References: <013068C38BB187448B7AB350AE98B35B38D3AD93@USNDC1453.us.deloitte.com> <54208167.2040508@redhat.com> <54218E89.2060800@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F3A@USNDC1453.us.deloitte.com> <20141007094614.GX4683@redhat.com> Message-ID: <013068C38BB187448B7AB350AE98B35B38D56F66@USNDC1453.us.deloitte.com> I edited both ldif files to remove fortezza_null. Looks like this now - nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs a_export1024_with_des_cbc_sha Ran the scan again, still seeing Null Cipher - TLSv1 NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. v.E.1 -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: Tuesday, October 07, 2014 5:46 AM To: Murty, Ajeet (US - Arlington) Cc: Martin Kosek; Nathan Kinder; freeipa-users at redhat.com Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >Hi Martin and Nathan, > >Thank you for providing that info. >Unfortunately, my IPA server is running on CentOS, and the latest IPA version available through YUM is - 'ipa-server.i686 3.0.0-37.el6'. >The latest version of 389-DS through YUM is - '389-ds-base.i686 1.2.11.15-34.el6_5 '. > >Nessus scan had detected this null cipher - > TLSv1 > NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 > >I found 2 'dse.ldif' files on disk - > /etc/dirsrv/slapd-PKI-IPA/dse.ldif > /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif > >In each of them, I found this - >nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo > rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > a_export1024_with_des_cbc_sha > > >So to disable null cipher, I removed 'rsa_null_md5' from that list - >nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo > rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > a_export1024_with_des_cbc_sha > >I restarted the entire IPA stack, and ran the scan again, I am still seeing that Null Cipher. > >Any ideas on how to resolve this? I can see also fortezza_null in the above list, maybe you are getting into that one? > >-----Original Message----- >From: Martin Kosek [mailto:mkosek at redhat.com] >Sent: Tuesday, September 23, 2014 11:15 AM >To: Nathan Kinder; freeipa-users at redhat.com; Murty, Ajeet (US - Arlington) >Subject: 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-/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 -- / Alexander Bokovoy From abokovoy at redhat.com Tue Oct 7 10:12:57 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 7 Oct 2014 13:12:57 +0300 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <013068C38BB187448B7AB350AE98B35B38D56F66@USNDC1453.us.deloitte.com> References: <013068C38BB187448B7AB350AE98B35B38D3AD93@USNDC1453.us.deloitte.com> <54208167.2040508@redhat.com> <54218E89.2060800@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F3A@USNDC1453.us.deloitte.com> <20141007094614.GX4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F66@USNDC1453.us.deloitte.com> Message-ID: <20141007101257.GA4683@redhat.com> On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >I edited both ldif files to remove fortezza_null. Looks like this now - > >nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo > rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs Here I can still see +fortezza_null. > a_export1024_with_des_cbc_sha > >Ran the scan again, still seeing Null Cipher - > >TLSv1 > NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 > > > > > > > >This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. > >v.E.1 > > >-----Original Message----- >From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >Sent: Tuesday, October 07, 2014 5:46 AM >To: Murty, Ajeet (US - Arlington) >Cc: Martin Kosek; Nathan Kinder; freeipa-users at redhat.com >Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports > >On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >>Hi Martin and Nathan, >> >>Thank you for providing that info. >>Unfortunately, my IPA server is running on CentOS, and the latest IPA version available through YUM is - 'ipa-server.i686 3.0.0-37.el6'. >>The latest version of 389-DS through YUM is - '389-ds-base.i686 1.2.11.15-34.el6_5 '. >> >>Nessus scan had detected this null cipher - >> TLSv1 >> NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 >> >>I found 2 'dse.ldif' files on disk - >> /etc/dirsrv/slapd-PKI-IPA/dse.ldif >> /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif >> >>In each of them, I found this - >>nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >> a_export1024_with_des_cbc_sha >> >> >>So to disable null cipher, I removed 'rsa_null_md5' from that list - >>nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >> a_export1024_with_des_cbc_sha >> >>I restarted the entire IPA stack, and ran the scan again, I am still seeing that Null Cipher. >> >>Any ideas on how to resolve this? >I can see also fortezza_null in the above list, maybe you are getting >into that one? > >> >>-----Original Message----- >>From: Martin Kosek [mailto:mkosek at redhat.com] >>Sent: Tuesday, September 23, 2014 11:15 AM >>To: Nathan Kinder; freeipa-users at redhat.com; Murty, Ajeet (US - Arlington) >>Subject: 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-/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 > >-- >/ Alexander Bokovoy -- / Alexander Bokovoy From amurty at deloitte.com Tue Oct 7 10:16:13 2014 From: amurty at deloitte.com (Murty, Ajeet (US - Arlington)) Date: Tue, 7 Oct 2014 10:16:13 +0000 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <20141007101257.GA4683@redhat.com> References: <013068C38BB187448B7AB350AE98B35B38D3AD93@USNDC1453.us.deloitte.com> <54208167.2040508@redhat.com> <54218E89.2060800@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F3A@USNDC1453.us.deloitte.com> <20141007094614.GX4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F66@USNDC1453.us.deloitte.com> <20141007101257.GA4683@redhat.com> Message-ID: <013068C38BB187448B7AB350AE98B35B38D56F99@USNDC1453.us.deloitte.com> Sorry, messed up copy paste, here is the edited section - nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+ rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128 _sha,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha numSubordinates: 1 I double checked this time. No Null ciphers in dse.ldif files. Still seeing the Null Cipher in scans. -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: Tuesday, October 07, 2014 6:13 AM To: Murty, Ajeet (US - Arlington) Cc: Martin Kosek; Nathan Kinder; freeipa-users at redhat.com Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >I edited both ldif files to remove fortezza_null. Looks like this now - > >nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo > rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs Here I can still see +fortezza_null. > a_export1024_with_des_cbc_sha > >Ran the scan again, still seeing Null Cipher - > >TLSv1 > NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 > > > > > > > >This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. > >v.E.1 > > >-----Original Message----- >From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >Sent: Tuesday, October 07, 2014 5:46 AM >To: Murty, Ajeet (US - Arlington) >Cc: Martin Kosek; Nathan Kinder; freeipa-users at redhat.com >Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports > >On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >>Hi Martin and Nathan, >> >>Thank you for providing that info. >>Unfortunately, my IPA server is running on CentOS, and the latest IPA version available through YUM is - 'ipa-server.i686 3.0.0-37.el6'. >>The latest version of 389-DS through YUM is - '389-ds-base.i686 1.2.11.15-34.el6_5 '. >> >>Nessus scan had detected this null cipher - >> TLSv1 >> NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 >> >>I found 2 'dse.ldif' files on disk - >> /etc/dirsrv/slapd-PKI-IPA/dse.ldif >> /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif >> >>In each of them, I found this - >>nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >> a_export1024_with_des_cbc_sha >> >> >>So to disable null cipher, I removed 'rsa_null_md5' from that list - >>nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >> a_export1024_with_des_cbc_sha >> >>I restarted the entire IPA stack, and ran the scan again, I am still seeing that Null Cipher. >> >>Any ideas on how to resolve this? >I can see also fortezza_null in the above list, maybe you are getting >into that one? > >> >>-----Original Message----- >>From: Martin Kosek [mailto:mkosek at redhat.com] >>Sent: Tuesday, September 23, 2014 11:15 AM >>To: Nathan Kinder; freeipa-users at redhat.com; Murty, Ajeet (US - Arlington) >>Subject: 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-/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 > >-- >/ Alexander Bokovoy -- / Alexander Bokovoy From lkrispen at redhat.com Tue Oct 7 10:49:51 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 07 Oct 2014 12:49:51 +0200 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <013068C38BB187448B7AB350AE98B35B38D56F99@USNDC1453.us.deloitte.com> References: <013068C38BB187448B7AB350AE98B35B38D3AD93@USNDC1453.us.deloitte.com> <54208167.2040508@redhat.com> <54218E89.2060800@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F3A@USNDC1453.us.deloitte.com> <20141007094614.GX4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F66@USNDC1453.us.deloitte.com> <20141007101257.GA4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F99@USNDC1453.us.deloitte.com> Message-ID: <5433C54F.2080402@redhat.com> On 10/07/2014 12:16 PM, Murty, Ajeet (US - Arlington) wrote: > Sorry, messed up copy paste, here is the edited section - > > nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+ > rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128 > _sha,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha > numSubordinates: 1 the +xxxx are probably added to a default set of ciphers, could you try with "-fortezza_null" ? > > I double checked this time. No Null ciphers in dse.ldif files. > Still seeing the Null Cipher in scans. > > > > -----Original Message----- > From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > Sent: Tuesday, October 07, 2014 6:13 AM > To: Murty, Ajeet (US - Arlington) > Cc: Martin Kosek; Nathan Kinder; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports > > On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >> I edited both ldif files to remove fortezza_null. Looks like this now - >> >> nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > Here I can still see +fortezza_null. > >> a_export1024_with_des_cbc_sha >> >> Ran the scan again, still seeing Null Cipher - >> >> TLSv1 >> NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 >> >> >> >> >> >> >> >> This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. >> >> v.E.1 >> >> >> -----Original Message----- >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> Sent: Tuesday, October 07, 2014 5:46 AM >> To: Murty, Ajeet (US - Arlington) >> Cc: Martin Kosek; Nathan Kinder; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports >> >> On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >>> Hi Martin and Nathan, >>> >>> Thank you for providing that info. >>> Unfortunately, my IPA server is running on CentOS, and the latest IPA version available through YUM is - 'ipa-server.i686 3.0.0-37.el6'. >>> The latest version of 389-DS through YUM is - '389-ds-base.i686 1.2.11.15-34.el6_5 '. >>> >>> Nessus scan had detected this null cipher - >>> TLSv1 >>> NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 >>> >>> I found 2 'dse.ldif' files on disk - >>> /etc/dirsrv/slapd-PKI-IPA/dse.ldif >>> /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif >>> >>> In each of them, I found this - >>> nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >>> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >>> rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >>> a_export1024_with_des_cbc_sha >>> >>> >>> So to disable null cipher, I removed 'rsa_null_md5' from that list - >>> nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >>> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >>> rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >>> a_export1024_with_des_cbc_sha >>> >>> I restarted the entire IPA stack, and ran the scan again, I am still seeing that Null Cipher. >>> >>> Any ideas on how to resolve this? >> I can see also fortezza_null in the above list, maybe you are getting >> into that one? >> >>> -----Original Message----- >>> From: Martin Kosek [mailto:mkosek at redhat.com] >>> Sent: Tuesday, September 23, 2014 11:15 AM >>> To: Nathan Kinder; freeipa-users at redhat.com; Murty, Ajeet (US - Arlington) >>> Subject: 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-/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 >> -- >> / Alexander Bokovoy From mkosek at redhat.com Tue Oct 7 12:09:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 07 Oct 2014 14:09:15 +0200 Subject: [Freeipa-users] GNOME Project moved to FreeIPA for managing its account information In-Reply-To: <20141007095809.GY4683@redhat.com> References: <20141007095809.GY4683@redhat.com> Message-ID: <5433D7EB.4020403@redhat.com> On 10/07/2014 11:58 AM, Alexander Bokovoy wrote: > Hi! > > As Andrea Veri describes in the blog[1], GNOME Project's infrastructure > is now powered by FreeIPA. While GNOME was already using SSSD since very > early days of SSSD project, move to FreeIPA on the server side took more > time. > > [1] > https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/ > > Nice! I wonder if they use any module of http://www.freeipa.org/page/Web_App_Authentication suite, I saw several potential use cases in the text. I asked in the blog, to find out. From licause at hp.com Tue Oct 7 13:11:16 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Tue, 7 Oct 2014 13:11:16 +0000 Subject: [Freeipa-users] FW: IdM failing to install after reconfiguring server. In-Reply-To: <543320E1.5010206@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2634@G6W2496.americas.hpqcorp.net> <543320E1.5010206@redhat.com> Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C49BC@G5W2742.americas.hpqcorp.net> Dmitri, Thanks very much.....that did it. I'm making a special note of this one and not storing it in the Outlook folders. RE: looking through the various log files didn't seem to help as they are someone confusing to the IM novice like myself. Al From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Monday, October 06, 2014 4:08 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] IdM failing to install after reconfiguring server. On 10/06/2014 04:55 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: [cid:part1.06090004.06000305 at redhat.com] My appologies if this is a repeat but for some reason Outlook has seen fit to delete or possibly hide the folder in which have saved my entries from this subject. I have reconfigured a RHEL V7 system so as to exist in a different subnet and domain from our AD server to allow us to create trust domains between a linux and a windows domain. I have rebooted the system and now when I try to run a fresh install using ipa-system-install --uninstall followed by ipa-system-install I get the following error: Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/22]: creating certificate server user [2/22]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpMmhbtg' returned non-zero exit status 1 Configuration of CA failed Can anyone suggest what is failing and how we can go about fixing this ? I think you hit this before in the other mail thread and it was recommended to do: pkidestroy -s CA -i pki-tomcat rm -rf /var/log/pki/pki-tomcat rm -rf /etc/sysconfig/pki-tomcat rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat rm -rf /var/lib/pki/pki-tomcat rm -rf /etc/pki/pki-tomcat Thanks Al Al Licause CSC Americas BCS Technical Specialist HP Customer Support Center Hours 5am-2pm Pacific time USA Manager: mark.bailey at hp.com -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ATT00001.gif Type: image/gif Size: 2051 bytes Desc: ATT00001.gif URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00002.txt URL: From purpleidea at gmail.com Tue Oct 7 13:27:53 2014 From: purpleidea at gmail.com (James) Date: Tue, 7 Oct 2014 09:27:53 -0400 Subject: [Freeipa-users] GNOME Project moved to FreeIPA for managing its account information In-Reply-To: <20141007095809.GY4683@redhat.com> References: <20141007095809.GY4683@redhat.com> Message-ID: On 7 October 2014 05:58, Alexander Bokovoy wrote: > Hi! > > As Andrea Veri describes in the blog[1], GNOME Project's infrastructure > is now powered by FreeIPA. While GNOME was already using SSSD since very > early days of SSSD project, move to FreeIPA on the server side took more > time. Yup :) I wonder who convinced him to look at FreeIPA... Hrmm ;) > > [1] > https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/ > > -- > / Alexander Bokovoy > > -- > 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 From licause at hp.com Tue Oct 7 13:44:20 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Tue, 7 Oct 2014 13:44:20 +0000 Subject: [Freeipa-users] FW: IdM failing to install after reconfiguring server. In-Reply-To: <543320E1.5010206@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2634@G6W2496.americas.hpqcorp.net> <543320E1.5010206@redhat.com> Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C59E4@G5W2742.americas.hpqcorp.net> Let me correct my last entry......in looking at the log files, I did come across this error and the end of the ipaserver-install.log but that was not one of the files or directories that had to be deleted as per the corrective list of actions: 2014-10-07T12:53:04Z DEBUG The ipa-server-install command failed, exception: OSError: [Errno 2] No such file or directory: '/var/lib/ipa/pki-ca/publish' Resolution: pkidestroy -s CA -i pki-tomcat rm -rf /var/log/pki/pki-tomcat rm -rf /etc/sysconfig/pki-tomcat rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat rm -rf /var/lib/pki/pki-tomcat rm -rf /etc/pki/pki-tomcat Al From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Monday, October 06, 2014 4:08 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] IdM failing to install after reconfiguring server. On 10/06/2014 04:55 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: [cid:part1.06090004.06000305 at redhat.com] My appologies if this is a repeat but for some reason Outlook has seen fit to delete or possibly hide the folder in which have saved my entries from this subject. I have reconfigured a RHEL V7 system so as to exist in a different subnet and domain from our AD server to allow us to create trust domains between a linux and a windows domain. I have rebooted the system and now when I try to run a fresh install using ipa-system-install --uninstall followed by ipa-system-install I get the following error: Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/22]: creating certificate server user [2/22]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpMmhbtg' returned non-zero exit status 1 Configuration of CA failed Can anyone suggest what is failing and how we can go about fixing this ? I think you hit this before in the other mail thread and it was recommended to do: pkidestroy -s CA -i pki-tomcat rm -rf /var/log/pki/pki-tomcat rm -rf /etc/sysconfig/pki-tomcat rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat rm -rf /var/lib/pki/pki-tomcat rm -rf /etc/pki/pki-tomcat Thanks Al Al Licause CSC Americas BCS Technical Specialist HP Customer Support Center Hours 5am-2pm Pacific time USA Manager: mark.bailey at hp.com -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ATT00001.gif Type: image/gif Size: 2051 bytes Desc: ATT00001.gif URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00002.txt URL: From purpleidea at gmail.com Tue Oct 7 14:11:49 2014 From: purpleidea at gmail.com (James) Date: Tue, 7 Oct 2014 10:11:49 -0400 Subject: [Freeipa-users] Enrolling with multiple IPA servers In-Reply-To: <20141006184340.GU4683@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7339CC@001FSN2MPN1-045.001f.mgd2.msft.net> <20141006184340.GU4683@redhat.com> Message-ID: On 6 October 2014 14:43, Alexander Bokovoy wrote: > If you have some masters that are accessible by these isolated nodes, > enroll isolated nodes against these masters. Nobody prevents you to > select your deployment strategy and manipulate configuration files > afterwards. Purpleidea's puppet module even allows you to define IPA > masters' topology right in puppet scripts, if puppet is in use. To elaborate on this, you can specify an algorithm to define the "shape" of the cluster. There are two built-in POC algorithms provided, but more will be accepted. "Shape" means how do I algorithmically define who is neighbours with who. The two provided are "flat" and "ring": [1] https://github.com/purpleidea/puppet-ipa/blob/master/DOCUMENTATION.md#topology [2] https://github.com/purpleidea/puppet-ipa/tree/master/lib/puppet/parser/functions HTH James From rmeggins at redhat.com Tue Oct 7 14:16:14 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 07 Oct 2014 08:16:14 -0600 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <013068C38BB187448B7AB350AE98B35B38D56F99@USNDC1453.us.deloitte.com> References: <013068C38BB187448B7AB350AE98B35B38D3AD93@USNDC1453.us.deloitte.com> <54208167.2040508@redhat.com> <54218E89.2060800@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F3A@USNDC1453.us.deloitte.com> <20141007094614.GX4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F66@USNDC1453.us.deloitte.com> <20141007101257.GA4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F99@USNDC1453.us.deloitte.com> Message-ID: <5433F5AE.7000405@redhat.com> On 10/07/2014 04:16 AM, Murty, Ajeet (US - Arlington) wrote: > Sorry, messed up copy paste, here is the edited section - > > nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+ > rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128 > _sha,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha > numSubordinates: 1 > > I double checked this time. No Null ciphers in dse.ldif files. > Still seeing the Null Cipher in scans. NOTE: You cannot edit dse.ldif while dirsrv is running. You must ensure dirsrv is not running before you edit dse.ldif. > > > > -----Original Message----- > From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > Sent: Tuesday, October 07, 2014 6:13 AM > To: Murty, Ajeet (US - Arlington) > Cc: Martin Kosek; Nathan Kinder; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports > > On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >> I edited both ldif files to remove fortezza_null. Looks like this now - >> >> nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > Here I can still see +fortezza_null. > >> a_export1024_with_des_cbc_sha >> >> Ran the scan again, still seeing Null Cipher - >> >> TLSv1 >> NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 >> >> >> >> >> >> >> >> This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. >> >> v.E.1 >> >> >> -----Original Message----- >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> Sent: Tuesday, October 07, 2014 5:46 AM >> To: Murty, Ajeet (US - Arlington) >> Cc: Martin Kosek; Nathan Kinder; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports >> >> On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >>> Hi Martin and Nathan, >>> >>> Thank you for providing that info. >>> Unfortunately, my IPA server is running on CentOS, and the latest IPA version available through YUM is - 'ipa-server.i686 3.0.0-37.el6'. >>> The latest version of 389-DS through YUM is - '389-ds-base.i686 1.2.11.15-34.el6_5 '. >>> >>> Nessus scan had detected this null cipher - >>> TLSv1 >>> NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 >>> >>> I found 2 'dse.ldif' files on disk - >>> /etc/dirsrv/slapd-PKI-IPA/dse.ldif >>> /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif >>> >>> In each of them, I found this - >>> nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >>> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >>> rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >>> a_export1024_with_des_cbc_sha >>> >>> >>> So to disable null cipher, I removed 'rsa_null_md5' from that list - >>> nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >>> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >>> rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >>> a_export1024_with_des_cbc_sha >>> >>> I restarted the entire IPA stack, and ran the scan again, I am still seeing that Null Cipher. >>> >>> Any ideas on how to resolve this? >> I can see also fortezza_null in the above list, maybe you are getting >> into that one? >> >>> -----Original Message----- >>> From: Martin Kosek [mailto:mkosek at redhat.com] >>> Sent: Tuesday, September 23, 2014 11:15 AM >>> To: Nathan Kinder; freeipa-users at redhat.com; Murty, Ajeet (US - Arlington) >>> Subject: 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-/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 >> -- >> / Alexander Bokovoy From rcritten at redhat.com Tue Oct 7 14:18:32 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 07 Oct 2014 10:18:32 -0400 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <013068C38BB187448B7AB350AE98B35B38D56F99@USNDC1453.us.deloitte.com> References: <013068C38BB187448B7AB350AE98B35B38D3AD93@USNDC1453.us.deloitte.com> <54208167.2040508@redhat.com> <54218E89.2060800@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F3A@USNDC1453.us.deloitte.com> <20141007094614.GX4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F66@USNDC1453.us.deloitte.com> <20141007101257.GA4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F99@USNDC1453.us.deloitte.com> Message-ID: <5433F638.306@redhat.com> Murty, Ajeet (US - Arlington) wrote: > Sorry, messed up copy paste, here is the edited section - > > nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+ > rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128 > _sha,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha > numSubordinates: 1 > > I double checked this time. No Null ciphers in dse.ldif files. > Still seeing the Null Cipher in scans. > Are you shutting down the server(s) before modifying dse.ldif or are you doing the changes online using ldapmodify? 389-ds writes dse.ldif during shutdown so if you make changes while the server is up and then restart it those changes will be lost. rob > > > -----Original Message----- > From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > Sent: Tuesday, October 07, 2014 6:13 AM > To: Murty, Ajeet (US - Arlington) > Cc: Martin Kosek; Nathan Kinder; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports > > On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >> I edited both ldif files to remove fortezza_null. Looks like this now - >> >> nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > Here I can still see +fortezza_null. > >> a_export1024_with_des_cbc_sha >> >> Ran the scan again, still seeing Null Cipher - >> >> TLSv1 >> NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 >> >> >> >> >> >> >> >> This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. >> >> v.E.1 >> >> >> -----Original Message----- >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> Sent: Tuesday, October 07, 2014 5:46 AM >> To: Murty, Ajeet (US - Arlington) >> Cc: Martin Kosek; Nathan Kinder; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports >> >> On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >>> Hi Martin and Nathan, >>> >>> Thank you for providing that info. >>> Unfortunately, my IPA server is running on CentOS, and the latest IPA version available through YUM is - 'ipa-server.i686 3.0.0-37.el6'. >>> The latest version of 389-DS through YUM is - '389-ds-base.i686 1.2.11.15-34.el6_5 '. >>> >>> Nessus scan had detected this null cipher - >>> TLSv1 >>> NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 >>> >>> I found 2 'dse.ldif' files on disk - >>> /etc/dirsrv/slapd-PKI-IPA/dse.ldif >>> /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif >>> >>> In each of them, I found this - >>> nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >>> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >>> rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >>> a_export1024_with_des_cbc_sha >>> >>> >>> So to disable null cipher, I removed 'rsa_null_md5' from that list - >>> nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >>> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >>> rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >>> a_export1024_with_des_cbc_sha >>> >>> I restarted the entire IPA stack, and ran the scan again, I am still seeing that Null Cipher. >>> >>> Any ideas on how to resolve this? >> I can see also fortezza_null in the above list, maybe you are getting >> into that one? >> >>> >>> -----Original Message----- >>> From: Martin Kosek [mailto:mkosek at redhat.com] >>> Sent: Tuesday, September 23, 2014 11:15 AM >>> To: Nathan Kinder; freeipa-users at redhat.com; Murty, Ajeet (US - Arlington) >>> Subject: 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-/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 >> >> -- >> / Alexander Bokovoy > From amurty at deloitte.com Tue Oct 7 16:10:38 2014 From: amurty at deloitte.com (Murty, Ajeet (US - Arlington)) Date: Tue, 7 Oct 2014 16:10:38 +0000 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <5433F638.306@redhat.com> References: <013068C38BB187448B7AB350AE98B35B38D3AD93@USNDC1453.us.deloitte.com> <54208167.2040508@redhat.com> <54218E89.2060800@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F3A@USNDC1453.us.deloitte.com> <20141007094614.GX4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F66@USNDC1453.us.deloitte.com> <20141007101257.GA4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F99@USNDC1453.us.deloitte.com> <5433F638.306@redhat.com> Message-ID: <013068C38BB187448B7AB350AE98B35B38D577FF@USNDC1453.us.deloitte.com> I was shutting down IPA before making any changes - 1. Shutdown IPA - [root]# /etc/init.d/ipa stop Stopping CA Service Stopping pki-ca: [ OK ] Stopping HTTP Service Stopping httpd: [ OK ] Stopping MEMCACHE Service Stopping ipa_memcached: [ OK ] Stopping KPASSWD Service Stopping Kerberos 5 Admin Server: [ OK ] Stopping KDC Service Stopping Kerberos 5 KDC: [ OK ] Stopping Directory Service Shutting down dirsrv: EXAMPLE-COM... [ OK ] PKI-IPA... [ OK ] 2. Edit 'dse.ldif' files to remove null ciphers - nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+ rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128 _sha,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha numSubordinates: 1 3. Start IPA - [root]# /etc/init.d/ipa start Starting Directory Service Starting dirsrv: EXAMPLE-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 ] 4. Run Scan. Null Ciphers detected again by Nessus - Here is the list of null SSL ciphers supported by the remote server : Null Ciphers (no encryption) TLSv1 NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 The fields above are : {OpenSSL ciphername} Port 389 / tcp / ldap 636 / tcp / ldap Ajeet Murty Deloitte & Touche LLP Tel: +1 571 882 5614 | Mobile: +1 704 421 8756 amurty at deloitte.com | www.deloitte.com -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Tuesday, October 07, 2014 10:19 AM To: Murty, Ajeet (US - Arlington); Alexander Bokovoy Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports Murty, Ajeet (US - Arlington) wrote: > Sorry, messed up copy paste, here is the edited section - > > nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+ > rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128 > _sha,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha > numSubordinates: 1 > > I double checked this time. No Null ciphers in dse.ldif files. > Still seeing the Null Cipher in scans. > Are you shutting down the server(s) before modifying dse.ldif or are you doing the changes online using ldapmodify? 389-ds writes dse.ldif during shutdown so if you make changes while the server is up and then restart it those changes will be lost. rob > > > -----Original Message----- > From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > Sent: Tuesday, October 07, 2014 6:13 AM > To: Murty, Ajeet (US - Arlington) > Cc: Martin Kosek; Nathan Kinder; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports > > On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >> I edited both ldif files to remove fortezza_null. Looks like this now - >> >> nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > Here I can still see +fortezza_null. > >> a_export1024_with_des_cbc_sha >> >> Ran the scan again, still seeing Null Cipher - >> >> TLSv1 >> NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 >> >> >> >> >> >> >> >> This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. >> >> v.E.1 >> >> >> -----Original Message----- >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> Sent: Tuesday, October 07, 2014 5:46 AM >> To: Murty, Ajeet (US - Arlington) >> Cc: Martin Kosek; Nathan Kinder; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports >> >> On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >>> Hi Martin and Nathan, >>> >>> Thank you for providing that info. >>> Unfortunately, my IPA server is running on CentOS, and the latest IPA version available through YUM is - 'ipa-server.i686 3.0.0-37.el6'. >>> The latest version of 389-DS through YUM is - '389-ds-base.i686 1.2.11.15-34.el6_5 '. >>> >>> Nessus scan had detected this null cipher - >>> TLSv1 >>> NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 >>> >>> I found 2 'dse.ldif' files on disk - >>> /etc/dirsrv/slapd-PKI-IPA/dse.ldif >>> /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif >>> >>> In each of them, I found this - >>> nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >>> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >>> rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >>> a_export1024_with_des_cbc_sha >>> >>> >>> So to disable null cipher, I removed 'rsa_null_md5' from that list - >>> nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >>> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >>> rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >>> a_export1024_with_des_cbc_sha >>> >>> I restarted the entire IPA stack, and ran the scan again, I am still seeing that Null Cipher. >>> >>> Any ideas on how to resolve this? >> I can see also fortezza_null in the above list, maybe you are getting >> into that one? >> >>> >>> -----Original Message----- >>> From: Martin Kosek [mailto:mkosek at redhat.com] >>> Sent: Tuesday, September 23, 2014 11:15 AM >>> To: Nathan Kinder; freeipa-users at redhat.com; Murty, Ajeet (US - Arlington) >>> Subject: 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-/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 >> >> -- >> / Alexander Bokovoy > From abokovoy at redhat.com Tue Oct 7 16:43:10 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 7 Oct 2014 19:43:10 +0300 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <013068C38BB187448B7AB350AE98B35B38D577FF@USNDC1453.us.deloitte.com> References: <013068C38BB187448B7AB350AE98B35B38D3AD93@USNDC1453.us.deloitte.com> <54208167.2040508@redhat.com> <54218E89.2060800@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F3A@USNDC1453.us.deloitte.com> <20141007094614.GX4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F66@USNDC1453.us.deloitte.com> <20141007101257.GA4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F99@USNDC1453.us.deloitte.com> <5433F638.306@redhat.com> <013068C38BB187448B7AB350AE98B35B38D577FF@USNDC1453.us.deloitte.com> Message-ID: <20141007164310.GH4683@redhat.com> On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >I was shutting down IPA before making any changes - > >1. Shutdown IPA - > >[root]# /etc/init.d/ipa stop >Stopping CA Service >Stopping pki-ca: [ OK ] >Stopping HTTP Service >Stopping httpd: [ OK ] >Stopping MEMCACHE Service >Stopping ipa_memcached: [ OK ] >Stopping KPASSWD Service >Stopping Kerberos 5 Admin Server: [ OK ] >Stopping KDC Service >Stopping Kerberos 5 KDC: [ OK ] >Stopping Directory Service >Shutting down dirsrv: > EXAMPLE-COM... [ OK ] > PKI-IPA... [ OK ] > >2. Edit 'dse.ldif' files to remove null ciphers - > >nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+ > rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128 > _sha,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha >numSubordinates: 1 I think Ludwig gave a good suggestion -- instead of removing them from the list, prefix the *_null ciphers with -, i.e. -rsa_null_md5, -fortezza_null. The way nsSSL3Ciphers attribute works, is by modifying default NSS ciphers list, with + and - to add and remove the ciphers accordingly. -- / Alexander Bokovoy From amurty at deloitte.com Tue Oct 7 16:59:53 2014 From: amurty at deloitte.com (Murty, Ajeet (US - Arlington)) Date: Tue, 7 Oct 2014 16:59:53 +0000 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <20141007164310.GH4683@redhat.com> References: <013068C38BB187448B7AB350AE98B35B38D3AD93@USNDC1453.us.deloitte.com> <54208167.2040508@redhat.com> <54218E89.2060800@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F3A@USNDC1453.us.deloitte.com> <20141007094614.GX4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F66@USNDC1453.us.deloitte.com> <20141007101257.GA4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F99@USNDC1453.us.deloitte.com> <5433F638.306@redhat.com> <013068C38BB187448B7AB350AE98B35B38D577FF@USNDC1453.us.deloitte.com> <20141007164310.GH4683@redhat.com> Message-ID: <013068C38BB187448B7AB350AE98B35B38D578B2@USNDC1453.us.deloitte.com> I shutdown IPA and modified both dse ldif files to look like this - nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs a_export1024_with_des_cbc_sha Then, when I try to start up IPA, I get this error message - [root]# /etc/init.d/ipa start Starting Directory Service Starting dirsrv: EXAMPLE-COM...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 116) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs a_export1024_with ...] [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 121) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. [FAILED] PKI-IPA...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 110) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs a_export1024_with ...] [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 115) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. [FAILED] This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. v.E.1 -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: Tuesday, October 07, 2014 12:43 PM To: Murty, Ajeet (US - Arlington) Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >I was shutting down IPA before making any changes - > >1. Shutdown IPA - > >[root]# /etc/init.d/ipa stop >Stopping CA Service >Stopping pki-ca: [ OK ] >Stopping HTTP Service >Stopping httpd: [ OK ] >Stopping MEMCACHE Service >Stopping ipa_memcached: [ OK ] >Stopping KPASSWD Service >Stopping Kerberos 5 Admin Server: [ OK ] >Stopping KDC Service >Stopping Kerberos 5 KDC: [ OK ] >Stopping Directory Service >Shutting down dirsrv: > EXAMPLE-COM... [ OK ] > PKI-IPA... [ OK ] > >2. Edit 'dse.ldif' files to remove null ciphers - > >nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+ > rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128 > _sha,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha >numSubordinates: 1 I think Ludwig gave a good suggestion -- instead of removing them from the list, prefix the *_null ciphers with -, i.e. -rsa_null_md5, -fortezza_null. The way nsSSL3Ciphers attribute works, is by modifying default NSS ciphers list, with + and - to add and remove the ciphers accordingly. -- / Alexander Bokovoy From abokovoy at redhat.com Tue Oct 7 17:07:37 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 7 Oct 2014 20:07:37 +0300 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <013068C38BB187448B7AB350AE98B35B38D578B2@USNDC1453.us.deloitte.com> References: <54218E89.2060800@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F3A@USNDC1453.us.deloitte.com> <20141007094614.GX4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F66@USNDC1453.us.deloitte.com> <20141007101257.GA4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F99@USNDC1453.us.deloitte.com> <5433F638.306@redhat.com> <013068C38BB187448B7AB350AE98B35B38D577FF@USNDC1453.us.deloitte.com> <20141007164310.GH4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D578B2@USNDC1453.us.deloitte.com> Message-ID: <20141007170737.GI4683@redhat.com> On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >I shutdown IPA and modified both dse ldif files to look like this - > > nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo > rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > a_export1024_with_des_cbc_sha > > >Then, when I try to start up IPA, I get this error message - > > [root]# /etc/init.d/ipa start > Starting Directory Service > Starting dirsrv: > EXAMPLE-COM...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed > [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn The lines above suggest that you actually separated nsSSL3Ciphers line from the entry itself. At least in my case it looks like this: dn: cn=encryption,cn=config objectClass: top objectClass: nsEncryptionConfig cn: encryption nsSSLSessionTimeout: 0 nsSSLClientAuth: allowed nsSSL2: off nsSSL3: off creatorsName: cn=server,cn=plugins,cn=config modifiersName: cn=directory manager createTimestamp: 20141001151245Z modifyTimestamp: 20141001151430Z nsSSL3Ciphers: +all allowWeakCipher: off numSubordinates: 1 note that it is part of cn=encryption,cn=config entry. You cannot separate attributes within the entry with empty lines because empty line finishes current entry and starts another one. > [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed > [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 116) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo > rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > a_export1024_with ...] > [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 121) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] > [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] > [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. > [FAILED] > PKI-IPA...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed > [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed > [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 110) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo > rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > a_export1024_with ...] > [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 115) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] > [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] > [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. > [FAILED] > > > > > > > >This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. > >v.E.1 > > >-----Original Message----- >From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >Sent: Tuesday, October 07, 2014 12:43 PM >To: Murty, Ajeet (US - Arlington) >Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com >Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports > >On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >>I was shutting down IPA before making any changes - >> >>1. Shutdown IPA - >> >>[root]# /etc/init.d/ipa stop >>Stopping CA Service >>Stopping pki-ca: [ OK ] >>Stopping HTTP Service >>Stopping httpd: [ OK ] >>Stopping MEMCACHE Service >>Stopping ipa_memcached: [ OK ] >>Stopping KPASSWD Service >>Stopping Kerberos 5 Admin Server: [ OK ] >>Stopping KDC Service >>Stopping Kerberos 5 KDC: [ OK ] >>Stopping Directory Service >>Shutting down dirsrv: >> EXAMPLE-COM... [ OK ] >> PKI-IPA... [ OK ] >> >>2. Edit 'dse.ldif' files to remove null ciphers - >> >>nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+ >> rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128 >> _sha,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha >>numSubordinates: 1 >I think Ludwig gave a good suggestion -- instead of removing them from >the list, prefix the *_null ciphers with -, i.e. -rsa_null_md5, -fortezza_null. >The way nsSSL3Ciphers attribute works, is by modifying default NSS >ciphers list, with + and - to add and remove the ciphers accordingly. > >-- >/ Alexander Bokovoy -- / Alexander Bokovoy From amurty at deloitte.com Tue Oct 7 17:21:04 2014 From: amurty at deloitte.com (Murty, Ajeet (US - Arlington)) Date: Tue, 7 Oct 2014 17:21:04 +0000 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <20141007170737.GI4683@redhat.com> References: <54218E89.2060800@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F3A@USNDC1453.us.deloitte.com> <20141007094614.GX4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F66@USNDC1453.us.deloitte.com> <20141007101257.GA4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F99@USNDC1453.us.deloitte.com> <5433F638.306@redhat.com> <013068C38BB187448B7AB350AE98B35B38D577FF@USNDC1453.us.deloitte.com> <20141007164310.GH4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D578B2@USNDC1453.us.deloitte.com> <20141007170737.GI4683@redhat.com> Message-ID: <013068C38BB187448B7AB350AE98B35B38D578EC@USNDC1453.us.deloitte.com> I removed the new lines, looks like this now - modifyTimestamp: 20140915221826Z nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs a_export1024_with_des_cbc_sha numSubordinates: 1 I am still seeing the null ciphers in my scan results. -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: Tuesday, October 07, 2014 1:08 PM To: Murty, Ajeet (US - Arlington) Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >I shutdown IPA and modified both dse ldif files to look like this - > > nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo > rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > a_export1024_with_des_cbc_sha > > >Then, when I try to start up IPA, I get this error message - > > [root]# /etc/init.d/ipa start > Starting Directory Service > Starting dirsrv: > EXAMPLE-COM...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed > [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn The lines above suggest that you actually separated nsSSL3Ciphers line from the entry itself. At least in my case it looks like this: dn: cn=encryption,cn=config objectClass: top objectClass: nsEncryptionConfig cn: encryption nsSSLSessionTimeout: 0 nsSSLClientAuth: allowed nsSSL2: off nsSSL3: off creatorsName: cn=server,cn=plugins,cn=config modifiersName: cn=directory manager createTimestamp: 20141001151245Z modifyTimestamp: 20141001151430Z nsSSL3Ciphers: +all allowWeakCipher: off numSubordinates: 1 note that it is part of cn=encryption,cn=config entry. You cannot separate attributes within the entry with empty lines because empty line finishes current entry and starts another one. > [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed > [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 116) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo > rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > a_export1024_with ...] > [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 121) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] > [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] > [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. > [FAILED] > PKI-IPA...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed > [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed > [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 110) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo > rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > a_export1024_with ...] > [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 115) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] > [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] > [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. > [FAILED] > > > > > > > >This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. > >v.E.1 > > >-----Original Message----- >From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >Sent: Tuesday, October 07, 2014 12:43 PM >To: Murty, Ajeet (US - Arlington) >Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com >Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports > >On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >>I was shutting down IPA before making any changes - >> >>1. Shutdown IPA - >> >>[root]# /etc/init.d/ipa stop >>Stopping CA Service >>Stopping pki-ca: [ OK ] >>Stopping HTTP Service >>Stopping httpd: [ OK ] >>Stopping MEMCACHE Service >>Stopping ipa_memcached: [ OK ] >>Stopping KPASSWD Service >>Stopping Kerberos 5 Admin Server: [ OK ] >>Stopping KDC Service >>Stopping Kerberos 5 KDC: [ OK ] >>Stopping Directory Service >>Shutting down dirsrv: >> EXAMPLE-COM... [ OK ] >> PKI-IPA... [ OK ] >> >>2. Edit 'dse.ldif' files to remove null ciphers - >> >>nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+ >> rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128 >> _sha,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha >>numSubordinates: 1 >I think Ludwig gave a good suggestion -- instead of removing them from >the list, prefix the *_null ciphers with -, i.e. -rsa_null_md5, -fortezza_null. >The way nsSSL3Ciphers attribute works, is by modifying default NSS >ciphers list, with + and - to add and remove the ciphers accordingly. > >-- >/ Alexander Bokovoy -- / Alexander Bokovoy From licause at hp.com Tue Oct 7 21:03:20 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Tue, 7 Oct 2014 21:03:20 +0000 Subject: [Freeipa-users] domain trust linux to AD server not finding user profiles Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C7E6A@G5W2742.americas.hpqcorp.net> I've been following the steps outlined in section 7.3.5 of the manual entitled Integrating OpenShift Enterprise with Identity Management (IdM) in Red Hat Enterprise Linux OpenShift Enterprise 2.1 IdM in Red Hat Enterprise Linux 7 Windows Server 2012 - Active Directory Integration I now have our RHEL V7 running IdM, setup as an IdM Server in a domain, Realm and subnet different from our existing AD server running Windows 2008 R2 with a populated user database that can be queried using ldapsearch and can authorize users. I have successfully created a domain trust between the RHEL V7 Server (linux.ipa.cxo.cpqcorp.net 10.20.0.59/24) and the AD Server (win2008.osn.cxo.cpqcorp.net 16.112.240.55). To simplify the configuration I have no firewall running and so have stopped both iptables and firewalld. All steps in section 7.3.5 have been followed. But when I run the first test for a user on the AD system, the system is unable to find anything: [root at linux ~]# getent group 'OSN\Domain Users' [root at linux ~]# [root at linux ~]# [root at linux ~]# getent passwd 'OSN\ldap25' [root at linux ~]# I find this in the krb5kdc.log file: Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.20.0.59: NEEDED_PREAUTH: host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET for krbtgt/IPA.CXO.CPQCORP.NET at IPA.CXO.CPQCORP.NET, Additional pre-authentication required Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.20.0.59: ISSUE: authtime 1412713681, etypes {rep=18 tkt=18 ses=18}, host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET for krbtgt/IPA.CXO.CPQCORP.NET at IPA.CXO.CPQCORP.NET Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) 10.20.0.59: ISSUE: authtime 1412713681, etypes {rep=18 tkt=18 ses=18}, host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET for ldap/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): closing down fd 11 I'm not quite sure what else I'm missing or have not understood in order to query the AD server from the linux IdM server...but it would appear that something is not correctly defined in the krb5.conf file found below: [root at linux ~]# cat /etc/krb5.conf includedir /var/lib/sss/pubconf/krb5.include.d/ [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = IPA.CXO.CPQCORP.NET dns_lookup_realm = false dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes default_ccache_name = KEYRING:persistent:%{uid} [realms] IPA.CXO.CPQCORP.NET = { kdc = linux.ipa.cxo.cpqcorp.net:88 master_kdc = linux.ipa.cxo.cpqcorp.net:88 admin_server = linux.ipa.cxo.cpqcorp.net:749 default_domain = ipa.cxo.cpqcorp.net pkinit_anchors = FILE:/etc/ipa/ca.crt auth_to_local = RULE:[1:$1@$0](^.*@OSN.CXO.CPQCORP.NET$)s/@OSN.CXO.CPQCORP.NET/@osn.cxo.cpqcorp.net/ auth_to_local = DEFAULT } OSN.CXO.CPQCORP.NET = { kdc = win2008.osn.cxo.cpqcorp.net master_kdc = win2008.osn.cxo.cpqcorp.net admin_sever = win2008.osn.cxo.cpqcorp.net } [domain_realm] .ipa.cxo.cpqcorp.net = IPA.CXO.CPQCORP.NET ipa.cxo.cpqcorp.net = IPA.CXO.CPQCORP.NET .osn.cxo.cpqcorp.net = OSN.CXO.CPQCORP.NET osn.cxo.cpqcorp.net = OSN.CXO.CPQCORP.NET [dbmodules] IPA.CXO.CPQCORP.NET = { db_library = ipadb.so } Any help greatly appreciated. Al Al Licause CSC Americas BCS Technical Specialist HP Customer Support Center Hours 5am-2pm Pacific time USA Manager: mark.bailey at hp.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2051 bytes Desc: image001.gif URL: From dpal at redhat.com Tue Oct 7 23:54:10 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 07 Oct 2014 19:54:10 -0400 Subject: [Freeipa-users] GNOME Project moved to FreeIPA for managing its account information In-Reply-To: References: <20141007095809.GY4683@redhat.com> Message-ID: <54347D22.6050203@redhat.com> On 10/07/2014 09:27 AM, James wrote: > On 7 October 2014 05:58, Alexander Bokovoy wrote: >> Hi! >> >> As Andrea Veri describes in the blog[1], GNOME Project's infrastructure >> is now powered by FreeIPA. While GNOME was already using SSSD since very >> early days of SSSD project, move to FreeIPA on the server side took more >> time. > Yup :) I wonder who convinced him to look at FreeIPA... Hrmm ;) Motherland should know its heros! ;-) > >> [1] >> https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/ >> >> -- >> / Alexander Bokovoy >> >> -- >> 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. From dpal at redhat.com Wed Oct 8 00:01:48 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 07 Oct 2014 20:01:48 -0400 Subject: [Freeipa-users] domain trust linux to AD server not finding user profiles In-Reply-To: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C7E6A@G5W2742.americas.hpqcorp.net> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C7E6A@G5W2742.americas.hpqcorp.net> Message-ID: <54347EEC.8070302@redhat.com> On 10/07/2014 05:03 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > > I've been following the steps outlined in section 7.3.5 of the manual > entitled > > Integrating OpenShift Enterprise > > with Identity Management (IdM) > > in Red Hat Enterprise Linux > > OpenShift Enterprise 2.1 > > IdM in Red Hat Enterprise Linux 7 > > Windows Server 2012 - Active Directory Integration > > I now have our RHEL V7 running IdM, setup as an IdM Server in a > domain, Realm and subnet > > different from our existing AD server running Windows 2008 R2 with a > populated user database > > that can be queried using ldapsearch and can authorize users. > > I have successfully created a domain trust between the RHEL V7 Server > > (linux.ipa.cxo.cpqcorp.net 10.20.0.59/24) and the AD Server > > (win2008.osn.cxo.cpqcorp.net 16.112.240.55). > > To simplify the configuration I have no firewall running and so have > stopped both iptables > > and firewalld. > > All steps in section 7.3.5 have been followed. But when I run the > first test for a user > > on the AD system, the system is unable to find anything: > > [root at linux ~]# getent group 'OSN\Domain Users' > > [root at linux ~]# > > [root at linux ~]# > > [root at linux ~]# getent passwd 'OSN\ldap25' > > [root at linux ~]# > The users and related information are not fetched until you authenticate as this user. The ability to fetch users and groups that are not yet authenticated is tracked by the ticket https://fedorahosted.org/sssd/ticket/2159 and will be addressed in the next version of SSSD. How frequently do you really need to lookup unauthenticated AD users and AD groups on linux systems? What is the use case? The ticket above is for the cases when there is an application that needs to fetch the user so that admin of the application can assign privileges to this user. But this is a pretty corner case. > I find this in the krb5kdc.log file: > > Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): AS_REQ > (6 etypes {18 17 16 23 25 26}) 10.20.0.59: NEEDED_PREAUTH: > host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET for > krbtgt/IPA.CXO.CPQCORP.NET at IPA.CXO.CPQCORP.NET, Additional > pre-authentication required > > Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): AS_REQ > (6 etypes {18 17 16 23 25 26}) 10.20.0.59: ISSUE: authtime 1412713681, > etypes {rep=18 tkt=18 ses=18}, > host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET for > krbtgt/IPA.CXO.CPQCORP.NET at IPA.CXO.CPQCORP.NET > > Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): > TGS_REQ (6 etypes {18 17 16 23 25 26}) 10.20.0.59: ISSUE: authtime > 1412713681, etypes {rep=18 tkt=18 ses=18}, > host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET for > ldap/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET > > Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): > closing down fd 11 > > I'm not quite sure what else I'm missing or have not understood in > order to query the > > AD server from the linux IdM server...but it would appear that > something is not correctly > > defined in the krb5.conf file found below: > > [root at linux ~]# cat /etc/krb5.conf > > includedir /var/lib/sss/pubconf/krb5.include.d/ > > [logging] > > default = FILE:/var/log/krb5libs.log > > kdc = FILE:/var/log/krb5kdc.log > > admin_server = FILE:/var/log/kadmind.log > > [libdefaults] > > default_realm = IPA.CXO.CPQCORP.NET > > dns_lookup_realm = false > > dns_lookup_kdc = true > > rdns = false > > ticket_lifetime = 24h > > forwardable = yes > > default_ccache_name = KEYRING:persistent:%{uid} > > [realms] > > IPA.CXO.CPQCORP.NET = { > > kdc = linux.ipa.cxo.cpqcorp.net:88 > > master_kdc = linux.ipa.cxo.cpqcorp.net:88 > > admin_server = linux.ipa.cxo.cpqcorp.net:749 > > default_domain = ipa.cxo.cpqcorp.net > > pkinit_anchors = FILE:/etc/ipa/ca.crt > > auth_to_local = > RULE:[1:$1@$0](^.*@OSN.CXO.CPQCORP.NET$)s/@OSN.CXO.CPQCORP.NET/@osn.cxo.cpqcorp.net/ > auth_to_local = DEFAULT > > } > > OSN.CXO.CPQCORP.NET = { > > kdc = win2008.osn.cxo.cpqcorp.net > > master_kdc = win2008.osn.cxo.cpqcorp.net > > admin_sever = win2008.osn.cxo.cpqcorp.net > > } > > [domain_realm] > > .ipa.cxo.cpqcorp.net = IPA.CXO.CPQCORP.NET > > ipa.cxo.cpqcorp.net = IPA.CXO.CPQCORP.NET > > .osn.cxo.cpqcorp.net = OSN.CXO.CPQCORP.NET > > osn.cxo.cpqcorp.net = OSN.CXO.CPQCORP.NET > > [dbmodules] > > IPA.CXO.CPQCORP.NET = { > > db_library = ipadb.so > > } > > Any help greatly appreciated. > > Al > > *Al Licause* > > *CSC Americas BCS Technical Specialist* > > *HP Customer Support Center* > > *Hours 5am-2pm Pacific time USA* > > *Manager: mark.bailey at hp.com* > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2051 bytes Desc: not available URL: From genadipost at gmail.com Wed Oct 8 00:42:47 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Wed, 8 Oct 2014 02:42:47 +0200 Subject: [Freeipa-users] Error: invalid 'AD domain controller' when establishing trust Message-ID: Hello. I am attempting to create trust between AD and IPA. I have deployed AD environment as follows: I have created domain RED.COM Then i add new domain tree root - BLUE.COM. Now i would like to establish trust with IPA as a sub domain (LINUX.BLUE.COM) of BLUE.COM. I followed the guide and when reaching to trust agreement creation i stumbled into this error: ipa trust-add --type=ad blue.com --admin Administrator --password Active directory domain administrator's password: ipa: ERROR: invalid 'AD domain controller': unsupported functional level Both AD server are 2008 R2. IPA version is 3.3, installed on RHEL 7. Help will be appreciated. Genadi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From purpleidea at gmail.com Wed Oct 8 01:33:16 2014 From: purpleidea at gmail.com (James) Date: Tue, 7 Oct 2014 21:33:16 -0400 Subject: [Freeipa-users] GNOME Project moved to FreeIPA for managing its account information In-Reply-To: <54347D22.6050203@redhat.com> References: <20141007095809.GY4683@redhat.com> <54347D22.6050203@redhat.com> Message-ID: On 7 October 2014 19:54, Dmitri Pal wrote: > On 10/07/2014 09:27 AM, James wrote: >> >> On 7 October 2014 05:58, Alexander Bokovoy wrote: >>> >>> Hi! >>> >>> As Andrea Veri describes in the blog[1], GNOME Project's infrastructure >>> is now powered by FreeIPA. While GNOME was already using SSSD since very >>> early days of SSSD project, move to FreeIPA on the server side took more >>> time. >> >> Yup :) I wonder who convinced him to look at FreeIPA... Hrmm ;) > > > Motherland should know its heros! ;-) > Your team are the heros. I'm just an integrator who likes your code... and maybe has a few feature requests :) >> >>> [1] >>> >>> https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/ >>> >>> -- >>> / Alexander Bokovoy >>> >>> -- >>> 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 From ftweedal at redhat.com Wed Oct 8 01:55:54 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 8 Oct 2014 11:55:54 +1000 Subject: [Freeipa-users] GNOME Project moved to FreeIPA for managing its account information In-Reply-To: <20141007095809.GY4683@redhat.com> References: <20141007095809.GY4683@redhat.com> Message-ID: <20141008015554.GT5346@dhcp-40-8.bne.redhat.com> On Tue, Oct 07, 2014 at 12:58:09PM +0300, Alexander Bokovoy wrote: > Hi! > > As Andrea Veri describes in the blog[1], GNOME Project's infrastructure > is now powered by FreeIPA. While GNOME was already using SSSD since very > early days of SSSD project, move to FreeIPA on the server side took more > time. > > [1] https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/ > > -- > / Alexander Bokovoy > This is great. Can we use the GNOME project's experience as a story or case study in promoting FreeIPA to other projects/communities? IMO we need a couple of examples like this on the freeipa.org front page. Fraser > -- > 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 From dpal at redhat.com Wed Oct 8 03:29:46 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 07 Oct 2014 23:29:46 -0400 Subject: [Freeipa-users] GNOME Project moved to FreeIPA for managing its account information In-Reply-To: <20141008015554.GT5346@dhcp-40-8.bne.redhat.com> References: <20141007095809.GY4683@redhat.com> <20141008015554.GT5346@dhcp-40-8.bne.redhat.com> Message-ID: <5434AFAA.3070202@redhat.com> On 10/07/2014 09:55 PM, Fraser Tweedale wrote: > On Tue, Oct 07, 2014 at 12:58:09PM +0300, Alexander Bokovoy wrote: >> Hi! >> >> As Andrea Veri describes in the blog[1], GNOME Project's infrastructure >> is now powered by FreeIPA. While GNOME was already using SSSD since very >> early days of SSSD project, move to FreeIPA on the server side took more >> time. >> >> [1] https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/ >> >> -- >> / Alexander Bokovoy >> > This is great. Can we use the GNOME project's experience as a story > or case study in promoting FreeIPA to other projects/communities? > IMO we need a couple of examples like this on the freeipa.org front > page. Sure. > Fraser > >> -- >> 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. From purpleidea at gmail.com Wed Oct 8 04:04:39 2014 From: purpleidea at gmail.com (James) Date: Wed, 8 Oct 2014 00:04:39 -0400 Subject: [Freeipa-users] GNOME Project moved to FreeIPA for managing its account information In-Reply-To: <20141008015554.GT5346@dhcp-40-8.bne.redhat.com> References: <20141007095809.GY4683@redhat.com> <20141008015554.GT5346@dhcp-40-8.bne.redhat.com> Message-ID: On 7 October 2014 21:55, Fraser Tweedale wrote: > This is great. Can we use the GNOME project's experience as a story > or case study in promoting FreeIPA to other projects/communities? > IMO we need a couple of examples like this on the freeipa.org front > page. I would recommend waiting a little bit to let them get more familiar with the tool... From amurty at deloitte.com Wed Oct 8 04:15:34 2014 From: amurty at deloitte.com (Murty, Ajeet (US - Arlington)) Date: Wed, 8 Oct 2014 04:15:34 +0000 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <013068C38BB187448B7AB350AE98B35B38D578EC@USNDC1453.us.deloitte.com> References: <54218E89.2060800@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F3A@USNDC1453.us.deloitte.com> <20141007094614.GX4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F66@USNDC1453.us.deloitte.com> <20141007101257.GA4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F99@USNDC1453.us.deloitte.com> <5433F638.306@redhat.com> <013068C38BB187448B7AB350AE98B35B38D577FF@USNDC1453.us.deloitte.com> <20141007164310.GH4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D578B2@USNDC1453.us.deloitte.com> <20141007170737.GI4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D578EC@USNDC1453.us.deloitte.com> Message-ID: <013068C38BB187448B7AB350AE98B35B38D58298@USNDC1453.us.deloitte.com> Any ideas on what else I can try here? Also, can we expect the new IPA and DS to be available in the CentOS/YUM repository in the next few weeks/months? Thanks again for all your help. -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Murty, Ajeet (US - Arlington) Sent: Tuesday, October 07, 2014 1:21 PM To: Alexander Bokovoy Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports I removed the new lines, looks like this now - modifyTimestamp: 20140915221826Z nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs a_export1024_with_des_cbc_sha numSubordinates: 1 I am still seeing the null ciphers in my scan results. -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: Tuesday, October 07, 2014 1:08 PM To: Murty, Ajeet (US - Arlington) Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >I shutdown IPA and modified both dse ldif files to look like this - > > nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo > rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > a_export1024_with_des_cbc_sha > > >Then, when I try to start up IPA, I get this error message - > > [root]# /etc/init.d/ipa start > Starting Directory Service > Starting dirsrv: > EXAMPLE-COM...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed > [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn The lines above suggest that you actually separated nsSSL3Ciphers line from the entry itself. At least in my case it looks like this: dn: cn=encryption,cn=config objectClass: top objectClass: nsEncryptionConfig cn: encryption nsSSLSessionTimeout: 0 nsSSLClientAuth: allowed nsSSL2: off nsSSL3: off creatorsName: cn=server,cn=plugins,cn=config modifiersName: cn=directory manager createTimestamp: 20141001151245Z modifyTimestamp: 20141001151430Z nsSSL3Ciphers: +all allowWeakCipher: off numSubordinates: 1 note that it is part of cn=encryption,cn=config entry. You cannot separate attributes within the entry with empty lines because empty line finishes current entry and starts another one. > [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed > [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 116) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo > rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > a_export1024_with ...] > [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 121) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] > [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] > [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. > [FAILED] > PKI-IPA...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed > [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed > [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 110) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo > rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > a_export1024_with ...] > [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 115) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. > [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] > [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] > [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. > [FAILED] > > > > > > > >This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. > >v.E.1 > > >-----Original Message----- >From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >Sent: Tuesday, October 07, 2014 12:43 PM >To: Murty, Ajeet (US - Arlington) >Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com >Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports > >On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >>I was shutting down IPA before making any changes - >> >>1. Shutdown IPA - >> >>[root]# /etc/init.d/ipa stop >>Stopping CA Service >>Stopping pki-ca: [ OK ] >>Stopping HTTP Service >>Stopping httpd: [ OK ] >>Stopping MEMCACHE Service >>Stopping ipa_memcached: [ OK ] >>Stopping KPASSWD Service >>Stopping Kerberos 5 Admin Server: [ OK ] >>Stopping KDC Service >>Stopping Kerberos 5 KDC: [ OK ] >>Stopping Directory Service >>Shutting down dirsrv: >> EXAMPLE-COM... [ OK ] >> PKI-IPA... [ OK ] >> >>2. Edit 'dse.ldif' files to remove null ciphers - >> >>nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+ >> rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128 >> _sha,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha >>numSubordinates: 1 >I think Ludwig gave a good suggestion -- instead of removing them from >the list, prefix the *_null ciphers with -, i.e. -rsa_null_md5, -fortezza_null. >The way nsSSL3Ciphers attribute works, is by modifying default NSS >ciphers list, with + and - to add and remove the ciphers accordingly. > >-- >/ Alexander Bokovoy -- / Alexander Bokovoy -- 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 From rmeggins at redhat.com Wed Oct 8 04:36:37 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 07 Oct 2014 22:36:37 -0600 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <013068C38BB187448B7AB350AE98B35B38D58298@USNDC1453.us.deloitte.com> References: <54218E89.2060800@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F3A@USNDC1453.us.deloitte.com> <20141007094614.GX4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F66@USNDC1453.us.deloitte.com> <20141007101257.GA4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F99@USNDC1453.us.deloitte.com> <5433F638.306@redhat.com> <013068C38BB187448B7AB350AE98B35B38D577FF@USNDC1453.us.deloitte.com> <20141007164310.GH4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D578B2@USNDC1453.us.deloitte.com> <20141007170737.GI4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D578EC@USNDC1453.us.deloitte.com> <013068C38BB187448B7AB350AE98B35B38D58298@USNDC1453.us.deloitte.com> Message-ID: <5434BF55.9080308@redhat.com> On 10/07/2014 10:15 PM, Murty, Ajeet (US - Arlington) wrote: > Any ideas on what else I can try here? Please file a ticket. > Also, can we expect the new IPA and DS to be available in the CentOS/YUM repository in the next few weeks/months? > > Thanks again for all your help. > > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Murty, Ajeet (US - Arlington) > Sent: Tuesday, October 07, 2014 1:21 PM > To: Alexander Bokovoy > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports > > I removed the new lines, looks like this now - > > modifyTimestamp: 20140915221826Z > nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo > rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > a_export1024_with_des_cbc_sha > numSubordinates: 1 > > I am still seeing the null ciphers in my scan results. > > > > -----Original Message----- > From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > Sent: Tuesday, October 07, 2014 1:08 PM > To: Murty, Ajeet (US - Arlington) > Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports > > On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >> I shutdown IPA and modified both dse ldif files to look like this - >> >> nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >> a_export1024_with_des_cbc_sha >> >> >> Then, when I try to start up IPA, I get this error message - >> >> [root]# /etc/init.d/ipa start >> Starting Directory Service >> Starting dirsrv: >> EXAMPLE-COM...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > The lines above suggest that you actually separated nsSSL3Ciphers line > from the entry itself. At least in my case it looks like this: > > dn: cn=encryption,cn=config > objectClass: top > objectClass: nsEncryptionConfig > cn: encryption > nsSSLSessionTimeout: 0 > nsSSLClientAuth: allowed > nsSSL2: off > nsSSL3: off > creatorsName: cn=server,cn=plugins,cn=config > modifiersName: cn=directory manager > createTimestamp: 20141001151245Z > modifyTimestamp: 20141001151430Z > nsSSL3Ciphers: +all > allowWeakCipher: off > numSubordinates: 1 > > note that it is part of cn=encryption,cn=config entry. You cannot > separate attributes within the entry with empty lines because empty line > finishes current entry and starts another one. > >> [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 116) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >> a_export1024_with ...] >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 121) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] >> [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] >> [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. >> [FAILED] >> PKI-IPA...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 110) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >> a_export1024_with ...] >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 115) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] >> [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] >> [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. >> [FAILED] >> >> >> >> >> >> >> >> This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. >> >> v.E.1 >> >> >> -----Original Message----- >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> Sent: Tuesday, October 07, 2014 12:43 PM >> To: Murty, Ajeet (US - Arlington) >> Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports >> >> On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >>> I was shutting down IPA before making any changes - >>> >>> 1. Shutdown IPA - >>> >>> [root]# /etc/init.d/ipa stop >>> Stopping CA Service >>> Stopping pki-ca: [ OK ] >>> Stopping HTTP Service >>> Stopping httpd: [ OK ] >>> Stopping MEMCACHE Service >>> Stopping ipa_memcached: [ OK ] >>> Stopping KPASSWD Service >>> Stopping Kerberos 5 Admin Server: [ OK ] >>> Stopping KDC Service >>> Stopping Kerberos 5 KDC: [ OK ] >>> Stopping Directory Service >>> Shutting down dirsrv: >>> EXAMPLE-COM... [ OK ] >>> PKI-IPA... [ OK ] >>> >>> 2. Edit 'dse.ldif' files to remove null ciphers - >>> >>> nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+ >>> rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128 >>> _sha,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha >>> numSubordinates: 1 >> I think Ludwig gave a good suggestion -- instead of removing them from >> the list, prefix the *_null ciphers with -, i.e. -rsa_null_md5, -fortezza_null. >> The way nsSSL3Ciphers attribute works, is by modifying default NSS >> ciphers list, with + and - to add and remove the ciphers accordingly. >> >> -- >> / Alexander Bokovoy From amurty at deloitte.com Wed Oct 8 05:08:39 2014 From: amurty at deloitte.com (Murty, Ajeet (US - Arlington)) Date: Wed, 8 Oct 2014 05:08:39 +0000 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <5434BF55.9080308@redhat.com> References: <54218E89.2060800@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F3A@USNDC1453.us.deloitte.com> <20141007094614.GX4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F66@USNDC1453.us.deloitte.com> <20141007101257.GA4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F99@USNDC1453.us.deloitte.com> <5433F638.306@redhat.com> <013068C38BB187448B7AB350AE98B35B38D577FF@USNDC1453.us.deloitte.com> <20141007164310.GH4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D578B2@USNDC1453.us.deloitte.com> <20141007170737.GI4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D578EC@USNDC1453.us.deloitte.com> <013068C38BB187448B7AB350AE98B35B38D58298@USNDC1453.us.deloitte.com> <5434BF55.9080308@redhat.com> Message-ID: <013068C38BB187448B7AB350AE98B35B38D5833F@USNDC1453.us.deloitte.com> Done. 'Bug 1150368 -Unable to disable Null Ciphers on 389-Directory-Server using nsSSL3Ciphers in Ldif ' https://bugzilla.redhat.com/show_bug.cgi?id=1150368 Thanks. -----Original Message----- From: Rich Megginson [mailto:rmeggins at redhat.com] Sent: Wednesday, October 08, 2014 12:37 AM To: Murty, Ajeet (US - Arlington); Alexander Bokovoy; Rob Crittenden Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports On 10/07/2014 10:15 PM, Murty, Ajeet (US - Arlington) wrote: > Any ideas on what else I can try here? Please file a ticket. > Also, can we expect the new IPA and DS to be available in the CentOS/YUM repository in the next few weeks/months? > > Thanks again for all your help. > > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Murty, Ajeet (US - Arlington) > Sent: Tuesday, October 07, 2014 1:21 PM > To: Alexander Bokovoy > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports > > I removed the new lines, looks like this now - > > modifyTimestamp: 20140915221826Z > nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo > rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > a_export1024_with_des_cbc_sha > numSubordinates: 1 > > I am still seeing the null ciphers in my scan results. > > > > -----Original Message----- > From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > Sent: Tuesday, October 07, 2014 1:08 PM > To: Murty, Ajeet (US - Arlington) > Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports > > On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >> I shutdown IPA and modified both dse ldif files to look like this - >> >> nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >> a_export1024_with_des_cbc_sha >> >> >> Then, when I try to start up IPA, I get this error message - >> >> [root]# /etc/init.d/ipa start >> Starting Directory Service >> Starting dirsrv: >> EXAMPLE-COM...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn > The lines above suggest that you actually separated nsSSL3Ciphers line > from the entry itself. At least in my case it looks like this: > > dn: cn=encryption,cn=config > objectClass: top > objectClass: nsEncryptionConfig > cn: encryption > nsSSLSessionTimeout: 0 > nsSSLClientAuth: allowed > nsSSL2: off > nsSSL3: off > creatorsName: cn=server,cn=plugins,cn=config > modifiersName: cn=directory manager > createTimestamp: 20141001151245Z > modifyTimestamp: 20141001151430Z > nsSSL3Ciphers: +all > allowWeakCipher: off > numSubordinates: 1 > > note that it is part of cn=encryption,cn=config entry. You cannot > separate attributes within the entry with empty lines because empty line > finishes current entry and starts another one. > >> [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 116) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >> a_export1024_with ...] >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 121) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] >> [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] >> [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. >> [FAILED] >> PKI-IPA...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 110) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >> a_export1024_with ...] >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 115) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] >> [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] >> [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. >> [FAILED] >> >> >> >> >> >> >> >> This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. >> >> v.E.1 >> >> >> -----Original Message----- >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> Sent: Tuesday, October 07, 2014 12:43 PM >> To: Murty, Ajeet (US - Arlington) >> Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports >> >> On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >>> I was shutting down IPA before making any changes - >>> >>> 1. Shutdown IPA - >>> >>> [root]# /etc/init.d/ipa stop >>> Stopping CA Service >>> Stopping pki-ca: [ OK ] >>> Stopping HTTP Service >>> Stopping httpd: [ OK ] >>> Stopping MEMCACHE Service >>> Stopping ipa_memcached: [ OK ] >>> Stopping KPASSWD Service >>> Stopping Kerberos 5 Admin Server: [ OK ] >>> Stopping KDC Service >>> Stopping Kerberos 5 KDC: [ OK ] >>> Stopping Directory Service >>> Shutting down dirsrv: >>> EXAMPLE-COM... [ OK ] >>> PKI-IPA... [ OK ] >>> >>> 2. Edit 'dse.ldif' files to remove null ciphers - >>> >>> nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+ >>> rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128 >>> _sha,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha >>> numSubordinates: 1 >> I think Ludwig gave a good suggestion -- instead of removing them from >> the list, prefix the *_null ciphers with -, i.e. -rsa_null_md5, -fortezza_null. >> The way nsSSL3Ciphers attribute works, is by modifying default NSS >> ciphers list, with + and - to add and remove the ciphers accordingly. >> >> -- >> / Alexander Bokovoy From abokovoy at redhat.com Wed Oct 8 06:00:47 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 8 Oct 2014 09:00:47 +0300 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <013068C38BB187448B7AB350AE98B35B38D58298@USNDC1453.us.deloitte.com> References: <013068C38BB187448B7AB350AE98B35B38D56F66@USNDC1453.us.deloitte.com> <20141007101257.GA4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F99@USNDC1453.us.deloitte.com> <5433F638.306@redhat.com> <013068C38BB187448B7AB350AE98B35B38D577FF@USNDC1453.us.deloitte.com> <20141007164310.GH4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D578B2@USNDC1453.us.deloitte.com> <20141007170737.GI4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D578EC@USNDC1453.us.deloitte.com> <013068C38BB187448B7AB350AE98B35B38D58298@USNDC1453.us.deloitte.com> Message-ID: <20141008060047.GA2328@redhat.com> On Wed, 08 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >Any ideas on what else I can try here? >Also, can we expect the new IPA and DS to be available in the CentOS/YUM repository in the next few weeks/months? In general, FreeIPA team doesn't do backports to older versions due to tight cooperation with other components when introducing new features. We depend a lot on changes in 389-ds, Dogtag, MIT Kerberos, and SSSD, at least, but also in Samba and other components, including Linux kernel. Backporting all the changes to older releases of certain distributions is left to distribution maintainers. For Fedora we do have some freedom on what can be done and try to maintain availability of FreeIPA releases on two current versions but sometimes it is impossible due to update polices -- Fedora 20 got 4.0.x upgrade via COPR repository while we are cleaning up Fedora 21 for 4.1 support. In case of Red Hat Enterprise Linux releases, Red Hat itself (I cannot speak for the company) makes decisions what to support and these decisions are also based on certain stability promises for ABI, see https://access.redhat.com/solutions/5154 for details. Some of components FreeIPA depends on change their ABI and therefore the changes can only be introduced in newer major releases. When these changes occurred, we coordinated with Red Hat engineering teams to make sure most important changes were folded into RHEL 7.0 release to provide a base for FreeIPA integration. For CentOS, as it tracks corresponding Red Hat Enterprise Linux releases, situation is similar. For packages that are not in RHEL/CentOS releases there are means to provide them through a side channels, like EPEL, but EPEL's policy prevents from packaging something that is available through the main channels for the release. We use COPR repositories to make possible to install newer FreeIPA versions on RHEL 7/CentOS 7/Fedora 20. However, these packages have no official support from Red Hat or CentOS project. They are FreeIPA upstream effort to make our releases more easily testable. For any issues found through COPR repositories you are welcome to file tickets to FreeIPA issue tracker at https://fedorahosted.org/freeipa/. > >Thanks again for all your help. > > >-----Original Message----- >From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Murty, Ajeet (US - Arlington) >Sent: Tuesday, October 07, 2014 1:21 PM >To: Alexander Bokovoy >Cc: freeipa-users at redhat.com >Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports > >I removed the new lines, looks like this now - > >modifyTimestamp: 20140915221826Z >nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo > rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > a_export1024_with_des_cbc_sha >numSubordinates: 1 > >I am still seeing the null ciphers in my scan results. > > > >-----Original Message----- >From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >Sent: Tuesday, October 07, 2014 1:08 PM >To: Murty, Ajeet (US - Arlington) >Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com >Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports > >On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >>I shutdown IPA and modified both dse ldif files to look like this - >> >> nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >> a_export1024_with_des_cbc_sha >> >> >>Then, when I try to start up IPA, I get this error message - >> >> [root]# /etc/init.d/ipa start >> Starting Directory Service >> Starting dirsrv: >> EXAMPLE-COM...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >The lines above suggest that you actually separated nsSSL3Ciphers line >from the entry itself. At least in my case it looks like this: > >dn: cn=encryption,cn=config >objectClass: top >objectClass: nsEncryptionConfig >cn: encryption >nsSSLSessionTimeout: 0 >nsSSLClientAuth: allowed >nsSSL2: off >nsSSL3: off >creatorsName: cn=server,cn=plugins,cn=config >modifiersName: cn=directory manager >createTimestamp: 20141001151245Z >modifyTimestamp: 20141001151430Z >nsSSL3Ciphers: +all >allowWeakCipher: off >numSubordinates: 1 > >note that it is part of cn=encryption,cn=config entry. You cannot >separate attributes within the entry with empty lines because empty line >finishes current entry and starts another one. > >> [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 116) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >> a_export1024_with ...] >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 121) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] >> [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] >> [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. >> [FAILED] >> PKI-IPA...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 110) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >> a_export1024_with ...] >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 115) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] >> [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] >> [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. >> [FAILED] >> >> >> >> >> >> >> >>This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. >> >>v.E.1 >> >> >>-----Original Message----- >>From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>Sent: Tuesday, October 07, 2014 12:43 PM >>To: Murty, Ajeet (US - Arlington) >>Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com >>Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports >> >>On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >>>I was shutting down IPA before making any changes - >>> >>>1. Shutdown IPA - >>> >>>[root]# /etc/init.d/ipa stop >>>Stopping CA Service >>>Stopping pki-ca: [ OK ] >>>Stopping HTTP Service >>>Stopping httpd: [ OK ] >>>Stopping MEMCACHE Service >>>Stopping ipa_memcached: [ OK ] >>>Stopping KPASSWD Service >>>Stopping Kerberos 5 Admin Server: [ OK ] >>>Stopping KDC Service >>>Stopping Kerberos 5 KDC: [ OK ] >>>Stopping Directory Service >>>Shutting down dirsrv: >>> EXAMPLE-COM... [ OK ] >>> PKI-IPA... [ OK ] >>> >>>2. Edit 'dse.ldif' files to remove null ciphers - >>> >>>nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+ >>> rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128 >>> _sha,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha >>>numSubordinates: 1 >>I think Ludwig gave a good suggestion -- instead of removing them from >>the list, prefix the *_null ciphers with -, i.e. -rsa_null_md5, -fortezza_null. >>The way nsSSL3Ciphers attribute works, is by modifying default NSS >>ciphers list, with + and - to add and remove the ciphers accordingly. >> >>-- >>/ Alexander Bokovoy > >-- >/ Alexander Bokovoy > >-- >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 -- / Alexander Bokovoy From amurty at deloitte.com Wed Oct 8 07:10:26 2014 From: amurty at deloitte.com (Murty, Ajeet (US - Arlington)) Date: Wed, 8 Oct 2014 07:10:26 +0000 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <20141008060047.GA2328@redhat.com> References: <013068C38BB187448B7AB350AE98B35B38D56F66@USNDC1453.us.deloitte.com> <20141007101257.GA4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F99@USNDC1453.us.deloitte.com> <5433F638.306@redhat.com> <013068C38BB187448B7AB350AE98B35B38D577FF@USNDC1453.us.deloitte.com> <20141007164310.GH4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D578B2@USNDC1453.us.deloitte.com> <20141007170737.GI4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D578EC@USNDC1453.us.deloitte.com> <013068C38BB187448B7AB350AE98B35B38D58298@USNDC1453.us.deloitte.com> <20141008060047.GA2328@redhat.com> Message-ID: <013068C38BB187448B7AB350AE98B35B38D58408@USNDC1453.us.deloitte.com> Understood. Thank you for clarifying all that. I believe my best options at this point are to rebuild my environment on CentOS 7, enable COPR repo, and get the latest version of FreeIPA 4.x. I will hold out for a few more weeks to see if someone at RedHat can provide a fix/patch for the older version. Fingers crossed. -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: Wednesday, October 08, 2014 2:01 AM To: Murty, Ajeet (US - Arlington) Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports On Wed, 08 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >Any ideas on what else I can try here? >Also, can we expect the new IPA and DS to be available in the CentOS/YUM repository in the next few weeks/months? In general, FreeIPA team doesn't do backports to older versions due to tight cooperation with other components when introducing new features. We depend a lot on changes in 389-ds, Dogtag, MIT Kerberos, and SSSD, at least, but also in Samba and other components, including Linux kernel. Backporting all the changes to older releases of certain distributions is left to distribution maintainers. For Fedora we do have some freedom on what can be done and try to maintain availability of FreeIPA releases on two current versions but sometimes it is impossible due to update polices -- Fedora 20 got 4.0.x upgrade via COPR repository while we are cleaning up Fedora 21 for 4.1 support. In case of Red Hat Enterprise Linux releases, Red Hat itself (I cannot speak for the company) makes decisions what to support and these decisions are also based on certain stability promises for ABI, see https://access.redhat.com/solutions/5154 for details. Some of components FreeIPA depends on change their ABI and therefore the changes can only be introduced in newer major releases. When these changes occurred, we coordinated with Red Hat engineering teams to make sure most important changes were folded into RHEL 7.0 release to provide a base for FreeIPA integration. For CentOS, as it tracks corresponding Red Hat Enterprise Linux releases, situation is similar. For packages that are not in RHEL/CentOS releases there are means to provide them through a side channels, like EPEL, but EPEL's policy prevents from packaging something that is available through the main channels for the release. We use COPR repositories to make possible to install newer FreeIPA versions on RHEL 7/CentOS 7/Fedora 20. However, these packages have no official support from Red Hat or CentOS project. They are FreeIPA upstream effort to make our releases more easily testable. For any issues found through COPR repositories you are welcome to file tickets to FreeIPA issue tracker at https://fedorahosted.org/freeipa/. > >Thanks again for all your help. > > >-----Original Message----- >From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Murty, Ajeet (US - Arlington) >Sent: Tuesday, October 07, 2014 1:21 PM >To: Alexander Bokovoy >Cc: freeipa-users at redhat.com >Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports > >I removed the new lines, looks like this now - > >modifyTimestamp: 20140915221826Z >nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, > +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo > rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs > a_export1024_with_des_cbc_sha >numSubordinates: 1 > >I am still seeing the null ciphers in my scan results. > > > >-----Original Message----- >From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >Sent: Tuesday, October 07, 2014 1:08 PM >To: Murty, Ajeet (US - Arlington) >Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com >Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports > >On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >>I shutdown IPA and modified both dse ldif files to look like this - >> >> nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >> a_export1024_with_des_cbc_sha >> >> >>Then, when I try to start up IPA, I get this error message - >> >> [root]# /etc/init.d/ipa start >> Starting Directory Service >> Starting dirsrv: >> EXAMPLE-COM...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >The lines above suggest that you actually separated nsSSL3Ciphers line >from the entry itself. At least in my case it looks like this: > >dn: cn=encryption,cn=config >objectClass: top >objectClass: nsEncryptionConfig >cn: encryption >nsSSLSessionTimeout: 0 >nsSSLClientAuth: allowed >nsSSL2: off >nsSSL3: off >creatorsName: cn=server,cn=plugins,cn=config >modifiersName: cn=directory manager >createTimestamp: 20141001151245Z >modifyTimestamp: 20141001151430Z >nsSSL3Ciphers: +all >allowWeakCipher: off >numSubordinates: 1 > >note that it is part of cn=encryption,cn=config entry. You cannot >separate attributes within the entry with empty lines because empty line >finishes current entry and starts another one. > >> [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 116) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >> a_export1024_with ...] >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 121) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] >> [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] >> [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. >> [FAILED] >> PKI-IPA...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 110) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >> a_export1024_with ...] >> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 115) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. >> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] >> [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] >> [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. >> [FAILED] >> >> >> >> >> >> >> >>This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. >> >>v.E.1 >> >> >>-----Original Message----- >>From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>Sent: Tuesday, October 07, 2014 12:43 PM >>To: Murty, Ajeet (US - Arlington) >>Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com >>Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports >> >>On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >>>I was shutting down IPA before making any changes - >>> >>>1. Shutdown IPA - >>> >>>[root]# /etc/init.d/ipa stop >>>Stopping CA Service >>>Stopping pki-ca: [ OK ] >>>Stopping HTTP Service >>>Stopping httpd: [ OK ] >>>Stopping MEMCACHE Service >>>Stopping ipa_memcached: [ OK ] >>>Stopping KPASSWD Service >>>Stopping Kerberos 5 Admin Server: [ OK ] >>>Stopping KDC Service >>>Stopping Kerberos 5 KDC: [ OK ] >>>Stopping Directory Service >>>Shutting down dirsrv: >>> EXAMPLE-COM... [ OK ] >>> PKI-IPA... [ OK ] >>> >>>2. Edit 'dse.ldif' files to remove null ciphers - >>> >>>nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+ >>> rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128 >>> _sha,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha >>>numSubordinates: 1 >>I think Ludwig gave a good suggestion -- instead of removing them from >>the list, prefix the *_null ciphers with -, i.e. -rsa_null_md5, -fortezza_null. >>The way nsSSL3Ciphers attribute works, is by modifying default NSS >>ciphers list, with + and - to add and remove the ciphers accordingly. >> >>-- >>/ Alexander Bokovoy > >-- >/ Alexander Bokovoy > >-- >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 -- / Alexander Bokovoy From sbose at redhat.com Wed Oct 8 07:24:27 2014 From: sbose at redhat.com (Sumit Bose) Date: Wed, 8 Oct 2014 09:24:27 +0200 Subject: [Freeipa-users] Error: invalid 'AD domain controller' when establishing trust In-Reply-To: References: Message-ID: <20141008072427.GU31737@localhost.localdomain> On Wed, Oct 08, 2014 at 02:42:47AM +0200, Genadi Postrilko wrote: > Hello. > > I am attempting to create trust between AD and IPA. > > I have deployed AD environment as follows: > > I have created domain RED.COM > Then i add new domain tree root - BLUE.COM. > > Now i would like to establish trust with IPA as a sub domain (LINUX.BLUE.COM) > of BLUE.COM. > > I followed the guide and when reaching to trust agreement creation i > stumbled into this error: > > ipa trust-add --type=ad blue.com --admin Administrator --password > Active directory domain administrator's password: > ipa: ERROR: invalid 'AD domain controller': unsupported functional level can you check the domain and forest functional levels of your domains? You can find this information in the 'Active Directory Domains and Trusts' utility by right-clicking the domain name and selecting properties? iirc the minimal level we support in 2003R2. bye, Sumit > > Both AD server are 2008 R2. > IPA version is 3.3, installed on RHEL 7. > > Help will be appreciated. > > Genadi. > -- > 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 From sbose at redhat.com Wed Oct 8 07:31:45 2014 From: sbose at redhat.com (Sumit Bose) Date: Wed, 8 Oct 2014 09:31:45 +0200 Subject: [Freeipa-users] domain trust linux to AD server not finding user profiles In-Reply-To: <54347EEC.8070302@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C7E6A@G5W2742.americas.hpqcorp.net> <54347EEC.8070302@redhat.com> Message-ID: <20141008073145.GV31737@localhost.localdomain> On Tue, Oct 07, 2014 at 08:01:48PM -0400, Dmitri Pal wrote: > On 10/07/2014 05:03 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network > Support) wrote: > > > >I've been following the steps outlined in section 7.3.5 of the manual > >entitled > > > >Integrating OpenShift Enterprise > > > >with Identity Management (IdM) > > > >in Red Hat Enterprise Linux > > > >OpenShift Enterprise 2.1 > > > >IdM in Red Hat Enterprise Linux 7 > > > >Windows Server 2012 - Active Directory Integration > > > >I now have our RHEL V7 running IdM, setup as an IdM Server in a domain, > >Realm and subnet > > > >different from our existing AD server running Windows 2008 R2 with a > >populated user database > > > >that can be queried using ldapsearch and can authorize users. > > > >I have successfully created a domain trust between the RHEL V7 Server > > > >(linux.ipa.cxo.cpqcorp.net 10.20.0.59/24) and the AD Server > > > >(win2008.osn.cxo.cpqcorp.net 16.112.240.55). > > > >To simplify the configuration I have no firewall running and so have > >stopped both iptables > > > >and firewalld. > > > >All steps in section 7.3.5 have been followed. But when I run the first > >test for a user > > > >on the AD system, the system is unable to find anything: > > > >[root at linux ~]# getent group 'OSN\Domain Users' > > > >[root at linux ~]# > > > >[root at linux ~]# > > > >[root at linux ~]# getent passwd 'OSN\ldap25' > > > >[root at linux ~]# > > > > The users and related information are not fetched until you authenticate as > this user. > The ability to fetch users and groups that are not yet authenticated is > tracked by the ticket https://fedorahosted.org/sssd/ticket/2159 and will be > addressed in the next version of SSSD. > How frequently do you really need to lookup unauthenticated AD users and AD > groups on linux systems? What is the use case? This is correct, but the simple lookups shown above should still work even for unauthenticated users. What is missing is the full group-membership of an unauthenticated user and the full list of members for a group. Coming back to the issue above, it would be nice if you can increase the debug level of SSSD running on the host where you call the getent commands and send the SSSD logs after running the commands. Feel free to send them to me directly if you think that the logs are too big or might contain information too sensitive for a public mailing-list. bye, Sumit > > The ticket above is for the cases when there is an application that needs to > fetch the user so that admin of the application can assign privileges to > this user. But this is a pretty corner case. > > >I find this in the krb5kdc.log file: > > > >Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): AS_REQ (6 > >etypes {18 17 16 23 25 26}) 10.20.0.59: NEEDED_PREAUTH: > >host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET for > >krbtgt/IPA.CXO.CPQCORP.NET at IPA.CXO.CPQCORP.NET, Additional > >pre-authentication required > > > >Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): AS_REQ (6 > >etypes {18 17 16 23 25 26}) 10.20.0.59: ISSUE: authtime 1412713681, etypes > >{rep=18 tkt=18 ses=18}, host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET > >for krbtgt/IPA.CXO.CPQCORP.NET at IPA.CXO.CPQCORP.NET > > > >Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): TGS_REQ (6 > >etypes {18 17 16 23 25 26}) 10.20.0.59: ISSUE: authtime 1412713681, etypes > >{rep=18 tkt=18 ses=18}, host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET > >for ldap/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET > > > >Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): closing > >down fd 11 > > > >I'm not quite sure what else I'm missing or have not understood in order > >to query the > > > >AD server from the linux IdM server...but it would appear that something > >is not correctly > > > >defined in the krb5.conf file found below: > > > >[root at linux ~]# cat /etc/krb5.conf > > > >includedir /var/lib/sss/pubconf/krb5.include.d/ > > > >[logging] > > > >default = FILE:/var/log/krb5libs.log > > > >kdc = FILE:/var/log/krb5kdc.log > > > >admin_server = FILE:/var/log/kadmind.log > > > >[libdefaults] > > > >default_realm = IPA.CXO.CPQCORP.NET > > > >dns_lookup_realm = false > > > >dns_lookup_kdc = true > > > >rdns = false > > > >ticket_lifetime = 24h > > > >forwardable = yes > > > >default_ccache_name = KEYRING:persistent:%{uid} > > > >[realms] > > > >IPA.CXO.CPQCORP.NET = { > > > >kdc = linux.ipa.cxo.cpqcorp.net:88 > > > >master_kdc = linux.ipa.cxo.cpqcorp.net:88 > > > >admin_server = linux.ipa.cxo.cpqcorp.net:749 > > > >default_domain = ipa.cxo.cpqcorp.net > > > >pkinit_anchors = FILE:/etc/ipa/ca.crt > > > >auth_to_local = RULE:[1:$1@$0](^.*@OSN.CXO.CPQCORP.NET$)s/@OSN.CXO.CPQCORP.NET/@osn.cxo.cpqcorp.net/ > >auth_to_local = DEFAULT > > > >} > > > >OSN.CXO.CPQCORP.NET = { > > > >kdc = win2008.osn.cxo.cpqcorp.net > > > >master_kdc = win2008.osn.cxo.cpqcorp.net > > > >admin_sever = win2008.osn.cxo.cpqcorp.net > > > >} > > > >[domain_realm] > > > >.ipa.cxo.cpqcorp.net = IPA.CXO.CPQCORP.NET > > > >ipa.cxo.cpqcorp.net = IPA.CXO.CPQCORP.NET > > > >.osn.cxo.cpqcorp.net = OSN.CXO.CPQCORP.NET > > > >osn.cxo.cpqcorp.net = OSN.CXO.CPQCORP.NET > > > >[dbmodules] > > > >IPA.CXO.CPQCORP.NET = { > > > >db_library = ipadb.so > > > >} > > > >Any help greatly appreciated. > > > >Al > > > >*Al Licause* > > > >*CSC Americas BCS Technical Specialist* > > > >*HP Customer Support Center* > > > >*Hours 5am-2pm Pacific time USA* > > > >*Manager: mark.bailey at hp.com* > > > > > > > > > -- > 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 From genadipost at gmail.com Wed Oct 8 11:29:38 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Wed, 8 Oct 2014 13:29:38 +0200 Subject: [Freeipa-users] Error: invalid 'AD domain controller' when establishing trust In-Reply-To: <20141008072427.GU31737@localhost.localdomain> References: <20141008072427.GU31737@localhost.localdomain> Message-ID: Both Domain functional level and Forest functional level are Windows Server 2008 R2. 2014-10-08 9:24 GMT+02:00 Sumit Bose : > On Wed, Oct 08, 2014 at 02:42:47AM +0200, Genadi Postrilko wrote: > > Hello. > > > > I am attempting to create trust between AD and IPA. > > > > I have deployed AD environment as follows: > > > > I have created domain RED.COM > > Then i add new domain tree root - BLUE.COM. > > > > Now i would like to establish trust with IPA as a sub domain ( > LINUX.BLUE.COM) > > of BLUE.COM. > > > > I followed the guide and when reaching to trust agreement creation i > > stumbled into this error: > > > > ipa trust-add --type=ad blue.com --admin Administrator --password > > Active directory domain administrator's password: > > ipa: ERROR: invalid 'AD domain controller': unsupported functional level > > can you check the domain and forest functional levels of your domains? > You can find this information in the 'Active Directory Domains and > Trusts' utility by right-clicking the domain name and selecting > properties? iirc the minimal level we support in 2003R2. > > bye, > Sumit > > > > > Both AD server are 2008 R2. > > IPA version is 3.3, installed on RHEL 7. > > > > Help will be appreciated. > > > > Genadi. > > > -- > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Oct 8 12:11:38 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 08 Oct 2014 08:11:38 -0400 Subject: [Freeipa-users] Error: invalid 'AD domain controller' when establishing trust In-Reply-To: References: <20141008072427.GU31737@localhost.localdomain> Message-ID: <543529FA.407@redhat.com> On 10/08/2014 07:29 AM, Genadi Postrilko wrote: > Both Domain functional level and Forest functional level are Windows > Server 2008 R2. > Does blue.com actually resolves to the AD host? May be there is some DNS misconfiguration on the Linux system where you run the command from. > 2014-10-08 9:24 GMT+02:00 Sumit Bose >: > > On Wed, Oct 08, 2014 at 02:42:47AM +0200, Genadi Postrilko wrote: > > Hello. > > > > I am attempting to create trust between AD and IPA. > > > > I have deployed AD environment as follows: > > > > I have created domain RED.COM > > Then i add new domain tree root - BLUE.COM . > > > > Now i would like to establish trust with IPA as a sub domain > (LINUX.BLUE.COM ) > > of BLUE.COM . > > > > I followed the guide and when reaching to trust agreement creation i > > stumbled into this error: > > > > ipa trust-add --type=ad blue.com --admin > Administrator --password > > Active directory domain administrator's password: > > ipa: ERROR: invalid 'AD domain controller': unsupported > functional level > > can you check the domain and forest functional levels of your domains? > You can find this information in the 'Active Directory Domains and > Trusts' utility by right-clicking the domain name and selecting > properties? iirc the minimal level we support in 2003R2. > > bye, > Sumit > > > > > Both AD server are 2008 R2. > > IPA version is 3.3, installed on RHEL 7. > > > > Help will be appreciated. > > > > Genadi. > > > -- > > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Oct 8 12:15:33 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 8 Oct 2014 15:15:33 +0300 Subject: [Freeipa-users] Error: invalid 'AD domain controller' when establishing trust In-Reply-To: References: <20141008072427.GU31737@localhost.localdomain> Message-ID: <20141008121533.GD2328@redhat.com> On Wed, 08 Oct 2014, Genadi Postrilko wrote: >Both Domain functional level and Forest functional level are Windows Server >2008 R2. You need to check if the AD DC server IPA tries to contact has PDC emulator role _and_ is a domain controller for the root domain of the forest. I've added some fixes to enforce this checked in 4.0 (and backported to 3.3 in some RHEL 7 update which is not yet pushed out) but the easiest thing to ensure you are using right domains and right servers. forest root domain = first domain created in the forest. If forest name is example.com, then that's the forest root domain as well. Using http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_trust you can generate proper logs to see where the issue is. > >2014-10-08 9:24 GMT+02:00 Sumit Bose : > >> On Wed, Oct 08, 2014 at 02:42:47AM +0200, Genadi Postrilko wrote: >> > Hello. >> > >> > I am attempting to create trust between AD and IPA. >> > >> > I have deployed AD environment as follows: >> > >> > I have created domain RED.COM >> > Then i add new domain tree root - BLUE.COM. >> > >> > Now i would like to establish trust with IPA as a sub domain ( >> LINUX.BLUE.COM) >> > of BLUE.COM. >> > >> > I followed the guide and when reaching to trust agreement creation i >> > stumbled into this error: >> > >> > ipa trust-add --type=ad blue.com --admin Administrator --password >> > Active directory domain administrator's password: >> > ipa: ERROR: invalid 'AD domain controller': unsupported functional level >> >> can you check the domain and forest functional levels of your domains? >> You can find this information in the 'Active Directory Domains and >> Trusts' utility by right-clicking the domain name and selecting >> properties? iirc the minimal level we support in 2003R2. >> >> bye, >> Sumit >> >> > >> > Both AD server are 2008 R2. >> > IPA version is 3.3, installed on RHEL 7. >> > >> > Help will be appreciated. >> > >> > Genadi. >> >> > -- >> > 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 -- / Alexander Bokovoy From licause at hp.com Wed Oct 8 13:13:14 2014 From: licause at hp.com (Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)) Date: Wed, 8 Oct 2014 13:13:14 +0000 Subject: [Freeipa-users] FW: domain trust linux to AD server not finding user profiles In-Reply-To: <54347EEC.8070302@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C7E6A@G5W2742.americas.hpqcorp.net> <54347EEC.8070302@redhat.com> Message-ID: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C7F2D@G5W2742.americas.hpqcorp.net> Thanks very much for the feedback. RE: how often do we need to lookup unauthenticated users......this is strictly a test environment used to duplicate customer problems so in reality we never have to do it but that is the current problem at hand.....customer is unable to consistently authenticate users. They have implemented additional screening limits for the users, but for now we are only trying to get the basic functionality to work. In our case, am unable to authenticate the valid users on the AD server using ssh on the IdM server; [root at linux ~]# ssh -l ldap2 at osn.cxo.cpqcorp.net linux ldap2 at osn.cxo.cpqcorp.net@linux's password: Permission denied, please try again. ldap2 at osn.cxo.cpqcorp.net@linux's password: Received disconnect from 10.20.0.59: 2: Too many authentication failures for ldap2 at osn.cxo.cpqcorp.net We know the password that is used for this test user is correct. The logs and the tcpdump seem to indicate a problem with Kerberos verification but not being a Kerberos heavy, I'm not sure just what might be wrong, possibly with the krb5.conf file. This is the krb5kdc.log entry for the attempted ssh login above: Oct 08 08:58:51 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.20.0.59: NEEDED_PREAUTH: host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET for krbtgt/IPA.CXO.CPQCORP.NET at IPA.CXO.CPQCORP.NET, Additional pre-authentication required Oct 08 08:58:51 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.20.0.59: ISSUE: authtime 1412773131, etypes {rep=18 tkt=18 ses=18}, host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET for krbtgt/IPA.CXO.CPQCORP.NET at IPA.CXO.CPQCORP.NET Oct 08 08:58:51 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) 10.20.0.59: ISSUE: authtime 1412773131, etypes {rep=18 tkt=18 ses=18}, host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET for ldap/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET Oct 08 08:58:51 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): closing down fd 11 >From tcpdump, the error given by Kerberos is STATUS_DOMAIN_TRUST_INCONSISTENT >From the IdM server, this is the trust setup previously between the IdM server and the AD server; [root at linux ~]# ipa trust-show osn.cxo.cpqcorp.net Realm name: osn.cxo.cpqcorp.net Domain NetBIOS name: OSN Domain Security Identifier: S-1-5-21-3753757867-1859638558-383537475 Trust direction: Two-way trust Trust type: Active Directory domain Further down in this e-mail is the krb5.conf file. Do we have something defined incorrectly for Kerberos ? Al From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Tuesday, October 07, 2014 5:02 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] domain trust linux to AD server not finding user profiles On 10/07/2014 05:03 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: [cid:part1.03030509.00090400 at redhat.com] I've been following the steps outlined in section 7.3.5 of the manual entitled Integrating OpenShift Enterprise with Identity Management (IdM) in Red Hat Enterprise Linux OpenShift Enterprise 2.1 IdM in Red Hat Enterprise Linux 7 Windows Server 2012 - Active Directory Integration I now have our RHEL V7 running IdM, setup as an IdM Server in a domain, Realm and subnet different from our existing AD server running Windows 2008 R2 with a populated user database that can be queried using ldapsearch and can authorize users. I have successfully created a domain trust between the RHEL V7 Server (linux.ipa.cxo.cpqcorp.net 10.20.0.59/24) and the AD Server (win2008.osn.cxo.cpqcorp.net 16.112.240.55). To simplify the configuration I have no firewall running and so have stopped both iptables and firewalld. All steps in section 7.3.5 have been followed. But when I run the first test for a user on the AD system, the system is unable to find anything: [root at linux ~]# getent group 'OSN\Domain Users' [root at linux ~]# [root at linux ~]# [root at linux ~]# getent passwd 'OSN\ldap25' [root at linux ~]# The users and related information are not fetched until you authenticate as this user. The ability to fetch users and groups that are not yet authenticated is tracked by the ticket https://fedorahosted.org/sssd/ticket/2159 and will be addressed in the next version of SSSD. How frequently do you really need to lookup unauthenticated AD users and AD groups on linux systems? What is the use case? The ticket above is for the cases when there is an application that needs to fetch the user so that admin of the application can assign privileges to this user. But this is a pretty corner case. I find this in the krb5kdc.log file: Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.20.0.59: NEEDED_PREAUTH: host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET for krbtgt/IPA.CXO.CPQCORP.NET at IPA.CXO.CPQCORP.NET, Additional pre-authentication required Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.20.0.59: ISSUE: authtime 1412713681, etypes {rep=18 tkt=18 ses=18}, host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET for krbtgt/IPA.CXO.CPQCORP.NET at IPA.CXO.CPQCORP.NET Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) 10.20.0.59: ISSUE: authtime 1412713681, etypes {rep=18 tkt=18 ses=18}, host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET for ldap/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): closing down fd 11 I'm not quite sure what else I'm missing or have not understood in order to query the AD server from the linux IdM server...but it would appear that something is not correctly defined in the krb5.conf file found below: [root at linux ~]# cat /etc/krb5.conf includedir /var/lib/sss/pubconf/krb5.include.d/ [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = IPA.CXO.CPQCORP.NET dns_lookup_realm = false dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes default_ccache_name = KEYRING:persistent:%{uid} [realms] IPA.CXO.CPQCORP.NET = { kdc = linux.ipa.cxo.cpqcorp.net:88 master_kdc = linux.ipa.cxo.cpqcorp.net:88 admin_server = linux.ipa.cxo.cpqcorp.net:749 default_domain = ipa.cxo.cpqcorp.net pkinit_anchors = FILE:/etc/ipa/ca.crt auth_to_local = RULE:[1:$1@$0](^.*@OSN.CXO.CPQCORP.NET$)s/@OSN.CXO.CPQCORP.NET/@osn.cxo.cpqcorp.net/ auth_to_local = DEFAULT } OSN.CXO.CPQCORP.NET = { kdc = win2008.osn.cxo.cpqcorp.net master_kdc = win2008.osn.cxo.cpqcorp.net admin_sever = win2008.osn.cxo.cpqcorp.net } [domain_realm] .ipa.cxo.cpqcorp.net = IPA.CXO.CPQCORP.NET ipa.cxo.cpqcorp.net = IPA.CXO.CPQCORP.NET .osn.cxo.cpqcorp.net = OSN.CXO.CPQCORP.NET osn.cxo.cpqcorp.net = OSN.CXO.CPQCORP.NET [dbmodules] IPA.CXO.CPQCORP.NET = { db_library = ipadb.so } Any help greatly appreciated. Al Al Licause CSC Americas BCS Technical Specialist HP Customer Support Center Hours 5am-2pm Pacific time USA Manager: mark.bailey at hp.com -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ATT00001.gif Type: image/gif Size: 2051 bytes Desc: ATT00001.gif URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00002.txt URL: From abokovoy at redhat.com Wed Oct 8 13:21:50 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 8 Oct 2014 16:21:50 +0300 Subject: [Freeipa-users] FW: domain trust linux to AD server not finding user profiles In-Reply-To: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C7F2D@G5W2742.americas.hpqcorp.net> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C7E6A@G5W2742.americas.hpqcorp.net> <54347EEC.8070302@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C7F2D@G5W2742.americas.hpqcorp.net> Message-ID: <20141008132150.GE2328@redhat.com> On Wed, 08 Oct 2014, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: >Thanks very much for the feedback. > >RE: how often do we need to lookup unauthenticated users......this is strictly a test environment used to duplicate customer problems >so in reality we never have to do it but that is the current problem at hand.....customer is unable to consistently authenticate users. >They have implemented additional screening limits for the users, but for now we are only trying to get the basic functionality to work. > >In our case, am unable to authenticate the valid users on the AD server using ssh on the IdM server; > >[root at linux ~]# ssh -l ldap2 at osn.cxo.cpqcorp.net linux >ldap2 at osn.cxo.cpqcorp.net@linux's password: >Permission denied, please try again. >ldap2 at osn.cxo.cpqcorp.net@linux's password: >Received disconnect from 10.20.0.59: 2: Too many authentication failures for ldap2 at osn.cxo.cpqcorp.net > >We know the password that is used for this test user is correct. > >The logs and the tcpdump seem to indicate a problem with Kerberos verification but not being a Kerberos heavy, I'm not sure >just what might be wrong, possibly with the krb5.conf file. This is the krb5kdc.log entry for the attempted ssh login above: > >Oct 08 08:58:51 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.20.0.59: NEEDED_PREAUTH: host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET for krbtgt/IPA.CXO.CPQCORP.NET at IPA.CXO.CPQCORP.NET, Additional pre-authentication required >Oct 08 08:58:51 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.20.0.59: ISSUE: authtime 1412773131, etypes {rep=18 tkt=18 ses=18}, host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET for krbtgt/IPA.CXO.CPQCORP.NET at IPA.CXO.CPQCORP.NET >Oct 08 08:58:51 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) 10.20.0.59: ISSUE: authtime 1412773131, etypes {rep=18 tkt=18 ses=18}, host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET for ldap/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET >Oct 08 08:58:51 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): closing down fd 11 > >>From tcpdump, the error given by Kerberos is STATUS_DOMAIN_TRUST_INCONSISTENT Ok, this means the process to establish trust didn't finish well. It is a known issue that despite a possible failure status of 'trust-add' says 'established and verified', we have a bug for that already. Please follow http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_trust to give enough debugging data to see what the actual problem is. > >>From the IdM server, this is the trust setup previously between the IdM server and the AD server; > >[root at linux ~]# ipa trust-show osn.cxo.cpqcorp.net > Realm name: osn.cxo.cpqcorp.net > Domain NetBIOS name: OSN > Domain Security Identifier: S-1-5-21-3753757867-1859638558-383537475 > Trust direction: Two-way trust > Trust type: Active Directory domain > >Further down in this e-mail is the krb5.conf file. > >Do we have something defined incorrectly for Kerberos ? > >Al > > > > > > > > > >From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal >Sent: Tuesday, October 07, 2014 5:02 PM >To: freeipa-users at redhat.com >Subject: Re: [Freeipa-users] domain trust linux to AD server not finding user profiles > >On 10/07/2014 05:03 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: >[cid:part1.03030509.00090400 at redhat.com] > >I've been following the steps outlined in section 7.3.5 of the manual entitled > >Integrating OpenShift Enterprise >with Identity Management (IdM) >in Red Hat Enterprise Linux >OpenShift Enterprise 2.1 >IdM in Red Hat Enterprise Linux 7 >Windows Server 2012 - Active Directory Integration > >I now have our RHEL V7 running IdM, setup as an IdM Server in a domain, Realm and subnet >different from our existing AD server running Windows 2008 R2 with a populated user database >that can be queried using ldapsearch and can authorize users. > >I have successfully created a domain trust between the RHEL V7 Server >(linux.ipa.cxo.cpqcorp.net 10.20.0.59/24) and the AD Server >(win2008.osn.cxo.cpqcorp.net 16.112.240.55). > >To simplify the configuration I have no firewall running and so have stopped both iptables >and firewalld. > >All steps in section 7.3.5 have been followed. But when I run the first test for a user >on the AD system, the system is unable to find anything: > >[root at linux ~]# getent group 'OSN\Domain Users' >[root at linux ~]# >[root at linux ~]# >[root at linux ~]# getent passwd 'OSN\ldap25' >[root at linux ~]# > >The users and related information are not fetched until you authenticate as this user. >The ability to fetch users and groups that are not yet authenticated is tracked by the ticket https://fedorahosted.org/sssd/ticket/2159 and will be addressed in the next version of SSSD. >How frequently do you really need to lookup unauthenticated AD users and AD groups on linux systems? What is the use case? > >The ticket above is for the cases when there is an application that needs to fetch the user so that admin of the application can assign privileges to this user. But this is a pretty corner case. > > > > >I find this in the krb5kdc.log file: >Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.20.0.59: NEEDED_PREAUTH: host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET for krbtgt/IPA.CXO.CPQCORP.NET at IPA.CXO.CPQCORP.NET, Additional pre-authentication required >Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.20.0.59: ISSUE: authtime 1412713681, etypes {rep=18 tkt=18 ses=18}, host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET for krbtgt/IPA.CXO.CPQCORP.NET at IPA.CXO.CPQCORP.NET >Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) 10.20.0.59: ISSUE: authtime 1412713681, etypes {rep=18 tkt=18 ses=18}, host/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET for ldap/linux.ipa.cxo.cpqcorp.net at IPA.CXO.CPQCORP.NET >Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): closing down fd 11 > >I'm not quite sure what else I'm missing or have not understood in order to query the >AD server from the linux IdM server...but it would appear that something is not correctly >defined in the krb5.conf file found below: > >[root at linux ~]# cat /etc/krb5.conf >includedir /var/lib/sss/pubconf/krb5.include.d/ > >[logging] >default = FILE:/var/log/krb5libs.log >kdc = FILE:/var/log/krb5kdc.log >admin_server = FILE:/var/log/kadmind.log > >[libdefaults] >default_realm = IPA.CXO.CPQCORP.NET >dns_lookup_realm = false >dns_lookup_kdc = true >rdns = false >ticket_lifetime = 24h >forwardable = yes >default_ccache_name = KEYRING:persistent:%{uid} > >[realms] >IPA.CXO.CPQCORP.NET = { > kdc = linux.ipa.cxo.cpqcorp.net:88 > master_kdc = linux.ipa.cxo.cpqcorp.net:88 > admin_server = linux.ipa.cxo.cpqcorp.net:749 > default_domain = ipa.cxo.cpqcorp.net > pkinit_anchors = FILE:/etc/ipa/ca.crt > auth_to_local = RULE:[1:$1@$0](^.*@OSN.CXO.CPQCORP.NET$)s/@OSN.CXO.CPQCORP.NET/@osn.cxo.cpqcorp.net/ auth_to_local = DEFAULT >} > >OSN.CXO.CPQCORP.NET = { > kdc = win2008.osn.cxo.cpqcorp.net > master_kdc = win2008.osn.cxo.cpqcorp.net > admin_sever = win2008.osn.cxo.cpqcorp.net > } > >[domain_realm] >.ipa.cxo.cpqcorp.net = IPA.CXO.CPQCORP.NET >ipa.cxo.cpqcorp.net = IPA.CXO.CPQCORP.NET >.osn.cxo.cpqcorp.net = OSN.CXO.CPQCORP.NET >osn.cxo.cpqcorp.net = OSN.CXO.CPQCORP.NET > >[dbmodules] > IPA.CXO.CPQCORP.NET = { > db_library = ipadb.so > } > > > >Any help greatly appreciated. > >Al > >Al Licause >CSC Americas BCS Technical Specialist >HP Customer Support Center >Hours 5am-2pm Pacific time USA >Manager: mark.bailey at hp.com > > > > > > > >-- > >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 -- / Alexander Bokovoy From loris at lgs.com.ve Wed Oct 8 13:22:34 2014 From: loris at lgs.com.ve (Loris Santamaria) Date: Wed, 08 Oct 2014 08:52:34 -0430 Subject: [Freeipa-users] domain trust linux to AD server not finding user profiles In-Reply-To: <54347EEC.8070302@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C7E6A@G5W2742.americas.hpqcorp.net> <54347EEC.8070302@redhat.com> Message-ID: <1412774554.4835.62.camel@toron.pzo.lgs.com.ve> El mar, 07-10-2014 a las 20:01 -0400, Dmitri Pal escribi?: > > The users and related information are not fetched until you > authenticate as this user. > The ability to fetch users and groups that are not yet authenticated > is tracked by the ticket https://fedorahosted.org/sssd/ticket/2159 and > will be addressed in the next version of SSSD. > How frequently do you really need to lookup unauthenticated AD users > and AD groups on linux systems? What is the use case? > > The ticket above is for the cases when there is an application that > needs to fetch the user so that admin of the application can assign > privileges to this user. But this is a pretty corner case. It is a pretty common request when you configure a proxy server with authentication. You get the user's ticket but the user is not logged in on the system, so normal group membership via sssd won't work. Best regards -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford From abokovoy at redhat.com Wed Oct 8 13:36:55 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 8 Oct 2014 16:36:55 +0300 Subject: [Freeipa-users] domain trust linux to AD server not finding user profiles In-Reply-To: <1412774554.4835.62.camel@toron.pzo.lgs.com.ve> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C7E6A@G5W2742.americas.hpqcorp.net> <54347EEC.8070302@redhat.com> <1412774554.4835.62.camel@toron.pzo.lgs.com.ve> Message-ID: <20141008133655.GF2328@redhat.com> On Wed, 08 Oct 2014, Loris Santamaria wrote: >El mar, 07-10-2014 a las 20:01 -0400, Dmitri Pal escribi?: > >> >> The users and related information are not fetched until you >> authenticate as this user. >> The ability to fetch users and groups that are not yet authenticated >> is tracked by the ticket https://fedorahosted.org/sssd/ticket/2159 and >> will be addressed in the next version of SSSD. >> How frequently do you really need to lookup unauthenticated AD users >> and AD groups on linux systems? What is the use case? >> >> The ticket above is for the cases when there is an application that >> needs to fetch the user so that admin of the application can assign >> privileges to this user. But this is a pretty corner case. > >It is a pretty common request when you configure a proxy server with >authentication. You get the user's ticket but the user is not logged in >on the system, so normal group membership via sssd won't work. If you get a user's ticket, you'd get MS-PAC in it, at least for AD and FreeIPA users when ipa-adtrust-install was run. That gives you full list of groups the user member of at the moment when TGT was issued. SSSD supports it already. What was poorly supported is the case of looking up groups of an AD user who never logged in. In that case SSSD did miss some of groups obtaining which required expensive traversal over AD DCs beyond Global Catalog service. This should be now better supported with 1.12.2. -- / Alexander Bokovoy From andreas.ladanyi at kit.edu Wed Oct 8 13:47:31 2014 From: andreas.ladanyi at kit.edu (Andreas Ladanyi) Date: Wed, 08 Oct 2014 15:47:31 +0200 Subject: [Freeipa-users] Migrate KRB DB hashes to IPA LDAP Message-ID: <54354073.5020904@kit.edu> Hello, i have the following situation: OpenLDAP with user entries. No userPassword hashes are available. MIT Kerberos with principals and password hashes in the KRB DB. I have migrated the user and group accounts via "ipa migrate-ds ..." successfully. Now, is it possible to get out the kerberos user principal password hashes from the KRB own DB to the appropriate krbPassword..... IPA LDAP attribute, so the users could login without any extra user action ? cheers, Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5266 bytes Desc: S/MIME Cryptographic Signature URL: From genadipost at gmail.com Wed Oct 8 15:10:15 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Wed, 8 Oct 2014 17:10:15 +0200 Subject: [Freeipa-users] Error: invalid 'AD domain controller' when establishing trust In-Reply-To: <20141008121533.GD2328@redhat.com> References: <20141008072427.GU31737@localhost.localdomain> <20141008121533.GD2328@redhat.com> Message-ID: The forest root domain in my case is RED.COM. I have attached the log files. 2014-10-08 14:15 GMT+02:00 Alexander Bokovoy : > On Wed, 08 Oct 2014, Genadi Postrilko wrote: > >> Both Domain functional level and Forest functional level are Windows >> Server >> 2008 R2. >> > You need to check if the AD DC server IPA tries to contact has PDC > emulator role _and_ is a domain controller for the root domain of the > forest. > > I've added some fixes to enforce this checked in 4.0 (and backported to > 3.3 in some RHEL 7 update which is not yet pushed out) but the easiest > thing to ensure you are using right domains and right servers. > > forest root domain = first domain created in the forest. If forest name > is example.com, then that's the forest root domain as well. > > Using http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup# > Debugging_trust > you can generate proper logs to see where the issue is. > > > >> 2014-10-08 9:24 GMT+02:00 Sumit Bose : >> >> On Wed, Oct 08, 2014 at 02:42:47AM +0200, Genadi Postrilko wrote: >>> > Hello. >>> > >>> > I am attempting to create trust between AD and IPA. >>> > >>> > I have deployed AD environment as follows: >>> > >>> > I have created domain RED.COM >>> > Then i add new domain tree root - BLUE.COM. >>> > >>> > Now i would like to establish trust with IPA as a sub domain ( >>> LINUX.BLUE.COM) >>> > of BLUE.COM. >>> > >>> > I followed the guide and when reaching to trust agreement creation i >>> > stumbled into this error: >>> > >>> > ipa trust-add --type=ad blue.com --admin Administrator --password >>> > Active directory domain administrator's password: >>> > ipa: ERROR: invalid 'AD domain controller': unsupported functional >>> level >>> >>> can you check the domain and forest functional levels of your domains? >>> You can find this information in the 'Active Directory Domains and >>> Trusts' utility by right-clicking the domain name and selecting >>> properties? iirc the minimal level we support in 2003R2. >>> >>> bye, >>> Sumit >>> >>> > >>> > Both AD server are 2008 R2. >>> > IPA version is 3.3, installed on RHEL 7. >>> > >>> > Help will be appreciated. >>> > >>> > Genadi. >>> >>> > -- >>> > 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 >> > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa_trust_debug.zip Type: application/zip Size: 1108363 bytes Desc: not available URL: From janellenicole80 at gmail.com Wed Oct 8 15:17:29 2014 From: janellenicole80 at gmail.com (Janelle) Date: Wed, 08 Oct 2014 08:17:29 -0700 Subject: [Freeipa-users] freeipa and RHEL 7 Message-ID: <54355589.9060107@gmail.com> Hi again Just wondering if anyone has found a work around to get freeipa installed on RHEL 7 -- the server works fine, but it never finishes the client install and you can't force a client install either. You end up with this in the logs, which I see has been reported, but wondering if fixed? stderr=Failed to issue method call: Unit fedora-domainname.service failed to load: No such file or directory. Thanks ~J From rcritten at redhat.com Wed Oct 8 15:26:17 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 08 Oct 2014 11:26:17 -0400 Subject: [Freeipa-users] freeipa and RHEL 7 In-Reply-To: <54355589.9060107@gmail.com> References: <54355589.9060107@gmail.com> Message-ID: <54355799.1090004@redhat.com> Janelle wrote: > Hi again > > Just wondering if anyone has found a work around to get freeipa > installed on RHEL 7 -- the server works fine, but it never finishes the > client install and you can't force a client install either. > > You end up with this in the logs, which I see has been reported, but > wondering if fixed? > > stderr=Failed to issue method call: Unit fedora-domainname.service > failed to load: No such file or directory. > > Thanks > ~J > It is being tracked in this ticket: https://fedorahosted.org/freeipa/ticket/4562 You need to modify the installer to call to use rhel-domain.service instead. I believe you need to modify /usr/lib/python2*/site-packages/ipaplatform/fedora/services.py to make the right call. rob From genadipost at gmail.com Wed Oct 8 15:33:49 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Wed, 8 Oct 2014 17:33:49 +0200 Subject: [Freeipa-users] Error: invalid 'AD domain controller' when establishing trust In-Reply-To: <543529FA.407@redhat.com> References: <20141008072427.GU31737@localhost.localdomain> <543529FA.407@redhat.com> Message-ID: The ipa server is able to resolve blue.com. dig SRV _ldap._tcp.blue.com does return answer. 2014-10-08 14:11 GMT+02:00 Dmitri Pal : > On 10/08/2014 07:29 AM, Genadi Postrilko wrote: > > Both Domain functional level and Forest functional level are Windows > Server 2008 R2. > > > Does blue.com actually resolves to the AD host? > May be there is some DNS misconfiguration on the Linux system where you > run the command from. > > > 2014-10-08 9:24 GMT+02:00 Sumit Bose : > >> On Wed, Oct 08, 2014 at 02:42:47AM +0200, Genadi Postrilko wrote: >> > Hello. >> > >> > I am attempting to create trust between AD and IPA. >> > >> > I have deployed AD environment as follows: >> > >> > I have created domain RED.COM >> > Then i add new domain tree root - BLUE.COM. >> > >> > Now i would like to establish trust with IPA as a sub domain ( >> LINUX.BLUE.COM) >> > of BLUE.COM. >> > >> > I followed the guide and when reaching to trust agreement creation i >> > stumbled into this error: >> > >> > ipa trust-add --type=ad blue.com --admin Administrator --password >> > Active directory domain administrator's password: >> > ipa: ERROR: invalid 'AD domain controller': unsupported functional level >> >> can you check the domain and forest functional levels of your domains? >> You can find this information in the 'Active Directory Domains and >> Trusts' utility by right-clicking the domain name and selecting >> properties? iirc the minimal level we support in 2003R2. >> >> bye, >> Sumit >> >> > >> > Both AD server are 2008 R2. >> > IPA version is 3.3, installed on RHEL 7. >> > >> > Help will be appreciated. >> > >> > Genadi. >> >> > -- >> > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Wed Oct 8 15:49:14 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 08 Oct 2014 17:49:14 +0200 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <013068C38BB187448B7AB350AE98B35B38D58408@USNDC1453.us.deloitte.com> References: <013068C38BB187448B7AB350AE98B35B38D56F66@USNDC1453.us.deloitte.com> <20141007101257.GA4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F99@USNDC1453.us.deloitte.com> <5433F638.306@redhat.com> <013068C38BB187448B7AB350AE98B35B38D577FF@USNDC1453.us.deloitte.com> <20141007164310.GH4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D578B2@USNDC1453.us.deloitte.com> <20141007170737.GI4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D578EC@USNDC1453.us.deloitte.com> <013068C38BB187448B7AB350AE98B35B38D58298@USNDC1453.us.deloitte.com> <20141008060047.GA2328@redhat.com> <013068C38BB187448B7AB350AE98B35B38D58408@USNDC1453.us.deloitte.com> Message-ID: <54355CFA.9070101@redhat.com> Hi, I did a test with 1.2.11.15-33 first test: nsSSL3Ciphers: +all running nmap gave: 636/tcp open ldapssl | ssl-enum-ciphers: | TLSv1.0: | ciphers: | SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA - strong | SSL_RSA_FIPS_WITH_DES_CBC_SHA - weak | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA - weak | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA - weak | TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - weak | TLS_RSA_EXPORT_WITH_RC4_40_MD5 - weak | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_DES_CBC_SHA - weak | TLS_RSA_WITH_NULL_SHA - broken <<<<<<<<<<<<<< | TLS_RSA_WITH_RC4_128_MD5 - strong | TLS_RSA_WITH_RC4_128_SHA - strong | compressors: | NULL |_ least strength: broken next test: nsSSL3Ciphers: +all,-rsa_null_sha nmap result: 636/tcp open ldapssl | ssl-enum-ciphers: | TLSv1.0: | ciphers: | SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA - strong | SSL_RSA_FIPS_WITH_DES_CBC_SHA - weak | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA - weak | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA - weak | TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - weak | TLS_RSA_EXPORT_WITH_RC4_40_MD5 - weak | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_DES_CBC_SHA - weak | TLS_RSA_WITH_RC4_128_MD5 - strong | TLS_RSA_WITH_RC4_128_SHA - strong | compressors: | NULL |_ least strength: weak maybe you can try adding "-rsa_null_sha" to your nSSL3cipher config. On 10/08/2014 09:10 AM, Murty, Ajeet (US - Arlington) wrote: > Understood. Thank you for clarifying all that. > I believe my best options at this point are to rebuild my environment on CentOS 7, enable COPR repo, and get the latest version of FreeIPA 4.x. > I will hold out for a few more weeks to see if someone at RedHat can provide a fix/patch for the older version. Fingers crossed. > > > -----Original Message----- > From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > Sent: Wednesday, October 08, 2014 2:01 AM > To: Murty, Ajeet (US - Arlington) > Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports > > On Wed, 08 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >> Any ideas on what else I can try here? >> Also, can we expect the new IPA and DS to be available in the CentOS/YUM repository in the next few weeks/months? > In general, FreeIPA team doesn't do backports to older versions due to > tight cooperation with other components when introducing new features. > We depend a lot on changes in 389-ds, Dogtag, MIT Kerberos, and SSSD, at least, > but also in Samba and other components, including Linux kernel. > > Backporting all the changes to older releases of certain distributions > is left to distribution maintainers. For Fedora we do have some freedom > on what can be done and try to maintain availability of FreeIPA releases > on two current versions but sometimes it is impossible due to update > polices -- Fedora 20 got 4.0.x upgrade via COPR repository while we are > cleaning up Fedora 21 for 4.1 support. > > In case of Red Hat Enterprise Linux releases, Red Hat itself (I cannot > speak for the company) makes decisions what to support and these > decisions are also based on certain stability promises for ABI, see > https://access.redhat.com/solutions/5154 for details. Some of components > FreeIPA depends on change their ABI and therefore the changes can only > be introduced in newer major releases. When these changes occurred, we > coordinated with Red Hat engineering teams to make sure most important > changes were folded into RHEL 7.0 release to provide a base for FreeIPA > integration. > > For CentOS, as it tracks corresponding Red Hat Enterprise Linux > releases, situation is similar. For packages that are not in RHEL/CentOS > releases there are means to provide them through a side channels, like > EPEL, but EPEL's policy prevents from packaging something that is > available through the main channels for the release. > > We use COPR repositories to make possible to install newer FreeIPA > versions on RHEL 7/CentOS 7/Fedora 20. However, these packages have no > official support from Red Hat or CentOS project. They are FreeIPA > upstream effort to make our releases more easily testable. For any issues > found through COPR repositories you are welcome to file tickets to > FreeIPA issue tracker at https://fedorahosted.org/freeipa/. > > >> Thanks again for all your help. >> >> >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Murty, Ajeet (US - Arlington) >> Sent: Tuesday, October 07, 2014 1:21 PM >> To: Alexander Bokovoy >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports >> >> I removed the new lines, looks like this now - >> >> modifyTimestamp: 20140915221826Z >> nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >> a_export1024_with_des_cbc_sha >> numSubordinates: 1 >> >> I am still seeing the null ciphers in my scan results. >> >> >> >> -----Original Message----- >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> Sent: Tuesday, October 07, 2014 1:08 PM >> To: Murty, Ajeet (US - Arlington) >> Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports >> >> On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >>> I shutdown IPA and modified both dse ldif files to look like this - >>> >>> nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >>> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >>> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >>> a_export1024_with_des_cbc_sha >>> >>> >>> Then, when I try to start up IPA, I get this error message - >>> >>> [root]# /etc/init.d/ipa start >>> Starting Directory Service >>> Starting dirsrv: >>> EXAMPLE-COM...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >>> [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed >>> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> The lines above suggest that you actually separated nsSSL3Ciphers line > >from the entry itself. At least in my case it looks like this: >> dn: cn=encryption,cn=config >> objectClass: top >> objectClass: nsEncryptionConfig >> cn: encryption >> nsSSLSessionTimeout: 0 >> nsSSLClientAuth: allowed >> nsSSL2: off >> nsSSL3: off >> creatorsName: cn=server,cn=plugins,cn=config >> modifiersName: cn=directory manager >> createTimestamp: 20141001151245Z >> modifyTimestamp: 20141001151430Z >> nsSSL3Ciphers: +all >> allowWeakCipher: off >> numSubordinates: 1 >> >> note that it is part of cn=encryption,cn=config entry. You cannot >> separate attributes within the entry with empty lines because empty line >> finishes current entry and starts another one. >> >>> [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed >>> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >>> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 116) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. >>> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >>> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >>> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >>> a_export1024_with ...] >>> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >>> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 121) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. >>> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] >>> [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] >>> [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. >>> [FAILED] >>> PKI-IPA...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >>> [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed >>> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >>> [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed >>> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >>> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 110) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. >>> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >>> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >>> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >>> a_export1024_with ...] >>> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >>> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 115) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. >>> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] >>> [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] >>> [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. >>> [FAILED] >>> >>> >>> >>> >>> >>> >>> >>> This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. >>> >>> v.E.1 >>> >>> >>> -----Original Message----- >>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>> Sent: Tuesday, October 07, 2014 12:43 PM >>> To: Murty, Ajeet (US - Arlington) >>> Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports >>> >>> On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >>>> I was shutting down IPA before making any changes - >>>> >>>> 1. Shutdown IPA - >>>> >>>> [root]# /etc/init.d/ipa stop >>>> Stopping CA Service >>>> Stopping pki-ca: [ OK ] >>>> Stopping HTTP Service >>>> Stopping httpd: [ OK ] >>>> Stopping MEMCACHE Service >>>> Stopping ipa_memcached: [ OK ] >>>> Stopping KPASSWD Service >>>> Stopping Kerberos 5 Admin Server: [ OK ] >>>> Stopping KDC Service >>>> Stopping Kerberos 5 KDC: [ OK ] >>>> Stopping Directory Service >>>> Shutting down dirsrv: >>>> EXAMPLE-COM... [ OK ] >>>> PKI-IPA... [ OK ] >>>> >>>> 2. Edit 'dse.ldif' files to remove null ciphers - >>>> >>>> nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+ >>>> rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128 >>>> _sha,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha >>>> numSubordinates: 1 >>> I think Ludwig gave a good suggestion -- instead of removing them from >>> the list, prefix the *_null ciphers with -, i.e. -rsa_null_md5, -fortezza_null. >>> The way nsSSL3Ciphers attribute works, is by modifying default NSS >>> ciphers list, with + and - to add and remove the ciphers accordingly. >>> >>> -- >>> / Alexander Bokovoy >> -- >> / Alexander Bokovoy >> >> -- >> 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 From abokovoy at redhat.com Wed Oct 8 15:48:20 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 8 Oct 2014 18:48:20 +0300 Subject: [Freeipa-users] Error: invalid 'AD domain controller' when establishing trust In-Reply-To: References: <20141008072427.GU31737@localhost.localdomain> <20141008121533.GD2328@redhat.com> Message-ID: <20141008154820.GG2328@redhat.com> On Wed, 08 Oct 2014, Genadi Postrilko wrote: >The forest root domain in my case is RED.COM. You need to establish trust to red.com then. Any domain which is member of the forest red.com will be visible through trust. Forest trust can only be established between forest root domains, that's how it is designed by Microsoft. > >I have attached the log files. These logs show you are attempting to establish trust to blue.com which is not a forest root domain, thus nothing works. > >2014-10-08 14:15 GMT+02:00 Alexander Bokovoy : > >> On Wed, 08 Oct 2014, Genadi Postrilko wrote: >> >>> Both Domain functional level and Forest functional level are Windows >>> Server >>> 2008 R2. >>> >> You need to check if the AD DC server IPA tries to contact has PDC >> emulator role _and_ is a domain controller for the root domain of the >> forest. >> >> I've added some fixes to enforce this checked in 4.0 (and backported to >> 3.3 in some RHEL 7 update which is not yet pushed out) but the easiest >> thing to ensure you are using right domains and right servers. >> >> forest root domain = first domain created in the forest. If forest name >> is example.com, then that's the forest root domain as well. >> >> Using http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup# >> Debugging_trust >> you can generate proper logs to see where the issue is. >> >> >> >>> 2014-10-08 9:24 GMT+02:00 Sumit Bose : >>> >>> On Wed, Oct 08, 2014 at 02:42:47AM +0200, Genadi Postrilko wrote: >>>> > Hello. >>>> > >>>> > I am attempting to create trust between AD and IPA. >>>> > >>>> > I have deployed AD environment as follows: >>>> > >>>> > I have created domain RED.COM >>>> > Then i add new domain tree root - BLUE.COM. >>>> > >>>> > Now i would like to establish trust with IPA as a sub domain ( >>>> LINUX.BLUE.COM) >>>> > of BLUE.COM. >>>> > >>>> > I followed the guide and when reaching to trust agreement creation i >>>> > stumbled into this error: >>>> > >>>> > ipa trust-add --type=ad blue.com --admin Administrator --password >>>> > Active directory domain administrator's password: >>>> > ipa: ERROR: invalid 'AD domain controller': unsupported functional >>>> level >>>> >>>> can you check the domain and forest functional levels of your domains? >>>> You can find this information in the 'Active Directory Domains and >>>> Trusts' utility by right-clicking the domain name and selecting >>>> properties? iirc the minimal level we support in 2003R2. >>>> >>>> bye, >>>> Sumit >>>> >>>> > >>>> > Both AD server are 2008 R2. >>>> > IPA version is 3.3, installed on RHEL 7. >>>> > >>>> > Help will be appreciated. >>>> > >>>> > Genadi. >>>> >>>> > -- >>>> > 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 >>> >> >> >> -- >> / Alexander Bokovoy >> -- / Alexander Bokovoy From abokovoy at redhat.com Wed Oct 8 15:54:33 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 8 Oct 2014 18:54:33 +0300 Subject: [Freeipa-users] freeipa and RHEL 7 In-Reply-To: <54355799.1090004@redhat.com> References: <54355589.9060107@gmail.com> <54355799.1090004@redhat.com> Message-ID: <20141008155433.GH2328@redhat.com> On Wed, 08 Oct 2014, Rob Crittenden wrote: >Janelle wrote: >> Hi again >> >> Just wondering if anyone has found a work around to get freeipa >> installed on RHEL 7 -- the server works fine, but it never finishes the >> client install and you can't force a client install either. >> >> You end up with this in the logs, which I see has been reported, but >> wondering if fixed? >> >> stderr=Failed to issue method call: Unit fedora-domainname.service >> failed to load: No such file or directory. >> >> Thanks >> ~J >> > >It is being tracked in this ticket: >https://fedorahosted.org/freeipa/ticket/4562 > >You need to modify the installer to call to use rhel-domain.service >instead. I believe you need to modify >/usr/lib/python2*/site-packages/ipaplatform/fedora/services.py to make >the right call. Another alternative would be ln -s /lib/systemd/system/fedora-domainname.service /etc/systemd/system/rhel-domainname.service systemctl daemon-reload and then do install the IPA client. Kind of a hack until patches currently on review on freeipa-devel@ get merged. -- / Alexander Bokovoy From dpal at redhat.com Wed Oct 8 16:37:30 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 08 Oct 2014 12:37:30 -0400 Subject: [Freeipa-users] Migrate KRB DB hashes to IPA LDAP In-Reply-To: <54354073.5020904@kit.edu> References: <54354073.5020904@kit.edu> Message-ID: <5435684A.2010206@redhat.com> On 10/08/2014 09:47 AM, Andreas Ladanyi wrote: > Hello, > > i have the following situation: > > OpenLDAP with user entries. No userPassword hashes are available. > MIT Kerberos with principals and password hashes in the KRB DB. > > I have migrated the user and group accounts via "ipa migrate-ds ..." > successfully. > > Now, is it possible to get out the kerberos user principal password > hashes from the KRB own DB to the appropriate krbPassword..... IPA LDAP > attribute, so the users could login without any extra user action ? > > cheers, > Andy > > > This will be a highly manual process. AFAIR it has been done couple times so please search archives 2-3 years ago. Simo was the person who provided the steps. You would need to not only migrate the hashes by extracting the fields from DB and loading them into LDAP using raw LDAP commands and ldif but also copy over and set the kerberos master key. If you are up to it and dig out the instructions we would really appreciate if you can then put them on a wiki as a solution: http://www.freeipa.org/page/HowTos -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yiorgos-lists at stamoulis.eu Wed Oct 8 16:41:15 2014 From: yiorgos-lists at stamoulis.eu (Yiorgos Stamoulis) Date: Wed, 08 Oct 2014 16:41:15 +0000 Subject: [Freeipa-users] freeipa and RHEL 7 In-Reply-To: <54355589.9060107@gmail.com> References: <54355589.9060107@gmail.com> Message-ID: <3394ea09.DSq.Fz0.cg.1jds41XMHU@mailjet.com> Hi Janelle, as a temp fix you can subsitute fedora-domainname.service with rhel-domainname.service in the relevant files: perl -i -pe 's/fedora-domainname.service/rhel-domainname.service/g' /usr/lib/python2.7/site-packages/ipaplatform{/fedora,}/services.py Cheers Y On 08/10/14 15:17, Janelle wrote: > Hi again > > Just wondering if anyone has found a work around to get freeipa > installed on RHEL 7 -- the server works fine, but it never finishes > the client install and you can't force a client install either. > > You end up with this in the logs, which I see has been reported, but > wondering if fixed? > > stderr=Failed to issue method call: Unit fedora-domainname.service > failed to load: No such file or directory. > > Thanks > ~J > -------------- next part -------------- An HTML attachment was scrubbed... URL: From genadipost at gmail.com Wed Oct 8 16:58:55 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Wed, 8 Oct 2014 18:58:55 +0200 Subject: [Freeipa-users] Error: invalid 'AD domain controller' when establishing trust In-Reply-To: <20141008154820.GG2328@redhat.com> References: <20141008072427.GU31737@localhost.localdomain> <20141008121533.GD2328@redhat.com> <20141008154820.GG2328@redhat.com> Message-ID: 2014-10-08 17:48 GMT+02:00 Alexander Bokovoy : > On Wed, 08 Oct 2014, Genadi Postrilko wrote: > >> The forest root domain in my case is RED.COM. >> > You need to establish trust to red.com then. Any domain which is member > of the forest red.com will be visible through trust. > > Forest trust can only be established between forest root domains, that's > how it is designed by Microsoft. > > It doesn't matter how complex the forest is? Even if the forest contains number of domain trees, the trust has to be established with the forest root domain? >> I have attached the log files. >> > These logs show you are attempting to establish trust to blue.com which > is not a forest root domain, thus nothing works. > I assumed that DNS forwarding has to be created between IPA (linux.blue.com) and the AD (blue.com). Should any DNS configuration change? -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Oct 8 17:06:01 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 8 Oct 2014 20:06:01 +0300 Subject: [Freeipa-users] Error: invalid 'AD domain controller' when establishing trust In-Reply-To: References: <20141008072427.GU31737@localhost.localdomain> <20141008121533.GD2328@redhat.com> <20141008154820.GG2328@redhat.com> Message-ID: <20141008170601.GI2328@redhat.com> On Wed, 08 Oct 2014, Genadi Postrilko wrote: >2014-10-08 17:48 GMT+02:00 Alexander Bokovoy : > >> On Wed, 08 Oct 2014, Genadi Postrilko wrote: >> >>> The forest root domain in my case is RED.COM. >>> >> You need to establish trust to red.com then. Any domain which is member >> of the forest red.com will be visible through trust. >> >> Forest trust can only be established between forest root domains, that's >> how it is designed by Microsoft. >> >> >It doesn't matter how complex the forest is? Even if the forest contains >number of domain trees, the trust has to be >established with the forest root domain? Yes, see "Forest trusts" section of http://technet.microsoft.com/en-us/library/cc773178%28v=ws.10%29.aspx >>> I have attached the log files. >>> >> These logs show you are attempting to establish trust to blue.com which >> is not a forest root domain, thus nothing works. >> > >I assumed that DNS forwarding has to be created between IPA (linux.blue.com) >and the AD (blue.com). >Should any DNS configuration change? It should be between all AD domains which would use IPA services, namely forest root domain (red.com) and all other domains whose users will be accessing the trust (blue.com in your case). Usually this is solved globally, of course. -- / Alexander Bokovoy From janellenicole80 at gmail.com Wed Oct 8 20:06:51 2014 From: janellenicole80 at gmail.com (Janelle) Date: Wed, 08 Oct 2014 13:06:51 -0700 Subject: [Freeipa-users] freeipa and RHEL 7 In-Reply-To: <54355799.1090004@redhat.com> References: <54355589.9060107@gmail.com> <54355799.1090004@redhat.com> Message-ID: <5435995B.9060807@gmail.com> That worked - thanks everyone!! Now I need to do my part and find a bug and report it before others do :-) ~J On 10/8/14 8:26 AM, Rob Crittenden wrote: > Janelle wrote: >> Hi again >> >> Just wondering if anyone has found a work around to get freeipa >> installed on RHEL 7 -- the server works fine, but it never finishes the >> client install and you can't force a client install either. >> >> You end up with this in the logs, which I see has been reported, but >> wondering if fixed? >> >> stderr=Failed to issue method call: Unit fedora-domainname.service >> failed to load: No such file or directory. >> >> Thanks >> ~J >> > It is being tracked in this ticket: > https://fedorahosted.org/freeipa/ticket/4562 > > You need to modify the installer to call to use rhel-domain.service > instead. I believe you need to modify > /usr/lib/python2*/site-packages/ipaplatform/fedora/services.py to make > the right call. > > rob > From simo at redhat.com Wed Oct 8 21:55:30 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 8 Oct 2014 17:55:30 -0400 Subject: [Freeipa-users] Migrate KRB DB hashes to IPA LDAP In-Reply-To: <5435684A.2010206@redhat.com> References: <54354073.5020904@kit.edu> <5435684A.2010206@redhat.com> Message-ID: <20141008175530.7e4b779b@willson.usersys.redhat.com> On Wed, 08 Oct 2014 12:37:30 -0400 Dmitri Pal wrote: > On 10/08/2014 09:47 AM, Andreas Ladanyi wrote: > > Hello, > > > > i have the following situation: > > > > OpenLDAP with user entries. No userPassword hashes are available. > > MIT Kerberos with principals and password hashes in the KRB DB. > > > > I have migrated the user and group accounts via "ipa migrate-ds ..." > > successfully. > > > > Now, is it possible to get out the kerberos user principal password > > hashes from the KRB own DB to the appropriate krbPassword..... IPA > > LDAP attribute, so the users could login without any extra user > > action ? > > > > cheers, > > Andy > > > > > > > This will be a highly manual process. > AFAIR it has been done couple times so please search archives 2-3 > years ago. Simo was the person who provided the steps. > > You would need to not only migrate the hashes by extracting the > fields from DB and loading them into LDAP using raw LDAP commands and > ldif but also copy over and set the kerberos master key. > If you are up to it and dig out the instructions we would really > appreciate if you can then put them on a wiki as a solution: > http://www.freeipa.org/page/HowTos It can be attempted by dumping, filtering and then re-importing the KDC database. The tools to look at are kdb5_util/kdb5_ldap_util depending on what kdb database you used in the original realm. for importing in IPA you'd have to use kdb5_util with some additional options to prevent the driver from discarding your modify operations. I would strongly advise you to test this in a throwaway setup because it is likely you'll end up breaking something :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From amurty at deloitte.com Thu Oct 9 05:08:18 2014 From: amurty at deloitte.com (Murty, Ajeet (US - Arlington)) Date: Thu, 9 Oct 2014 05:08:18 +0000 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <54355CFA.9070101@redhat.com> References: <013068C38BB187448B7AB350AE98B35B38D56F66@USNDC1453.us.deloitte.com> <20141007101257.GA4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D56F99@USNDC1453.us.deloitte.com> <5433F638.306@redhat.com> <013068C38BB187448B7AB350AE98B35B38D577FF@USNDC1453.us.deloitte.com> <20141007164310.GH4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D578B2@USNDC1453.us.deloitte.com> <20141007170737.GI4683@redhat.com> <013068C38BB187448B7AB350AE98B35B38D578EC@USNDC1453.us.deloitte.com> <013068C38BB187448B7AB350AE98B35B38D58298@USNDC1453.us.deloitte.com> <20141008060047.GA2328@redhat.com> <013068C38BB187448B7AB350AE98B35B38D58408@USNDC1453.us.deloitte.com> <54355CFA.9070101@redhat.com> Message-ID: <013068C38BB187448B7AB350AE98B35B38D59527@USNDC1453.us.deloitte.com> That worked! I should have read the DS-389 documentation more carefully. I had to set nsSSL3Ciphers to the following - modifyTimestamp: 20140915221826Z nsSSL3Ciphers: +all,-rsa_null_sha numSubordinates: 1 Ran the scan again, and no Null Ciphers detected. Cipher configuration documentation for DS-389 - http://directory.fedoraproject.org/docs/389ds/design/nss-cipher-design.html Thanks! -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig Krispenz Sent: Wednesday, October 08, 2014 11:49 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports Hi, I did a test with 1.2.11.15-33 first test: nsSSL3Ciphers: +all running nmap gave: 636/tcp open ldapssl | ssl-enum-ciphers: | TLSv1.0: | ciphers: | SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA - strong | SSL_RSA_FIPS_WITH_DES_CBC_SHA - weak | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA - weak | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA - weak | TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - weak | TLS_RSA_EXPORT_WITH_RC4_40_MD5 - weak | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_DES_CBC_SHA - weak | TLS_RSA_WITH_NULL_SHA - broken <<<<<<<<<<<<<< | TLS_RSA_WITH_RC4_128_MD5 - strong | TLS_RSA_WITH_RC4_128_SHA - strong | compressors: | NULL |_ least strength: broken next test: nsSSL3Ciphers: +all,-rsa_null_sha nmap result: 636/tcp open ldapssl | ssl-enum-ciphers: | TLSv1.0: | ciphers: | SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA - strong | SSL_RSA_FIPS_WITH_DES_CBC_SHA - weak | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA - weak | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA - weak | TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - weak | TLS_RSA_EXPORT_WITH_RC4_40_MD5 - weak | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_DES_CBC_SHA - weak | TLS_RSA_WITH_RC4_128_MD5 - strong | TLS_RSA_WITH_RC4_128_SHA - strong | compressors: | NULL |_ least strength: weak maybe you can try adding "-rsa_null_sha" to your nSSL3cipher config. On 10/08/2014 09:10 AM, Murty, Ajeet (US - Arlington) wrote: > Understood. Thank you for clarifying all that. > I believe my best options at this point are to rebuild my environment on CentOS 7, enable COPR repo, and get the latest version of FreeIPA 4.x. > I will hold out for a few more weeks to see if someone at RedHat can provide a fix/patch for the older version. Fingers crossed. > > > -----Original Message----- > From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > Sent: Wednesday, October 08, 2014 2:01 AM > To: Murty, Ajeet (US - Arlington) > Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports > > On Wed, 08 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >> Any ideas on what else I can try here? >> Also, can we expect the new IPA and DS to be available in the CentOS/YUM repository in the next few weeks/months? > In general, FreeIPA team doesn't do backports to older versions due to > tight cooperation with other components when introducing new features. > We depend a lot on changes in 389-ds, Dogtag, MIT Kerberos, and SSSD, at least, > but also in Samba and other components, including Linux kernel. > > Backporting all the changes to older releases of certain distributions > is left to distribution maintainers. For Fedora we do have some freedom > on what can be done and try to maintain availability of FreeIPA releases > on two current versions but sometimes it is impossible due to update > polices -- Fedora 20 got 4.0.x upgrade via COPR repository while we are > cleaning up Fedora 21 for 4.1 support. > > In case of Red Hat Enterprise Linux releases, Red Hat itself (I cannot > speak for the company) makes decisions what to support and these > decisions are also based on certain stability promises for ABI, see > https://access.redhat.com/solutions/5154 for details. Some of components > FreeIPA depends on change their ABI and therefore the changes can only > be introduced in newer major releases. When these changes occurred, we > coordinated with Red Hat engineering teams to make sure most important > changes were folded into RHEL 7.0 release to provide a base for FreeIPA > integration. > > For CentOS, as it tracks corresponding Red Hat Enterprise Linux > releases, situation is similar. For packages that are not in RHEL/CentOS > releases there are means to provide them through a side channels, like > EPEL, but EPEL's policy prevents from packaging something that is > available through the main channels for the release. > > We use COPR repositories to make possible to install newer FreeIPA > versions on RHEL 7/CentOS 7/Fedora 20. However, these packages have no > official support from Red Hat or CentOS project. They are FreeIPA > upstream effort to make our releases more easily testable. For any issues > found through COPR repositories you are welcome to file tickets to > FreeIPA issue tracker at https://fedorahosted.org/freeipa/. > > >> Thanks again for all your help. >> >> >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Murty, Ajeet (US - Arlington) >> Sent: Tuesday, October 07, 2014 1:21 PM >> To: Alexander Bokovoy >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports >> >> I removed the new lines, looks like this now - >> >> modifyTimestamp: 20140915221826Z >> nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >> a_export1024_with_des_cbc_sha >> numSubordinates: 1 >> >> I am still seeing the null ciphers in my scan results. >> >> >> >> -----Original Message----- >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> Sent: Tuesday, October 07, 2014 1:08 PM >> To: Murty, Ajeet (US - Arlington) >> Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports >> >> On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >>> I shutdown IPA and modified both dse ldif files to look like this - >>> >>> nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >>> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >>> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >>> a_export1024_with_des_cbc_sha >>> >>> >>> Then, when I try to start up IPA, I get this error message - >>> >>> [root]# /etc/init.d/ipa start >>> Starting Directory Service >>> Starting dirsrv: >>> EXAMPLE-COM...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >>> [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed >>> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >> The lines above suggest that you actually separated nsSSL3Ciphers line > >from the entry itself. At least in my case it looks like this: >> dn: cn=encryption,cn=config >> objectClass: top >> objectClass: nsEncryptionConfig >> cn: encryption >> nsSSLSessionTimeout: 0 >> nsSSLClientAuth: allowed >> nsSSL2: off >> nsSSL3: off >> creatorsName: cn=server,cn=plugins,cn=config >> modifiersName: cn=directory manager >> createTimestamp: 20141001151245Z >> modifyTimestamp: 20141001151430Z >> nsSSL3Ciphers: +all >> allowWeakCipher: off >> numSubordinates: 1 >> >> note that it is part of cn=encryption,cn=config entry. You cannot >> separate attributes within the entry with empty lines because empty line >> finishes current entry and starts another one. >> >>> [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed >>> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >>> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 116) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. >>> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >>> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >>> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >>> a_export1024_with ...] >>> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >>> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 121) in file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif failed. >>> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] >>> [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] >>> [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. >>> [FAILED] >>> PKI-IPA...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >>> [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed >>> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >>> [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile /etc/dirsrv/slapd-PKI-IPA/dse.ldif was empty or could not be parsed >>> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >>> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 110) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. >>> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, >>> +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo >>> rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs >>> a_export1024_with ...] >>> [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn >>> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Parsing entry (lineno: 115) in file /etc/dirsrv/slapd-PKI-IPA/dse.ldif failed. >>> [07/Oct/2014:12:49:59 -0400] dse_read_one_file - Invalid section [numSubordinates: 1] >>> [07/Oct/2014:12:49:59 -0400] dse - Could not load config file [dse.ldif] >>> [07/Oct/2014:12:49:59 -0400] dse - Please edit the file to correct the reported problems and then restart the server. >>> [FAILED] >>> >>> >>> >>> >>> >>> >>> >>> This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. >>> >>> v.E.1 >>> >>> >>> -----Original Message----- >>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>> Sent: Tuesday, October 07, 2014 12:43 PM >>> To: Murty, Ajeet (US - Arlington) >>> Cc: Rob Crittenden; Rich Megginson; freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports >>> >>> On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: >>>> I was shutting down IPA before making any changes - >>>> >>>> 1. Shutdown IPA - >>>> >>>> [root]# /etc/init.d/ipa stop >>>> Stopping CA Service >>>> Stopping pki-ca: [ OK ] >>>> Stopping HTTP Service >>>> Stopping httpd: [ OK ] >>>> Stopping MEMCACHE Service >>>> Stopping ipa_memcached: [ OK ] >>>> Stopping KPASSWD Service >>>> Stopping Kerberos 5 Admin Server: [ OK ] >>>> Stopping KDC Service >>>> Stopping Kerberos 5 KDC: [ OK ] >>>> Stopping Directory Service >>>> Shutting down dirsrv: >>>> EXAMPLE-COM... [ OK ] >>>> PKI-IPA... [ OK ] >>>> >>>> 2. Edit 'dse.ldif' files to remove null ciphers - >>>> >>>> nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+ >>>> rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128 >>>> _sha,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha >>>> numSubordinates: 1 >>> I think Ludwig gave a good suggestion -- instead of removing them from >>> the list, prefix the *_null ciphers with -, i.e. -rsa_null_md5, -fortezza_null. >>> The way nsSSL3Ciphers attribute works, is by modifying default NSS >>> ciphers list, with + and - to add and remove the ciphers accordingly. >>> >>> -- >>> / Alexander Bokovoy >> -- >> / Alexander Bokovoy >> >> -- >> 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 From natxo.asenjo at gmail.com Thu Oct 9 06:42:09 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 9 Oct 2014 08:42:09 +0200 Subject: [Freeipa-users] kdc certificate web interface expiration warning Message-ID: hi, today our monitoring system started warning us that the web ui certificate for our first kdc will expire in 30 days. I have checked manually with this command: $ sudo getcert list |grep auto-renew auto-renew: yes auto-renew: yes auto-renew: yes auto-renew: yes auto-renew: yes auto-renew: yes auto-renew: yes auto-renew: yes So it should all be fine, right? Just checking..., I will probably not be at the office in 30 days so I just want to make sure things will keep working here. Or is there a way to manually renew those certs? Thanks! -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Thu Oct 9 12:06:01 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 9 Oct 2014 14:06:01 +0200 Subject: [Freeipa-users] kdc certificate web interface expiration warning In-Reply-To: References: Message-ID: On Thu, Oct 9, 2014 at 8:42 AM, Natxo Asenjo wrote: > > hi, > > today our monitoring system started warning us that the web ui certificate for our first kdc will expire in 30 days. > > I have checked manually with this command: > > $ sudo getcert list |grep auto-renew auto-renew: yes > auto-renew: yes > auto-renew: yes > auto-renew: yes > auto-renew: yes > auto-renew: yes > auto-renew: yes > auto-renew: yes > > So it should all be fine, right? Just checking..., I will probably not be at the office in 30 days so I just want to make sure things will keep working here. from http://www.freeipa.org/page/Certmonger: The expiration date is UTC. By default certmonger will start trying to renew the certificate 28 days before it expires. | Or is there a way to manually renew those certs? http://www.freeipa.org/page/Certmonger#Manually_renew_a_certificate Manually renew a certificate If you want to manually renew a certificate prior to its expiration date, run: # ipa-getcert resubmit -i REQUEST_ID so I will just wait 2 days and see if it has automatically renewed; otherwise renew it. I must say that certmonger is an awesome piece of work. -- Groeten, natxo From natxo.asenjo at gmail.com Thu Oct 9 12:33:48 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 9 Oct 2014 14:33:48 +0200 Subject: [Freeipa-users] yet another certificate question Message-ID: hi, if during the enrollment of a host a host certificate is created, then this will be a nssdb type certificate. However, lots of applications use file certificates and we can very easily create one of those (even using configuration management tools): /usr/bin/ipa-getcert request -r -f /etc/pki/tls/certs/`hostname --fqdn`.crt -k /etc/pki/tls/private/`hostname --fqdn`.key getcert list will see both, but in the ipa web interface in the host information only the last one will be shown. Is this a problem? -- Groeten, natxo From natxo.asenjo at gmail.com Thu Oct 9 13:03:19 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 9 Oct 2014 15:03:19 +0200 Subject: [Freeipa-users] yet another certificate question In-Reply-To: References: Message-ID: On Thu, Oct 9, 2014 at 2:33 PM, Natxo Asenjo wrote: > hi, > > if during the enrollment of a host a host certificate is created, then > this will be a nssdb type certificate. > > However, lots of applications use file certificates and we can very > easily create one of those (even using configuration management > tools): > > /usr/bin/ipa-getcert request -r -f /etc/pki/tls/certs/`hostname > --fqdn`.crt -k /etc/pki/tls/private/`hostname --fqdn`.key > > getcert list will see both, but in the ipa web interface in the host > information only the last one will be shown. well, replying to mysel, the attribute userCertificate appears to be single valued. So that must be why. So what happens with the other certificate in the nssdb directory? Can I just stop tracking it locally? Or do I have to stop tracking it because it will try to auto renew when it expires, and that will block the file certificate? Tips welcome! -- groet, natxo From rcritten at redhat.com Thu Oct 9 15:39:23 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 09 Oct 2014 11:39:23 -0400 Subject: [Freeipa-users] yet another certificate question In-Reply-To: References: Message-ID: <5436AC2B.9060900@redhat.com> Natxo Asenjo wrote: > On Thu, Oct 9, 2014 at 2:33 PM, Natxo Asenjo wrote: >> hi, >> >> if during the enrollment of a host a host certificate is created, then >> this will be a nssdb type certificate. >> >> However, lots of applications use file certificates and we can very >> easily create one of those (even using configuration management >> tools): >> >> /usr/bin/ipa-getcert request -r -f /etc/pki/tls/certs/`hostname >> --fqdn`.crt -k /etc/pki/tls/private/`hostname --fqdn`.key >> >> getcert list will see both, but in the ipa web interface in the host >> information only the last one will be shown. > > well, replying to mysel, the attribute userCertificate appears to be > single valued. So that must be why. > > So what happens with the other certificate in the nssdb directory? Can > I just stop tracking it locally? Or do I have to stop tracking it > because it will try to auto renew when it expires, and that will block > the file certificate? I was going to wait a bit as you've seem to be doing a great job answering your own questions in this thread :-) As you've discovered, it's one cert per service (or host). What you aren't seeing is that when you request another cert for the same service any existing certificate is revoked. If/when you start using OCSP or CRLs you'll see it big time. I think renewal will work ok for both but the last one would "win" and all others would end up being marked as revoked. So yeah, you should stop tracking it. I suspect that unless the renewal happened simultaneously both would end up renewed, but one would be revoked (last one wins). You may want to look into per-service certificates using the -K option to ipa-getcert. This will require pre-creating the services in IPA to store the certificate but otherwise it will function the same way. rob From carlosla1987 at gmail.com Thu Oct 9 20:38:13 2014 From: carlosla1987 at gmail.com (=?UTF-8?Q?Carlos_Ra=C3=BAl_Laguna?=) Date: Thu, 9 Oct 2014 16:38:13 -0400 Subject: [Freeipa-users] Migration from FreeIPA-Windows to FreeIPA-samba4 Message-ID: Hello to everyone, for some time now i have been pretty much stalking the samba project site, looking forward to forest trust and it seem that they introduced new functions to support trust domains https://download.samba.org/pub/samba/rc/WHATSNEW-4.2.0rc1.txt i guess i an future will be possible. Anyway, i am about to do a FreeIPA-Windows deployment and i was wondering if it will be possible in a future migrate from windows to samba? And also, which version of FreeIPA is most ready for deployment ? Thanks for your time and effort. Regard -------------- next part -------------- An HTML attachment was scrubbed... URL: From sallen at theembassyvfx.com Thu Oct 9 21:27:53 2014 From: sallen at theembassyvfx.com (Scott Allen) Date: Thu, 9 Oct 2014 14:27:53 -0700 Subject: [Freeipa-users] FreeIPA 3.0, OSX 10.7 and 10.8, and secondary groups Message-ID: Hello, I have managed to get most of the functionality working with OSX and FreeIPA. What I cannot seem to get is the secondary groups working. Posix security is working for primary groups but the security for people with a secondary group doesn't work. I can see in the Directory Utility on OSX that each user has it's own group created and the secondary groups are in there. As well, I have a mapping that connected groupMember to memberUid which I have read is the correct way to do this. Here is what I get when I go 'dscl -read` on OSX 10.8 asking about the production group. --------- dscl -read /LDAPv3/192.168.x.x/Groups/production dsAttrTypeNative:description: producers and budget access for documents dsAttrTypeNative:ipaUniqueID: db1a2b38-4440-11e4-a2aa-00304881a4bc dsAttrTypeNative:member: uid=alapierre,cn=users,cn=accounts,dc=embassy,dc=vfx uid=danielle,cn=users,cn=accounts,dc=embassy,dc=vfx uid=ran,cn=users,cn=accounts,dc=embassy,dc=vfx uid=winston,cn=users,cn=accounts,dc=embassy,dc=vfx uid=trevor,cn=users,cn=accounts,dc=embassy,dc=vfx dsAttrTypeNative:objectClass: top groupofnames nestedgroup ipausergroup ipaobject posixgroup AppleMetaNodeLocation: /LDAPv3/192.168.4.150 AppleMetaRecordName: cn=production,cn=groups,cn=accounts,dc=embassy,dc=vfx PrimaryGroupID: 55400020 RecordName: production RecordType: dsRecTypeStandard:Groups ------ However, when I type `groups` on the Mac, production isn't there and if I `id` one of the members of the group, they do not show the secondary group. So I guess I am wondering how do I get OSX access control to use the ALL the info that it already sees from FreeIPA? Thanks Scott A -- Scott Allen Head of IT The Embassy Visual Effects Inc. 4th Floor - 177 W 7th Avenue Vancouver, B.C. V5Y 1L8 604.696.6862 ext 239 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Oct 9 22:12:59 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 09 Oct 2014 18:12:59 -0400 Subject: [Freeipa-users] Migration from FreeIPA-Windows to FreeIPA-samba4 In-Reply-To: References: Message-ID: <5437086B.5010403@redhat.com> On 10/09/2014 04:38 PM, Carlos Ra?l Laguna wrote: > Hello to everyone, for some time now i have been pretty much stalking > the samba project site, looking forward to forest trust and it seem > that they introduced new functions to support trust domains > https://download.samba.org/pub/samba/rc/WHATSNEW-4.2.0rc1.txt i guess > i an future will be possible. > Yes in future. > Anyway, i am about to do a FreeIPA-Windows deployment and i was > wondering if it will be possible in a future migrate from windows to > samba? Yes. This is the intent. At least to be able to replace AD with Samba DC in some cases. I am not sure how smooth the "migration" part will be. > And also, which version of FreeIPA is most ready for deployment ? Now? In which distro? In RHEL please use what is in 7.0. If you use Fedora then at least 4.0. You might want to wait couple weeks and use 4.1 when it gets released. > Thanks for your time and effort. Regard > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From genadipost at gmail.com Thu Oct 9 23:07:47 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Fri, 10 Oct 2014 01:07:47 +0200 Subject: [Freeipa-users] Error: invalid 'AD domain controller' when establishing trust In-Reply-To: <20141008170601.GI2328@redhat.com> References: <20141008072427.GU31737@localhost.localdomain> <20141008121533.GD2328@redhat.com> <20141008154820.GG2328@redhat.com> <20141008170601.GI2328@redhat.com> Message-ID: Thank you for providing the reference. I understood that when creating a forest trust between two AD forests, the trust is transitive to all domains in both forests (by default). And it has to be established between the two forest root domain. External trust (between AD forests or domains), is non transitive. Trust can be established between (child) domains in different forests, without the need to create trust between child domains and the forest root domain of the opposite forest. But i'm not sure about Realm Trust. Realm Trust considered as a kind of forest trust? And that why the trust has to be established between the forest root domains (and not like external trust) ? Assuming i follow the IPA Trust setup guide- The trust created between red.com (AD forest root domain) and linux.blue.com (IPA domain) is configured to be transitive? Users from blue.com domain will able to login to IPA domain? And so are users from other child and root domains in the forest? 2014-10-08 19:06 GMT+02:00 Alexander Bokovoy : > On Wed, 08 Oct 2014, Genadi Postrilko wrote: > >> 2014-10-08 17:48 GMT+02:00 Alexander Bokovoy : >> >> On Wed, 08 Oct 2014, Genadi Postrilko wrote: >>> >>> The forest root domain in my case is RED.COM. >>>> >>>> You need to establish trust to red.com then. Any domain which is >>> member >>> of the forest red.com will be visible through trust. >>> >>> Forest trust can only be established between forest root domains, that's >>> how it is designed by Microsoft. >>> >>> >>> It doesn't matter how complex the forest is? Even if the forest contains >> number of domain trees, the trust has to be >> established with the forest root domain? >> > Yes, see "Forest trusts" section of > http://technet.microsoft.com/en-us/library/cc773178%28v=ws.10%29.aspx > > I have attached the log files. >>>> >>>> These logs show you are attempting to establish trust to blue.com >>> which >>> is not a forest root domain, thus nothing works. >>> >>> >> I assumed that DNS forwarding has to be created between IPA ( >> linux.blue.com) >> and the AD (blue.com). >> Should any DNS configuration change? >> > It should be between all AD domains which would use IPA services, namely > forest root domain (red.com) and all other domains whose users will be > accessing the trust (blue.com in your case). > > Usually this is solved globally, of course. > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Oct 10 00:36:58 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 09 Oct 2014 20:36:58 -0400 Subject: [Freeipa-users] Error: invalid 'AD domain controller' when establishing trust In-Reply-To: References: <20141008072427.GU31737@localhost.localdomain> <20141008121533.GD2328@redhat.com> <20141008154820.GG2328@redhat.com> <20141008170601.GI2328@redhat.com> Message-ID: <54372A2A.2020603@redhat.com> On 10/09/2014 07:07 PM, Genadi Postrilko wrote: > Thank you for providing the reference. > I understood that when creating a forest trust between two AD forests, > the trust is transitive to all domains in both forests (by default). > And it has > to be established between the two forest root domain. > > External trust (between AD forests or domains), is non transitive. > Trust can be established between (child) domains in different forests, > without the need to > create trust between child domains and the forest root domain of > the opposite forest. > > But i'm not sure about Realm Trust. > Realm Trust considered as a kind of forest trust? And that why the > trust has > to be established between the forest root domains (and not like > external trust) ? > > Assuming i follow the IPA Trust setup guide- > The trust created between red.com (AD forest root > domain) and linux.blue.com (IPA domain) > is configured to be transitive? Users from blue.com > domain will able to login to IPA domain? > And so are users from other child and root domains in the forest? Yes. If you have forest trust between IPA and your AD forest where red is the root domain then users from all subdomains including blue would be able to access resources in the IPA domain. This is true starting freeipa 3.3. > > > > > 2014-10-08 19:06 GMT+02:00 Alexander Bokovoy >: > > On Wed, 08 Oct 2014, Genadi Postrilko wrote: > > 2014-10-08 17:48 GMT+02:00 Alexander Bokovoy > >: > > On Wed, 08 Oct 2014, Genadi Postrilko wrote: > > The forest root domain in my case is RED.COM > . > > You need to establish trust to red.com > then. Any domain which is member > of the forest red.com will be visible > through trust. > > Forest trust can only be established between forest root > domains, that's > how it is designed by Microsoft. > > > It doesn't matter how complex the forest is? Even if the > forest contains > number of domain trees, the trust has to be > established with the forest root domain? > > Yes, see "Forest trusts" section of > http://technet.microsoft.com/en-us/library/cc773178%28v=ws.10%29.aspx > > I have attached the log files. > > These logs show you are attempting to establish trust to > blue.com which > is not a forest root domain, thus nothing works. > > > I assumed that DNS forwarding has to be created between IPA > (linux.blue.com ) > and the AD (blue.com ). > Should any DNS configuration change? > > It should be between all AD domains which would use IPA services, > namely > forest root domain (red.com ) and all other > domains whose users will be > accessing the trust (blue.com in your case). > > Usually this is solved globally, of course. > -- > / Alexander Bokovoy > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Oct 10 04:26:27 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 10 Oct 2014 07:26:27 +0300 Subject: [Freeipa-users] Error: invalid 'AD domain controller' when establishing trust In-Reply-To: References: <20141008072427.GU31737@localhost.localdomain> <20141008121533.GD2328@redhat.com> <20141008154820.GG2328@redhat.com> <20141008170601.GI2328@redhat.com> Message-ID: <20141010042627.GW2328@redhat.com> On Fri, 10 Oct 2014, Genadi Postrilko wrote: >Thank you for providing the reference. >I understood that when creating a forest trust between two AD forests, >the trust is transitive to all domains in both forests (by default). >And it has to be established between the two forest root domain. > >External trust (between AD forests or domains), is non transitive. >Trust can be established between (child) domains in different forests, >without the need to create trust between child domains and the forest >root domain of the opposite forest. > >But i'm not sure about Realm Trust. >Realm Trust considered as a kind of forest trust? And that why the trust >has to be established between the forest root domains (and not like >external trust) ? FreeIPA only provides the first type of the trust -- a forest trust to AD where AD thinks it trusts an AD forest. All other types of forest are irrelevant in this context and have no implementation or support in FreeIPA. > >Assuming i follow the IPA Trust setup guide- >The trust created between red.com (AD forest root domain) and >linux.blue.com (IPA domain) is configured to be transitive? Users from >blue.com domain will able to login to IPA domain? And so are users >from other child and root domains in the forest? Yes, and yes. You have ipa trustdomain-find|del|disable|enable commands to manage what domains from the trust can have access to IPA resources. Forest root domain is always allowed, you cannot disable it, only delete the whole trust. > > > > >2014-10-08 19:06 GMT+02:00 Alexander Bokovoy : > >> On Wed, 08 Oct 2014, Genadi Postrilko wrote: >> >>> 2014-10-08 17:48 GMT+02:00 Alexander Bokovoy : >>> >>> On Wed, 08 Oct 2014, Genadi Postrilko wrote: >>>> >>>> The forest root domain in my case is RED.COM. >>>>> >>>>> You need to establish trust to red.com then. Any domain which is >>>> member >>>> of the forest red.com will be visible through trust. >>>> >>>> Forest trust can only be established between forest root domains, that's >>>> how it is designed by Microsoft. >>>> >>>> >>>> It doesn't matter how complex the forest is? Even if the forest contains >>> number of domain trees, the trust has to be >>> established with the forest root domain? >>> >> Yes, see "Forest trusts" section of >> http://technet.microsoft.com/en-us/library/cc773178%28v=ws.10%29.aspx >> >> I have attached the log files. >>>>> >>>>> These logs show you are attempting to establish trust to blue.com >>>> which >>>> is not a forest root domain, thus nothing works. >>>> >>>> >>> I assumed that DNS forwarding has to be created between IPA ( >>> linux.blue.com) >>> and the AD (blue.com). >>> Should any DNS configuration change? >>> >> It should be between all AD domains which would use IPA services, namely >> forest root domain (red.com) and all other domains whose users will be >> accessing the trust (blue.com in your case). >> >> Usually this is solved globally, of course. >> -- >> / Alexander Bokovoy >> -- / Alexander Bokovoy From jpazdziora at redhat.com Fri Oct 10 08:32:45 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 10 Oct 2014 10:32:45 +0200 Subject: [Freeipa-users] FW: FW: FW: named and IpA In-Reply-To: <5432C5A3.4060003@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <542E5DAF.2090706@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2057@G6W2496.americas.hpqcorp.net> <54324B50.2050907@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C243C@G6W2496.americas.hpqcorp.net> <5432A8A1.2040707@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C24C8@G6W2496.americas.hpqcorp.net> <5432C5A3.4060003@redhat.com> Message-ID: <20141010083245.GB11376@redhat.com> On Mon, Oct 06, 2014 at 06:38:59PM +0200, Petr Spacek wrote: > On 6.10.2014 17:22, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: > >Thanks for the additional data. It starts to make sense now, but I'm wondering if that could possibly be a weakness > >in the IdM model ? > > Well, define a weakness :-) > > Whole IPA server is built around LDAP database so LDAP is single point of > failure *for one particular* IPA server. > > IPA offers a solution called "replicas". You can have multiple IPA servers > with (two-way) replicated LDAP database so outage on N-1 servers will not > affect your clients as long as clients are able to fail-over to the last > functional server. The question is, what should happen when no LDAP server can be used? Should the forwarding suddenly kick in for all zones which will cause completely different data to be served? Or should the DNS server refuse to serve anything at that point (even the forwarding) because it has no way to know what should be forwarded and what not (I assume bind does not keep around list of zones that were LDAP-backed the last time LDAP worked). There probably should be at least an option (if not default) for bind to serve nothing if LDAP is not accessible. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From sipazzo at yahoo.com Fri Oct 10 22:34:22 2014 From: sipazzo at yahoo.com (sipazzo) Date: Fri, 10 Oct 2014 15:34:22 -0700 Subject: [Freeipa-users] Solaris 10 client configuration using profile Message-ID: <1412980462.30218.YahooMailBasic@web122506.mail.ne1.yahoo.com> Hello, I am trying to set up a default profile for my Solaris 10 IPA clients as recommended. I generated a profile on a Solaris with the attributes I needed except I got an "invalid parameter" error when specifying the domainName attribute like this -a domainName=example.com even though this parameter works when I use it in ldapclient manual. More of an issue though is I have been unable to find documentation on getting the profile incorporated into the ipa server. How do I get this profile on the ipa server and make it available to my Solaris clients? Also, my understanding is the clients periodically check this profile so they stay updated with the latest configuration information. What generates this check? Is it time based, a restart of a service or ?? Thank you for any assistance. From rcritten at redhat.com Fri Oct 10 23:53:51 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 10 Oct 2014 19:53:51 -0400 Subject: [Freeipa-users] Solaris 10 client configuration using profile In-Reply-To: <1412980462.30218.YahooMailBasic@web122506.mail.ne1.yahoo.com> References: <1412980462.30218.YahooMailBasic@web122506.mail.ne1.yahoo.com> Message-ID: <5438718F.5050407@redhat.com> sipazzo wrote: > Hello, I am trying to set up a default profile for my Solaris 10 IPA clients as recommended. I generated a profile on a Solaris with the attributes I needed except I got an "invalid parameter" error when specifying the domainName attribute like this -a domainName=example.com even though this parameter works when I use it in ldapclient manual. More of an issue though is I have been unable to find documentation on getting the profile incorporated into the ipa server. How do I get this profile on the ipa server and make it available to my Solaris clients? Also, my understanding is the clients periodically check this profile so they stay updated with the latest configuration information. What generates this check? Is it time based, a restart of a service or ?? > > Thank you for any assistance. > It's been forever since I configured a Solaris anything client but I can tell you where the profile gets stored: cn=profilename,cn=default,ou=profile,$SUFFIX IPA ships with a default profile of: dn: cn=default,ou=profile,$SUFFIX ObjectClass: top ObjectClass: DUAConfigProfile defaultServerList: $FQDN defaultSearchBase: $SUFFIX authenticationMethod: none searchTimeLimit: 15 cn: default serviceSearchDescriptor: passwd:cn=users,cn=accounts,$SUFFIX serviceSearchDescriptor: group:cn=groups,cn=compat,$SUFFIX bindTimeLimit: 5 objectClassMap: shadow:shadowAccount=posixAccount followReferrals:TRUE The full schema can be found at http://docs.oracle.com/cd/E23824_01/html/821-1455/schemas-17.html So if your profile is named foo you'd invoke it with something like: # ldapclient init -a profileName=foo ipa.example.com rob From rcritten at redhat.com Sat Oct 11 17:10:06 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 11 Oct 2014 13:10:06 -0400 Subject: [Freeipa-users] Solaris 10 client configuration using profile In-Reply-To: <1412986404.75392.YahooMailBasic@web122503.mail.ne1.yahoo.com> References: <1412986404.75392.YahooMailBasic@web122503.mail.ne1.yahoo.com> Message-ID: <5439646E.3010906@redhat.com> sipazzo wrote: > Thank you,I know where the profile is in the directory tree and how I would invoke it were it there...I don't know how to get it into the directory tree so that it is available to clients. I see posts giving examples of different profilesthat could be used but no post as to how to add it to the directory. Sorry if I am missing something obvious. > > > -------------------------------------------- > On Fri, 10/10/14, Rob Crittenden wrote: > > Subject: Re: [Freeipa-users] Solaris 10 client configuration using profile > To: "sipazzo" , freeipa-users at redhat.com > Date: Friday, October 10, 2014, 4:53 PM > > sipazzo wrote: > > > Hello, I am trying to set up a default profile for my > Solaris 10 IPA clients as recommended. I generated a profile > on a Solaris with the attributes I needed except I got an > "invalid parameter" error when specifying the > domainName attribute like this -a domainName=example.com > even though this parameter works when I use it in > ldapclient manual. More of an issue though is I have been > unable to find documentation on getting the profile > incorporated into the ipa server. How do I get this profile > on the ipa server and make it available to my Solaris > clients? Also, my understanding is the clients periodically > check this profile so they stay updated with the latest > configuration information. What generates this check? Is it > time based, a restart of a service or ?? > > > > Thank you for any > assistance. > > > > It's been forever since I configured a > Solaris anything client but I can > tell you > where the profile gets stored: > cn=profilename,cn=default,ou=profile,$SUFFIX > > IPA ships with a default > profile of: > > dn: > cn=default,ou=profile,$SUFFIX > ObjectClass: > top > ObjectClass: DUAConfigProfile > defaultServerList: $FQDN > defaultSearchBase: $SUFFIX > authenticationMethod: none > searchTimeLimit: 15 > cn: > default > serviceSearchDescriptor: > passwd:cn=users,cn=accounts,$SUFFIX > serviceSearchDescriptor: > group:cn=groups,cn=compat,$SUFFIX > bindTimeLimit: 5 > objectClassMap: > shadow:shadowAccount=posixAccount > followReferrals:TRUE > > The full schema can be found at > http://docs.oracle.com/cd/E23824_01/html/821-1455/schemas-17.html > > So if your profile is named > foo you'd invoke it with something like: > > # ldapclient init -a > profileName=foo ipa.example.com > > rob > > Here is an example inspired by https://bugzilla.redhat.com/show_bug.cgi?id=815515 $ ldapmodify -x -D 'cn=Directory Manager' -W dn: cn=solaris_authssl_test,ou=profile,dc=example,dc=com objectClass: top objectClass: DUAConfigProfile cn: solaris_authssl_test authenticationMethod: tls:simple bindTimeLimit: 5 credentialLevel: proxy defaultSearchBase: dc=example,dc=com defaultSearchScope: one defaultServerList: ipa01.example.com ipa02.example.com ipa03.example.com followReferrals: TRUE objectclassMap: shadow:shadowAccount=posixAccount objectclassMap: printers:sunPrinter=printerService preferredServerList: ipa01.example.com ipa02.example.com profileTTL: 6000 searchTimeLimit: 10 serviceSearchDescriptor: passwd:cn=users,cn=accounts,dc=example,dc=com serviceSearchDescriptor: group:cn=groups,cn=compat,dc=example,dc=com serviceSearchDescriptor: netgroup:cn=ng,cn=compat,dc=example,dc=com serviceSearchDescriptor: ethers:cn=computers,cn=accounts,dc=example,dc=com serviceSearchDescriptor: automount:cn=default,cn=automount,dc=example,dc=com serviceSearchDescriptor: auto_master:automountMapName=auto.master,cn=defualt,cn=automount,dc=example,dc=com serviceSearchDescriptor: aliases:ou=aliases,ou=test,dc=example,dc=com serviceSearchDescriptor: printers:ou=printers,ou=test,dc=example,dc=com ^D You may want to check out https://bugzilla.redhat.com/show_bug.cgi?id=815533 as well. rob From mohammadsereshki at yahoo.com Sat Oct 11 17:38:22 2014 From: mohammadsereshki at yahoo.com (mohammad sereshki) Date: Sat, 11 Oct 2014 10:38:22 -0700 Subject: [Freeipa-users] Solaris 10 client configuration using profile In-Reply-To: <5439646E.3010906@redhat.com> References: <1412986404.75392.YahooMailBasic@web122503.mail.ne1.yahoo.com> <5439646E.3010906@redhat.com> Message-ID: <1413049102.28991.YahooMailNeo@web161506.mail.bf1.yahoo.com> Dear I have done steps of be;low link for solaris 10 and it works fine. Re: [Freeipa-users] Does Solaris 11 work as client to IPA server? Re: [Freeipa-users] Does Solaris 11 work as client to IPA server? [Date Prev][Date Next] [Thread Prev][Thread Next] [Thread Index] [Date Index] [Author Index] Re: [Freeipa-users] Does Solaris 11 work as client to IPA server? View on www.redhat.com Preview by Yahoo ________________________________ From: Rob Crittenden To: sipazzo ; "Freeipa-users at redhat.com" Sent: Saturday, October 11, 2014 8:40 PM Subject: Re: [Freeipa-users] Solaris 10 client configuration using profile sipazzo wrote: > Thank you,I know where the profile is in the directory tree and how I would invoke it were it there...I don't know how to get it into the directory tree so that it is available to clients. I see posts giving examples of different profilesthat could be used but no post as to how to add it to the directory. Sorry if I am missing something obvious. > > > -------------------------------------------- > On Fri, 10/10/14, Rob Crittenden wrote: > > Subject: Re: [Freeipa-users] Solaris 10 client configuration using profile > To: "sipazzo" , freeipa-users at redhat.com > Date: Friday, October 10, 2014, 4:53 PM > > sipazzo wrote: > > > Hello, I am trying to set up a default profile for my > Solaris 10 IPA clients as recommended. I generated a profile > on a Solaris with the attributes I needed except I got an > "invalid parameter" error when specifying the > domainName attribute like this -a domainName=example.com > even though this parameter works when I use it in > ldapclient manual. More of an issue though is I have been > unable to find documentation on getting the profile > incorporated into the ipa server. How do I get this profile > on the ipa server and make it available to my Solaris > clients? Also, my understanding is the clients periodically > check this profile so they stay updated with the latest > configuration information. What generates this check? Is it > time based, a restart of a service or ?? > > > > Thank you for any > assistance. > > > > It's been forever since I configured a > Solaris anything client but I can > tell you > where the profile gets stored: > cn=profilename,cn=default,ou=profile,$SUFFIX > > IPA ships with a default > profile of: > > dn: > cn=default,ou=profile,$SUFFIX > ObjectClass: > top > ObjectClass: DUAConfigProfile > defaultServerList: $FQDN > defaultSearchBase: $SUFFIX > authenticationMethod: none > searchTimeLimit: 15 > cn: > default > serviceSearchDescriptor: > passwd:cn=users,cn=accounts,$SUFFIX > serviceSearchDescriptor: > group:cn=groups,cn=compat,$SUFFIX > bindTimeLimit: 5 > objectClassMap: > shadow:shadowAccount=posixAccount > followReferrals:TRUE > > The full schema can be found at > http://docs.oracle.com/cd/E23824_01/html/821-1455/schemas-17.html > > So if your profile is named > foo you'd invoke it with something like: > > # ldapclient init -a > profileName=foo ipa.example.com > > rob > > Here is an example inspired by https://bugzilla.redhat.com/show_bug.cgi?id=815515 $ ldapmodify -x -D 'cn=Directory Manager' -W dn: cn=solaris_authssl_test,ou=profile,dc=example,dc=com objectClass: top objectClass: DUAConfigProfile cn: solaris_authssl_test authenticationMethod: tls:simple bindTimeLimit: 5 credentialLevel: proxy defaultSearchBase: dc=example,dc=com defaultSearchScope: one defaultServerList: ipa01.example.com ipa02.example.com ipa03.example.com followReferrals: TRUE objectclassMap: shadow:shadowAccount=posixAccount objectclassMap: printers:sunPrinter=printerService preferredServerList: ipa01.example.com ipa02.example.com profileTTL: 6000 searchTimeLimit: 10 serviceSearchDescriptor: passwd:cn=users,cn=accounts,dc=example,dc=com serviceSearchDescriptor: group:cn=groups,cn=compat,dc=example,dc=com serviceSearchDescriptor: netgroup:cn=ng,cn=compat,dc=example,dc=com serviceSearchDescriptor: ethers:cn=computers,cn=accounts,dc=example,dc=com serviceSearchDescriptor: automount:cn=default,cn=automount,dc=example,dc=com serviceSearchDescriptor: auto_master:automountMapName=auto.master,cn=defualt,cn=automount,dc=example,dc=com serviceSearchDescriptor: aliases:ou=aliases,ou=test,dc=example,dc=com serviceSearchDescriptor: printers:ou=printers,ou=test,dc=example,dc=com ^D You may want to check out https://bugzilla.redhat.com/show_bug.cgi?id=815533 as well. rob -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Sat Oct 11 17:54:49 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 11 Oct 2014 20:54:49 +0300 Subject: [Freeipa-users] Solaris 10 client configuration using profile In-Reply-To: <5439646E.3010906@redhat.com> References: <1412986404.75392.YahooMailBasic@web122503.mail.ne1.yahoo.com> <5439646E.3010906@redhat.com> Message-ID: <20141011175449.GG2328@redhat.com> On Sat, 11 Oct 2014, Rob Crittenden wrote: >sipazzo wrote: >> Thank you,I know where the profile is in the directory tree and how I would invoke it were it there...I don't know how to get it into the directory tree so that it is available to clients. I see posts giving examples of different profilesthat could be used but no post as to how to add it to the directory. Sorry if I am missing something obvious. >> >> >> -------------------------------------------- >> On Fri, 10/10/14, Rob Crittenden wrote: >> >> Subject: Re: [Freeipa-users] Solaris 10 client configuration using profile >> To: "sipazzo" , freeipa-users at redhat.com >> Date: Friday, October 10, 2014, 4:53 PM >> >> sipazzo wrote: >> > >> Hello, I am trying to set up a default profile for my >> Solaris 10 IPA clients as recommended. I generated a profile >> on a Solaris with the attributes I needed except I got an >> "invalid parameter" error when specifying the >> domainName attribute like this -a domainName=example.com >> even though this parameter works when I use it in >> ldapclient manual. More of an issue though is I have been >> unable to find documentation on getting the profile >> incorporated into the ipa server. How do I get this profile >> on the ipa server and make it available to my Solaris >> clients? Also, my understanding is the clients periodically >> check this profile so they stay updated with the latest >> configuration information. What generates this check? Is it >> time based, a restart of a service or ?? >> > >> > Thank you for any >> assistance. >> > >> >> It's been forever since I configured a >> Solaris anything client but I can >> tell you >> where the profile gets stored: >> cn=profilename,cn=default,ou=profile,$SUFFIX >> >> IPA ships with a default >> profile of: >> >> dn: >> cn=default,ou=profile,$SUFFIX >> ObjectClass: >> top >> ObjectClass: DUAConfigProfile >> defaultServerList: $FQDN >> defaultSearchBase: $SUFFIX >> authenticationMethod: none >> searchTimeLimit: 15 >> cn: >> default >> serviceSearchDescriptor: >> passwd:cn=users,cn=accounts,$SUFFIX >> serviceSearchDescriptor: >> group:cn=groups,cn=compat,$SUFFIX >> bindTimeLimit: 5 >> objectClassMap: >> shadow:shadowAccount=posixAccount >> followReferrals:TRUE >> >> The full schema can be found at >> http://docs.oracle.com/cd/E23824_01/html/821-1455/schemas-17.html >> >> So if your profile is named >> foo you'd invoke it with something like: >> >> # ldapclient init -a >> profileName=foo ipa.example.com >> >> rob >> >> > >Here is an example inspired by >https://bugzilla.redhat.com/show_bug.cgi?id=815515 > >$ ldapmodify -x -D 'cn=Directory Manager' -W >dn: cn=solaris_authssl_test,ou=profile,dc=example,dc=com >objectClass: top >objectClass: DUAConfigProfile >cn: solaris_authssl_test >authenticationMethod: tls:simple >bindTimeLimit: 5 >credentialLevel: proxy >defaultSearchBase: dc=example,dc=com >defaultSearchScope: one >defaultServerList: ipa01.example.com ipa02.example.com ipa03.example.com >followReferrals: TRUE >objectclassMap: shadow:shadowAccount=posixAccount >objectclassMap: printers:sunPrinter=printerService >preferredServerList: ipa01.example.com ipa02.example.com >profileTTL: 6000 >searchTimeLimit: 10 >serviceSearchDescriptor: passwd:cn=users,cn=accounts,dc=example,dc=com >serviceSearchDescriptor: group:cn=groups,cn=compat,dc=example,dc=com >serviceSearchDescriptor: netgroup:cn=ng,cn=compat,dc=example,dc=com >serviceSearchDescriptor: ethers:cn=computers,cn=accounts,dc=example,dc=com >serviceSearchDescriptor: automount:cn=default,cn=automount,dc=example,dc=com >serviceSearchDescriptor: >auto_master:automountMapName=auto.master,cn=defualt,cn=automount,dc=example,dc=com >serviceSearchDescriptor: aliases:ou=aliases,ou=test,dc=example,dc=com >serviceSearchDescriptor: printers:ou=printers,ou=test,dc=example,dc=com > >^D > >You may want to check out >https://bugzilla.redhat.com/show_bug.cgi?id=815533 as well. Should the profile be available anonymously? It is not in 4.x: $ ldapsearch -x -b ou=profile,dc=ipacloud,dc=test # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 $ kinit admin Password for admin at IPACLOUD.TEST: $ ldapsearch -Y GSSAPI -b ou=profile,dc=ipacloud,dc=test SASL/GSSAPI authentication started SASL username: admin at IPACLOUD.TEST SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # profile, ipacloud.test dn: ou=profile,dc=ipacloud,dc=test objectClass: top objectClass: organizationalUnit ou: profiles ou: profile # default, profile, ipacloud.test dn: cn=default,ou=profile,dc=ipacloud,dc=test defaultServerList: cc21.ipacloud.test defaultSearchBase: dc=ipacloud,dc=test objectClass: top objectClass: DUAConfigProfile serviceSearchDescriptor: passwd:cn=users,cn=accounts,dc=ipacloud,dc=test serviceSearchDescriptor: group:cn=groups,cn=compat,dc=ipacloud,dc=test searchTimeLimit: 15 followReferrals: TRUE objectclassMap: shadow:shadowAccount=posixAccount bindTimeLimit: 5 authenticationMethod: none cn: default # search result search: 4 result: 0 Success # numResponses: 3 # numEntries: 2 I think it should be available anonymously too, so we need to add a specialized ACI for that. -- / Alexander Bokovoy From sigbjorn at nixtra.com Sat Oct 11 18:26:07 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Sat, 11 Oct 2014 20:26:07 +0200 (CEST) Subject: [Freeipa-users] Solaris 10 client configuration using profile In-Reply-To: <20141011175449.GG2328@redhat.com> References: <1412986404.75392.YahooMailBasic@web122503.mail.ne1.yahoo.com> <5439646E.3010906@redhat.com> <20141011175449.GG2328@redhat.com> Message-ID: <59833.81.167.145.195.1413051967.squirrel@www.nixtra.com> On Sat, October 11, 2014 19:54, Alexander Bokovoy wrote: > On Sat, 11 Oct 2014, Rob Crittenden wrote: > >> sipazzo wrote: >>> Thank you,I know where the profile is in the directory tree and how I would invoke it were it >>> there...I don't know how to get it into the directory tree so that it is available to >>> clients. I see posts giving examples of different profilesthat could be used but no post as >>> to how to add it to the directory. Sorry if I am missing something obvious. >>> >>> >>> -------------------------------------------- >>> On Fri, 10/10/14, Rob Crittenden wrote: >>> >>> >>> Subject: Re: [Freeipa-users] Solaris 10 client configuration using profile >>> To: "sipazzo" , freeipa-users at redhat.com >>> Date: Friday, October 10, 2014, 4:53 PM >>> >>> >>> sipazzo wrote: >>>> >>> Hello, I am trying to set up a default profile for my >>> Solaris 10 IPA clients as recommended. I generated a profile >>> on a Solaris with the attributes I needed except I got an "invalid parameter" error when >>> specifying the domainName attribute like this -a domainName=example.com even though this >>> parameter works when I use it in ldapclient manual. More of an issue though is I have been >>> unable to find documentation on getting the profile incorporated into the ipa server. How do I >>> get this profile on the ipa server and make it available to my Solaris clients? Also, my >>> understanding is the clients periodically check this profile so they stay updated with the >>> latest configuration information. What generates this check? Is it time based, a restart of a >>> service or ?? >>>> >>>> Thank you for any >>>> >>> assistance. >>>> >>> >>> It's been forever since I configured a >>> Solaris anything client but I can >>> tell you where the profile gets stored: cn=profilename,cn=default,ou=profile,$SUFFIX >>> >>> IPA ships with a default >>> profile of: >>> >>> dn: >>> cn=default,ou=profile,$SUFFIX ObjectClass: >>> top ObjectClass: DUAConfigProfile >>> defaultServerList: $FQDN >>> defaultSearchBase: $SUFFIX >>> authenticationMethod: none >>> searchTimeLimit: 15 >>> cn: >>> default serviceSearchDescriptor: >>> passwd:cn=users,cn=accounts,$SUFFIX >>> serviceSearchDescriptor: >>> group:cn=groups,cn=compat,$SUFFIX >>> bindTimeLimit: 5 >>> objectClassMap: >>> shadow:shadowAccount=posixAccount >>> followReferrals:TRUE >>> >>> >>> The full schema can be found at >>> http://docs.oracle.com/cd/E23824_01/html/821-1455/schemas-17.html >>> >>> >>> So if your profile is named >>> foo you'd invoke it with something like: >>> >>> # ldapclient init -a >>> profileName=foo ipa.example.com >>> >>> rob >>> >>> >> >> Here is an example inspired by >> https://bugzilla.redhat.com/show_bug.cgi?id=815515 >> >> >> $ ldapmodify -x -D 'cn=Directory Manager' -W >> dn: cn=solaris_authssl_test,ou=profile,dc=example,dc=com >> objectClass: top >> objectClass: DUAConfigProfile >> cn: solaris_authssl_test >> authenticationMethod: tls:simple >> bindTimeLimit: 5 >> credentialLevel: proxy >> defaultSearchBase: dc=example,dc=com >> defaultSearchScope: one >> defaultServerList: ipa01.example.com ipa02.example.com ipa03.example.com >> followReferrals: TRUE >> objectclassMap: shadow:shadowAccount=posixAccount >> objectclassMap: printers:sunPrinter=printerService >> preferredServerList: ipa01.example.com ipa02.example.com >> profileTTL: 6000 >> searchTimeLimit: 10 >> serviceSearchDescriptor: passwd:cn=users,cn=accounts,dc=example,dc=com >> serviceSearchDescriptor: group:cn=groups,cn=compat,dc=example,dc=com >> serviceSearchDescriptor: netgroup:cn=ng,cn=compat,dc=example,dc=com >> serviceSearchDescriptor: ethers:cn=computers,cn=accounts,dc=example,dc=com >> serviceSearchDescriptor: automount:cn=default,cn=automount,dc=example,dc=com >> serviceSearchDescriptor: >> auto_master:automountMapName=auto.master,cn=defualt,cn=automount,dc=example,dc=com >> serviceSearchDescriptor: aliases:ou=aliases,ou=test,dc=example,dc=com >> serviceSearchDescriptor: printers:ou=printers,ou=test,dc=example,dc=com >> >> ^D >> >> >> You may want to check out >> https://bugzilla.redhat.com/show_bug.cgi?id=815533 as well. >> > Should the profile be available anonymously? It is not in 4.x: > $ ldapsearch -x -b ou=profile,dc=ipacloud,dc=test > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > > # search result > search: 2 > result: 0 Success > > > # numResponses: 1 > $ kinit admin > Password for admin at IPACLOUD.TEST: > $ ldapsearch -Y GSSAPI -b ou=profile,dc=ipacloud,dc=test > SASL/GSSAPI authentication started > SASL username: admin at IPACLOUD.TEST > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > > # profile, ipacloud.test > dn: ou=profile,dc=ipacloud,dc=test > objectClass: top > objectClass: organizationalUnit > ou: profiles > ou: profile > > > # default, profile, ipacloud.test > dn: cn=default,ou=profile,dc=ipacloud,dc=test > defaultServerList: cc21.ipacloud.test > defaultSearchBase: dc=ipacloud,dc=test > objectClass: top > objectClass: DUAConfigProfile > serviceSearchDescriptor: passwd:cn=users,cn=accounts,dc=ipacloud,dc=test > serviceSearchDescriptor: group:cn=groups,cn=compat,dc=ipacloud,dc=test > searchTimeLimit: 15 > followReferrals: TRUE > objectclassMap: shadow:shadowAccount=posixAccount > bindTimeLimit: 5 > authenticationMethod: none > cn: default > > > # search result > search: 4 > result: 0 Success > > > # numResponses: 3 > # numEntries: 2 > > > > I think it should be available anonymously too, so we need to add a > specialized ACI for that. -- Hi, The DUA profile does not need to be available anonymously. Additional parameters (-D to specify a ldap user DN and -w or -W for password for the ldap user, if memory serves correctly) can be specified to allow the ldapclient script to bind to the LDAP server before looking for a DUA profile. The ldapclient script had an issue in earlier Solaris 10, which prevented the additional bind parameters from working, however later patches (released a few years ago now) has solved this issue. I?ve also configured Solaris 8 with the IPA LDAP server being closed for anonymous connections, and it works just fine. I do however use the "rootdse" option when closing the LDAP server for anonymous connections. If I remember correctly this has to be done to make the Solaris "ldapclient" script to work. For the bugzillas referred to by Rob, these are the instructions I wrote after I completed migration of several environments having Solaris 10 (and some Solaris 8) from a NIS environment to an IPA environment, and these DUA profiles are in production today and working just fine. Regards, Siggi From genadipost at gmail.com Sat Oct 11 20:03:13 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Sat, 11 Oct 2014 22:03:13 +0200 Subject: [Freeipa-users] Error: invalid 'AD domain controller' when establishing trust In-Reply-To: <20141010042627.GW2328@redhat.com> References: <20141008072427.GU31737@localhost.localdomain> <20141008121533.GD2328@redhat.com> <20141008154820.GG2328@redhat.com> <20141008170601.GI2328@redhat.com> <20141010042627.GW2328@redhat.com> Message-ID: All understood :) Thank you (and all others who responded) for the explanations. Genadi. 2014-10-10 6:26 GMT+02:00 Alexander Bokovoy : > On Fri, 10 Oct 2014, Genadi Postrilko wrote: > >> Thank you for providing the reference. >> I understood that when creating a forest trust between two AD forests, >> the trust is transitive to all domains in both forests (by default). >> And it has to be established between the two forest root domain. >> >> External trust (between AD forests or domains), is non transitive. >> Trust can be established between (child) domains in different forests, >> without the need to create trust between child domains and the forest >> root domain of the opposite forest. >> >> But i'm not sure about Realm Trust. >> Realm Trust considered as a kind of forest trust? And that why the trust >> has to be established between the forest root domains (and not like >> external trust) ? >> > FreeIPA only provides the first type of the trust -- a forest trust to > AD where AD thinks it trusts an AD forest. All other types of forest are > irrelevant in this context and have no implementation or support in > FreeIPA. > > >> Assuming i follow the IPA Trust setup guide- >> The trust created between red.com (AD forest root domain) and >> linux.blue.com (IPA domain) is configured to be transitive? Users from >> blue.com domain will able to login to IPA domain? And so are users >> from other child and root domains in the forest? >> > Yes, and yes. > > You have ipa trustdomain-find|del|disable|enable > > commands to manage what domains from the trust can have access to IPA > resources. Forest root domain is always allowed, you cannot disable it, > only delete the whole trust. > > > >> >> >> >> 2014-10-08 19:06 GMT+02:00 Alexander Bokovoy : >> >> On Wed, 08 Oct 2014, Genadi Postrilko wrote: >>> >>> 2014-10-08 17:48 GMT+02:00 Alexander Bokovoy : >>>> >>>> On Wed, 08 Oct 2014, Genadi Postrilko wrote: >>>> >>>>> >>>>> The forest root domain in my case is RED.COM. >>>>> >>>>>> >>>>>> You need to establish trust to red.com then. Any domain which is >>>>>> >>>>> member >>>>> of the forest red.com will be visible through trust. >>>>> >>>>> Forest trust can only be established between forest root domains, >>>>> that's >>>>> how it is designed by Microsoft. >>>>> >>>>> >>>>> It doesn't matter how complex the forest is? Even if the forest >>>>> contains >>>>> >>>> number of domain trees, the trust has to be >>>> established with the forest root domain? >>>> >>>> Yes, see "Forest trusts" section of >>> http://technet.microsoft.com/en-us/library/cc773178%28v=ws.10%29.aspx >>> >>> I have attached the log files. >>> >>>> >>>>>> These logs show you are attempting to establish trust to blue.com >>>>>> >>>>> which >>>>> is not a forest root domain, thus nothing works. >>>>> >>>>> >>>>> I assumed that DNS forwarding has to be created between IPA ( >>>> linux.blue.com) >>>> and the AD (blue.com). >>>> Should any DNS configuration change? >>>> >>>> It should be between all AD domains which would use IPA services, >>> namely >>> forest root domain (red.com) and all other domains whose users will be >>> accessing the trust (blue.com in your case). >>> >>> Usually this is solved globally, of course. >>> -- >>> / Alexander Bokovoy >>> >>> > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Sun Oct 12 19:14:53 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Sun, 12 Oct 2014 21:14:53 +0200 Subject: [Freeipa-users] Sudo on Ubuntu Client works, on CentOS it doesn't Message-ID: Hi All. I'm using sudo rules on Ubuntu machines perfectly, but on CentOS I get: User username is not allowed to run sudo on centos This is in my sssd.conf which should be OK? [domain/domain.local] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = domain.local id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = centos.domain.local chpass_provider = ipa ipa_server = _srv_,ipa.domain.local ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh, sudo config_file_version = 2 domains = domain.local The strange thing is that I cannot find any log issues except: (Sun Oct 12 18:03:37 2014) [sssd[sudo]] [sss_dp_init] (0x0010): Failed to connect to monitor services. (Sun Oct 12 18:03:37 2014) [sssd[sudo]] [sss_process_init] (0x0010): fatal error setting up backend connector Where I think this only happens with restarting sssd, but not always. Thanks, Matt From yamakasi.014 at gmail.com Sun Oct 12 23:16:54 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Mon, 13 Oct 2014 01:16:54 +0200 Subject: [Freeipa-users] Sudo on Ubuntu Client works, on CentOS it doesn't In-Reply-To: References: Message-ID: OK, found it... I needed to comment out my other ldap lines, but I wonder why this is needed on CentOS and Ubuntu works without them. 2014-10-12 21:14 GMT+02:00 Matt . : > Hi All. > > I'm using sudo rules on Ubuntu machines perfectly, but on CentOS I get: > > User username is not allowed to run sudo on centos > > This is in my sssd.conf which should be OK? > > [domain/domain.local] > > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = domain.local > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = centos.domain.local > chpass_provider = ipa > ipa_server = _srv_,ipa.domain.local > ldap_tls_cacert = /etc/ipa/ca.crt > > > [sssd] > services = nss, pam, ssh, sudo > config_file_version = 2 > > domains = domain.local > > The strange thing is that I cannot find any log issues except: > > (Sun Oct 12 18:03:37 2014) [sssd[sudo]] [sss_dp_init] (0x0010): Failed > to connect to monitor services. > (Sun Oct 12 18:03:37 2014) [sssd[sudo]] [sss_process_init] (0x0010): > fatal error setting up backend connector > > Where I think this only happens with restarting sssd, but not always. > > Thanks, > > Matt From janellenicole80 at gmail.com Sun Oct 12 23:55:25 2014 From: janellenicole80 at gmail.com (Janelle) Date: Sun, 12 Oct 2014 16:55:25 -0700 Subject: [Freeipa-users] sysctl and/or limits.conf? Message-ID: <543B14ED.5090205@gmail.com> Hi again, I was wondering if there were any suggestions for performance of IPA and settings to sysctl and maybe limits.conf? I tried the website, but did not see anything. Have about 3000 servers that will be talking to 3-4 masters/replicas. Are there any formulas to follow? thanks ~Janelle From purpleidea at gmail.com Mon Oct 13 00:07:59 2014 From: purpleidea at gmail.com (James) Date: Sun, 12 Oct 2014 20:07:59 -0400 Subject: [Freeipa-users] sysctl and/or limits.conf? In-Reply-To: <543B14ED.5090205@gmail.com> References: <543B14ED.5090205@gmail.com> Message-ID: On 12 October 2014 19:55, Janelle wrote: > Hi again, > > I was wondering if there were any suggestions for performance of IPA and > settings to sysctl and maybe limits.conf? I tried the website, but did not > see anything. Have about 3000 servers that will be talking to 3-4 > masters/replicas. Are there any formulas to follow? > > thanks If you get an answer to this, or if you know of any other performance tuning params, let me know and I'll build it in to puppet-ipa. Thanks, James From lslebodn at redhat.com Mon Oct 13 08:29:22 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 13 Oct 2014 10:29:22 +0200 Subject: [Freeipa-users] Sudo on Ubuntu Client works, on CentOS it doesn't In-Reply-To: References: Message-ID: <20141013082921.GC29589@mail.corp.redhat.com> On (13/10/14 01:16), Matt . wrote: >OK, found it... I needed to comment out my other ldap lines, but I >wonder why this is needed on CentOS and Ubuntu works without them. > Which version of CentOS do you mean? LS From pspacek at redhat.com Mon Oct 13 11:02:38 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 13 Oct 2014 13:02:38 +0200 Subject: [Freeipa-users] FW: FW: FW: named and IpA In-Reply-To: <20141010083245.GB11376@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <542E5DAF.2090706@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2057@G6W2496.americas.hpqcorp.net> <54324B50.2050907@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C243C@G6W2496.americas.hpqcorp.net> <5432A8A1.2040707@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C24C8@G6W2496.americas.hpqcorp.net> <5432C5A3.4060003@redhat.com> <20141010083245.GB11376@redhat.com> Message-ID: <543BB14E.2080900@redhat.com> On 10.10.2014 10:32, Jan Pazdziora wrote: > On Mon, Oct 06, 2014 at 06:38:59PM +0200, Petr Spacek wrote: >> On 6.10.2014 17:22, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: >>> Thanks for the additional data. It starts to make sense now, but I'm wondering if that could possibly be a weakness >>> in the IdM model ? >> >> Well, define a weakness :-) >> >> Whole IPA server is built around LDAP database so LDAP is single point of >> failure *for one particular* IPA server. >> >> IPA offers a solution called "replicas". You can have multiple IPA servers >> with (two-way) replicated LDAP database so outage on N-1 servers will not >> affect your clients as long as clients are able to fail-over to the last >> functional server. > > The question is, what should happen when no LDAP server can be > used? > > Should the forwarding suddenly kick in for all zones which will > cause completely different data to be served? Or should the DNS > server refuse to serve anything at that point (even the forwarding) > because it has no way to know what should be forwarded and what > not (I assume bind does not keep around list of zones that were > LDAP-backed the last time LDAP worked). > > There probably should be at least an option (if not default) for bind > to serve nothing if LDAP is not accessible. In the past, named refused to start when LDAP was not available. Later it was flagged as bug and current behavior was implemented: https://bugzilla.redhat.com/show_bug.cgi?id=662930 Feel free to open RFE. -- Petr^2 Spacek From jpazdziora at redhat.com Mon Oct 13 11:42:36 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 13 Oct 2014 13:42:36 +0200 Subject: [Freeipa-users] FW: FW: FW: named and IpA In-Reply-To: <543BB14E.2080900@redhat.com> References: <5D18EEAFC11A0D4FAA5F6902124D35C61F3C1E3E@G6W2496.americas.hpqcorp.net> <542E5DAF.2090706@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C2057@G6W2496.americas.hpqcorp.net> <54324B50.2050907@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C243C@G6W2496.americas.hpqcorp.net> <5432A8A1.2040707@redhat.com> <5D18EEAFC11A0D4FAA5F6902124D35C61F3C24C8@G6W2496.americas.hpqcorp.net> <5432C5A3.4060003@redhat.com> <20141010083245.GB11376@redhat.com> <543BB14E.2080900@redhat.com> Message-ID: <20141013114236.GP11376@redhat.com> On Mon, Oct 13, 2014 at 01:02:38PM +0200, Petr Spacek wrote: > > > >There probably should be at least an option (if not default) for bind > >to serve nothing if LDAP is not accessible. > > In the past, named refused to start when LDAP was not available. Later it > was flagged as bug and current behavior was implemented: > https://bugzilla.redhat.com/show_bug.cgi?id=662930 > > Feel free to open RFE. Done: https://fedorahosted.org/bind-dyndb-ldap/ticket/140 Thank you, -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From natxo.asenjo at gmail.com Mon Oct 13 14:27:44 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 13 Oct 2014 16:27:44 +0200 Subject: [Freeipa-users] mastercrl.bin very old Message-ID: hi, yet another certificate authority question. We have a centos 6.5 ipa environment with two domain controllers (kdc01, kdc02). The first one is the first replica and maintains the crl (or so it should). Recently our monitoring warned us that the web host certificate for kdc01 was about to expire. And it auto-renewed this weeked, with was great. But if I go to the crl url (http://kdc01.domain.tld/ipa.crl ) all the files I see are very old (the MasterCRL.bin file is dated 28 june 2013), and on the kdc02 it is newer (July 2 2013). Am I looking at the wrong urls? How can I check that the crl is ok? Thanks in advance for your tips. -- Groeten, natxo From andreas.ladanyi at kit.edu Mon Oct 13 15:30:58 2014 From: andreas.ladanyi at kit.edu (Andreas Ladanyi) Date: Mon, 13 Oct 2014 17:30:58 +0200 Subject: [Freeipa-users] Migrate KRB DB hashes to IPA LDAP Message-ID: <543BF032.3000103@kit.edu> On my old system from which i migrated the users/group accounts uses the Kerberos own DB without LDAP for the principals. I could dump the master key : kdb5_util dump filename K/M at REALM Now i have a lot of numbers in the dumpfile. Which number belongs to which LDAP attribute in the (test) FreeIPA 389 LDAP System (Simon called it a throwaway system :-) ) I dont know the data structure of the KRB own DB. cheers, Andy From carlosla1987 at gmail.com Mon Oct 13 15:40:28 2014 From: carlosla1987 at gmail.com (=?UTF-8?Q?Carlos_Ra=C3=BAl_Laguna?=) Date: Mon, 13 Oct 2014 11:40:28 -0400 Subject: [Freeipa-users] Migration from FreeIPA-Windows to FreeIPA-samba4 In-Reply-To: <5437086B.5010403@redhat.com> References: <5437086B.5010403@redhat.com> Message-ID: 2014-10-09 18:12 GMT-04:00 Dmitri Pal : > On 10/09/2014 04:38 PM, Carlos Ra?l Laguna wrote: > > Hello to everyone, for some time now i have been pretty much stalking the > samba project site, looking forward to forest trust and it seem that they > introduced new functions to support trust domains > https://download.samba.org/pub/samba/rc/WHATSNEW-4.2.0rc1.txt i guess i > an future will be possible. > > > Yes in future. > > > Anyway, i am about to do a FreeIPA-Windows deployment and i was > wondering if it will be possible in a future migrate from windows to samba? > > > Yes. This is the intent. At least to be able to replace AD with Samba DC > in some cases. I am not sure how smooth the "migration" part will be. > > And also, which version of FreeIPA is most ready for deployment ? > > > Now? > In which distro? > > In RHEL please use what is in 7.0. > If you use Fedora then at least 4.0. You might want to wait couple weeks > and use 4.1 when it gets released. > > Thanks for your time and effort. Regard > > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > Thanks for your reply, it will be any way to use 4.1 in RHEL 7L.Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From janellenicole80 at gmail.com Mon Oct 13 16:18:42 2014 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 13 Oct 2014 09:18:42 -0700 Subject: [Freeipa-users] strange error from EL 7 install? Message-ID: <543BFB62.6070705@gmail.com> Happy Monday everyone... Wondering if anyone else is seeing this error since this weekend? Trying to add in a new IPA replica, which of course requires the software installed -- this is in CentOS 7 using COPR repo and : --> Finished Dependency Resolution Error: Package: pki-base-10.2.0-3.el7.centos.noarch (ipa) Requires: jackson-jaxrs-json-provider and yet, I have never had that issue until this weekend. :-( Any help? Janelle From janellenicole80 at gmail.com Mon Oct 13 16:52:40 2014 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 13 Oct 2014 09:52:40 -0700 Subject: [Freeipa-users] strange error from EL 7 install? In-Reply-To: <543BFB62.6070705@gmail.com> References: <543BFB62.6070705@gmail.com> Message-ID: <543C0358.3080905@gmail.com> After further investigation - it looks like the PKI base was altered/updated because even on a running server a yum update produces same error: # yum check-update Loaded plugins: fastestmirror, product-id, subscription-manager, versionlock Loading mirror speeds from cached hostfile * base: linux.mirrors.es.net * extras: mirrors.usinternet.com * updates: centos.host-engine.com pki-base.noarch 10.2.0-3.el7.centos freeipa pki-ca.noarch 10.2.0-3.el7.centos freeipa pki-server.noarch 10.2.0-3.el7.centos freeipa pki-tools.x86_64 10.2.0-3.el7.centos freeipa slapi-nis.x86_64 0.54-1.el7.centos freeipa and: if you select yes: ---> Package pki-base.noarch 0:10.2.0-3.el7.centos will be an update --> Processing Dependency: jackson-jaxrs-json-provider for package: pki-base-10.2.0-3.el7.centos.noarch --> Finished Dependency Resolution Error: Package: pki-base-10.2.0-3.el7.centos.noarch (freeipa) Requires: jackson-jaxrs-json-provider You could try using --skip-broken to work around the problem On 10/13/14 9:18 AM, Janelle wrote: > Happy Monday everyone... > > Wondering if anyone else is seeing this error since this weekend? > Trying to add in a new IPA replica, which of course requires the > software installed -- this is in CentOS 7 using COPR repo and : > > --> Finished Dependency Resolution > Error: Package: pki-base-10.2.0-3.el7.centos.noarch (ipa) > Requires: jackson-jaxrs-json-provider > > and yet, I have never had that issue until this weekend. :-( > > Any help? > Janelle -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Mon Oct 13 17:27:47 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 13 Oct 2014 19:27:47 +0200 Subject: [Freeipa-users] mastercrl.bin very old In-Reply-To: References: Message-ID: On Mon, Oct 13, 2014 at 4:27 PM, Natxo Asenjo wrote: > But if I go to the crl url (http://kdc01.domain.tld/ipa.crl ) all the > files I see are very old (the MasterCRL.bin file is dated 28 june > 2013), and on the kdc02 it is newer (July 2 2013). on 28 June 2013 I patched the kdc01: Jun 28 23:17:30 Updated: ipa-server-3.0.0-26.el6_4.4.i686 and the kdc02 a few days later: Jul 02 15:21:51 Updated: ipa-server-3.0.0-26.el6_4.4.i686 So that explains the dates, but why dit it stop the publication of crls? -- -- Groeten, natxo From rcritten at redhat.com Mon Oct 13 17:53:32 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 13 Oct 2014 13:53:32 -0400 Subject: [Freeipa-users] mastercrl.bin very old In-Reply-To: References: Message-ID: <543C119C.8070509@redhat.com> Natxo Asenjo wrote: > On Mon, Oct 13, 2014 at 4:27 PM, Natxo Asenjo wrote: >> But if I go to the crl url (http://kdc01.domain.tld/ipa.crl ) all the >> files I see are very old (the MasterCRL.bin file is dated 28 june >> 2013), and on the kdc02 it is newer (July 2 2013). > > on 28 June 2013 I patched the kdc01: > > Jun 28 23:17:30 Updated: ipa-server-3.0.0-26.el6_4.4.i686 > > and the kdc02 a few days later: > > Jul 02 15:21:51 Updated: ipa-server-3.0.0-26.el6_4.4.i686 > > So that explains the dates, but why dit it stop the publication of crls? > I'd suggest looking in /var/log/ipaupgrade.log for those dates to see what happened. I'm guessing that both were deemed to not be the CRL generator so generation was stopped on both. See http://www.freeipa.org/page/CVE-2012-4546 step 2 for how to enable one of the masters to do the CRL generation. rob From orkhan-azeri at mail.ru Mon Oct 13 18:10:12 2014 From: orkhan-azeri at mail.ru (=?UTF-8?B?0J7RgNGF0LDQvSDQmtCw0YHRg9C80L7Qsg==?=) Date: Mon, 13 Oct 2014 22:10:12 +0400 Subject: [Freeipa-users] =?utf-8?q?No_result_when_trying_to_integrate_a_Fr?= =?utf-8?q?eeBSD_client_with_the_FreeIPA_server?= Message-ID: <1413223812.36347990@f357.i.mail.ru> Good day to everybody. There`s a post on how to make a FreeBSD client work with a FreeIPA server: https://forums.freebsd.org/viewtopic.php?f=39&t=46526&p=260146#p260146 ? For some reason the instructions in that post don`t lead to a working solution. Getent passwd/group return no data from the IPA server, although ldapsearch works fine. I followed the instructions exactly (+ configured ldap.conf & started sssd) and didn`t get errors anywhere, all steps completed successfully. My setup: 2 VMs, one is the FreeIPA server (on Fedora 20), the other is a FreeBSD client (on FreeBSD 10.0). IPA server is configured as written in the IPA Quick Start Quide, it has no integrated DNS server. Both VMs have identical /etc/hosts file: ::1 ? ? ? ? ? ? ? ? ? ?localhost 127.0.0.1 ? ? ? ? localhost 192.168.1.10 ? ipa1.mydomain.com ipa1 192.168.1.30 ? bsd1.mydomain.com bsd1 Seems like some instructions in etc/nsswitch.conf file, like "group: files sss" and "passwd: files sss" have no effect. Does anybody tried this setup, what could be wrong with it? I can provide outputs of any commands if necessary. If I shouldn`t have asked this question here, please advise me where to ask. Any hint on what to do will be highly appreciated! -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Mon Oct 13 18:17:07 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 13 Oct 2014 20:17:07 +0200 Subject: [Freeipa-users] mastercrl.bin very old In-Reply-To: <543C119C.8070509@redhat.com> References: <543C119C.8070509@redhat.com> Message-ID: On Mon, Oct 13, 2014 at 7:53 PM, Rob Crittenden wrote: > Natxo Asenjo wrote: >> On Mon, Oct 13, 2014 at 4:27 PM, Natxo Asenjo wrote: >>> But if I go to the crl url (http://kdc01.domain.tld/ipa.crl ) all the >>> files I see are very old (the MasterCRL.bin file is dated 28 june >>> 2013), and on the kdc02 it is newer (July 2 2013). >> >> on 28 June 2013 I patched the kdc01: >> >> Jun 28 23:17:30 Updated: ipa-server-3.0.0-26.el6_4.4.i686 >> >> and the kdc02 a few days later: >> >> Jul 02 15:21:51 Updated: ipa-server-3.0.0-26.el6_4.4.i686 >> >> So that explains the dates, but why dit it stop the publication of crls? >> > > I'd suggest looking in /var/log/ipaupgrade.log for those dates to see > what happened. > > I'm guessing that both were deemed to not be the CRL generator so > generation was stopped on both. > > See http://www.freeipa.org/page/CVE-2012-4546 step 2 for how to enable > one of the masters to do the CRL generation. I was just looking at that article and wondering if that would not be the culprit. I will post and update later. Thanks! -- Groeten, natxo From jhrozek at redhat.com Mon Oct 13 18:33:07 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 13 Oct 2014 20:33:07 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <1413223812.36347990@f357.i.mail.ru> References: <1413223812.36347990@f357.i.mail.ru> Message-ID: <20141013183307.GH3279@hendrix.brq.redhat.com> On Mon, Oct 13, 2014 at 10:10:12PM +0400, ????? ??????? wrote: > Good day to everybody. > There`s a post on how to make a FreeBSD client work with a FreeIPA server: https://forums.freebsd.org/viewtopic.php?f=39&t=46526&p=260146#p260146 ? > For some reason the instructions in that post don`t lead to a working solution. > Getent passwd/group return no data from the IPA server, although ldapsearch works fine. > I followed the instructions exactly (+ configured ldap.conf & started sssd) and didn`t get errors anywhere, all steps completed successfully. > My setup: 2 VMs, one is the FreeIPA server (on Fedora 20), the other is a FreeBSD client (on FreeBSD 10.0). > IPA server is configured as written in the IPA Quick Start Quide, it has no integrated DNS server. > Both VMs have identical /etc/hosts file: > > ::1 ? ? ? ? ? ? ? ? ? ?localhost > 127.0.0.1 ? ? ? ? localhost > 192.168.1.10 ? ipa1.mydomain.com ipa1 > 192.168.1.30 ? bsd1.mydomain.com bsd1 > > Seems like some instructions in etc/nsswitch.conf file, like "group: files sss" and "passwd: files sss" have no effect. > Does anybody tried this setup, what could be wrong with it? > I can provide outputs of any commands if necessary. > If I shouldn`t have asked this question here, please advise me where to ask. > Any hint on what to do will be highly appreciated! Hi, I think SSSD logs would be the best start.. Put debug_level=7 into the [domain] section, restart SSSD and then check out /var/log/sssd/*.log From quest.monger at gmail.com Mon Oct 13 19:13:29 2014 From: quest.monger at gmail.com (quest monger) Date: Mon, 13 Oct 2014 15:13:29 -0400 Subject: [Freeipa-users] Replace Self-Signed Cert Message-ID: Hello All, I installed FreeIPA server on a CentOS host. I have 20+ Linux and Solaris clients hooked up to it. SSH and Sudo works on all clients. I would like to replace the self-signed cert that is used on Port 389 and 636. Is there a way to do this without re-installing the server and clients. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Oct 13 19:17:20 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 13 Oct 2014 15:17:20 -0400 Subject: [Freeipa-users] Replace Self-Signed Cert In-Reply-To: References: Message-ID: <543C2540.60507@redhat.com> quest monger wrote: > Hello All, > > I installed FreeIPA server on a CentOS host. I have 20+ Linux and > Solaris clients hooked up to it. SSH and Sudo works on all clients. > > I would like to replace the self-signed cert that is used on Port 389 > and 636. > > Is there a way to do this without re-installing the server and clients. Why do you want to do this? rob From quest.monger at gmail.com Mon Oct 13 19:24:41 2014 From: quest.monger at gmail.com (quest monger) Date: Mon, 13 Oct 2014 15:24:41 -0400 Subject: [Freeipa-users] Replace Self-Signed Cert In-Reply-To: <543C2540.60507@redhat.com> References: <543C2540.60507@redhat.com> Message-ID: I was told by my admin team that Self-signed certs pose a security risk. On Mon, Oct 13, 2014 at 3:17 PM, Rob Crittenden wrote: > quest monger wrote: > > Hello All, > > > > I installed FreeIPA server on a CentOS host. I have 20+ Linux and > > Solaris clients hooked up to it. SSH and Sudo works on all clients. > > > > I would like to replace the self-signed cert that is used on Port 389 > > and 636. > > > > Is there a way to do this without re-installing the server and clients. > > Why do you want to do this? > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Mon Oct 13 19:32:45 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 13 Oct 2014 21:32:45 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141013183307.GH3279@hendrix.brq.redhat.com> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> Message-ID: <20141013193245.GA27164@mail.corp.redhat.com> On (13/10/14 20:33), Jakub Hrozek wrote: >On Mon, Oct 13, 2014 at 10:10:12PM +0400, ????? ??????? wrote: >> Good day to everybody. >> There`s a post on how to make a FreeBSD client work with a FreeIPA server: https://forums.freebsd.org/viewtopic.php?f=39&t=46526&p=260146#p260146 ? >> For some reason the instructions in that post don`t lead to a working solution. >> Getent passwd/group return no data from the IPA server, although ldapsearch works fine. >> I followed the instructions exactly (+ configured ldap.conf & started sssd) and didn`t get errors anywhere, all steps completed successfully. >> My setup: 2 VMs, one is the FreeIPA server (on Fedora 20), the other is a FreeBSD client (on FreeBSD 10.0). >> IPA server is configured as written in the IPA Quick Start Quide, it has no integrated DNS server. >> Both VMs have identical /etc/hosts file: >> >> ::1 ? ? ? ? ? ? ? ? ? ?localhost >> 127.0.0.1 ? ? ? ? localhost >> 192.168.1.10 ? ipa1.mydomain.com ipa1 >> 192.168.1.30 ? bsd1.mydomain.com bsd1 >> >> Seems like some instructions in etc/nsswitch.conf file, like "group: files sss" and "passwd: files sss" have no effect. >> Does anybody tried this setup, what could be wrong with it? >> I can provide outputs of any commands if necessary. >> If I shouldn`t have asked this question here, please advise me where to ask. >> Any hint on what to do will be highly appreciated! > >Hi, > >I think SSSD logs would be the best start.. > >Put debug_level=7 into the [domain] section, restart SSSD and then check >out /var/log/sssd/*.log > "debug_level = 7" can be put into "nss" section as well. Could you share your sssd configuration file /usr/local/etc/sssd.conf? LS From natxo.asenjo at gmail.com Mon Oct 13 19:39:00 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 13 Oct 2014 21:39:00 +0200 Subject: [Freeipa-users] mastercrl.bin very old In-Reply-To: References: <543C119C.8070509@redhat.com> Message-ID: On Mon, Oct 13, 2014 at 8:17 PM, Natxo Asenjo wrote: > On Mon, Oct 13, 2014 at 7:53 PM, Rob Crittenden wrote: >> Natxo Asenjo wrote: >>> On Mon, Oct 13, 2014 at 4:27 PM, Natxo Asenjo wrote: >>>> But if I go to the crl url (http://kdc01.domain.tld/ipa.crl ) all the >>>> files I see are very old (the MasterCRL.bin file is dated 28 june >>>> 2013), and on the kdc02 it is newer (July 2 2013). >>> >>> on 28 June 2013 I patched the kdc01: >>> >>> Jun 28 23:17:30 Updated: ipa-server-3.0.0-26.el6_4.4.i686 >>> >>> and the kdc02 a few days later: >>> >>> Jul 02 15:21:51 Updated: ipa-server-3.0.0-26.el6_4.4.i686 >>> >>> So that explains the dates, but why dit it stop the publication of crls? >>> >> >> I'd suggest looking in /var/log/ipaupgrade.log for those dates to see >> what happened. >> >> I'm guessing that both were deemed to not be the CRL generator so >> generation was stopped on both. >> >> See http://www.freeipa.org/page/CVE-2012-4546 step 2 for how to enable >> one of the masters to do the CRL generation. > > I was just looking at that article and wondering if that would not be > the culprit. > > I will post and update later. > ok, so I added on the CRL generator (kdc01) this to CS.cfg : ca.listenToCloneModifications=true and rebooted and on the kdc02 (the second replica, not holding the CRL generator) I removed the comment on the rewrite rule, restarted apache2 and now when getting /ipa/crl/MasterCRL.bin clients get redirected to https://kdc01.domain.tld/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL And this crl is up to date $ openssl crl -inform DER -in Downloads/MasterCRL.crl -noout -lastupdate lastUpdate=Oct 13 19:00:00 2014 GMT $ openssl crl -inform DER -in Downloads/MasterCRL.crl -noout -nextupdate nextUpdate=Oct 13 23:00:00 2014 GMT But if I get it from the crl generator using /ipa/crl/MasterCRL.bin I still get the old crl dated june 28th last year. Should I modify ipa-pki-proxy.conf as well on the CRL generator host to point to the /ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL as well? -- Groeten, natxo From quest.monger at gmail.com Mon Oct 13 19:39:21 2014 From: quest.monger at gmail.com (quest monger) Date: Mon, 13 Oct 2014 15:39:21 -0400 Subject: [Freeipa-users] Replace Self-Signed Cert In-Reply-To: References: <543C2540.60507@redhat.com> Message-ID: I found some documentation for getting certificate signed by external CA (2.3.3.2. Using Different CA Configurations) - http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/creating-server.html But looks like those instructions apply to a first time fresh install, not for upgrading an existing install. On Mon, Oct 13, 2014 at 3:24 PM, quest monger wrote: > I was told by my admin team that Self-signed certs pose a security risk. > > > On Mon, Oct 13, 2014 at 3:17 PM, Rob Crittenden > wrote: > >> quest monger wrote: >> > Hello All, >> > >> > I installed FreeIPA server on a CentOS host. I have 20+ Linux and >> > Solaris clients hooked up to it. SSH and Sudo works on all clients. >> > >> > I would like to replace the self-signed cert that is used on Port 389 >> > and 636. >> > >> > Is there a way to do this without re-installing the server and clients. >> >> Why do you want to do this? >> >> rob >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Oct 13 21:05:22 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 13 Oct 2014 17:05:22 -0400 Subject: [Freeipa-users] Migrate KRB DB hashes to IPA LDAP In-Reply-To: <543BF032.3000103@kit.edu> References: <543BF032.3000103@kit.edu> Message-ID: <20141013170522.32b3dc8d@willson.usersys.redhat.com> On Mon, 13 Oct 2014 17:30:58 +0200 Andreas Ladanyi wrote: > On my old system from which i migrated the users/group accounts uses > the Kerberos own DB without LDAP for the principals. > > I could dump the master key : > > kdb5_util dump filename K/M at REALM > > Now i have a lot of numbers in the dumpfile. Which number belongs to > which LDAP attribute in the (test) FreeIPA 389 LDAP System (Simon > called it a throwaway system :-) ) > > I dont know the data structure of the KRB own DB. And you shouldn't really care, you should use the kdb5 utils to load back the dumped DB, provided you first create all users and hosts and services via the freeipa tools. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Mon Oct 13 22:18:22 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 13 Oct 2014 18:18:22 -0400 Subject: [Freeipa-users] sysctl and/or limits.conf? In-Reply-To: References: <543B14ED.5090205@gmail.com> Message-ID: <543C4FAE.9030801@redhat.com> On 10/12/2014 08:07 PM, James wrote: > On 12 October 2014 19:55, Janelle wrote: >> Hi again, >> >> I was wondering if there were any suggestions for performance of IPA and >> settings to sysctl and maybe limits.conf? I tried the website, but did not >> see anything. Have about 3000 servers that will be talking to 3-4 >> masters/replicas. Are there any formulas to follow? >> >> thanks > > If you get an answer to this, or if you know of any other performance > tuning params, let me know and I'll build it in to puppet-ipa. > > Thanks, > James > I do not think it is easy automatable. Please see http://www.freeipa.org/page/Deployment_Recommendations and part about replicas. If 3000 in one datacenter then 3 is good enough or 4 if you are very LDAP heavy (some applications are like Jira for example). If you have 2 data center I would go for 2+2. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Mon Oct 13 22:21:28 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 13 Oct 2014 18:21:28 -0400 Subject: [Freeipa-users] mastercrl.bin very old In-Reply-To: References: <543C119C.8070509@redhat.com> Message-ID: <543C5068.1030205@redhat.com> On 10/13/2014 03:39 PM, Natxo Asenjo wrote: > On Mon, Oct 13, 2014 at 8:17 PM, Natxo Asenjo wrote: >> On Mon, Oct 13, 2014 at 7:53 PM, Rob Crittenden wrote: >>> Natxo Asenjo wrote: >>>> On Mon, Oct 13, 2014 at 4:27 PM, Natxo Asenjo wrote: >>>>> But if I go to the crl url (http://kdc01.domain.tld/ipa.crl ) all the >>>>> files I see are very old (the MasterCRL.bin file is dated 28 june >>>>> 2013), and on the kdc02 it is newer (July 2 2013). >>>> on 28 June 2013 I patched the kdc01: >>>> >>>> Jun 28 23:17:30 Updated: ipa-server-3.0.0-26.el6_4.4.i686 >>>> >>>> and the kdc02 a few days later: >>>> >>>> Jul 02 15:21:51 Updated: ipa-server-3.0.0-26.el6_4.4.i686 >>>> >>>> So that explains the dates, but why dit it stop the publication of crls? >>>> >>> I'd suggest looking in /var/log/ipaupgrade.log for those dates to see >>> what happened. >>> >>> I'm guessing that both were deemed to not be the CRL generator so >>> generation was stopped on both. >>> >>> See http://www.freeipa.org/page/CVE-2012-4546 step 2 for how to enable >>> one of the masters to do the CRL generation. >> I was just looking at that article and wondering if that would not be >> the culprit. >> >> I will post and update later. >> > ok, so I added on the CRL generator (kdc01) this to CS.cfg : > > ca.listenToCloneModifications=true > > and rebooted > > and on the kdc02 (the second replica, not holding the CRL generator) I > removed the comment on the rewrite rule, restarted apache2 and now > when getting /ipa/crl/MasterCRL.bin clients get redirected to > https://kdc01.domain.tld/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL > > And this crl is up to date > > $ openssl crl -inform DER -in Downloads/MasterCRL.crl -noout -lastupdate > lastUpdate=Oct 13 19:00:00 2014 GMT > > $ openssl crl -inform DER -in Downloads/MasterCRL.crl -noout -nextupdate > nextUpdate=Oct 13 23:00:00 2014 GMT > > But if I get it from the crl generator using /ipa/crl/MasterCRL.bin I > still get the old crl dated june 28th last year. > > Should I modify ipa-pki-proxy.conf as well on the CRL generator host > to point to the /ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL > as well? > > > -- > Groeten, > natxo > Is there bug lurking somewhere? Please do not forget to file a ticket if we determine that this is in fact the case. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Mon Oct 13 22:31:12 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 13 Oct 2014 18:31:12 -0400 Subject: [Freeipa-users] Replace Self-Signed Cert In-Reply-To: References: <543C2540.60507@redhat.com> Message-ID: <543C52B0.9030400@redhat.com> On 10/13/2014 03:39 PM, quest monger wrote: > I found some documentation for getting certificate signed by external > CA (2.3.3.2. Using Different CA Configurations) - > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/creating-server.html > > > But looks like those instructions apply to a first time fresh install, > not for upgrading an existing install. > > > > On Mon, Oct 13, 2014 at 3:24 PM, quest monger > wrote: > > I was told by my admin team that Self-signed certs pose a security > risk. > > > On Mon, Oct 13, 2014 at 3:17 PM, Rob Crittenden > > wrote: > > quest monger wrote: > > Hello All, > > > > I installed FreeIPA server on a CentOS host. I have 20+ > Linux and > > Solaris clients hooked up to it. SSH and Sudo works on all > clients. > > > > I would like to replace the self-signed cert that is used on > Port 389 > > and 636. > > > > Is there a way to do this without re-installing the server > and clients. > > Why do you want to do this? > > rob > > > > > Do I get it right that you installed IPA using self-signed certificate and now want to change it? What version of IPA you have? Did you use self-signed CA-less install or using self-signed CA? The tools to change the chaining are only being released in 4.1 so you might have to move to latest when we release 4.1 for CentOS. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Oct 13 22:32:44 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 13 Oct 2014 18:32:44 -0400 Subject: [Freeipa-users] Migration from FreeIPA-Windows to FreeIPA-samba4 In-Reply-To: References: <5437086B.5010403@redhat.com> Message-ID: <543C530C.3000005@redhat.com> On 10/13/2014 11:40 AM, Carlos Ra?l Laguna wrote: > > > 2014-10-09 18:12 GMT-04:00 Dmitri Pal >: > > On 10/09/2014 04:38 PM, Carlos Ra?l Laguna wrote: >> Hello to everyone, for some time now i have been pretty much >> stalking the samba project site, looking forward to forest trust >> and it seem that they introduced new functions to support trust >> domains >> https://download.samba.org/pub/samba/rc/WHATSNEW-4.2.0rc1.txt i >> guess i an future will be possible. >> > > Yes in future. > > >> Anyway, i am about to do a FreeIPA-Windows deployment and i was >> wondering if it will be possible in a future migrate from windows >> to samba? > > Yes. This is the intent. At least to be able to replace AD with > Samba DC in some cases. I am not sure how smooth the "migration" > part will be. > >> And also, which version of FreeIPA is most ready for deployment ? > > Now? > In which distro? > > In RHEL please use what is in 7.0. > If you use Fedora then at least 4.0. You might want to wait couple > weeks and use 4.1 when it gets released. > >> Thanks for your time and effort. Regard > > >> >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > Thanks for your reply, it will be any way to use 4.1 in RHEL 7L.Regards > > We plan to bring 4.1 into RHEL7.x. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From quest.monger at gmail.com Mon Oct 13 22:45:05 2014 From: quest.monger at gmail.com (quest monger) Date: Mon, 13 Oct 2014 18:45:05 -0400 Subject: [Freeipa-users] Replace Self-Signed Cert In-Reply-To: <543C52B0.9030400@redhat.com> References: <543C2540.60507@redhat.com> <543C52B0.9030400@redhat.com> Message-ID: I did the default IPA install, didnt change any certs or anything. As part of that install, it now shows 2 certs, one on port 443 (HTTPS) and one on port 636 (LDAPS). These certs dont have a trust chain, hence i called them self-signed. We have a contract with a third party CA that issues TLS certs for us. I was asked to find a way to replace those 2 self signed certs with certs from this third party CA. I was wondering if there was a way i could do that. I found this - http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP I am currently running 3.0.0. On Mon, Oct 13, 2014 at 6:31 PM, Dmitri Pal wrote: > On 10/13/2014 03:39 PM, quest monger wrote: > > I found some documentation for getting certificate signed by external CA > (2.3.3.2. Using Different CA Configurations) - > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/creating-server.html > > But looks like those instructions apply to a first time fresh install, > not for upgrading an existing install. > > > > On Mon, Oct 13, 2014 at 3:24 PM, quest monger > wrote: > >> I was told by my admin team that Self-signed certs pose a security risk. >> >> >> On Mon, Oct 13, 2014 at 3:17 PM, Rob Crittenden >> wrote: >> >>> quest monger wrote: >>> > Hello All, >>> > >>> > I installed FreeIPA server on a CentOS host. I have 20+ Linux and >>> > Solaris clients hooked up to it. SSH and Sudo works on all clients. >>> > >>> > I would like to replace the self-signed cert that is used on Port 389 >>> > and 636. >>> > >>> > Is there a way to do this without re-installing the server and clients. >>> >>> Why do you want to do this? >>> >>> rob >>> >>> >> > > > > Do I get it right that you installed IPA using self-signed certificate and > now want to change it? > What version of IPA you have? Did you use self-signed CA-less install or > using self-signed CA? > The tools to change the chaining are only being released in 4.1 so you > might have to move to latest when we release 4.1 for CentOS. > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wgraboyes at cenic.org Mon Oct 13 22:53:53 2014 From: wgraboyes at cenic.org (William Graboyes) Date: Mon, 13 Oct 2014 15:53:53 -0700 Subject: [Freeipa-users] Replace Self-Signed Cert In-Reply-To: References: <543C2540.60507@redhat.com> <543C52B0.9030400@redhat.com> Message-ID: <543C5801.8060009@cenic.org> Hi there, My understanding is the only way to install a third party cert is to start from scratch. The part that is unclear to me is if there is a method of exporting the data prior to, and importing the data after the fresh instance of freeipa has been installed. I assume that one would also have to re-install all clients utilizing freeipa. Thanks, Bill On Mon Oct 13 15:45:05 2014, quest monger wrote: > I did the default IPA install, didnt change any certs or anything. > As part of that install, it now shows 2 certs, one on port 443 (HTTPS) and > one on port 636 (LDAPS). These certs dont have a trust chain, hence i > called them self-signed. > We have a contract with a third party CA that issues TLS certs for us. I > was asked to find a way to replace those 2 self signed certs with certs > from this third party CA. > I was wondering if there was a way i could do that. > > I found this - > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP > > I am currently running 3.0.0. > > > > On Mon, Oct 13, 2014 at 6:31 PM, Dmitri Pal wrote: > >> On 10/13/2014 03:39 PM, quest monger wrote: >> >> I found some documentation for getting certificate signed by external CA >> (2.3.3.2. Using Different CA Configurations) - >> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/creating-server.html >> >> But looks like those instructions apply to a first time fresh install, >> not for upgrading an existing install. >> >> >> >> On Mon, Oct 13, 2014 at 3:24 PM, quest monger >> wrote: >> >>> I was told by my admin team that Self-signed certs pose a security risk. >>> >>> >>> On Mon, Oct 13, 2014 at 3:17 PM, Rob Crittenden >>> wrote: >>> >>>> quest monger wrote: >>>>> Hello All, >>>>> >>>>> I installed FreeIPA server on a CentOS host. I have 20+ Linux and >>>>> Solaris clients hooked up to it. SSH and Sudo works on all clients. >>>>> >>>>> I would like to replace the self-signed cert that is used on Port 389 >>>>> and 636. >>>>> >>>>> Is there a way to do this without re-installing the server and clients. >>>> >>>> Why do you want to do this? >>>> >>>> rob >>>> >>>> >>> >> >> >> >> Do I get it right that you installed IPA using self-signed certificate and >> now want to change it? >> What version of IPA you have? Did you use self-signed CA-less install or >> using self-signed CA? >> The tools to change the chaining are only being released in 4.1 so you >> might have to move to latest when we release 4.1 for CentOS. >> >> >> -- >> 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 >> > > > From purpleidea at gmail.com Mon Oct 13 22:58:37 2014 From: purpleidea at gmail.com (James) Date: Mon, 13 Oct 2014 18:58:37 -0400 Subject: [Freeipa-users] sysctl and/or limits.conf? In-Reply-To: <543C4FAE.9030801@redhat.com> References: <543B14ED.5090205@gmail.com> <543C4FAE.9030801@redhat.com> Message-ID: On 13 October 2014 18:18, Dmitri Pal wrote: > On 10/12/2014 08:07 PM, James wrote: >> >> On 12 October 2014 19:55, Janelle wrote: >>> >>> Hi again, >>> >>> I was wondering if there were any suggestions for performance of IPA and >>> settings to sysctl and maybe limits.conf? I tried the website, but did >>> not >>> see anything. Have about 3000 servers that will be talking to 3-4 >>> masters/replicas. Are there any formulas to follow? >>> >>> thanks >> >> >> If you get an answer to this, or if you know of any other performance >> tuning params, let me know and I'll build it in to puppet-ipa. >> >> Thanks, >> James >> > I do not think it is easy automatable. You underestimate me ;) > Please see http://www.freeipa.org/page/Deployment_Recommendations and part > about replicas. > If 3000 in one datacenter then 3 is good enough or 4 if you are very LDAP > heavy (some applications are like Jira for example). > If you have 2 data center I would go for 2+2. OP (and myself) were also curious on if there were any machine specific optimizations to add? Eg: sysctl, /proc tuning, etc... Anything out there? From dpal at redhat.com Mon Oct 13 23:01:57 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 13 Oct 2014 19:01:57 -0400 Subject: [Freeipa-users] Replace Self-Signed Cert In-Reply-To: References: <543C2540.60507@redhat.com> <543C52B0.9030400@redhat.com> Message-ID: <543C59E5.2000202@redhat.com> On 10/13/2014 06:45 PM, quest monger wrote: > I did the default IPA install, didnt change any certs or anything. > As part of that install, it now shows 2 certs, one on port 443 (HTTPS) > and one on port 636 (LDAPS). These certs dont have a trust chain, > hence i called them self-signed. > We have a contract with a third party CA that issues TLS certs for us. > I was asked to find a way to replace those 2 self signed certs with > certs from this third party CA. > I was wondering if there was a way i could do that. > > I found this - > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP > > I am currently running 3.0.0. > > AFAIU the biggest issue will be with the clients. I suspect that they might be quite confused if you just drop in the certs from the 3rd party. If you noticed the page has the following line: "The certificate in mysite.crt must be signed by the CA used when installing FreeIPA." I think it should say by "external" CA to be clear. It is not the case in your situation. If it were the situation the CA would have been already in trust chain on the clients and procedure would have worked but I do not think it would work now. You would need to use the cert chaining tool that was was built in 4.1 when 4.1 gets released on CentOS. > > On Mon, Oct 13, 2014 at 6:31 PM, Dmitri Pal > wrote: > > On 10/13/2014 03:39 PM, quest monger wrote: >> I found some documentation for getting certificate signed by >> external CA (2.3.3.2. Using Different CA Configurations) - >> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/creating-server.html >> >> >> But looks like those instructions apply to a first time fresh >> install, not for upgrading an existing install. >> >> >> >> On Mon, Oct 13, 2014 at 3:24 PM, quest monger >> > wrote: >> >> I was told by my admin team that Self-signed certs pose a >> security risk. >> >> >> On Mon, Oct 13, 2014 at 3:17 PM, Rob Crittenden >> > wrote: >> >> quest monger wrote: >> > Hello All, >> > >> > I installed FreeIPA server on a CentOS host. I have 20+ >> Linux and >> > Solaris clients hooked up to it. SSH and Sudo works on >> all clients. >> > >> > I would like to replace the self-signed cert that is >> used on Port 389 >> > and 636. >> > >> > Is there a way to do this without re-installing the >> server and clients. >> >> Why do you want to do this? >> >> rob >> >> >> >> >> > > Do I get it right that you installed IPA using self-signed > certificate and now want to change it? > What version of IPA you have? Did you use self-signed CA-less > install or using self-signed CA? > The tools to change the chaining are only being released in 4.1 so > you might have to move to latest when we release 4.1 for CentOS. > > > -- > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Oct 13 23:03:42 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 13 Oct 2014 19:03:42 -0400 Subject: [Freeipa-users] sysctl and/or limits.conf? In-Reply-To: References: <543B14ED.5090205@gmail.com> <543C4FAE.9030801@redhat.com> Message-ID: <543C5A4E.5060104@redhat.com> On 10/13/2014 06:58 PM, James wrote: > On 13 October 2014 18:18, Dmitri Pal wrote: >> On 10/12/2014 08:07 PM, James wrote: >>> On 12 October 2014 19:55, Janelle wrote: >>>> Hi again, >>>> >>>> I was wondering if there were any suggestions for performance of IPA and >>>> settings to sysctl and maybe limits.conf? I tried the website, but did >>>> not >>>> see anything. Have about 3000 servers that will be talking to 3-4 >>>> masters/replicas. Are there any formulas to follow? >>>> >>>> thanks >>> >>> If you get an answer to this, or if you know of any other performance >>> tuning params, let me know and I'll build it in to puppet-ipa. >>> >>> Thanks, >>> James >>> >> I do not think it is easy automatable. > You underestimate me ;) > >> Please see http://www.freeipa.org/page/Deployment_Recommendations and part >> about replicas. >> If 3000 in one datacenter then 3 is good enough or 4 if you are very LDAP >> heavy (some applications are like Jira for example). >> If you have 2 data center I would go for 2+2. > OP (and myself) were also curious on if there were any machine > specific optimizations to add? Eg: sysctl, /proc tuning, etc... > > Anything out there? Not to the best of my knowledge. I mean DS has a lot of knobs but they need tuneup only in case of huge databases. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From quest.monger at gmail.com Mon Oct 13 23:10:47 2014 From: quest.monger at gmail.com (quest monger) Date: Mon, 13 Oct 2014 19:10:47 -0400 Subject: [Freeipa-users] Replace Self-Signed Cert In-Reply-To: <543C59E5.2000202@redhat.com> References: <543C2540.60507@redhat.com> <543C52B0.9030400@redhat.com> <543C59E5.2000202@redhat.com> Message-ID: makes sense. i will still try out that cert add command in my test environment, just to see if it works. looks like for now, 4.1 upgrade is my best option. On Mon, Oct 13, 2014 at 7:01 PM, Dmitri Pal wrote: > On 10/13/2014 06:45 PM, quest monger wrote: > > I did the default IPA install, didnt change any certs or anything. > As part of that install, it now shows 2 certs, one on port 443 (HTTPS) and > one on port 636 (LDAPS). These certs dont have a trust chain, hence i > called them self-signed. > We have a contract with a third party CA that issues TLS certs for us. I > was asked to find a way to replace those 2 self signed certs with certs > from this third party CA. > I was wondering if there was a way i could do that. > > I found this - > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP > > I am currently running 3.0.0. > > > > AFAIU the biggest issue will be with the clients. > I suspect that they might be quite confused if you just drop in the certs > from the 3rd party. > If you noticed the page has the following line: > "The certificate in mysite.crt must be signed by the CA used when > installing FreeIPA." I think it should say by "external" CA to be clear. > It is not the case in your situation. If it were the situation the CA > would have been already in trust chain on the clients and procedure would > have worked but I do not think it would work now. > You would need to use the cert chaining tool that was was built in 4.1 > when 4.1 gets released on CentOS. > > > > > > On Mon, Oct 13, 2014 at 6:31 PM, Dmitri Pal wrote: > >> On 10/13/2014 03:39 PM, quest monger wrote: >> >> I found some documentation for getting certificate signed by external CA >> (2.3.3.2. Using Different CA Configurations) - >> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/creating-server.html >> >> But looks like those instructions apply to a first time fresh install, >> not for upgrading an existing install. >> >> >> >> On Mon, Oct 13, 2014 at 3:24 PM, quest monger >> wrote: >> >>> I was told by my admin team that Self-signed certs pose a security risk. >>> >>> >>> On Mon, Oct 13, 2014 at 3:17 PM, Rob Crittenden >>> wrote: >>> >>>> quest monger wrote: >>>> > Hello All, >>>> > >>>> > I installed FreeIPA server on a CentOS host. I have 20+ Linux and >>>> > Solaris clients hooked up to it. SSH and Sudo works on all clients. >>>> > >>>> > I would like to replace the self-signed cert that is used on Port 389 >>>> > and 636. >>>> > >>>> > Is there a way to do this without re-installing the server and >>>> clients. >>>> >>>> Why do you want to do this? >>>> >>>> rob >>>> >>>> >>> >> >> >> >> Do I get it right that you installed IPA using self-signed certificate >> and now want to change it? >> What version of IPA you have? Did you use self-signed CA-less install or >> using self-signed CA? >> The tools to change the chaining are only being released in 4.1 so you >> might have to move to latest when we release 4.1 for CentOS. >> >> >> -- >> 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janellenicole80 at gmail.com Tue Oct 14 00:28:12 2014 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 13 Oct 2014 17:28:12 -0700 Subject: [Freeipa-users] sysctl and/or limits.conf? In-Reply-To: <543C4FAE.9030801@redhat.com> References: <543B14ED.5090205@gmail.com> <543C4FAE.9030801@redhat.com> Message-ID: <543C6E1C.4010901@gmail.com> Hi again, A lot of this information has been very useful. I did have a question I could not answer. I noticed in the Deployment Recommendations docs, it says not to have any more than 4 replication agreements. Perhaps I am missing something, but I don't see how to get a replica to be a master to be able to create another replicate? Am I missing something obvious here? Thank you, ~Janelle On 10/13/14 3:18 PM, Dmitri Pal wrote: > On 10/12/2014 08:07 PM, James wrote: >> On 12 October 2014 19:55, Janelle wrote: >>> Hi again, >>> >>> I was wondering if there were any suggestions for performance of IPA >>> and >>> settings to sysctl and maybe limits.conf? I tried the website, but >>> did not >>> see anything. Have about 3000 servers that will be talking to 3-4 >>> masters/replicas. Are there any formulas to follow? >>> >>> thanks >> >> If you get an answer to this, or if you know of any other performance >> tuning params, let me know and I'll build it in to puppet-ipa. >> >> Thanks, >> James >> > I do not think it is easy automatable. > Please see http://www.freeipa.org/page/Deployment_Recommendations and > part about replicas. > If 3000 in one datacenter then 3 is good enough or 4 if you are very > LDAP heavy (some applications are like Jira for example). > If you have 2 data center I would go for 2+2. > From ftweedal at redhat.com Tue Oct 14 04:48:51 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 14 Oct 2014 14:48:51 +1000 Subject: [Freeipa-users] strange error from EL 7 install? In-Reply-To: <543C0358.3080905@gmail.com> References: <543BFB62.6070705@gmail.com> <543C0358.3080905@gmail.com> Message-ID: <20141014044851.GJ5346@dhcp-40-8.bne.redhat.com> On Mon, Oct 13, 2014 at 09:52:40AM -0700, Janelle wrote: > After further investigation - it looks like the PKI base was altered/updated > because even on a running server a yum update produces same error: > > # yum check-update > Loaded plugins: fastestmirror, product-id, subscription-manager, versionlock > Loading mirror speeds from cached hostfile > * base: linux.mirrors.es.net > * extras: mirrors.usinternet.com > * updates: centos.host-engine.com > > pki-base.noarch 10.2.0-3.el7.centos freeipa > pki-ca.noarch 10.2.0-3.el7.centos freeipa > pki-server.noarch 10.2.0-3.el7.centos freeipa > pki-tools.x86_64 10.2.0-3.el7.centos freeipa > slapi-nis.x86_64 0.54-1.el7.centos freeipa > > and: if you select yes: > > ---> Package pki-base.noarch 0:10.2.0-3.el7.centos will be an update > --> Processing Dependency: jackson-jaxrs-json-provider for package: > pki-base-10.2.0-3.el7.centos.noarch > --> Finished Dependency Resolution > Error: Package: pki-base-10.2.0-3.el7.centos.noarch (freeipa) > Requires: jackson-jaxrs-json-provider > You could try using --skip-broken to work around the problem > Hi Janelle, Looks like the COPR moved from Dogtag 10.1 to 10.2 on 8 Oct, and 10.2 declares a dependency on Jackson which is not in EPEL. The dependency causing the probelm (jackson-jaxrs-json-provider) was introduced at commit 32d71bb. I'm not sure on the right approach to fixing this but I've copied pki-devel who will be able to help. Fraser > > > On 10/13/14 9:18 AM, Janelle wrote: > >Happy Monday everyone... > > > >Wondering if anyone else is seeing this error since this weekend? Trying > >to add in a new IPA replica, which of course requires the software > >installed -- this is in CentOS 7 using COPR repo and : > > > >--> Finished Dependency Resolution > >Error: Package: pki-base-10.2.0-3.el7.centos.noarch (ipa) > > Requires: jackson-jaxrs-json-provider > > > >and yet, I have never had that issue until this weekend. :-( > > > >Any help? > >Janelle > > -- > 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 From janellenicole80 at gmail.com Tue Oct 14 05:08:55 2014 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 13 Oct 2014 22:08:55 -0700 Subject: [Freeipa-users] strange error from EL 7 install? In-Reply-To: <20141014044851.GJ5346@dhcp-40-8.bne.redhat.com> References: <543BFB62.6070705@gmail.com> <543C0358.3080905@gmail.com> <20141014044851.GJ5346@dhcp-40-8.bne.redhat.com> Message-ID: <543CAFE7.1070104@gmail.com> Actually, I did find a fix and forgot to post. I was able to mirror the COPR repo, and after reviewing it, found that simply removing the pki-base...fc21 directory, and regenning the repo data with createrepo, fixed the problem. It drops the version of PKI back to the 10.1 branch and that resolved the dependencies. Hope this helps, Janelle On 10/13/14 9:48 PM, Fraser Tweedale wrote: > On Mon, Oct 13, 2014 at 09:52:40AM -0700, Janelle wrote: >> After further investigation - it looks like the PKI base was altered/updated >> because even on a running server a yum update produces same error: >> >> # yum check-update >> Loaded plugins: fastestmirror, product-id, subscription-manager, versionlock >> Loading mirror speeds from cached hostfile >> * base: linux.mirrors.es.net >> * extras: mirrors.usinternet.com >> * updates: centos.host-engine.com >> >> pki-base.noarch 10.2.0-3.el7.centos freeipa >> pki-ca.noarch 10.2.0-3.el7.centos freeipa >> pki-server.noarch 10.2.0-3.el7.centos freeipa >> pki-tools.x86_64 10.2.0-3.el7.centos freeipa >> slapi-nis.x86_64 0.54-1.el7.centos freeipa >> >> and: if you select yes: >> >> ---> Package pki-base.noarch 0:10.2.0-3.el7.centos will be an update >> --> Processing Dependency: jackson-jaxrs-json-provider for package: >> pki-base-10.2.0-3.el7.centos.noarch >> --> Finished Dependency Resolution >> Error: Package: pki-base-10.2.0-3.el7.centos.noarch (freeipa) >> Requires: jackson-jaxrs-json-provider >> You could try using --skip-broken to work around the problem >> > Hi Janelle, > > Looks like the COPR moved from Dogtag 10.1 to 10.2 on 8 Oct, and > 10.2 declares a dependency on Jackson which is not in EPEL. The > dependency causing the probelm (jackson-jaxrs-json-provider) was > introduced at commit 32d71bb. I'm not sure on the right approach to > fixing this but I've copied pki-devel who will be able to help. > > Fraser > >> >> On 10/13/14 9:18 AM, Janelle wrote: >>> Happy Monday everyone... >>> >>> Wondering if anyone else is seeing this error since this weekend? Trying >>> to add in a new IPA replica, which of course requires the software >>> installed -- this is in CentOS 7 using COPR repo and : >>> >>> --> Finished Dependency Resolution >>> Error: Package: pki-base-10.2.0-3.el7.centos.noarch (ipa) >>> Requires: jackson-jaxrs-json-provider >>> >>> and yet, I have never had that issue until this weekend. :-( >>> >>> Any help? >>> Janelle >> -- >> 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 From orkhan-azeri at mail.ru Tue Oct 14 05:23:09 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Tue, 14 Oct 2014 10:23:09 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141013193245.GA27164@mail.corp.redhat.com> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> Message-ID: <543CB33D.6020005@mail.ru> Thanks to both of you for the interest. Here`s the info you asked: 1. Putting "debug_level = 7" either in [domain] or/and [nss] section of the /usr/local/etc/sssd/sssd.conf file gives nothing in the log. The log file located at /var/log/sssd/sssd.log is only populated with data when I make some errors in sssd.conf & sssd process fails to start. But that`s the case only if I deliberately introduce some errors; with current configuration sssd starts successfully. 2. My original sssd.conf (without debugs) is as follows (exact copy of what was shown in the post at FreeBSD forums): ----------------------------------------- [domain/mydomain.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = mydomain.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ipa1.mydomain.com chpass_provider = ipa ipa_server = _srv_ #our FreeIPA server has DNS SRV entries ldap_tls_cacert = /etc/ssl/ca.crt enumerate = True #to enumerate users and groups [sssd] enumerate = True services = nss, pam, sudo config_file_version = 2 domains = mydomain.com [nss] [pam] [sudo] ----------------------------------------- Interestingly enough the [nss] section is empty, just as shown in the post at FreeBSD forums. 3. The users created at the IPA server can`t locally log in to the server, but it`s possible to ssh to the server as an IPA user from the FreeBSD host. However, there are some interesting behaviors (again, this is what happens when just following the IPA Quick Start Quide for the server side & the post from FreeBSD forums for the client side): - home directories are not automatically created on the IPA server; - "id" command output shows correct uid, but the group of any IPA user doesn`t show as "ipausers" - instead, the group name is the same as username, + something like "context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023". 4. Here is the list of snapshots taken from my FreeBSD VM when I installed necessary ports, maybe these snapshots will provide some additional info on sssd behavior: clean_install starting_sssd_install krb5_choice_added_LDAP openldap24-sasl-client_choice_added_FETCH_GSSAPI cyrus-sasl2_choice_defaults bind_choice_added_GSSAPI_MIT sssd_installation_finished sudo_installed_with_INSULTS_LDAP_SSSD cyrus-sasl2-gssapi_choice_added_MIT all_ports_installed_directories_created all_configs_applied_sssd_started 14-Oct-14 00:32, Lukas Slebodnik ?????: > On (13/10/14 20:33), Jakub Hrozek wrote: >> On Mon, Oct 13, 2014 at 10:10:12PM +0400, ????? ??????? wrote: >>> Good day to everybody. >>> There`s a post on how to make a FreeBSD client work with a FreeIPA server: https://forums.freebsd.org/viewtopic.php?f=39&t=46526&p=260146#p260146 >>> For some reason the instructions in that post don`t lead to a working solution. >>> Getent passwd/group return no data from the IPA server, although ldapsearch works fine. >>> I followed the instructions exactly (+ configured ldap.conf & started sssd) and didn`t get errors anywhere, all steps completed successfully. >>> My setup: 2 VMs, one is the FreeIPA server (on Fedora 20), the other is a FreeBSD client (on FreeBSD 10.0). >>> IPA server is configured as written in the IPA Quick Start Quide, it has no integrated DNS server. >>> Both VMs have identical /etc/hosts file: >>> >>> ::1 localhost >>> 127.0.0.1 localhost >>> 192.168.1.10 ipa1.mydomain.com ipa1 >>> 192.168.1.30 bsd1.mydomain.com bsd1 >>> >>> Seems like some instructions in etc/nsswitch.conf file, like "group: files sss" and "passwd: files sss" have no effect. >>> Does anybody tried this setup, what could be wrong with it? >>> I can provide outputs of any commands if necessary. >>> If I shouldn`t have asked this question here, please advise me where to ask. >>> Any hint on what to do will be highly appreciated! >> Hi, >> >> I think SSSD logs would be the best start.. >> >> Put debug_level=7 into the [domain] section, restart SSSD and then check >> out /var/log/sssd/*.log >> > "debug_level = 7" can be put into "nss" section as well. > Could you share your sssd configuration file /usr/local/etc/sssd.conf? > > LS > From ftweedal at redhat.com Tue Oct 14 06:03:24 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 14 Oct 2014 16:03:24 +1000 Subject: [Freeipa-users] strange error from EL 7 install? In-Reply-To: <543CAFE7.1070104@gmail.com> References: <543BFB62.6070705@gmail.com> <543C0358.3080905@gmail.com> <20141014044851.GJ5346@dhcp-40-8.bne.redhat.com> <543CAFE7.1070104@gmail.com> Message-ID: <20141014060324.GK5346@dhcp-40-8.bne.redhat.com> On Mon, Oct 13, 2014 at 10:08:55PM -0700, Janelle wrote: > Actually, I did find a fix and forgot to post. > > I was able to mirror the COPR repo, and after reviewing it, found that > simply removing the pki-base...fc21 directory, and regenning the repo data > with createrepo, fixed the problem. It drops the version of PKI back to the > 10.1 branch and that resolved the dependencies. > > Hope this helps, > Janelle > Glad you were able to find a fix. Of course, we will still need to fix the 10.2 build, so thanks for reporting! Fraser > On 10/13/14 9:48 PM, Fraser Tweedale wrote: > >On Mon, Oct 13, 2014 at 09:52:40AM -0700, Janelle wrote: > >>After further investigation - it looks like the PKI base was altered/updated > >>because even on a running server a yum update produces same error: > >> > >># yum check-update > >>Loaded plugins: fastestmirror, product-id, subscription-manager, versionlock > >>Loading mirror speeds from cached hostfile > >> * base: linux.mirrors.es.net > >> * extras: mirrors.usinternet.com > >> * updates: centos.host-engine.com > >> > >>pki-base.noarch 10.2.0-3.el7.centos freeipa > >>pki-ca.noarch 10.2.0-3.el7.centos freeipa > >>pki-server.noarch 10.2.0-3.el7.centos freeipa > >>pki-tools.x86_64 10.2.0-3.el7.centos freeipa > >>slapi-nis.x86_64 0.54-1.el7.centos freeipa > >> > >>and: if you select yes: > >> > >>---> Package pki-base.noarch 0:10.2.0-3.el7.centos will be an update > >>--> Processing Dependency: jackson-jaxrs-json-provider for package: > >>pki-base-10.2.0-3.el7.centos.noarch > >>--> Finished Dependency Resolution > >>Error: Package: pki-base-10.2.0-3.el7.centos.noarch (freeipa) > >> Requires: jackson-jaxrs-json-provider > >> You could try using --skip-broken to work around the problem > >> > >Hi Janelle, > > > >Looks like the COPR moved from Dogtag 10.1 to 10.2 on 8 Oct, and > >10.2 declares a dependency on Jackson which is not in EPEL. The > >dependency causing the probelm (jackson-jaxrs-json-provider) was > >introduced at commit 32d71bb. I'm not sure on the right approach to > >fixing this but I've copied pki-devel who will be able to help. > > > >Fraser > > > >> > >>On 10/13/14 9:18 AM, Janelle wrote: > >>>Happy Monday everyone... > >>> > >>>Wondering if anyone else is seeing this error since this weekend? Trying > >>>to add in a new IPA replica, which of course requires the software > >>>installed -- this is in CentOS 7 using COPR repo and : > >>> > >>>--> Finished Dependency Resolution > >>>Error: Package: pki-base-10.2.0-3.el7.centos.noarch (ipa) > >>> Requires: jackson-jaxrs-json-provider > >>> > >>>and yet, I have never had that issue until this weekend. :-( > >>> > >>>Any help? > >>>Janelle > >>-- > >>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 > From abokovoy at redhat.com Tue Oct 14 06:05:57 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 14 Oct 2014 09:05:57 +0300 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <543CB33D.6020005@mail.ru> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CB33D.6020005@mail.ru> Message-ID: <20141014060557.GJ4143@redhat.com> On Tue, 14 Oct 2014, Orkhan Gasimov wrote: >Thanks to both of you for the interest. >Here`s the info you asked: > >1. Putting "debug_level = 7" either in [domain] or/and [nss] section >of the /usr/local/etc/sssd/sssd.conf file gives nothing in the log. >The log file located at /var/log/sssd/sssd.log is only populated with >data when I make some errors in sssd.conf & sssd process fails to >start. But that`s the case only if I deliberately introduce some >errors; with current configuration sssd starts successfully. SSSD writes separate log files per each section, so you need to look at /var/log/sssd/sssd_mydomain.com.log for [domain/mydomain.com] and /var/log/sssd/sssd_nss.log for nss section. >3. The users created at the IPA server can`t locally log in to the >server, but it`s possible to ssh to the server as an IPA user from the >FreeBSD host. However, there are some interesting behaviors (again, >this is what happens when just following the IPA Quick Start Quide for >the server side & the post from FreeBSD forums for the client side): > - home directories are not automatically created on the IPA server; > - "id" command output shows correct uid, but the group of any IPA >user doesn`t show as "ipausers" - instead, the group name is the same >as username, + something like >"context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023". In FreeIPA in Fedora we switched off ipausers being a POSIX group. FreeIPA supports POSIX and non-POSIX groups; the latter is for grouping purposes as groups can be nested in FreeIPA. 'ipausers' is the group every user is a member of but it is not a POSIX group anymore so it has less effect on performance in large deployments (tens of thousands users in the same group). So it is expected. The group named as a username is a user-private group which is maintained automatically per each user. It has the same GID as user's UID. -- / Alexander Bokovoy From natxo.asenjo at gmail.com Tue Oct 14 06:47:31 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 14 Oct 2014 08:47:31 +0200 Subject: [Freeipa-users] mastercrl.bin very old In-Reply-To: References: <543C119C.8070509@redhat.com> Message-ID: On Mon, Oct 13, 2014 at 9:39 PM, Natxo Asenjo wrote: > But if I get it from the crl generator using /ipa/crl/MasterCRL.bin I > still get the old crl dated june 28th last year. > > Should I modify ipa-pki-proxy.conf as well on the CRL generator host > to point to the /ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL > as well? This morning the /ipa/crl dir still had the lists of 28th June 2013 in the crl generator host. In my test environment running centos 7 the files get updated, so I think a process is nut running. But which one? Going to the /ca/ee/ca/getCRL?op=getCRL& crlIssuingPoint=MasterCRL gives me the up to date CRL. -- Groeten, natxo From orkhan-azeri at mail.ru Tue Oct 14 07:34:09 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Tue, 14 Oct 2014 12:34:09 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141013193245.GA27164@mail.corp.redhat.com> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> Message-ID: <543CD1F1.603@mail.ru> With help from Alexander Bokovoy I found correct log destinations: sssd-domain-log: https://cloud.mail.ru/public/1e803a00989e%2Fsssd_eurosel.az.log sssd-nss-log: https://cloud.mail.ru/public/ae41ae3b44b6%2Fsssd_nss.log These files are from my second Fedora - FreeBSD setup, they have different domain name, but everything else is identical. Interestingly enough, there are lines in sssd_nss.log telling that there are no users or groups in the domain. But as I said, I can ssh to the IPA server as an IPA user. 14-Oct-14 00:32, Lukas Slebodnik ?????: > On (13/10/14 20:33), Jakub Hrozek wrote: >> On Mon, Oct 13, 2014 at 10:10:12PM +0400, ????? ??????? wrote: >>> Good day to everybody. >>> There`s a post on how to make a FreeBSD client work with a FreeIPA server: https://forums.freebsd.org/viewtopic.php?f=39&t=46526&p=260146#p260146 >>> For some reason the instructions in that post don`t lead to a working solution. >>> Getent passwd/group return no data from the IPA server, although ldapsearch works fine. >>> I followed the instructions exactly (+ configured ldap.conf & started sssd) and didn`t get errors anywhere, all steps completed successfully. >>> My setup: 2 VMs, one is the FreeIPA server (on Fedora 20), the other is a FreeBSD client (on FreeBSD 10.0). >>> IPA server is configured as written in the IPA Quick Start Quide, it has no integrated DNS server. >>> Both VMs have identical /etc/hosts file: >>> >>> ::1 localhost >>> 127.0.0.1 localhost >>> 192.168.1.10 ipa1.mydomain.com ipa1 >>> 192.168.1.30 bsd1.mydomain.com bsd1 >>> >>> Seems like some instructions in etc/nsswitch.conf file, like "group: files sss" and "passwd: files sss" have no effect. >>> Does anybody tried this setup, what could be wrong with it? >>> I can provide outputs of any commands if necessary. >>> If I shouldn`t have asked this question here, please advise me where to ask. >>> Any hint on what to do will be highly appreciated! >> Hi, >> >> I think SSSD logs would be the best start.. >> >> Put debug_level=7 into the [domain] section, restart SSSD and then check >> out /var/log/sssd/*.log >> > "debug_level = 7" can be put into "nss" section as well. > Could you share your sssd configuration file /usr/local/etc/sssd.conf? > > LS > From orkhan-azeri at mail.ru Tue Oct 14 07:38:37 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Tue, 14 Oct 2014 12:38:37 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <543CB33D.6020005@mail.ru> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CB33D.6020005@mail.ru> Message-ID: <543CD2FD.6080702@mail.ru> With help from Alexander Bokovoy I found correct log destinations: sssd-domain-log:https://cloud.mail.ru/public/1e803a00989e%2Fsssd_eurosel.az.log sssd-nss-log:https://cloud.mail.ru/public/ae41ae3b44b6%2Fsssd_nss.log These files are from my second Fedora - FreeBSD setup, they have different domain name, but everything else is identical. Interestingly enough, there are lines in sssd_nss.log telling that there are no users or groups in the domain. But as I said, I can ssh to the IPA server as an IPA user. 14-Oct-14 10:23, Orkhan Gasimov ?????: > Thanks to both of you for the interest. > Here`s the info you asked: > > 1. Putting "debug_level = 7" either in [domain] or/and [nss] section > of the /usr/local/etc/sssd/sssd.conf file gives nothing in the log. > The log file located at /var/log/sssd/sssd.log is only populated with > data when I make some errors in sssd.conf & sssd process fails to > start. But that`s the case only if I deliberately introduce some > errors; with current configuration sssd starts successfully. > > 2. My original sssd.conf (without debugs) is as follows (exact copy of > what was shown in the post at FreeBSD forums): > > ----------------------------------------- > [domain/mydomain.com] > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = mydomain.com > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = ipa1.mydomain.com > chpass_provider = ipa > ipa_server = _srv_ #our FreeIPA server has DNS SRV entries > ldap_tls_cacert = /etc/ssl/ca.crt > enumerate = True #to enumerate users and groups > > [sssd] > enumerate = True > services = nss, pam, sudo > config_file_version = 2 > domains = mydomain.com > > [nss] > > [pam] > > [sudo] > ----------------------------------------- > > Interestingly enough the [nss] section is empty, just as shown in the > post at FreeBSD forums. > > 3. The users created at the IPA server can`t locally log in to the > server, but it`s possible to ssh to the server as an IPA user from the > FreeBSD host. However, there are some interesting behaviors (again, > this is what happens when just following the IPA Quick Start Quide for > the server side & the post from FreeBSD forums for the client side): > - home directories are not automatically created on the IPA server; > - "id" command output shows correct uid, but the group of any IPA > user doesn`t show as "ipausers" - instead, the group name is the same > as username, + something like > "context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023". > > 4. Here is the list of snapshots taken from my FreeBSD VM when I > installed necessary ports, maybe these snapshots will provide some > additional info on sssd behavior: > > clean_install > starting_sssd_install > krb5_choice_added_LDAP > openldap24-sasl-client_choice_added_FETCH_GSSAPI > cyrus-sasl2_choice_defaults > bind_choice_added_GSSAPI_MIT > sssd_installation_finished > sudo_installed_with_INSULTS_LDAP_SSSD > cyrus-sasl2-gssapi_choice_added_MIT > all_ports_installed_directories_created > all_configs_applied_sssd_started > > > 14-Oct-14 00:32, Lukas Slebodnik ?????: >> On (13/10/14 20:33), Jakub Hrozek wrote: >>> On Mon, Oct 13, 2014 at 10:10:12PM +0400, ????? ??????? wrote: >>>> Good day to everybody. >>>> There`s a post on how to make a FreeBSD client work with a FreeIPA >>>> server: >>>> https://forums.freebsd.org/viewtopic.php?f=39&t=46526&p=260146#p260146 >>>> For some reason the instructions in that post don`t lead to a >>>> working solution. >>>> Getent passwd/group return no data from the IPA server, although >>>> ldapsearch works fine. >>>> I followed the instructions exactly (+ configured ldap.conf & >>>> started sssd) and didn`t get errors anywhere, all steps completed >>>> successfully. >>>> My setup: 2 VMs, one is the FreeIPA server (on Fedora 20), the >>>> other is a FreeBSD client (on FreeBSD 10.0). >>>> IPA server is configured as written in the IPA Quick Start Quide, >>>> it has no integrated DNS server. >>>> Both VMs have identical /etc/hosts file: >>>> >>>> ::1 localhost >>>> 127.0.0.1 localhost >>>> 192.168.1.10 ipa1.mydomain.com ipa1 >>>> 192.168.1.30 bsd1.mydomain.com bsd1 >>>> >>>> Seems like some instructions in etc/nsswitch.conf file, like >>>> "group: files sss" and "passwd: files sss" have no effect. >>>> Does anybody tried this setup, what could be wrong with it? >>>> I can provide outputs of any commands if necessary. >>>> If I shouldn`t have asked this question here, please advise me >>>> where to ask. >>>> Any hint on what to do will be highly appreciated! >>> Hi, >>> >>> I think SSSD logs would be the best start.. >>> >>> Put debug_level=7 into the [domain] section, restart SSSD and then >>> check >>> out /var/log/sssd/*.log >>> >> "debug_level = 7" can be put into "nss" section as well. >> Could you share your sssd configuration file /usr/local/etc/sssd.conf? >> >> LS >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Tue Oct 14 07:48:20 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 14 Oct 2014 17:48:20 +1000 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <543CD1F1.603@mail.ru> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CD1F1.603@mail.ru> Message-ID: <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> On Tue, Oct 14, 2014 at 12:34:09PM +0500, Orkhan Gasimov wrote: > With help from Alexander Bokovoy I found correct log destinations: > > sssd-domain-log: > https://cloud.mail.ru/public/1e803a00989e%2Fsssd_eurosel.az.log > sssd-nss-log: https://cloud.mail.ru/public/ae41ae3b44b6%2Fsssd_nss.log > > These files are from my second Fedora - FreeBSD setup, they have different > domain name, but everything else is identical. > > Interestingly enough, there are lines in sssd_nss.log telling that there are > no users or groups in the domain. But as I said, I can ssh to the IPA server > as an IPA user. > Hi Orkhan, Thanks for the logs. What were their actual locations? I'm going to try and reproduce your setup and see whether I get the same outcome. I have been building and installing the ports as indicated in the forum post, and one thing I have noticed is that there are a lot of configuration options on some of the important ports - perhaps there was an important option that the author forgot to mention. It is the end of the day for me, but sssd is now installed so I should let you know tomorrow whether I am running into the same issues as you, or whether I find success. (As a side node: once I get to a working setup I will create and publish a pkg(8) repo with the needed ports built with the correct options and make.conf variables. This should make it easier and certainly quicker to use FreeBSD as a FreeIPA client.) Cheers, Fraser > 14-Oct-14 00:32, Lukas Slebodnik ?????: > >On (13/10/14 20:33), Jakub Hrozek wrote: > >>On Mon, Oct 13, 2014 at 10:10:12PM +0400, ????? ??????? wrote: > >>> Good day to everybody. > >>>There`s a post on how to make a FreeBSD client work with a FreeIPA server: https://forums.freebsd.org/viewtopic.php?f=39&t=46526&p=260146#p260146 > >>>For some reason the instructions in that post don`t lead to a working solution. > >>>Getent passwd/group return no data from the IPA server, although ldapsearch works fine. > >>>I followed the instructions exactly (+ configured ldap.conf & started sssd) and didn`t get errors anywhere, all steps completed successfully. > >>>My setup: 2 VMs, one is the FreeIPA server (on Fedora 20), the other is a FreeBSD client (on FreeBSD 10.0). > >>>IPA server is configured as written in the IPA Quick Start Quide, it has no integrated DNS server. > >>>Both VMs have identical /etc/hosts file: > >>> > >>>::1 localhost > >>>127.0.0.1 localhost > >>>192.168.1.10 ipa1.mydomain.com ipa1 > >>>192.168.1.30 bsd1.mydomain.com bsd1 > >>> > >>>Seems like some instructions in etc/nsswitch.conf file, like "group: files sss" and "passwd: files sss" have no effect. > >>>Does anybody tried this setup, what could be wrong with it? > >>>I can provide outputs of any commands if necessary. > >>>If I shouldn`t have asked this question here, please advise me where to ask. > >>>Any hint on what to do will be highly appreciated! > >>Hi, > >> > >>I think SSSD logs would be the best start.. > >> > >>Put debug_level=7 into the [domain] section, restart SSSD and then check > >>out /var/log/sssd/*.log > >> > >"debug_level = 7" can be put into "nss" section as well. > >Could you share your sssd configuration file /usr/local/etc/sssd.conf? > > > >LS > > > > -- > 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 From abokovoy at redhat.com Tue Oct 14 07:50:34 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 14 Oct 2014 10:50:34 +0300 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <543CD2FD.6080702@mail.ru> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CB33D.6020005@mail.ru> <543CD2FD.6080702@mail.ru> Message-ID: <20141014075034.GL4143@redhat.com> On Tue, 14 Oct 2014, Orkhan Gasimov wrote: >With help from Alexander Bokovoy I found correct log destinations: > >sssd-domain-log:https://cloud.mail.ru/public/1e803a00989e%2Fsssd_eurosel.az.log >sssd-nss-log:https://cloud.mail.ru/public/ae41ae3b44b6%2Fsssd_nss.log > >These files are from my second Fedora - FreeBSD setup, they have >different domain name, but everything else is identical. > >Interestingly enough, there are lines in sssd_nss.log telling that there >are no users or groups in the domain. But as I said, I can ssh to the >IPA server as an IPA user. You have basic problem of DNS resolution at the FreeBSD client side: (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [request_watch_destructor] (0x0400): Deleting request watch (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [resolve_srv_done] (0x0020): SRV query failed: [Domain name not found] (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'not working' (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'IPA' as 'not resolved' (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (SRV lookup meta-server), resolver returned (5) ... (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'not working' (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'IPA' as 'not resolved' (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (SRV lookup meta-server), resolver returned (5) (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [be_resolve_server_process] (0x1000): Trying with the next one! (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [get_port_status] (0x1000): Port status of port 0 for server '(no name)' is 'not working' (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [fo_resolve_service_send] (0x0020): No available servers for service 'IPA' (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [be_resolve_server_done] (0x1000): Server resolution failed: 5 (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error]) (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks. Make sure your DNS infrastructure is actually working. Run following on FreeBSD side: dig SRV _ldap._tcp.eurosel.az dig SRV _kerberos._tcp.eurosel.az and fix either your resolver or DNS server to properly resolve SRV records for IPA domain (assuming eurosel.az is your IPA domain). -- / Alexander Bokovoy From lslebodn at redhat.com Tue Oct 14 07:58:33 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 14 Oct 2014 09:58:33 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <543CB33D.6020005@mail.ru> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CB33D.6020005@mail.ru> Message-ID: <20141014075833.GA3104@mail.corp.redhat.com> On (14/10/14 10:23), Orkhan Gasimov wrote: >Thanks to both of you for the interest. >Here`s the info you asked: > >1. Putting "debug_level = 7" either in [domain] or/and [nss] section of the >/usr/local/etc/sssd/sssd.conf file gives nothing in the log. The log file >located at /var/log/sssd/sssd.log is only populated with data when I make >some errors in sssd.conf & sssd process fails to start. But that`s the case >only if I deliberately introduce some errors; with current configuration sssd >starts successfully. > >2. My original sssd.conf (without debugs) is as follows (exact copy of what >was shown in the post at FreeBSD forums): > >----------------------------------------- >[domain/mydomain.com] >cache_credentials = True >krb5_store_password_if_offline = True >ipa_domain = mydomain.com >id_provider = ipa >auth_provider = ipa >access_provider = ipa >ipa_hostname = ipa1.mydomain.com >chpass_provider = ipa >ipa_server = _srv_ #our FreeIPA server has DNS SRV entries [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.eurosel.az' ... [resolve_srv_done] (0x0020): SRV query failed: [Domain name not found] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'IPA' as 'not resolved' [be_resolve_server_process] (0x0080): Couldn't resolve server (SRV lookup meta-server), resolver returned (5) DNS discovery of IPA server failed, becuase you just configured few hostnames in /etc/hosts You can add IP address or hostname to the option ipa_server e.g. ipa_server = _srv_, vm-120.eurosel.az BTW In my opinion, it is better to have comment before the optiona and not on the same line :-) LS From orkhan-azeri at mail.ru Tue Oct 14 08:04:29 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Tue, 14 Oct 2014 13:04:29 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CD1F1.603@mail.ru> <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> Message-ID: <543CD90D.9080502@mail.ru> Thanks for taking time to find a solution. 1. Location of log files is /var/log/sssd , I just didn`t know that each section of sssd.conf file produced its own log file: /var/log/sssd/sssd_.log /var/log/sssd/sssd_nss.log 2. For the client side, here again the list of snapshots taken from my FreeBSD VM when I installed necessary ports, maybe these snapshots will provide some additional info on sssd behavior: clean_install starting_sssd_install krb5_choice_added_LDAP openldap24-sasl-client_choice_added_FETCH_GSSAPI cyrus-sasl2_choice_defaults bind_choice_added_GSSAPI_MIT sssd_installation_finished sudo_installed_with_INSULTS_LDAP_SSSD cyrus-sasl2-gssapi_choice_added_MIT all_ports_installed_directories_created all_configs_applied_sssd_started 3. For the server side, one thing that I had to do differently when adding the client to the server, is I used the "--force" option, as the server complained about the host not having a DNS A record (I don`t run DNS server on IPA server). 14-Oct-14 12:48, Fraser Tweedale ?????: > On Tue, Oct 14, 2014 at 12:34:09PM +0500, Orkhan Gasimov wrote: >> With help from Alexander Bokovoy I found correct log destinations: >> >> sssd-domain-log: >> https://cloud.mail.ru/public/1e803a00989e%2Fsssd_eurosel.az.log >> sssd-nss-log: https://cloud.mail.ru/public/ae41ae3b44b6%2Fsssd_nss.log >> >> These files are from my second Fedora - FreeBSD setup, they have different >> domain name, but everything else is identical. >> >> Interestingly enough, there are lines in sssd_nss.log telling that there are >> no users or groups in the domain. But as I said, I can ssh to the IPA server >> as an IPA user. >> > Hi Orkhan, > > Thanks for the logs. What were their actual locations? > > I'm going to try and reproduce your setup and see whether I get the > same outcome. I have been building and installing the ports as > indicated in the forum post, and one thing I have noticed is that > there are a lot of configuration options on some of the important > ports - perhaps there was an important option that the author forgot > to mention. > > It is the end of the day for me, but sssd is now installed so I > should let you know tomorrow whether I am running into the same > issues as you, or whether I find success. > > (As a side node: once I get to a working setup I will create and > publish a pkg(8) repo with the needed ports built with the correct > options and make.conf variables. This should make it easier and > certainly quicker to use FreeBSD as a FreeIPA client.) > > Cheers, > > Fraser > >> 14-Oct-14 00:32, Lukas Slebodnik ?????: >>> On (13/10/14 20:33), Jakub Hrozek wrote: >>>> On Mon, Oct 13, 2014 at 10:10:12PM +0400, ????? ??????? wrote: >>>>> Good day to everybody. >>>>> There`s a post on how to make a FreeBSD client work with a FreeIPA server: https://forums.freebsd.org/viewtopic.php?f=39&t=46526&p=260146#p260146 >>>>> For some reason the instructions in that post don`t lead to a working solution. >>>>> Getent passwd/group return no data from the IPA server, although ldapsearch works fine. >>>>> I followed the instructions exactly (+ configured ldap.conf & started sssd) and didn`t get errors anywhere, all steps completed successfully. >>>>> My setup: 2 VMs, one is the FreeIPA server (on Fedora 20), the other is a FreeBSD client (on FreeBSD 10.0). >>>>> IPA server is configured as written in the IPA Quick Start Quide, it has no integrated DNS server. >>>>> Both VMs have identical /etc/hosts file: >>>>> >>>>> ::1 localhost >>>>> 127.0.0.1 localhost >>>>> 192.168.1.10 ipa1.mydomain.com ipa1 >>>>> 192.168.1.30 bsd1.mydomain.com bsd1 >>>>> >>>>> Seems like some instructions in etc/nsswitch.conf file, like "group: files sss" and "passwd: files sss" have no effect. >>>>> Does anybody tried this setup, what could be wrong with it? >>>>> I can provide outputs of any commands if necessary. >>>>> If I shouldn`t have asked this question here, please advise me where to ask. >>>>> Any hint on what to do will be highly appreciated! >>>> Hi, >>>> >>>> I think SSSD logs would be the best start.. >>>> >>>> Put debug_level=7 into the [domain] section, restart SSSD and then check >>>> out /var/log/sssd/*.log >>>> >>> "debug_level = 7" can be put into "nss" section as well. >>> Could you share your sssd configuration file /usr/local/etc/sssd.conf? >>> >>> LS >>> >> -- >> 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 From orkhan-azeri at mail.ru Tue Oct 14 09:49:00 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Tue, 14 Oct 2014 14:49:00 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141014075833.GA3104@mail.corp.redhat.com> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CB33D.6020005@mail.ru> <20141014075833.GA3104@mail.corp.redhat.com> Message-ID: <543CF18C.1090503@mail.ru> I suspected that problems could arise with DNS, and here they are... In fact, this entire string: "ipa_server = _srv_ #our FreeIPA server has DNS SRV entries" was taken as-is from the how-to on FreeBSD forums. First I commented it out, because was unsure sure if it was appropriate for my simple setup with just 2 VMs and and a bunch of records in /etc/hosts file. After starting sssd, I could get no IPA data with"getent passwd" or "getent group" commands. They I uncommented it and restarted sssd, but things remained the same. Now your advice is: "...add IP address or hostname to the option ipa_server", but you use an arbitrary name like "vm-120.eurosel.az". Could you please explain which host`s FQDN I should put there? If I use "ipa1.eurosel.az", then sssd won`t start (complains about "...Looping detected inside krb5_get_in_tkt..."). If it MUST be a DNS server, then everything changes. And the question then becomes: is it possible to set up a test FreeIPA client-server interaction using only 2 VMs and proper records in /etc/hosts instead of a DNS server? Or one MUST add a third VM and make it a DNS server to facilitate client-server interaction? 14-Oct-14 12:58, Lukas Slebodnik ?????: > On (14/10/14 10:23), Orkhan Gasimov wrote: >> Thanks to both of you for the interest. >> Here`s the info you asked: >> >> 1. Putting "debug_level = 7" either in [domain] or/and [nss] section of the >> /usr/local/etc/sssd/sssd.conf file gives nothing in the log. The log file >> located at /var/log/sssd/sssd.log is only populated with data when I make >> some errors in sssd.conf & sssd process fails to start. But that`s the case >> only if I deliberately introduce some errors; with current configuration sssd >> starts successfully. >> >> 2. My original sssd.conf (without debugs) is as follows (exact copy of what >> was shown in the post at FreeBSD forums): >> >> ----------------------------------------- >> [domain/mydomain.com] >> cache_credentials = True >> krb5_store_password_if_offline = True >> ipa_domain = mydomain.com >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = ipa1.mydomain.com >> chpass_provider = ipa >> ipa_server = _srv_ #our FreeIPA server has DNS SRV entries > > [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.eurosel.az' > ... > [resolve_srv_done] (0x0020): SRV query failed: [Domain name not found] > [set_srv_data_status] (0x0100): Marking SRV lookup of service 'IPA' as 'not resolved' > [be_resolve_server_process] (0x0080): Couldn't resolve server (SRV lookup meta-server), resolver returned (5) > > DNS discovery of IPA server failed, becuase you just configured few hostnames > in /etc/hosts > > You can add IP address or hostname to the option ipa_server > e.g. > ipa_server = _srv_, vm-120.eurosel.az > > BTW In my opinion, it is better to have comment before the optiona and not on > the same line :-) > > LS From orkhan-azeri at mail.ru Tue Oct 14 09:59:26 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Tue, 14 Oct 2014 14:59:26 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141014075034.GL4143@redhat.com> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CB33D.6020005@mail.ru> <543CD2FD.6080702@mail.ru> <20141014075034.GL4143@redhat.com> Message-ID: <543CF3FE.8080307@mail.ru> I tried to avoid setting up a third VM to serve as a DNS server for my test scenario. Thought it would be possible to set up working FreeIPA client-server interaction with just 2 VMs & correct hostnames & /etc/hosts files in them. Do I correctly understand your idea that it`s a MUST to set up a DNS server to facilitate FreeIPA client-server interaction? Or there`s a way to do it with just 2 VMs and no DNS server? 14-Oct-14 12:50, Alexander Bokovoy ?????: > On Tue, 14 Oct 2014, Orkhan Gasimov wrote: >> With help from Alexander Bokovoy I found correct log destinations: >> >> sssd-domain-log:https://cloud.mail.ru/public/1e803a00989e%2Fsssd_eurosel.az.log >> >> sssd-nss-log:https://cloud.mail.ru/public/ae41ae3b44b6%2Fsssd_nss.log >> >> These files are from my second Fedora - FreeBSD setup, they have >> different domain name, but everything else is identical. >> >> Interestingly enough, there are lines in sssd_nss.log telling that there >> are no users or groups in the domain. But as I said, I can ssh to the >> IPA server as an IPA user. > You have basic problem of DNS resolution at the FreeBSD client side: > (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] > [request_watch_destructor] (0x0400): Deleting request watch > (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [resolve_srv_done] > (0x0020): SRV query failed: [Domain name not found] > (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [fo_set_port_status] > (0x0100): Marking port 0 of server '(no name)' as 'not working' > (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [set_srv_data_status] > (0x0100): Marking SRV lookup of service 'IPA' as 'not resolved' > (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] > [be_resolve_server_process] (0x0080): Couldn't resolve server (SRV > lookup meta-server), resolver returned (5) > ... > (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [fo_set_port_status] > (0x0100): Marking port 0 of server '(no name)' as 'not working' > (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [set_srv_data_status] > (0x0100): Marking SRV lookup of service 'IPA' as 'not resolved' > (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] > [be_resolve_server_process] (0x0080): Couldn't resolve server (SRV > lookup meta-server), resolver returned (5) > (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] > [be_resolve_server_process] (0x1000): Trying with the next one! > (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [get_port_status] > (0x1000): Port status of port 0 for server '(no name)' is 'not working' > (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] > [fo_resolve_service_send] (0x0020): No available servers for service > 'IPA' > (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] > [be_resolve_server_done] (0x1000): Server resolution failed: 5 > (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] > [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 > [Input/output error]) > (Tue Oct 14 12:09:04 2014) [sssd[be[eurosel.az]]] [be_run_offline_cb] > (0x0080): Going offline. Running callbacks. > > > Make sure your DNS infrastructure is actually working. Run following on > FreeBSD side: > > dig SRV _ldap._tcp.eurosel.az > dig SRV _kerberos._tcp.eurosel.az > > and fix either your resolver or DNS server to properly resolve SRV > records for IPA domain (assuming eurosel.az is your IPA domain). > From pspacek at redhat.com Tue Oct 14 10:04:20 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 Oct 2014 12:04:20 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <543CF18C.1090503@mail.ru> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CB33D.6020005@mail.ru> <20141014075833.GA3104@mail.corp.redhat.com> <543CF18C.1090503@mail.ru> Message-ID: <543CF524.4050605@redhat.com> On 14.10.2014 11:49, Orkhan Gasimov wrote: > I suspected that problems could arise with DNS, and here they are... > > In fact, this entire string: "ipa_server = _srv_ #our FreeIPA server has DNS > SRV entries" was taken as-is from the how-to on FreeBSD forums. First I > commented it out, because was unsure sure if it was appropriate for my simple > setup with just 2 VMs and and a bunch of records in /etc/hosts file. After > starting sssd, I could get no IPA data with"getent passwd" or "getent group" > commands. They I uncommented it and restarted sssd, but things remained the same. > > Now your advice is: "...add IP address or hostname to the option ipa_server", > but you use an arbitrary name like "vm-120.eurosel.az". Could you please > explain which host`s FQDN I should put there? If I use "ipa1.eurosel.az", then > sssd won`t start (complains about "...Looping detected inside > krb5_get_in_tkt..."). > > If it MUST be a DNS server, then everything changes. And the question then > becomes: is it possible to set up a test FreeIPA client-server interaction > using only 2 VMs and proper records in /etc/hosts instead of a DNS server? Or > one MUST add a third VM and make it a DNS server to facilitate client-server > interaction? IPA theoretically can work without DNS records but it requires very careful configuration on clients and is strongly discouraged. If you want to do quick & dirty test, do this: $ ipa-server-install --setup-dns --forwarder + specify IPA domain name which is sub-domain of you existing domain (e.g. ipa.eurosel.az) + change /etc/resolv.conf on *all* clients to point to IPA server *This is a dirty trick* and it will not work unless all your clients has the IPA server in resolv.conf. It will most likely break when you try to use AD trust with AD clients etc. *In production environment* you should add NS records for ipa.eurosel.az domain to the parent DNS zone to create proper delegation. In that case you don't need to fiddle with resolv.conf on all clients. Let me know if you need further assistance. Petr^2 Spacek > 14-Oct-14 12:58, Lukas Slebodnik ?????: >> On (14/10/14 10:23), Orkhan Gasimov wrote: >>> Thanks to both of you for the interest. >>> Here`s the info you asked: >>> >>> 1. Putting "debug_level = 7" either in [domain] or/and [nss] section of the >>> /usr/local/etc/sssd/sssd.conf file gives nothing in the log. The log file >>> located at /var/log/sssd/sssd.log is only populated with data when I make >>> some errors in sssd.conf & sssd process fails to start. But that`s the case >>> only if I deliberately introduce some errors; with current configuration sssd >>> starts successfully. >>> >>> 2. My original sssd.conf (without debugs) is as follows (exact copy of what >>> was shown in the post at FreeBSD forums): >>> >>> ----------------------------------------- >>> [domain/mydomain.com] >>> cache_credentials = True >>> krb5_store_password_if_offline = True >>> ipa_domain = mydomain.com >>> id_provider = ipa >>> auth_provider = ipa >>> access_provider = ipa >>> ipa_hostname = ipa1.mydomain.com >>> chpass_provider = ipa >>> ipa_server = _srv_ #our FreeIPA server has DNS SRV entries >> >> [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of >> '_ldap._tcp.eurosel.az' >> ... >> [resolve_srv_done] (0x0020): SRV query failed: [Domain name not found] >> [set_srv_data_status] (0x0100): Marking SRV lookup of service 'IPA' as 'not >> resolved' >> [be_resolve_server_process] (0x0080): Couldn't resolve server (SRV lookup >> meta-server), resolver returned (5) >> >> DNS discovery of IPA server failed, becuase you just configured few hostnames >> in /etc/hosts >> >> You can add IP address or hostname to the option ipa_server >> e.g. >> ipa_server = _srv_, vm-120.eurosel.az >> >> BTW In my opinion, it is better to have comment before the optiona and not on >> the same line :-) From abokovoy at redhat.com Tue Oct 14 10:15:17 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 14 Oct 2014 13:15:17 +0300 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <543CF3FE.8080307@mail.ru> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CB33D.6020005@mail.ru> <543CD2FD.6080702@mail.ru> <20141014075034.GL4143@redhat.com> <543CF3FE.8080307@mail.ru> Message-ID: <20141014101453.GM4143@redhat.com> On Tue, 14 Oct 2014, Orkhan Gasimov wrote: >I tried to avoid setting up a third VM to serve as a DNS server for my >test scenario. Thought it would be possible to set up working FreeIPA >client-server interaction with just 2 VMs & correct hostnames & >/etc/hosts files in them. Many applications rely on service discovery based on DNS. In particular, SSSD uses this approach if you don't set explicitly servers for LDAP, Kerberos, IPA, etc. See sssd-ldap(5), sssd-krb5(5), sssd-ipa(5), section 'SERVICE DISCOVERY'. The mechanism is described in RFC 2782. It becomes even more important for cases like integration with Active Directory where AD side relies on DNS service discovery unconditionally. IPA has integrated DNS server, all you needed to do is to run 'ipa-server-install --setup-dns' or 'ipa-dns-install' afterwards. If you don't want to use IPA-provided DNS server, at the end of ipa-server-install a sample DNS zone was generated to show what records need to be added to your DNS zone. >Do I correctly understand your idea that it`s a MUST to set up a DNS >server to facilitate FreeIPA client-server interaction? Or there`s a >way to do it with just 2 VMs and no DNS server? Use integrated DNS server in FreeIPA server, this is supported way of doing it. FreeIPA then will make it manageable through its tools -- be it command line interface or web UI. -- / Alexander Bokovoy From orkhan-azeri at mail.ru Tue Oct 14 10:54:31 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Tue, 14 Oct 2014 15:54:31 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <543CF524.4050605@redhat.com> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CB33D.6020005@mail.ru> <20141014075833.GA3104@mail.corp.redhat.com> <543CF18C.1090503@mail.ru> <543CF524.4050605@redhat.com> Message-ID: <543D00E7.6090201@mail.ru> I`ll try such a test setup, then share information about results. 14-Oct-14 15:04, Petr Spacek ?????: > On 14.10.2014 11:49, Orkhan Gasimov wrote: >> I suspected that problems could arise with DNS, and here they are... >> >> In fact, this entire string: "ipa_server = _srv_ #our FreeIPA server >> has DNS >> SRV entries" was taken as-is from the how-to on FreeBSD forums. First I >> commented it out, because was unsure sure if it was appropriate for >> my simple >> setup with just 2 VMs and and a bunch of records in /etc/hosts file. >> After >> starting sssd, I could get no IPA data with"getent passwd" or "getent >> group" >> commands. They I uncommented it and restarted sssd, but things >> remained the same. >> >> Now your advice is: "...add IP address or hostname to the option >> ipa_server", >> but you use an arbitrary name like "vm-120.eurosel.az". Could you please >> explain which host`s FQDN I should put there? If I use >> "ipa1.eurosel.az", then >> sssd won`t start (complains about "...Looping detected inside >> krb5_get_in_tkt..."). >> >> If it MUST be a DNS server, then everything changes. And the question >> then >> becomes: is it possible to set up a test FreeIPA client-server >> interaction >> using only 2 VMs and proper records in /etc/hosts instead of a DNS >> server? Or >> one MUST add a third VM and make it a DNS server to facilitate >> client-server >> interaction? > > IPA theoretically can work without DNS records but it requires very > careful configuration on clients and is strongly discouraged. > > If you want to do quick & dirty test, do this: > $ ipa-server-install --setup-dns --forwarder *existing* DNS server> > + specify IPA domain name which is sub-domain of you existing domain > (e.g. ipa.eurosel.az) > + change /etc/resolv.conf on *all* clients to point to IPA server > > *This is a dirty trick* and it will not work unless all your clients > has the IPA server in resolv.conf. It will most likely break when you > try to use AD trust with AD clients etc. > > > *In production environment* you should add NS records for > ipa.eurosel.az domain to the parent DNS zone to create proper > delegation. In that case you don't need to fiddle with resolv.conf on > all clients. > > Let me know if you need further assistance. > > Petr^2 Spacek > > >> 14-Oct-14 12:58, Lukas Slebodnik ?????: >>> On (14/10/14 10:23), Orkhan Gasimov wrote: >>>> Thanks to both of you for the interest. >>>> Here`s the info you asked: >>>> >>>> 1. Putting "debug_level = 7" either in [domain] or/and [nss] >>>> section of the >>>> /usr/local/etc/sssd/sssd.conf file gives nothing in the log. The >>>> log file >>>> located at /var/log/sssd/sssd.log is only populated with data when >>>> I make >>>> some errors in sssd.conf & sssd process fails to start. But that`s >>>> the case >>>> only if I deliberately introduce some errors; with current >>>> configuration sssd >>>> starts successfully. >>>> >>>> 2. My original sssd.conf (without debugs) is as follows (exact copy >>>> of what >>>> was shown in the post at FreeBSD forums): >>>> >>>> ----------------------------------------- >>>> [domain/mydomain.com] >>>> cache_credentials = True >>>> krb5_store_password_if_offline = True >>>> ipa_domain = mydomain.com >>>> id_provider = ipa >>>> auth_provider = ipa >>>> access_provider = ipa >>>> ipa_hostname = ipa1.mydomain.com >>>> chpass_provider = ipa >>>> ipa_server = _srv_ #our FreeIPA server has DNS SRV entries >>> >>> [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of >>> '_ldap._tcp.eurosel.az' >>> ... >>> [resolve_srv_done] (0x0020): SRV query failed: [Domain name not found] >>> [set_srv_data_status] (0x0100): Marking SRV lookup of service 'IPA' >>> as 'not >>> resolved' >>> [be_resolve_server_process] (0x0080): Couldn't resolve server (SRV >>> lookup >>> meta-server), resolver returned (5) >>> >>> DNS discovery of IPA server failed, becuase you just configured few >>> hostnames >>> in /etc/hosts >>> >>> You can add IP address or hostname to the option ipa_server >>> e.g. >>> ipa_server = _srv_, vm-120.eurosel.az >>> >>> BTW In my opinion, it is better to have comment before the optiona >>> and not on >>> the same line :-) > From pspacek at redhat.com Tue Oct 14 11:29:01 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 Oct 2014 13:29:01 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <543CF18C.1090503@mail.ru> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CB33D.6020005@mail.ru> <20141014075833.GA3104@mail.corp.redhat.com> <543CF18C.1090503@mail.ru> Message-ID: <543D08FD.8030703@redhat.com> On 14.10.2014 11:49, Orkhan Gasimov wrote: > I suspected that problems could arise with DNS, and here they are... > > In fact, this entire string: "ipa_server = _srv_ #our FreeIPA server has DNS > SRV entries" was taken as-is from the how-to on FreeBSD forums. First I > commented it out, because was unsure sure if it was appropriate for my simple > setup with just 2 VMs and and a bunch of records in /etc/hosts file. After > starting sssd, I could get no IPA data with"getent passwd" or "getent group" > commands. They I uncommented it and restarted sssd, but things remained the same. > > Now your advice is: "...add IP address or hostname to the option ipa_server", > but you use an arbitrary name like "vm-120.eurosel.az". Could you please > explain which host`s FQDN I should put there? If I use "ipa1.eurosel.az", then > sssd won`t start (complains about "...Looping detected inside > krb5_get_in_tkt..."). > > If it MUST be a DNS server, then everything changes. And the question then > becomes: is it possible to set up a test FreeIPA client-server interaction > using only 2 VMs and proper records in /etc/hosts instead of a DNS server? Or > one MUST add a third VM and make it a DNS server to facilitate client-server > interaction? IPA theoretically can work without DNS records but it requires very careful configuration on clients and is strongly discouraged. If you want to do quick & dirty test, do this: $ ipa-server-install --setup-dns --forwarder + specify IPA domain name which is sub-domain of you existing domain (e.g. ipa.eurosel.az) + change /etc/resolv.conf on *all* clients to point to IPA server *This is a dirty trick* and it will not work unless all your clients has the IPA server in resolv.conf. It will most likely break when you try to use AD trust with AD clients etc. *In production environment* you should add NS records for ipa.eurosel.az domain to the parent DNS zone to create proper delegation. In that case you don't need to fiddle with resolv.conf on all clients. Let me know if you need further assistance. Petr^2 Spacek > 14-Oct-14 12:58, Lukas Slebodnik ?????: >> On (14/10/14 10:23), Orkhan Gasimov wrote: >>> Thanks to both of you for the interest. >>> Here`s the info you asked: >>> >>> 1. Putting "debug_level = 7" either in [domain] or/and [nss] section of the >>> /usr/local/etc/sssd/sssd.conf file gives nothing in the log. The log file >>> located at /var/log/sssd/sssd.log is only populated with data when I make >>> some errors in sssd.conf & sssd process fails to start. But that`s the case >>> only if I deliberately introduce some errors; with current configuration sssd >>> starts successfully. >>> >>> 2. My original sssd.conf (without debugs) is as follows (exact copy of what >>> was shown in the post at FreeBSD forums): >>> >>> ----------------------------------------- >>> [domain/mydomain.com] >>> cache_credentials = True >>> krb5_store_password_if_offline = True >>> ipa_domain = mydomain.com >>> id_provider = ipa >>> auth_provider = ipa >>> access_provider = ipa >>> ipa_hostname = ipa1.mydomain.com >>> chpass_provider = ipa >>> ipa_server = _srv_ #our FreeIPA server has DNS SRV entries >> >> [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of >> '_ldap._tcp.eurosel.az' >> ... >> [resolve_srv_done] (0x0020): SRV query failed: [Domain name not found] >> [set_srv_data_status] (0x0100): Marking SRV lookup of service 'IPA' as 'not >> resolved' >> [be_resolve_server_process] (0x0080): Couldn't resolve server (SRV lookup >> meta-server), resolver returned (5) >> >> DNS discovery of IPA server failed, becuase you just configured few hostnames >> in /etc/hosts >> >> You can add IP address or hostname to the option ipa_server >> e.g. >> ipa_server = _srv_, vm-120.eurosel.az >> >> BTW In my opinion, it is better to have comment before the optiona and not on >> the same line :-) -- Petr^2 Spacek From orkhan-azeri at mail.ru Tue Oct 14 11:48:28 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Tue, 14 Oct 2014 16:48:28 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <543D08FD.8030703@redhat.com> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CB33D.6020005@mail.ru> <20141014075833.GA3104@mail.corp.redhat.com> <543CF18C.1090503@mail.ru> <543D08FD.8030703@redhat.com> Message-ID: <543D0D8C.5050705@mail.ru> I need further assistance with this moment: "specify IPA domain name which is sub-domain of you existing domain (e.g. ipa.eurosel.az) ". Currently my FreeIPA server's hostname is ipa1.eurosel.az, and client's hostname is bsd1.eurosel.az. So when running this command: "ipa-server-install --setup-dns --forwarder ", the installation program detects the hostname of the VM (ipa1.eurosel.az) and offers it as IPA server FQDN; then it offers "eurosel.az" as the domain name. I can make changes right during the installation process (FQDN = ipa1.ipa.eurosel.az & domain = ipa.eurosel.az), but then there will be a conflict with the real hostname and records in the /etc/hosts file. On the other hand, if I change the hostname of the server VM to "ipa1.ipa.eurosel.az" prior to running the IPA installation program, then the installation program will offer my server an FQDN of "ipa1.ipa.eurosel.az" and a domain name of "ipa.eurosel.az". But doesn`t it mean that my client`s hostname should also be changed to bsd1.ipa.eurosel.az? I`d like to avoid this, because in production I won`t be able to change the domain part of FQDN for hundreds of clients. Please don`t hesitate to explain a little clearer. 14-Oct-14 16:29, Petr Spacek ?????: > On 14.10.2014 11:49, Orkhan Gasimov wrote: >> I suspected that problems could arise with DNS, and here they are... >> >> In fact, this entire string: "ipa_server = _srv_ #our FreeIPA server >> has DNS >> SRV entries" was taken as-is from the how-to on FreeBSD forums. First I >> commented it out, because was unsure sure if it was appropriate for >> my simple >> setup with just 2 VMs and and a bunch of records in /etc/hosts file. >> After >> starting sssd, I could get no IPA data with"getent passwd" or "getent >> group" >> commands. They I uncommented it and restarted sssd, but things >> remained the same. >> >> Now your advice is: "...add IP address or hostname to the option >> ipa_server", >> but you use an arbitrary name like "vm-120.eurosel.az". Could you please >> explain which host`s FQDN I should put there? If I use >> "ipa1.eurosel.az", then >> sssd won`t start (complains about "...Looping detected inside >> krb5_get_in_tkt..."). >> >> If it MUST be a DNS server, then everything changes. And the question >> then >> becomes: is it possible to set up a test FreeIPA client-server >> interaction >> using only 2 VMs and proper records in /etc/hosts instead of a DNS >> server? Or >> one MUST add a third VM and make it a DNS server to facilitate >> client-server >> interaction? > > IPA theoretically can work without DNS records but it requires very > careful configuration on clients and is strongly discouraged. > > If you want to do quick & dirty test, do this: > $ ipa-server-install --setup-dns --forwarder *existing* DNS server> > + specify IPA domain name which is sub-domain of you existing domain > (e.g. ipa.eurosel.az) > + change /etc/resolv.conf on *all* clients to point to IPA server > > *This is a dirty trick* and it will not work unless all your clients > has the IPA server in resolv.conf. It will most likely break when you > try to use AD trust with AD clients etc. > > > *In production environment* you should add NS records for > ipa.eurosel.az domain to the parent DNS zone to create proper > delegation. In that case you don't need to fiddle with resolv.conf on > all clients. > > Let me know if you need further assistance. > > Petr^2 Spacek > > >> 14-Oct-14 12:58, Lukas Slebodnik ?????: >>> On (14/10/14 10:23), Orkhan Gasimov wrote: >>>> Thanks to both of you for the interest. >>>> Here`s the info you asked: >>>> >>>> 1. Putting "debug_level = 7" either in [domain] or/and [nss] >>>> section of the >>>> /usr/local/etc/sssd/sssd.conf file gives nothing in the log. The >>>> log file >>>> located at /var/log/sssd/sssd.log is only populated with data when >>>> I make >>>> some errors in sssd.conf & sssd process fails to start. But that`s >>>> the case >>>> only if I deliberately introduce some errors; with current >>>> configuration sssd >>>> starts successfully. >>>> >>>> 2. My original sssd.conf (without debugs) is as follows (exact copy >>>> of what >>>> was shown in the post at FreeBSD forums): >>>> >>>> ----------------------------------------- >>>> [domain/mydomain.com] >>>> cache_credentials = True >>>> krb5_store_password_if_offline = True >>>> ipa_domain = mydomain.com >>>> id_provider = ipa >>>> auth_provider = ipa >>>> access_provider = ipa >>>> ipa_hostname = ipa1.mydomain.com >>>> chpass_provider = ipa >>>> ipa_server = _srv_ #our FreeIPA server has DNS SRV entries >>> >>> [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of >>> '_ldap._tcp.eurosel.az' >>> ... >>> [resolve_srv_done] (0x0020): SRV query failed: [Domain name not found] >>> [set_srv_data_status] (0x0100): Marking SRV lookup of service 'IPA' >>> as 'not >>> resolved' >>> [be_resolve_server_process] (0x0080): Couldn't resolve server (SRV >>> lookup >>> meta-server), resolver returned (5) >>> >>> DNS discovery of IPA server failed, becuase you just configured few >>> hostnames >>> in /etc/hosts >>> >>> You can add IP address or hostname to the option ipa_server >>> e.g. >>> ipa_server = _srv_, vm-120.eurosel.az >>> >>> BTW In my opinion, it is better to have comment before the optiona >>> and not on >>> the same line :-) > From pspacek at redhat.com Tue Oct 14 12:43:45 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 Oct 2014 14:43:45 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <543D0D8C.5050705@mail.ru> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CB33D.6020005@mail.ru> <20141014075833.GA3104@mail.corp.redhat.com> <543CF18C.1090503@mail.ru> <543D08FD.8030703@redhat.com> <543D0D8C.5050705@mail.ru> Message-ID: <543D1A81.9080001@redhat.com> On 14.10.2014 13:48, Orkhan Gasimov wrote: > I need further assistance with this moment: > "specify IPA domain name which is sub-domain of you existing domain (e.g. > ipa.eurosel.az) ". > > Currently my FreeIPA server's hostname is ipa1.eurosel.az, and client's > hostname is bsd1.eurosel.az. > So when running this command: > > "ipa-server-install --setup-dns --forwarder server>", > > the installation program detects the hostname of the VM (ipa1.eurosel.az) and > offers it as IPA server FQDN; > then it offers "eurosel.az" as the domain name. I can make changes right > during the installation process (FQDN = ipa1.ipa.eurosel.az & domain = > ipa.eurosel.az), but then there will be a conflict with the real hostname and > records in the /etc/hosts file. > > On the other hand, if I change the hostname of the server VM to > "ipa1.ipa.eurosel.az" prior to running the IPA installation program, then the > installation program will offer my server an FQDN of "ipa1.ipa.eurosel.az" and > a domain name of "ipa.eurosel.az". But doesn`t it mean that my client`s > hostname should also be changed to bsd1.ipa.eurosel.az? I`d like to avoid > this, because in production I won`t be able to change the domain part of FQDN > for hundreds of clients. Clients don't need to be in the same domain as IPA. The IPA domain in DNS is necessary to store 'metadata' like SRV and TXT records etc. You can even experiment with IPA servers which are not in the IPA domain but I'm not sure how much it was tested. Alexander can add more details about records required for AD integration and how it should work with clients which are not in the IPA domain. Petr^2 Spacek > > 14-Oct-14 16:29, Petr Spacek ?????: >> On 14.10.2014 11:49, Orkhan Gasimov wrote: >>> I suspected that problems could arise with DNS, and here they are... >>> >>> In fact, this entire string: "ipa_server = _srv_ #our FreeIPA server has DNS >>> SRV entries" was taken as-is from the how-to on FreeBSD forums. First I >>> commented it out, because was unsure sure if it was appropriate for my simple >>> setup with just 2 VMs and and a bunch of records in /etc/hosts file. After >>> starting sssd, I could get no IPA data with"getent passwd" or "getent group" >>> commands. They I uncommented it and restarted sssd, but things remained the >>> same. >>> >>> Now your advice is: "...add IP address or hostname to the option ipa_server", >>> but you use an arbitrary name like "vm-120.eurosel.az". Could you please >>> explain which host`s FQDN I should put there? If I use "ipa1.eurosel.az", then >>> sssd won`t start (complains about "...Looping detected inside >>> krb5_get_in_tkt..."). >>> >>> If it MUST be a DNS server, then everything changes. And the question then >>> becomes: is it possible to set up a test FreeIPA client-server interaction >>> using only 2 VMs and proper records in /etc/hosts instead of a DNS server? Or >>> one MUST add a third VM and make it a DNS server to facilitate client-server >>> interaction? >> >> IPA theoretically can work without DNS records but it requires very careful >> configuration on clients and is strongly discouraged. >> >> If you want to do quick & dirty test, do this: >> $ ipa-server-install --setup-dns --forwarder > DNS server> >> + specify IPA domain name which is sub-domain of you existing domain (e.g. >> ipa.eurosel.az) >> + change /etc/resolv.conf on *all* clients to point to IPA server >> >> *This is a dirty trick* and it will not work unless all your clients has the >> IPA server in resolv.conf. It will most likely break when you try to use AD >> trust with AD clients etc. >> >> >> *In production environment* you should add NS records for ipa.eurosel.az >> domain to the parent DNS zone to create proper delegation. In that case you >> don't need to fiddle with resolv.conf on all clients. >> >> Let me know if you need further assistance. >> >> Petr^2 Spacek >> >> >>> 14-Oct-14 12:58, Lukas Slebodnik ?????: >>>> On (14/10/14 10:23), Orkhan Gasimov wrote: >>>>> Thanks to both of you for the interest. >>>>> Here`s the info you asked: >>>>> >>>>> 1. Putting "debug_level = 7" either in [domain] or/and [nss] section of the >>>>> /usr/local/etc/sssd/sssd.conf file gives nothing in the log. The log file >>>>> located at /var/log/sssd/sssd.log is only populated with data when I make >>>>> some errors in sssd.conf & sssd process fails to start. But that`s the case >>>>> only if I deliberately introduce some errors; with current configuration >>>>> sssd >>>>> starts successfully. >>>>> >>>>> 2. My original sssd.conf (without debugs) is as follows (exact copy of what >>>>> was shown in the post at FreeBSD forums): >>>>> >>>>> ----------------------------------------- >>>>> [domain/mydomain.com] >>>>> cache_credentials = True >>>>> krb5_store_password_if_offline = True >>>>> ipa_domain = mydomain.com >>>>> id_provider = ipa >>>>> auth_provider = ipa >>>>> access_provider = ipa >>>>> ipa_hostname = ipa1.mydomain.com >>>>> chpass_provider = ipa >>>>> ipa_server = _srv_ #our FreeIPA server has DNS SRV entries >>>> >>>> [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of >>>> '_ldap._tcp.eurosel.az' >>>> ... >>>> [resolve_srv_done] (0x0020): SRV query failed: [Domain name not found] >>>> [set_srv_data_status] (0x0100): Marking SRV lookup of service 'IPA' as 'not >>>> resolved' >>>> [be_resolve_server_process] (0x0080): Couldn't resolve server (SRV lookup >>>> meta-server), resolver returned (5) >>>> >>>> DNS discovery of IPA server failed, becuase you just configured few hostnames >>>> in /etc/hosts >>>> >>>> You can add IP address or hostname to the option ipa_server >>>> e.g. >>>> ipa_server = _srv_, vm-120.eurosel.az >>>> >>>> BTW In my opinion, it is better to have comment before the optiona and not on >>>> the same line :-) -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek From orkhan-azeri at mail.ru Tue Oct 14 12:58:41 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Tue, 14 Oct 2014 17:58:41 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <543D1A81.9080001@redhat.com> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CB33D.6020005@mail.ru> <20141014075833.GA3104@mail.corp.redhat.com> <543CF18C.1090503@mail.ru> <543D08FD.8030703@redhat.com> <543D0D8C.5050705@mail.ru> <543D1A81.9080001@redhat.com> Message-ID: <543D1E01.2030401@mail.ru> So which way do I go? 1) Change the server VM`s hostname from "ipa1.eurosel.az" to "ipa1.ipa.eurosel.az" prior to issuing IPA installation command 2) or leave my hostname and contents of /etc/hosts file intact and specify a different FQDN and domain part of the IPA server after issuing IPA installation command? Yes, I know - this is a question Homer Simpson would ask. 14-Oct-14 17:43, Petr Spacek ?????: > On 14.10.2014 13:48, Orkhan Gasimov wrote: >> I need further assistance with this moment: >> "specify IPA domain name which is sub-domain of you existing domain >> (e.g. >> ipa.eurosel.az) ". >> >> Currently my FreeIPA server's hostname is ipa1.eurosel.az, and client's >> hostname is bsd1.eurosel.az. >> So when running this command: >> >> "ipa-server-install --setup-dns --forwarder > *existing* DNS >> server>", >> >> the installation program detects the hostname of the VM >> (ipa1.eurosel.az) and >> offers it as IPA server FQDN; >> then it offers "eurosel.az" as the domain name. I can make changes right >> during the installation process (FQDN = ipa1.ipa.eurosel.az & domain = >> ipa.eurosel.az), but then there will be a conflict with the real >> hostname and >> records in the /etc/hosts file. >> >> On the other hand, if I change the hostname of the server VM to >> "ipa1.ipa.eurosel.az" prior to running the IPA installation program, >> then the >> installation program will offer my server an FQDN of >> "ipa1.ipa.eurosel.az" and >> a domain name of "ipa.eurosel.az". But doesn`t it mean that my client`s >> hostname should also be changed to bsd1.ipa.eurosel.az? I`d like to >> avoid >> this, because in production I won`t be able to change the domain part >> of FQDN >> for hundreds of clients. > > Clients don't need to be in the same domain as IPA. The IPA domain in > DNS is necessary to store 'metadata' like SRV and TXT records etc. > > You can even experiment with IPA servers which are not in the IPA > domain but I'm not sure how much it was tested. > > Alexander can add more details about records required for AD > integration and how it should work with clients which are not in the > IPA domain. > > Petr^2 Spacek > >> >> 14-Oct-14 16:29, Petr Spacek ?????: >>> On 14.10.2014 11:49, Orkhan Gasimov wrote: >>>> I suspected that problems could arise with DNS, and here they are... >>>> >>>> In fact, this entire string: "ipa_server = _srv_ #our FreeIPA >>>> server has DNS >>>> SRV entries" was taken as-is from the how-to on FreeBSD forums. >>>> First I >>>> commented it out, because was unsure sure if it was appropriate for >>>> my simple >>>> setup with just 2 VMs and and a bunch of records in /etc/hosts >>>> file. After >>>> starting sssd, I could get no IPA data with"getent passwd" or >>>> "getent group" >>>> commands. They I uncommented it and restarted sssd, but things >>>> remained the >>>> same. >>>> >>>> Now your advice is: "...add IP address or hostname to the option >>>> ipa_server", >>>> but you use an arbitrary name like "vm-120.eurosel.az". Could you >>>> please >>>> explain which host`s FQDN I should put there? If I use >>>> "ipa1.eurosel.az", then >>>> sssd won`t start (complains about "...Looping detected inside >>>> krb5_get_in_tkt..."). >>>> >>>> If it MUST be a DNS server, then everything changes. And the >>>> question then >>>> becomes: is it possible to set up a test FreeIPA client-server >>>> interaction >>>> using only 2 VMs and proper records in /etc/hosts instead of a DNS >>>> server? Or >>>> one MUST add a third VM and make it a DNS server to facilitate >>>> client-server >>>> interaction? >>> >>> IPA theoretically can work without DNS records but it requires very >>> careful >>> configuration on clients and is strongly discouraged. >>> >>> If you want to do quick & dirty test, do this: >>> $ ipa-server-install --setup-dns --forwarder >> *existing* >>> DNS server> >>> + specify IPA domain name which is sub-domain of you existing domain >>> (e.g. >>> ipa.eurosel.az) >>> + change /etc/resolv.conf on *all* clients to point to IPA server >>> >>> *This is a dirty trick* and it will not work unless all your clients >>> has the >>> IPA server in resolv.conf. It will most likely break when you try to >>> use AD >>> trust with AD clients etc. >>> >>> >>> *In production environment* you should add NS records for >>> ipa.eurosel.az >>> domain to the parent DNS zone to create proper delegation. In that >>> case you >>> don't need to fiddle with resolv.conf on all clients. >>> >>> Let me know if you need further assistance. >>> >>> Petr^2 Spacek >>> >>> >>>> 14-Oct-14 12:58, Lukas Slebodnik ?????: >>>>> On (14/10/14 10:23), Orkhan Gasimov wrote: >>>>>> Thanks to both of you for the interest. >>>>>> Here`s the info you asked: >>>>>> >>>>>> 1. Putting "debug_level = 7" either in [domain] or/and [nss] >>>>>> section of the >>>>>> /usr/local/etc/sssd/sssd.conf file gives nothing in the log. The >>>>>> log file >>>>>> located at /var/log/sssd/sssd.log is only populated with data >>>>>> when I make >>>>>> some errors in sssd.conf & sssd process fails to start. But >>>>>> that`s the case >>>>>> only if I deliberately introduce some errors; with current >>>>>> configuration >>>>>> sssd >>>>>> starts successfully. >>>>>> >>>>>> 2. My original sssd.conf (without debugs) is as follows (exact >>>>>> copy of what >>>>>> was shown in the post at FreeBSD forums): >>>>>> >>>>>> ----------------------------------------- >>>>>> [domain/mydomain.com] >>>>>> cache_credentials = True >>>>>> krb5_store_password_if_offline = True >>>>>> ipa_domain = mydomain.com >>>>>> id_provider = ipa >>>>>> auth_provider = ipa >>>>>> access_provider = ipa >>>>>> ipa_hostname = ipa1.mydomain.com >>>>>> chpass_provider = ipa >>>>>> ipa_server = _srv_ #our FreeIPA server has DNS SRV entries >>>>> >>>>> [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of >>>>> '_ldap._tcp.eurosel.az' >>>>> ... >>>>> [resolve_srv_done] (0x0020): SRV query failed: [Domain name not >>>>> found] >>>>> [set_srv_data_status] (0x0100): Marking SRV lookup of service >>>>> 'IPA' as 'not >>>>> resolved' >>>>> [be_resolve_server_process] (0x0080): Couldn't resolve server (SRV >>>>> lookup >>>>> meta-server), resolver returned (5) >>>>> >>>>> DNS discovery of IPA server failed, becuase you just configured >>>>> few hostnames >>>>> in /etc/hosts >>>>> >>>>> You can add IP address or hostname to the option ipa_server >>>>> e.g. >>>>> ipa_server = _srv_, vm-120.eurosel.az >>>>> >>>>> BTW In my opinion, it is better to have comment before the optiona >>>>> and not on >>>>> the same line :-) From abokovoy at redhat.com Tue Oct 14 13:06:02 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 14 Oct 2014 16:06:02 +0300 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <543D1E01.2030401@mail.ru> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CB33D.6020005@mail.ru> <20141014075833.GA3104@mail.corp.redhat.com> <543CF18C.1090503@mail.ru> <543D08FD.8030703@redhat.com> <543D0D8C.5050705@mail.ru> <543D1A81.9080001@redhat.com> <543D1E01.2030401@mail.ru> Message-ID: <20141014130602.GN4143@redhat.com> On Tue, 14 Oct 2014, Orkhan Gasimov wrote: >So which way do I go? >1) Change the server VM`s hostname from "ipa1.eurosel.az" to >"ipa1.ipa.eurosel.az" prior to issuing IPA installation command >2) or leave my hostname and contents of /etc/hosts file intact and >specify a different FQDN and domain part of the IPA server after >issuing IPA installation command? >Yes, I know - this is a question Homer Simpson would ask. Allocate ipa.eurosel.az domain zone to FreeIPA and install FreeIPA with integrated DNS. Essentially, (1), with domain=ipa.eurosel.az, realm IPA.EUROSEL.AZ. If you want later to see how this setup scales, all you would need to do is to make sure the other clients would use ipa1.ipa.eurosel.az as a resolver. > > >14-Oct-14 17:43, Petr Spacek ?????: >>On 14.10.2014 13:48, Orkhan Gasimov wrote: >>>I need further assistance with this moment: >>>"specify IPA domain name which is sub-domain of you existing >>>domain (e.g. >>>ipa.eurosel.az) ". >>> >>>Currently my FreeIPA server's hostname is ipa1.eurosel.az, and client's >>>hostname is bsd1.eurosel.az. >>>So when running this command: >>> >>>"ipa-server-install --setup-dns --forwarder >>*existing* DNS >>>server>", >>> >>>the installation program detects the hostname of the VM >>>(ipa1.eurosel.az) and >>>offers it as IPA server FQDN; >>>then it offers "eurosel.az" as the domain name. I can make changes right >>>during the installation process (FQDN = ipa1.ipa.eurosel.az & domain = >>>ipa.eurosel.az), but then there will be a conflict with the real >>>hostname and >>>records in the /etc/hosts file. >>> >>>On the other hand, if I change the hostname of the server VM to >>>"ipa1.ipa.eurosel.az" prior to running the IPA installation >>>program, then the >>>installation program will offer my server an FQDN of >>>"ipa1.ipa.eurosel.az" and >>>a domain name of "ipa.eurosel.az". But doesn`t it mean that my client`s >>>hostname should also be changed to bsd1.ipa.eurosel.az? I`d like >>>to avoid >>>this, because in production I won`t be able to change the domain >>>part of FQDN >>>for hundreds of clients. >> >>Clients don't need to be in the same domain as IPA. The IPA domain >>in DNS is necessary to store 'metadata' like SRV and TXT records >>etc. >> >>You can even experiment with IPA servers which are not in the IPA >>domain but I'm not sure how much it was tested. >> >>Alexander can add more details about records required for AD >>integration and how it should work with clients which are not in the >>IPA domain. >> >>Petr^2 Spacek >> >>> >>>14-Oct-14 16:29, Petr Spacek ?????: >>>>On 14.10.2014 11:49, Orkhan Gasimov wrote: >>>>>I suspected that problems could arise with DNS, and here they are... >>>>> >>>>>In fact, this entire string: "ipa_server = _srv_ #our FreeIPA >>>>>server has DNS >>>>>SRV entries" was taken as-is from the how-to on FreeBSD >>>>>forums. First I >>>>>commented it out, because was unsure sure if it was >>>>>appropriate for my simple >>>>>setup with just 2 VMs and and a bunch of records in /etc/hosts >>>>>file. After >>>>>starting sssd, I could get no IPA data with"getent passwd" or >>>>>"getent group" >>>>>commands. They I uncommented it and restarted sssd, but things >>>>>remained the >>>>>same. >>>>> >>>>>Now your advice is: "...add IP address or hostname to the >>>>>option ipa_server", >>>>>but you use an arbitrary name like "vm-120.eurosel.az". Could >>>>>you please >>>>>explain which host`s FQDN I should put there? If I use >>>>>"ipa1.eurosel.az", then >>>>>sssd won`t start (complains about "...Looping detected inside >>>>>krb5_get_in_tkt..."). >>>>> >>>>>If it MUST be a DNS server, then everything changes. And the >>>>>question then >>>>>becomes: is it possible to set up a test FreeIPA client-server >>>>>interaction >>>>>using only 2 VMs and proper records in /etc/hosts instead of a >>>>>DNS server? Or >>>>>one MUST add a third VM and make it a DNS server to facilitate >>>>>client-server >>>>>interaction? >>>> >>>>IPA theoretically can work without DNS records but it requires >>>>very careful >>>>configuration on clients and is strongly discouraged. >>>> >>>>If you want to do quick & dirty test, do this: >>>>$ ipa-server-install --setup-dns --forwarder >>>*existing* >>>>DNS server> >>>>+ specify IPA domain name which is sub-domain of you existing >>>>domain (e.g. >>>>ipa.eurosel.az) >>>>+ change /etc/resolv.conf on *all* clients to point to IPA server >>>> >>>>*This is a dirty trick* and it will not work unless all your >>>>clients has the >>>>IPA server in resolv.conf. It will most likely break when you >>>>try to use AD >>>>trust with AD clients etc. >>>> >>>> >>>>*In production environment* you should add NS records for >>>>ipa.eurosel.az >>>>domain to the parent DNS zone to create proper delegation. In >>>>that case you >>>>don't need to fiddle with resolv.conf on all clients. >>>> >>>>Let me know if you need further assistance. >>>> >>>>Petr^2 Spacek >>>> >>>> >>>>>14-Oct-14 12:58, Lukas Slebodnik ?????: >>>>>>On (14/10/14 10:23), Orkhan Gasimov wrote: >>>>>>>Thanks to both of you for the interest. >>>>>>>Here`s the info you asked: >>>>>>> >>>>>>>1. Putting "debug_level = 7" either in [domain] or/and >>>>>>>[nss] section of the >>>>>>>/usr/local/etc/sssd/sssd.conf file gives nothing in the >>>>>>>log. The log file >>>>>>>located at /var/log/sssd/sssd.log is only populated with >>>>>>>data when I make >>>>>>>some errors in sssd.conf & sssd process fails to start. >>>>>>>But that`s the case >>>>>>>only if I deliberately introduce some errors; with current >>>>>>>configuration >>>>>>>sssd >>>>>>>starts successfully. >>>>>>> >>>>>>>2. My original sssd.conf (without debugs) is as follows >>>>>>>(exact copy of what >>>>>>>was shown in the post at FreeBSD forums): >>>>>>> >>>>>>>----------------------------------------- >>>>>>>[domain/mydomain.com] >>>>>>>cache_credentials = True >>>>>>>krb5_store_password_if_offline = True >>>>>>>ipa_domain = mydomain.com >>>>>>>id_provider = ipa >>>>>>>auth_provider = ipa >>>>>>>access_provider = ipa >>>>>>>ipa_hostname = ipa1.mydomain.com >>>>>>>chpass_provider = ipa >>>>>>>ipa_server = _srv_ #our FreeIPA server has DNS SRV entries >>>>>> >>>>>>[resolv_getsrv_send] (0x0100): Trying to resolve SRV record of >>>>>>'_ldap._tcp.eurosel.az' >>>>>>... >>>>>>[resolve_srv_done] (0x0020): SRV query failed: [Domain name >>>>>>not found] >>>>>>[set_srv_data_status] (0x0100): Marking SRV lookup of >>>>>>service 'IPA' as 'not >>>>>>resolved' >>>>>>[be_resolve_server_process] (0x0080): Couldn't resolve >>>>>>server (SRV lookup >>>>>>meta-server), resolver returned (5) >>>>>> >>>>>>DNS discovery of IPA server failed, becuase you just >>>>>>configured few hostnames >>>>>>in /etc/hosts >>>>>> >>>>>>You can add IP address or hostname to the option ipa_server >>>>>>e.g. >>>>>> ipa_server = _srv_, vm-120.eurosel.az >>>>>> >>>>>>BTW In my opinion, it is better to have comment before the >>>>>>optiona and not on >>>>>>the same line :-) > >-- >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 -- / Alexander Bokovoy From rcritten at redhat.com Tue Oct 14 13:42:36 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 14 Oct 2014 09:42:36 -0400 Subject: [Freeipa-users] Replace Self-Signed Cert In-Reply-To: References: <543C2540.60507@redhat.com> <543C52B0.9030400@redhat.com> <543C59E5.2000202@redhat.com> Message-ID: <543D284C.3010608@redhat.com> quest monger wrote: > makes sense. > i will still try out that cert add command in my test environment, just > to see if it works. > looks like for now, 4.1 upgrade is my best option. IPA 3.x includes a command, ipa-server-certinstall, which will do what you need. This can be a bumpy process with clients and such which is why Dmitri suggested using 4.1, but it should still basically work. It depends greatly on whether the CA issuing the certs is already known by clients (for example being a default CA shipped by NSS and openssl). But I'd step cautiously and ask a lot of questions before you proceed. The IPA certificates are not self-signed. They are issued by a CA controlled by IPA. I think your admin's concerns are related to users getting an unknown CA/cert error. It can be confusing and can train users to accept any SSL certificate they see which is bad. There are some downsides to not using the IPA CA: - no automatic renewal of certificates. This means you need to manually monitor your infrastructure and renew the certificates before they expire. Otherwise your identity infrastructure could go down. - for every replica you set up you will need to get a web and ldap certificate in advance rob > > > On Mon, Oct 13, 2014 at 7:01 PM, Dmitri Pal > wrote: > > On 10/13/2014 06:45 PM, quest monger wrote: >> I did the default IPA install, didnt change any certs or anything. >> As part of that install, it now shows 2 certs, one on port 443 >> (HTTPS) and one on port 636 (LDAPS). These certs dont have a trust >> chain, hence i called them self-signed. >> We have a contract with a third party CA that issues TLS certs for >> us. I was asked to find a way to replace those 2 self signed certs >> with certs from this third party CA. >> I was wondering if there was a way i could do that. >> >> I found this >> - http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP >> >> I am currently running 3.0.0. >> >> > > AFAIU the biggest issue will be with the clients. > I suspect that they might be quite confused if you just drop in the > certs from the 3rd party. > If you noticed the page has the following line: > "The certificate in mysite.crt must be signed by the CA used when > installing FreeIPA." I think it should say by "external" CA to be clear. > It is not the case in your situation. If it were the situation the > CA would have been already in trust chain on the clients and > procedure would have worked but I do not think it would work now. > You would need to use the cert chaining tool that was was built in > 4.1 when 4.1 gets released on CentOS. > > > > >> >> On Mon, Oct 13, 2014 at 6:31 PM, Dmitri Pal > > wrote: >> >> On 10/13/2014 03:39 PM, quest monger wrote: >>> I found some documentation for getting certificate signed by >>> external CA (2.3.3.2. Using Different CA Configurations) - >>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/creating-server.html >>> >>> >>> But looks like those instructions apply to a first time fresh >>> install, not for upgrading an existing install. >>> >>> >>> >>> On Mon, Oct 13, 2014 at 3:24 PM, quest monger >>> > wrote: >>> >>> I was told by my admin team that Self-signed certs pose a >>> security risk. >>> >>> >>> On Mon, Oct 13, 2014 at 3:17 PM, Rob Crittenden >>> > wrote: >>> >>> quest monger wrote: >>> > Hello All, >>> > >>> > I installed FreeIPA server on a CentOS host. I have >>> 20+ Linux and >>> > Solaris clients hooked up to it. SSH and Sudo works >>> on all clients. >>> > >>> > I would like to replace the self-signed cert that >>> is used on Port 389 >>> > and 636. >>> > >>> > Is there a way to do this without re-installing the >>> server and clients. >>> >>> Why do you want to do this? >>> >>> rob >>> >>> >>> >>> >>> >> >> Do I get it right that you installed IPA using self-signed >> certificate and now want to change it? >> What version of IPA you have? Did you use self-signed CA-less >> install or using self-signed CA? >> The tools to change the chaining are only being released in >> 4.1 so you might have to move to latest when we release 4.1 >> for CentOS. >> >> >> -- >> 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. > > > > From rcritten at redhat.com Tue Oct 14 13:48:04 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 14 Oct 2014 09:48:04 -0400 Subject: [Freeipa-users] sysctl and/or limits.conf? In-Reply-To: <543C6E1C.4010901@gmail.com> References: <543B14ED.5090205@gmail.com> <543C4FAE.9030801@redhat.com> <543C6E1C.4010901@gmail.com> Message-ID: <543D2994.7070103@redhat.com> Janelle wrote: > Hi again, > > A lot of this information has been very useful. I did have a question I > could not answer. I noticed in the Deployment Recommendations docs, it > says not to have any more than 4 replication agreements. Perhaps I am > missing something, but I don't see how to get a replica to be a master > to be able to create another replicate? Am I missing something obvious > here? Every IPA install is a master. The only distinction between servers are the optional services of DNS and a CA. So don't get confused by replica vs master. Once an IPA server is up it is a master. We don't recommend any one master to have more than 4 agreements. Each agreement adds a bit more load on the server to calculate the differences to send to each one, so you want to keep it reasonable. I'd recommend making a map of your topology to ensure that no master ends up alone, or one ends up being overloaded. You can use ipa-replica-manage to control the replication topology. By default a single agreement is set up between a new master and the one that created it. Any master can create a new master. As you do your installations be sure to have at least 2 masters with a CA on it to avoid a single point of failure. rob > > Thank you, > ~Janelle > > On 10/13/14 3:18 PM, Dmitri Pal wrote: >> On 10/12/2014 08:07 PM, James wrote: >>> On 12 October 2014 19:55, Janelle wrote: >>>> Hi again, >>>> >>>> I was wondering if there were any suggestions for performance of IPA >>>> and >>>> settings to sysctl and maybe limits.conf? I tried the website, but >>>> did not >>>> see anything. Have about 3000 servers that will be talking to 3-4 >>>> masters/replicas. Are there any formulas to follow? >>>> >>>> thanks >>> >>> If you get an answer to this, or if you know of any other performance >>> tuning params, let me know and I'll build it in to puppet-ipa. >>> >>> Thanks, >>> James >>> >> I do not think it is easy automatable. >> Please see http://www.freeipa.org/page/Deployment_Recommendations and >> part about replicas. >> If 3000 in one datacenter then 3 is good enough or 4 if you are very >> LDAP heavy (some applications are like Jira for example). >> If you have 2 data center I would go for 2+2. >> > From janellenicole80 at gmail.com Tue Oct 14 13:50:48 2014 From: janellenicole80 at gmail.com (Janelle) Date: Tue, 14 Oct 2014 06:50:48 -0700 Subject: [Freeipa-users] sysctl and/or limits.conf? In-Reply-To: <543D2994.7070103@redhat.com> References: <543B14ED.5090205@gmail.com> <543C4FAE.9030801@redhat.com> <543C6E1C.4010901@gmail.com> <543D2994.7070103@redhat.com> Message-ID: <543D2A38.4040605@gmail.com> Hi Rob, Thanks for that - it clears up one point - and explains why the replica manage command shows all masters, but what I don't understand is how to get the CA to a "replica" once it is created? I don't see anything in the docs on that. Am I missing something very obvious here? I am coming from the AD world and trying to replace it, so please excuse my ignorance in this area. thanks Janelle On 10/14/14 6:48 AM, Rob Crittenden wrote: > Janelle wrote: >> Hi again, >> >> A lot of this information has been very useful. I did have a question I >> could not answer. I noticed in the Deployment Recommendations docs, it >> says not to have any more than 4 replication agreements. Perhaps I am >> missing something, but I don't see how to get a replica to be a master >> to be able to create another replicate? Am I missing something obvious >> here? > Every IPA install is a master. The only distinction between servers are > the optional services of DNS and a CA. So don't get confused by replica > vs master. Once an IPA server is up it is a master. > > We don't recommend any one master to have more than 4 agreements. Each > agreement adds a bit more load on the server to calculate the > differences to send to each one, so you want to keep it reasonable. I'd > recommend making a map of your topology to ensure that no master ends up > alone, or one ends up being overloaded. You can use ipa-replica-manage > to control the replication topology. By default a single agreement is > set up between a new master and the one that created it. > > Any master can create a new master. > > As you do your installations be sure to have at least 2 masters with a > CA on it to avoid a single point of failure. > > rob > >> Thank you, >> ~Janelle >> >> On 10/13/14 3:18 PM, Dmitri Pal wrote: >>> On 10/12/2014 08:07 PM, James wrote: >>>> On 12 October 2014 19:55, Janelle wrote: >>>>> Hi again, >>>>> >>>>> I was wondering if there were any suggestions for performance of IPA >>>>> and >>>>> settings to sysctl and maybe limits.conf? I tried the website, but >>>>> did not >>>>> see anything. Have about 3000 servers that will be talking to 3-4 >>>>> masters/replicas. Are there any formulas to follow? >>>>> >>>>> thanks >>>> If you get an answer to this, or if you know of any other performance >>>> tuning params, let me know and I'll build it in to puppet-ipa. >>>> >>>> Thanks, >>>> James >>>> >>> I do not think it is easy automatable. >>> Please see http://www.freeipa.org/page/Deployment_Recommendations and >>> part about replicas. >>> If 3000 in one datacenter then 3 is good enough or 4 if you are very >>> LDAP heavy (some applications are like Jira for example). >>> If you have 2 data center I would go for 2+2. >>> From rcritten at redhat.com Tue Oct 14 13:58:49 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 14 Oct 2014 09:58:49 -0400 Subject: [Freeipa-users] sysctl and/or limits.conf? In-Reply-To: <543D2A38.4040605@gmail.com> References: <543B14ED.5090205@gmail.com> <543C4FAE.9030801@redhat.com> <543C6E1C.4010901@gmail.com> <543D2994.7070103@redhat.com> <543D2A38.4040605@gmail.com> Message-ID: <543D2C19.9060105@redhat.com> Janelle wrote: > Hi Rob, > > Thanks for that - it clears up one point - and explains why the replica > manage command shows all masters, but what I don't understand is how to > get the CA to a "replica" once it is created? I don't see anything in > the docs on that. Am I missing something very obvious here? I am coming > from the AD world and trying to replace it, so please excuse my > ignorance in this area. ipa-ca-install rob > > thanks > Janelle > > > On 10/14/14 6:48 AM, Rob Crittenden wrote: >> Janelle wrote: >>> Hi again, >>> >>> A lot of this information has been very useful. I did have a question I >>> could not answer. I noticed in the Deployment Recommendations docs, it >>> says not to have any more than 4 replication agreements. Perhaps I am >>> missing something, but I don't see how to get a replica to be a master >>> to be able to create another replicate? Am I missing something obvious >>> here? >> Every IPA install is a master. The only distinction between servers are >> the optional services of DNS and a CA. So don't get confused by replica >> vs master. Once an IPA server is up it is a master. >> >> We don't recommend any one master to have more than 4 agreements. Each >> agreement adds a bit more load on the server to calculate the >> differences to send to each one, so you want to keep it reasonable. I'd >> recommend making a map of your topology to ensure that no master ends up >> alone, or one ends up being overloaded. You can use ipa-replica-manage >> to control the replication topology. By default a single agreement is >> set up between a new master and the one that created it. >> >> Any master can create a new master. >> >> As you do your installations be sure to have at least 2 masters with a >> CA on it to avoid a single point of failure. >> >> rob >> >>> Thank you, >>> ~Janelle >>> >>> On 10/13/14 3:18 PM, Dmitri Pal wrote: >>>> On 10/12/2014 08:07 PM, James wrote: >>>>> On 12 October 2014 19:55, Janelle wrote: >>>>>> Hi again, >>>>>> >>>>>> I was wondering if there were any suggestions for performance of IPA >>>>>> and >>>>>> settings to sysctl and maybe limits.conf? I tried the website, but >>>>>> did not >>>>>> see anything. Have about 3000 servers that will be talking to 3-4 >>>>>> masters/replicas. Are there any formulas to follow? >>>>>> >>>>>> thanks >>>>> If you get an answer to this, or if you know of any other performance >>>>> tuning params, let me know and I'll build it in to puppet-ipa. >>>>> >>>>> Thanks, >>>>> James >>>>> >>>> I do not think it is easy automatable. >>>> Please see http://www.freeipa.org/page/Deployment_Recommendations and >>>> part about replicas. >>>> If 3000 in one datacenter then 3 is good enough or 4 if you are very >>>> LDAP heavy (some applications are like Jira for example). >>>> If you have 2 data center I would go for 2+2. >>>> > From lslebodn at redhat.com Tue Oct 14 14:47:20 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 14 Oct 2014 16:47:20 +0200 Subject: [Freeipa-users] strange error from EL 7 install? In-Reply-To: <20141014060324.GK5346@dhcp-40-8.bne.redhat.com> References: <543BFB62.6070705@gmail.com> <543C0358.3080905@gmail.com> <20141014044851.GJ5346@dhcp-40-8.bne.redhat.com> <543CAFE7.1070104@gmail.com> <20141014060324.GK5346@dhcp-40-8.bne.redhat.com> Message-ID: <20141014144720.GH3104@mail.corp.redhat.com> On (14/10/14 16:03), Fraser Tweedale wrote: >On Mon, Oct 13, 2014 at 10:08:55PM -0700, Janelle wrote: >> Actually, I did find a fix and forgot to post. >> >> I was able to mirror the COPR repo, and after reviewing it, found that >> simply removing the pki-base...fc21 directory, and regenning the repo data >> with createrepo, fixed the problem. It drops the version of PKI back to the >> 10.1 branch and that resolved the dependencies. >> >> Hope this helps, >> Janelle >> > >Glad you were able to find a fix. Of course, we will still need to >fix the 10.2 build, so thanks for reporting! If dogtag team adds new dependency you will not be able to fix 10.2 build. I am able to install pki-base-10.2 on fedora 21 without any problem. So ther isn't problem in pki-base. The problem is with backporting pki-base to el7. The package jackson-jaxrs-json-provider should be backported to el7 as well. (or someone should package jackson-jaxrs-json-provider in epel7) If we don't want to have the latest packages from fedora in COPR repo then the other option is to have minimal required version of packages in COPR repo. It would reduce count of backported packages. LS From herlo1 at gmail.com Tue Oct 14 16:58:36 2014 From: herlo1 at gmail.com (Clint Savage) Date: Tue, 14 Oct 2014 10:58:36 -0600 Subject: [Freeipa-users] Migration fails with custom objectClasses Message-ID: Hi all, I've been working on a migration plan using three custom user objectClasses and one group objectclass. In my attempt, I've setup an openldap server with the proper schemas, imported the ldif and have records that look something like this in ldif format. ----------------------------------------------------------------------- dn: dc=example,dc=com objectClass: top objectClass: domain dc: example dn: ou=Groups,dc=example,dc=com objectClass: top objectClass: organizationalunit ou: Groups dn: ou=People,dc=example,dc=com objectClass: top objectClass: organizationalunit ou: People dn: uid=amyengh,ou=People,dc=example,dc=com objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: organizationalPerson objectClass: person objectClass: radiusProfile objectClass: sambaSamAccount objectClass: customPersonAttributes cn: Amy Engh gidNumber: 1141801056 homeDirectory: /home/amyengh sn: Engh uid: amyengh uidNumber: 1141801056 displayName: Amy Engh givenName: Amy loginShell: /sbin/nologin mail: amyengh at attask.com userPassword:: REDACTED dialupAccess: yes radiusTunnelMediumType: IEEE-802 radiusTunnelPrivateGroupId: 1421 radiusTunnelType: VLAN emailPassword:: REDACTED sambaAcctFlags: [U ] sambaLMPassword: REDACTED sambaNTPassword: REDACTED sambaPasswordHistory: 000000000000000000000000000000000000000000000000000000 0000000000 sambaPwdLastSet: 1402698001 sambaSID: S-1-5-21-2332447373-4108748234-3602490535-3146 dn: cn=amyengh,ou=Groups,dc=example,dc=com objectClass: top objectClass: posixGroup cn: amyengh gidNumber: 1141801056 memberUid: amyengh -------------------------------------------------------------------- I then run the migration (with or without compat makes no difference) and get the following: ipa migrate-ds --with-compat --user-container="ou=People" --group-container="ou=Groups" --user-objectclass=posixAccount --group-objectclass=posixgroup ldap://192.168.122.210 --bind-dn="cn=Manager,dc=example,dc=com" Password: ----------- migrate-ds: ----------- Migrated: Failed user: amyengh: Type or value exists: Failed group: amyengh: This entry already exists. Check GID of the existing group. Use --group-overwrite-gid option to overwrite the GID ---------- Passwords have been migrated in pre-hashed format. IPA is unable to generate Kerberos keys unless provided with clear text passwords. All migrated users need to login at https://your.domain/ipa/migration/ before they can use their Kerberos accounts. The objectclasses are listed in the configuration properly: # ipa config-show --all ..snip.. Default group objectclasses: top, groupofnames, nestedgroup, ipausergroup, ipaobject, sambaGroupMapping Default user objectclasses: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser, radiusProfile, customPersonAttributes, sambaSamAccount ..snip.. I can verify the objectclasses appear to work when I add a user manually, though I have not updated the plugins to allow entries for the above objectClasses. --------------------------- My question exists around the error ' amyengh: Type or value exists:'. I can take out the custom objectclasses, and this error goes away. I've looked into all of the custom objectclasses and don't see anything that would indicate errors. I have some 5k+ records to migrate and don't want to have to manipulate the ldif and then create modify records just to get the data into IPA. Any suggestions to help me identify why this is happening? I'd be happy to provide further information as requested. Thanks, herlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Oct 14 18:42:47 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 Oct 2014 20:42:47 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141014130602.GN4143@redhat.com> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CB33D.6020005@mail.ru> <20141014075833.GA3104@mail.corp.redhat.com> <543CF18C.1090503@mail.ru> <543D08FD.8030703@redhat.com> <543D0D8C.5050705@mail.ru> <543D1A81.9080001@redhat.com> <543D1E01.2030401@mail.ru> <20141014130602.GN4143@redhat.com> Message-ID: <543D6EA7.7020806@redhat.com> On 14.10.2014 15:06, Alexander Bokovoy wrote: > On Tue, 14 Oct 2014, Orkhan Gasimov wrote: >> So which way do I go? >> 1) Change the server VM`s hostname from "ipa1.eurosel.az" to >> "ipa1.ipa.eurosel.az" prior to issuing IPA installation command >> 2) or leave my hostname and contents of /etc/hosts file intact and specify a >> different FQDN and domain part of the IPA server after issuing IPA >> installation command? >> Yes, I know - this is a question Homer Simpson would ask. > Allocate ipa.eurosel.az domain zone to FreeIPA and install FreeIPA with > integrated DNS. Essentially, (1), with domain=ipa.eurosel.az, realm > IPA.EUROSEL.AZ. > > If you want later to see how this setup scales, all you would need to do > is to make sure the other clients would use ipa1.ipa.eurosel.az as a > resolver. Again - in production it is unnecessary to change resolv.conf if you have proper NS records in place. Petr^2 Spacek >> 14-Oct-14 17:43, Petr Spacek ?????: >>> On 14.10.2014 13:48, Orkhan Gasimov wrote: >>>> I need further assistance with this moment: >>>> "specify IPA domain name which is sub-domain of you existing domain (e.g. >>>> ipa.eurosel.az) ". >>>> >>>> Currently my FreeIPA server's hostname is ipa1.eurosel.az, and client's >>>> hostname is bsd1.eurosel.az. >>>> So when running this command: >>>> >>>> "ipa-server-install --setup-dns --forwarder >>> DNS >>>> server>", >>>> >>>> the installation program detects the hostname of the VM (ipa1.eurosel.az) and >>>> offers it as IPA server FQDN; >>>> then it offers "eurosel.az" as the domain name. I can make changes right >>>> during the installation process (FQDN = ipa1.ipa.eurosel.az & domain = >>>> ipa.eurosel.az), but then there will be a conflict with the real hostname and >>>> records in the /etc/hosts file. >>>> >>>> On the other hand, if I change the hostname of the server VM to >>>> "ipa1.ipa.eurosel.az" prior to running the IPA installation program, then the >>>> installation program will offer my server an FQDN of "ipa1.ipa.eurosel.az" >>>> and >>>> a domain name of "ipa.eurosel.az". But doesn`t it mean that my client`s >>>> hostname should also be changed to bsd1.ipa.eurosel.az? I`d like to avoid >>>> this, because in production I won`t be able to change the domain part of FQDN >>>> for hundreds of clients. >>> >>> Clients don't need to be in the same domain as IPA. The IPA domain in DNS >>> is necessary to store 'metadata' like SRV and TXT records etc. >>> >>> You can even experiment with IPA servers which are not in the IPA domain >>> but I'm not sure how much it was tested. >>> >>> Alexander can add more details about records required for AD integration >>> and how it should work with clients which are not in the IPA domain. >>> >>> Petr^2 Spacek >>> >>>> >>>> 14-Oct-14 16:29, Petr Spacek ?????: >>>>> On 14.10.2014 11:49, Orkhan Gasimov wrote: >>>>>> I suspected that problems could arise with DNS, and here they are... >>>>>> >>>>>> In fact, this entire string: "ipa_server = _srv_ #our FreeIPA server has >>>>>> DNS >>>>>> SRV entries" was taken as-is from the how-to on FreeBSD forums. First I >>>>>> commented it out, because was unsure sure if it was appropriate for my >>>>>> simple >>>>>> setup with just 2 VMs and and a bunch of records in /etc/hosts file. After >>>>>> starting sssd, I could get no IPA data with"getent passwd" or "getent >>>>>> group" >>>>>> commands. They I uncommented it and restarted sssd, but things remained the >>>>>> same. >>>>>> >>>>>> Now your advice is: "...add IP address or hostname to the option >>>>>> ipa_server", >>>>>> but you use an arbitrary name like "vm-120.eurosel.az". Could you please >>>>>> explain which host`s FQDN I should put there? If I use >>>>>> "ipa1.eurosel.az", then >>>>>> sssd won`t start (complains about "...Looping detected inside >>>>>> krb5_get_in_tkt..."). >>>>>> >>>>>> If it MUST be a DNS server, then everything changes. And the question then >>>>>> becomes: is it possible to set up a test FreeIPA client-server interaction >>>>>> using only 2 VMs and proper records in /etc/hosts instead of a DNS >>>>>> server? Or >>>>>> one MUST add a third VM and make it a DNS server to facilitate >>>>>> client-server >>>>>> interaction? >>>>> >>>>> IPA theoretically can work without DNS records but it requires very careful >>>>> configuration on clients and is strongly discouraged. >>>>> >>>>> If you want to do quick & dirty test, do this: >>>>> $ ipa-server-install --setup-dns --forwarder >>>> DNS server> >>>>> + specify IPA domain name which is sub-domain of you existing domain (e.g. >>>>> ipa.eurosel.az) >>>>> + change /etc/resolv.conf on *all* clients to point to IPA server >>>>> >>>>> *This is a dirty trick* and it will not work unless all your clients has the >>>>> IPA server in resolv.conf. It will most likely break when you try to use AD >>>>> trust with AD clients etc. >>>>> >>>>> >>>>> *In production environment* you should add NS records for ipa.eurosel.az >>>>> domain to the parent DNS zone to create proper delegation. In that case you >>>>> don't need to fiddle with resolv.conf on all clients. >>>>> >>>>> Let me know if you need further assistance. >>>>> >>>>> Petr^2 Spacek >>>>> >>>>> >>>>>> 14-Oct-14 12:58, Lukas Slebodnik ?????: >>>>>>> On (14/10/14 10:23), Orkhan Gasimov wrote: >>>>>>>> Thanks to both of you for the interest. >>>>>>>> Here`s the info you asked: >>>>>>>> >>>>>>>> 1. Putting "debug_level = 7" either in [domain] or/and [nss] section >>>>>>>> of the >>>>>>>> /usr/local/etc/sssd/sssd.conf file gives nothing in the log. The log file >>>>>>>> located at /var/log/sssd/sssd.log is only populated with data when I make >>>>>>>> some errors in sssd.conf & sssd process fails to start. But that`s the >>>>>>>> case >>>>>>>> only if I deliberately introduce some errors; with current configuration >>>>>>>> sssd >>>>>>>> starts successfully. >>>>>>>> >>>>>>>> 2. My original sssd.conf (without debugs) is as follows (exact copy of >>>>>>>> what >>>>>>>> was shown in the post at FreeBSD forums): >>>>>>>> >>>>>>>> ----------------------------------------- >>>>>>>> [domain/mydomain.com] >>>>>>>> cache_credentials = True >>>>>>>> krb5_store_password_if_offline = True >>>>>>>> ipa_domain = mydomain.com >>>>>>>> id_provider = ipa >>>>>>>> auth_provider = ipa >>>>>>>> access_provider = ipa >>>>>>>> ipa_hostname = ipa1.mydomain.com >>>>>>>> chpass_provider = ipa >>>>>>>> ipa_server = _srv_ #our FreeIPA server has DNS SRV entries >>>>>>> >>>>>>> [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of >>>>>>> '_ldap._tcp.eurosel.az' >>>>>>> ... >>>>>>> [resolve_srv_done] (0x0020): SRV query failed: [Domain name not found] >>>>>>> [set_srv_data_status] (0x0100): Marking SRV lookup of service 'IPA' as >>>>>>> 'not >>>>>>> resolved' >>>>>>> [be_resolve_server_process] (0x0080): Couldn't resolve server (SRV lookup >>>>>>> meta-server), resolver returned (5) >>>>>>> >>>>>>> DNS discovery of IPA server failed, becuase you just configured few >>>>>>> hostnames >>>>>>> in /etc/hosts >>>>>>> >>>>>>> You can add IP address or hostname to the option ipa_server >>>>>>> e.g. >>>>>>> ipa_server = _srv_, vm-120.eurosel.az >>>>>>> >>>>>>> BTW In my opinion, it is better to have comment before the optiona and >>>>>>> not on >>>>>>> the same line :-) From orkhan-azeri at mail.ru Tue Oct 14 19:40:01 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Wed, 15 Oct 2014 00:40:01 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <543D6EA7.7020806@redhat.com> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CB33D.6020005@mail.ru> <20141014075833.GA3104@mail.corp.redhat.com> <543CF18C.1090503@mail.ru> <543D08FD.8030703@redhat.com> <543D0D8C.5050705@mail.ru> <543D1A81.9080001@redhat.com> <543D1E01.2030401@mail.ru> <20141014130602.GN4143@redhat.com> <543D6EA7.7020806@redhat.com> Message-ID: <6b8e6fc5-5288-4e88-a736-d09f19a41b61@email.bluemailapp.com> Ok, friends, you helped me to understand one thing. My test scenario with 2 VMs and no DNS server introduces problems with DNS resolution, which seems to be almost necessary. So now I have 2 tasks: 1) properly configure IPA server to work with DNS; 2) make a FreeBSD host (which is a "non-native" client for FreeIPA) join an IPA domain. As problems of the first task can be errantly considered to be problems of the second task, I'll change my approach. First I'll try to set up a Fedora FreeIPA server with DNS and add a "native" Fedora FreeIPA client to it. (I guess a Fedora client: 1) should be easier to set up; 2) is guaranteed to work if configured properly.) Then I'll try to add a FreeBSD client to my working setup and see if the post at FreeBSD forums leads to a working solution. I'll share the results with you, however it may take some time before I set up a working Fedora IPA server - Fedora IPA client setup. If you have any links to proved-to-work tutorials (either in text or video format), please share. ?????????? ?? Blue Mail ?? 23:47, 14.10.2014, ? 23:47, Petr Spacek ???????:?>On 14.10.2014 15:06, Alexander Bokovoy wrote: >> On Tue, 14 Oct 2014, Orkhan Gasimov wrote: >>> So which way do I go? >>> 1) Change the server VM`s hostname from "ipa1.eurosel.az" to >>> "ipa1.ipa.eurosel.az" prior to issuing IPA installation command >>> 2) or leave my hostname and contents of /etc/hosts file intact and >specify a >>> different FQDN and domain part of the IPA server after issuing IPA >>> installation command? >>> Yes, I know - this is a question Homer Simpson would ask. >> Allocate ipa.eurosel.az domain zone to FreeIPA and install FreeIPA >with >> integrated DNS. Essentially, (1), with domain=ipa.eurosel.az, realm >> IPA.EUROSEL.AZ. >> >> If you want later to see how this setup scales, all you would need to >do >> is to make sure the other clients would use ipa1.ipa.eurosel.az as a >> resolver. > >Again - in production it is unnecessary to change resolv.conf if you >have >proper NS records in place. > >Petr^2 Spacek > >>> 14-Oct-14 17:43, Petr Spacek ?????: >>>> On 14.10.2014 13:48, Orkhan Gasimov wrote: >>>>> I need further assistance with this moment: >>>>> "specify IPA domain name which is sub-domain of you existing >domain (e.g. >>>>> ipa.eurosel.az) ". >>>>> >>>>> Currently my FreeIPA server's hostname is ipa1.eurosel.az, and >client's >>>>> hostname is bsd1.eurosel.az. >>>>> So when running this command: >>>>> >>>>> "ipa-server-install --setup-dns --forwarder *existing* >>>>> DNS >>>>> server>", >>>>> >>>>> the installation program detects the hostname of the VM >(ipa1.eurosel.az) and >>>>> offers it as IPA server FQDN; >>>>> then it offers "eurosel.az" as the domain name. I can make changes >right >>>>> during the installation process (FQDN = ipa1.ipa.eurosel.az & >domain = >>>>> ipa.eurosel.az), but then there will be a conflict with the real >hostname and >>>>> records in the /etc/hosts file. >>>>> >>>>> On the other hand, if I change the hostname of the server VM to >>>>> "ipa1.ipa.eurosel.az" prior to running the IPA installation >program, then the >>>>> installation program will offer my server an FQDN of >"ipa1.ipa.eurosel.az" >>>>> and >>>>> a domain name of "ipa.eurosel.az". But doesn`t it mean that my >client`s >>>>> hostname should also be changed to bsd1.ipa.eurosel.az? I`d like >to avoid >>>>> this, because in production I won`t be able to change the domain >part of FQDN >>>>> for hundreds of clients. >>>> >>>> Clients don't need to be in the same domain as IPA. The IPA domain >in DNS >>>> is necessary to store 'metadata' like SRV and TXT records etc. >>>> >>>> You can even experiment with IPA servers which are not in the IPA >domain >>>> but I'm not sure how much it was tested. >>>> >>>> Alexander can add more details about records required for AD >integration >>>> and how it should work with clients which are not in the IPA >domain. >>>> >>>> Petr^2 Spacek >>>> >>>>> >>>>> 14-Oct-14 16:29, Petr Spacek ?????: >>>>>> On 14.10.2014 11:49, Orkhan Gasimov wrote: >>>>>>> I suspected that problems could arise with DNS, and here they >are... >>>>>>> >>>>>>> In fact, this entire string: "ipa_server = _srv_ #our FreeIPA >server has >>>>>>> DNS >>>>>>> SRV entries" was taken as-is from the how-to on FreeBSD forums. >First I >>>>>>> commented it out, because was unsure sure if it was appropriate >for my >>>>>>> simple >>>>>>> setup with just 2 VMs and and a bunch of records in /etc/hosts >file. After >>>>>>> starting sssd, I could get no IPA data with"getent passwd" or >"getent >>>>>>> group" >>>>>>> commands. They I uncommented it and restarted sssd, but things >remained the >>>>>>> same. >>>>>>> >>>>>>> Now your advice is: "...add IP address or hostname to the >option >>>>>>> ipa_server", >>>>>>> but you use an arbitrary name like "vm-120.eurosel.az". Could >you please >>>>>>> explain which host`s FQDN I should put there? If I use >>>>>>> "ipa1.eurosel.az", then >>>>>>> sssd won`t start (complains about "...Looping detected inside >>>>>>> krb5_get_in_tkt..."). >>>>>>> >>>>>>> If it MUST be a DNS server, then everything changes. And the >question then >>>>>>> becomes: is it possible to set up a test FreeIPA client-server >interaction >>>>>>> using only 2 VMs and proper records in /etc/hosts instead of a >DNS >>>>>>> server? Or >>>>>>> one MUST add a third VM and make it a DNS server to facilitate >>>>>>> client-server >>>>>>> interaction? >>>>>> >>>>>> IPA theoretically can work without DNS records but it requires >very careful >>>>>> configuration on clients and is strongly discouraged. >>>>>> >>>>>> If you want to do quick & dirty test, do this: >>>>>> $ ipa-server-install --setup-dns --forwarder *existing* >>>>>> DNS server> >>>>>> + specify IPA domain name which is sub-domain of you existing >domain (e.g. >>>>>> ipa.eurosel.az) >>>>>> + change /etc/resolv.conf on *all* clients to point to IPA server >>>>>> >>>>>> *This is a dirty trick* and it will not work unless all your >clients has the >>>>>> IPA server in resolv.conf. It will most likely break when you try >to use AD >>>>>> trust with AD clients etc. >>>>>> >>>>>> >>>>>> *In production environment* you should add NS records for >ipa.eurosel.az >>>>>> domain to the parent DNS zone to create proper delegation. In >that case you >>>>>> don't need to fiddle with resolv.conf on all clients. >>>>>> >>>>>> Let me know if you need further assistance. >>>>>> >>>>>> Petr^2 Spacek >>>>>> >>>>>> >>>>>>> 14-Oct-14 12:58, Lukas Slebodnik ?????: >>>>>>>> On (14/10/14 10:23), Orkhan Gasimov wrote: >>>>>>>>> Thanks to both of you for the interest. >>>>>>>>> Here`s the info you asked: >>>>>>>>> >>>>>>>>> 1. Putting "debug_level = 7" either in [domain] or/and [nss] >section >>>>>>>>> of the >>>>>>>>> /usr/local/etc/sssd/sssd.conf file gives nothing in the log. >The log file >>>>>>>>> located at /var/log/sssd/sssd.log is only populated with data >when I make >>>>>>>>> some errors in sssd.conf & sssd process fails to start. But >that`s the >>>>>>>>> case >>>>>>>>> only if I deliberately introduce some errors; with current >configuration >>>>>>>>> sssd >>>>>>>>> starts successfully. >>>>>>>>> >>>>>>>>> 2. My original sssd.conf (without debugs) is as follows (exact >copy of >>>>>>>>> what >>>>>>>>> was shown in the post at FreeBSD forums): >>>>>>>>> >>>>>>>>> ----------------------------------------- >>>>>>>>> [domain/mydomain.com] >>>>>>>>> cache_credentials = True >>>>>>>>> krb5_store_password_if_offline = True >>>>>>>>> ipa_domain = mydomain.com >>>>>>>>> id_provider = ipa >>>>>>>>> auth_provider = ipa >>>>>>>>> access_provider = ipa >>>>>>>>> ipa_hostname = ipa1.mydomain.com >>>>>>>>> chpass_provider = ipa >>>>>>>>> ipa_server = _srv_ #our FreeIPA server has DNS SRV entries >>>>>>>> >>>>>>>> [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of >>>>>>>> '_ldap._tcp.eurosel.az' >>>>>>>> ... >>>>>>>> [resolve_srv_done] (0x0020): SRV query failed: [Domain name not >found] >>>>>>>> [set_srv_data_status] (0x0100): Marking SRV lookup of service >'IPA' as >>>>>>>> 'not >>>>>>>> resolved' >>>>>>>> [be_resolve_server_process] (0x0080): Couldn't resolve server >(SRV lookup >>>>>>>> meta-server), resolver returned (5) >>>>>>>> >>>>>>>> DNS discovery of IPA server failed, becuase you just configured >few >>>>>>>> hostnames >>>>>>>> in /etc/hosts >>>>>>>> >>>>>>>> You can add IP address or hostname to the option ipa_server >>>>>>>> e.g. >>>>>>>> ipa_server = _srv_, vm-120.eurosel.az >>>>>>>> >>>>>>>> BTW In my opinion, it is better to have comment before the >optiona and >>>>>>>> not on >>>>>>>> the same line :-) > >-- >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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Wed Oct 15 01:14:42 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 15 Oct 2014 11:14:42 +1000 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141014131305.GE3104@mail.corp.redhat.com> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CD1F1.603@mail.ru> <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> <20141014131305.GE3104@mail.corp.redhat.com> Message-ID: <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> On Tue, Oct 14, 2014 at 03:13:06PM +0200, Lukas Slebodnik wrote: > On (14/10/14 17:48), Fraser Tweedale wrote: > >On Tue, Oct 14, 2014 at 12:34:09PM +0500, Orkhan Gasimov wrote: > >> With help from Alexander Bokovoy I found correct log destinations: > >> > >> sssd-domain-log: > >> https://cloud.mail.ru/public/1e803a00989e%2Fsssd_eurosel.az.log > >> sssd-nss-log: https://cloud.mail.ru/public/ae41ae3b44b6%2Fsssd_nss.log > >> > >> These files are from my second Fedora - FreeBSD setup, they have different > >> domain name, but everything else is identical. > >> > >> Interestingly enough, there are lines in sssd_nss.log telling that there are > >> no users or groups in the domain. But as I said, I can ssh to the IPA server > >> as an IPA user. > >> > >Hi Orkhan, > > > >Thanks for the logs. What were their actual locations? > > > >I'm going to try and reproduce your setup and see whether I get the > >same outcome. I have been building and installing the ports as > >indicated in the forum post, and one thing I have noticed is that > >there are a lot of configuration options on some of the important > >ports - perhaps there was an important option that the author forgot > >to mention. > > > You needn't build sssd from ports. You can install sssd with pkg utility. > The only necessary step is to build openldap client with SASL support, > because default version of openldap client is build without SASL support. > sssd cannot initialize ipa_provider with openldap libraries without SASL > support. On the other hand, {ldap,krb5,ad} providers can be used without any > problem. > > The steps, how to build openldap client with SASL support, are described > in freebsd forum. > > >It is the end of the day for me, but sssd is now installed so I > >should let you know tomorrow whether I am running into the same > >issues as you, or whether I find success. > > > >(As a side node: once I get to a working setup I will create and > >publish a pkg(8) repo with the needed ports built with the correct > >options and make.conf variables. This should make it easier and > >certainly quicker to use FreeBSD as a FreeIPA client.) > I am not sure what you are trying to do. Everything is described on forum. > If there isn't something clear feel free to send rephrased(updated) version of > howto. I can contact an author of that post. > Since there are non-default options and make variables to be set, is it not desirable that there be a pkg(8) repository people can use to install the packages needed for ipa integration? I think it is desirable. It is easy to thanks to ports-mgmt/poudriere. Fraser > LS From leszek.mis at gmail.com Wed Oct 15 12:47:05 2014 From: leszek.mis at gmail.com (crony) Date: Wed, 15 Oct 2014 14:47:05 +0200 Subject: [Freeipa-users] IPA Trust AD and Illegal cross-realm ticket Message-ID: Hi, I've been following the AD integration guide for IPAv3: http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup My setup is: ? 5 domain controllers with Windows 2008 R2 AD DC -> example.com as Forest Root Domain and acme.example.com as transitive child domain ? RHEL7 as IPA server with domain: linux.acme.example.com ? RHEL6.5 as IPA client server ipatst03.linux.acme.example.com Everything works correctly around IPA Server, but the problem is within IPA Client. I can not login by SSH or by su -: [leszek at ipatst03 ~]$ su - user1 at acme.example.com Password: su: incorrect password I found this error in /var/log/sssd/krb5_child.log : (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [validate_tgt] (0x0020): TGT failed verification using key for [host/ ipatst03.linux.acme.example.com at LINUX.ACME.EXAMPLE.COM]. (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [get_and_save_tgt] (0x0020): 988: [-1765328341][Illegal cross-realm ticket] (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [map_krb5_error] (0x0020): 1043: [-1765328341][Illegal cross-realm ticket] (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [k5c_send_data] (0x0200): Received error code 1432158209 (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [pack_response_packet] (0x2000): response packet size: [20] (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [k5c_send_data] (0x4000): Response sent. (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [main] (0x0400): krb5_child completed successfully >From that IPA client I can run: [root at ipatst03 ~]$ getent passwd user1 at acme.example.com user1 at acme.example.com:*:127283727:127283727:user1:/home/ acme.example.com/user1: Do you know what is wrong with my setup? After adding krb5_validate = false to sssd.conf on IPA client ipatst03 I can login by su/ssh but without kerberos principals and without groups assigned: [leszek at ipatst03 ~]$ su - user1 at acme.example.com Password: -sh-4.1$ id uid=127283727(user1 at acme.example.com) gid=127283727(user1 at acme.example.com) groups=127283727(user1 at acme.example.com) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 -sh-4.1$ klist klist: No credentials cache found while retrieving principal name Below you can find setup information from IPA Server where everything looks good: [root at ipa1 ~]# kinit admin Password for admin at LINUX.ACME.EXAMPLE.COM: [root at ipa1 ~]# klist Ticket cache: KEYRING:persistent:0:0 Default principal: admin at LINUX.ACME.EXAMPLE.COM Valid starting Expires Service principal 10/15/2014 14:02:29 10/16/2014 14:02:25 krbtgt/ LINUX.ACME.EXAMPLE.COM at LINUX.ACME.EXAMPLE.COM [root at ipa1 ~]# getent passwd user1 at acme.example.com user1 at acme.example.com:*:127283727:127283727:user1:/home/ acme.example.com/user1: [root at ipa1 ~]# su - user1 at acme.example.com Last login: Wed Oct 15 13:05:11 CEST 2014 from 10.9.79.93 on pts/4 -sh-4.2$ id uid=127283727(user1 at acme.example.com) gid=127283727(user1 at acme.example.com) groups=127283727(user1 at acme.example.com),127200513(domain users at acme.example.com) -sh-4.2$ klist Ticket cache: KEYRING:persistent:127283727:krb_ccache_Aablt0q Default principal: USER1 at ACME.EXAMPLE.COM Valid starting Expires Service principal 10/15/2014 13:05:22 10/15/2014 21:26:29 host/ ipatst03.linux.acme.example.com at LINUX.ACME.EXAMPLE.COM renew until 10/16/2014 11:26:29 10/15/2014 13:05:20 10/15/2014 21:26:29 krbtgt/ LINUX.ACME.EXAMPLE.COM at EXAMPLE.COM renew until 10/16/2014 11:26:29 10/15/2014 13:05:20 10/15/2014 21:26:29 krbtgt/ EXAMPLE.COM at ACME.EXAMPLE.COM renew until 10/16/2014 11:26:29 10/15/2014 11:26:29 10/15/2014 21:26:29 krbtgt/ ACME.EXAMPLE.COM at ACME.EXAMPLE.COM renew until 10/16/2014 11:26:29 [leszek at ipa1 ~]$ su - user1 at acme.example.com Has?o: -sh-4.2$ klist Ticket cache: KEYRING:persistent:127283727:krb_ccache_Aablt0q Default principal: USER1 at ACME.EXAMPLE.COM Valid starting Expires Service principal 10/15/2014 14:43:00 10/16/2014 00:43:00 krbtgt/ ACME.EXAMPLE.COM at ACME.EXAMPLE.COM renew until 10/16/2014 14:43:00 Everything looks good. [root at ipa1 ipa trustdomain-find "example.com" Domain name: example.com Domain NetBIOS name: EXAMPLE Domain Security Identifier: S-1-5-21-827937240-19931235763-83952325 Domain enabled: True Domain name: acme.example.com Domain NetBIOS name: ACME Domain Security Identifier: S-1-5-21-107454117-223899964-1235820382 Domain enabled: True ---------------------------- Number of entries returned 2 ---------------------------- Any suggestions for help? Thanks. -- http://cronylab.pl http://emerge.pl -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Oct 15 13:02:37 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 15 Oct 2014 09:02:37 -0400 Subject: [Freeipa-users] Migration fails with custom objectClasses In-Reply-To: References: Message-ID: <20141015090237.018d642b@willson.usersys.redhat.com> On Tue, 14 Oct 2014 10:58:36 -0600 Clint Savage wrote: > Hi all, > > I've been working on a migration plan using three custom user > objectClasses and one group objectclass. In my attempt, I've setup an > openldap server with the proper schemas, imported the ldif and have > records that look something like this in ldif format. > > ----------------------------------------------------------------------- > > dn: dc=example,dc=com > objectClass: top > objectClass: domain > dc: example > > dn: ou=Groups,dc=example,dc=com > objectClass: top > objectClass: organizationalunit > ou: Groups > > dn: ou=People,dc=example,dc=com > objectClass: top > objectClass: organizationalunit > ou: People > > dn: uid=amyengh,ou=People,dc=example,dc=com > objectClass: inetOrgPerson > objectClass: posixAccount > objectClass: top > objectClass: organizationalPerson > objectClass: person > objectClass: radiusProfile > objectClass: sambaSamAccount > objectClass: customPersonAttributes > cn: Amy Engh > gidNumber: 1141801056 > homeDirectory: /home/amyengh > sn: Engh > uid: amyengh > uidNumber: 1141801056 > displayName: Amy Engh > givenName: Amy > loginShell: /sbin/nologin > mail: amyengh at attask.com > userPassword:: REDACTED > dialupAccess: yes > radiusTunnelMediumType: IEEE-802 > radiusTunnelPrivateGroupId: 1421 > radiusTunnelType: VLAN > emailPassword:: REDACTED > sambaAcctFlags: [U ] > sambaLMPassword: REDACTED > sambaNTPassword: REDACTED > sambaPasswordHistory: > 000000000000000000000000000000000000000000000000000000 0000000000 > sambaPwdLastSet: 1402698001 > sambaSID: S-1-5-21-2332447373-4108748234-3602490535-3146 > > dn: cn=amyengh,ou=Groups,dc=example,dc=com > objectClass: top > objectClass: posixGroup > cn: amyengh > gidNumber: 1141801056 > memberUid: amyengh > > -------------------------------------------------------------------- > > I then run the migration (with or without compat makes no difference) > and get the following: > > ipa migrate-ds --with-compat --user-container="ou=People" > --group-container="ou=Groups" --user-objectclass=posixAccount > --group-objectclass=posixgroup ldap://192.168.122.210 > --bind-dn="cn=Manager,dc=example,dc=com" > Password: > ----------- > migrate-ds: > ----------- > Migrated: > Failed user: > amyengh: Type or value exists: > Failed group: > amyengh: This entry already exists. Check GID of the existing > group. Use --group-overwrite-gid option to overwrite the GID > ---------- > Passwords have been migrated in pre-hashed format. > IPA is unable to generate Kerberos keys unless provided > with clear text passwords. All migrated users need to > login at https://your.domain/ipa/migration/ before they > can use their Kerberos accounts. > > The objectclasses are listed in the configuration properly: > > # ipa config-show --all > ..snip.. > Default group objectclasses: top, groupofnames, nestedgroup, > ipausergroup, ipaobject, sambaGroupMapping > Default user objectclasses: top, person, organizationalperson, > inetorgperson, inetuser, posixaccount, krbprincipalaux, > krbticketpolicyaux, ipaobject, ipasshuser, radiusProfile, > customPersonAttributes, sambaSamAccount > ..snip.. > > I can verify the objectclasses appear to work when I add a user > manually, though I have not updated the plugins to allow entries for > the above objectClasses. > > --------------------------- > My question exists around the error ' amyengh: Type or value > exists:'. I can take out the custom objectclasses, and this error > goes away. I've looked into all of the custom objectclasses and don't > see anything that would indicate errors. I have some 5k+ records to > migrate and don't want to have to manipulate the ldif and then create > modify records just to get the data into IPA. > > Any suggestions to help me identify why this is happening? I'd be > happy to provide further information as requested. Have you extended the IPA schema with the custom objectclasses ? Or is your intention to drop them during the import ? Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Wed Oct 15 13:50:59 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Oct 2014 16:50:59 +0300 Subject: [Freeipa-users] IPA Trust AD and Illegal cross-realm ticket In-Reply-To: References: Message-ID: <20141015135059.GB21350@redhat.com> On Wed, 15 Oct 2014, crony wrote: >Hi, >I've been following the AD integration guide for IPAv3: >http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup > >My setup is: >? 5 domain controllers with Windows 2008 R2 AD DC -> example.com as Forest >Root Domain and acme.example.com as transitive child domain >? RHEL7 as IPA server with domain: linux.acme.example.com >? RHEL6.5 as IPA client server ipatst03.linux.acme.example.com > >Everything works correctly around IPA Server, but the problem is within IPA >Client. > >I can not login by SSH or by su -: > >[leszek at ipatst03 ~]$ su - user1 at acme.example.com >Password: >su: incorrect password > >I found this error in /var/log/sssd/krb5_child.log : > >(Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [validate_tgt] >(0x0020): TGT failed verification using key for [host/ >ipatst03.linux.acme.example.com at LINUX.ACME.EXAMPLE.COM]. >(Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [get_and_save_tgt] >(0x0020): 988: [-1765328341][Illegal cross-realm ticket] >(Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [map_krb5_error] >(0x0020): 1043: [-1765328341][Illegal cross-realm ticket] >(Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [k5c_send_data] >(0x0200): Received error code 1432158209 >(Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] >[pack_response_packet] (0x2000): response packet size: [20] >(Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [k5c_send_data] >(0x4000): Response sent. >(Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [main] (0x0400): >krb5_child completed successfully Yes, this is known issue for transitive trusts. MIT Kerberos requires for non-hierarchical trusts that [capaths] section contains proper map of relationships between the realms. We've got an API to manage this map from IPA KDC driver and we also write it down on the IPA masters with the help of SSSD for KDC to use but on IPA clients it is not generated as we hoped that receiving referrals from KDC would be enough. You can see that this is the issue by copying /var/lib/sss/pubconf/krb5conf.d/domain_realm_linux_acme_example_com to your client and placing it as /var/lib/sss/pubconf/krb5conf.d/domain_realm_linux_acme_example_com_capaths On next authentication attempt things will work. -- / Alexander Bokovoy From leszek.mis at gmail.com Wed Oct 15 14:31:55 2014 From: leszek.mis at gmail.com (crony) Date: Wed, 15 Oct 2014 16:31:55 +0200 Subject: [Freeipa-users] IPA Trust AD and Illegal cross-realm ticket In-Reply-To: <20141015135059.GB21350@redhat.com> References: <20141015135059.GB21350@redhat.com> Message-ID: Alex, thank you. Now it works, but not completely: 1. [leszek at ipa1 ~]$ ssh ipatst03.linux.acme.example.com -l user1 at acme.example.com Password: Last login: Wed Oct 15 16:11:27 2014 -sh-4.1$ id uid=127283727(user1 at acme.example.com) gid=127283727(user1 at acme.example.com) grupy=127283727(user1 at acme.example.com),127292838( linuxgroup at acme.example.com) I can't see all my groups. User1 is a member of 15 different groups at AD side, not one as above: linuxgroup at acme.example.com Could it be related? I can see all these membership groups at IPA Server (id user1 at acme.example.com) 2. After login ssh ipatst03.linux.acme.example.com -l user1 at acme.example.com -sh-4.1$ klist klist: Included profile file could not be read while initializing krb5 Even kinit not works: -sh-4.1$ kinit user1 at acme.example.com kinit: Included profile file could not be read while initializing Kerberos 5 library What about that? I didn't see this error before. Related? I have another, but related question, If you don't mind: What if I would like to connect RHEL5 IPA client to my IPA Server AD Trust Setup? Do you think it is real and could it work? Thank you in advanced 2014-10-15 15:50 GMT+02:00 Alexander Bokovoy : > On Wed, 15 Oct 2014, crony wrote: > >> Hi, >> I've been following the AD integration guide for IPAv3: >> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup >> >> My setup is: >> ? 5 domain controllers with Windows 2008 R2 AD DC -> example.com as >> Forest >> Root Domain and acme.example.com as transitive child domain >> ? RHEL7 as IPA server with domain: linux.acme.example.com >> ? RHEL6.5 as IPA client server ipatst03.linux.acme.example.com >> >> Everything works correctly around IPA Server, but the problem is within >> IPA >> Client. >> >> I can not login by SSH or by su -: >> >> [leszek at ipatst03 ~]$ su - user1 at acme.example.com >> Password: >> su: incorrect password >> >> I found this error in /var/log/sssd/krb5_child.log : >> >> (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [validate_tgt] >> (0x0020): TGT failed verification using key for [host/ >> ipatst03.linux.acme.example.com at LINUX.ACME.EXAMPLE.COM]. >> (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [get_and_save_tgt] >> (0x0020): 988: [-1765328341][Illegal cross-realm ticket] >> (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [map_krb5_error] >> (0x0020): 1043: [-1765328341][Illegal cross-realm ticket] >> (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [k5c_send_data] >> (0x0200): Received error code 1432158209 >> (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] >> [pack_response_packet] (0x2000): response packet size: [20] >> (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [k5c_send_data] >> (0x4000): Response sent. >> (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [main] (0x0400): >> krb5_child completed successfully >> > Yes, this is known issue for transitive trusts. MIT Kerberos requires > for non-hierarchical trusts that [capaths] section contains proper map > of relationships between the realms. We've got an API to manage this map > from IPA KDC driver and we also write it down on the IPA masters with > the help of SSSD for KDC to use but on IPA clients it is not generated > as we hoped that receiving referrals from KDC would be enough. > > You can see that this is the issue by copying > /var/lib/sss/pubconf/krb5conf.d/domain_realm_linux_acme_example_com to > your client and placing it as > /var/lib/sss/pubconf/krb5conf.d/domain_realm_linux_acme_ > example_com_capaths > > On next authentication attempt things will work. > > -- > / Alexander Bokovoy > -- Pozdrawiam Leszek Mi? www: http://cronylab.pl www: http://emerge.pl Nothing is secure, paranoia is your friend. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Wed Oct 15 15:43:32 2014 From: sbose at redhat.com (Sumit Bose) Date: Wed, 15 Oct 2014 17:43:32 +0200 Subject: [Freeipa-users] IPA Trust AD and Illegal cross-realm ticket In-Reply-To: References: <20141015135059.GB21350@redhat.com> Message-ID: <20141015154332.GJ22964@localhost.localdomain> On Wed, Oct 15, 2014 at 04:31:55PM +0200, crony wrote: > Alex, > thank you. Now it works, but not completely: > > 1. > > [leszek at ipa1 ~]$ ssh ipatst03.linux.acme.example.com -l > user1 at acme.example.com > Password: > Last login: Wed Oct 15 16:11:27 2014 > > -sh-4.1$ id > uid=127283727(user1 at acme.example.com) gid=127283727(user1 at acme.example.com) > grupy=127283727(user1 at acme.example.com),127292838( > linuxgroup at acme.example.com) > > I can't see all my groups. User1 is a member of 15 different groups at AD > side, not one as above: linuxgroup at acme.example.com What type/scope do the AD groups have? If they are 'Domain Local' groups they will not be available in the IPA domain. HTH bye, Sumit > > Could it be related? I can see all these membership groups at IPA Server > (id user1 at acme.example.com) > > 2. After login ssh ipatst03.linux.acme.example.com -l user1 at acme.example.com > > -sh-4.1$ klist > klist: Included profile file could not be read while initializing krb5 > > Even kinit not works: > > -sh-4.1$ kinit user1 at acme.example.com > kinit: Included profile file could not be read while initializing Kerberos > 5 library > > What about that? I didn't see this error before. Related? > > I have another, but related question, If you don't mind: What if I would > like to connect RHEL5 IPA client to my IPA Server AD Trust Setup? Do you > think it is real and could it work? > > Thank you in advanced > > > > 2014-10-15 15:50 GMT+02:00 Alexander Bokovoy : > > > On Wed, 15 Oct 2014, crony wrote: > > > >> Hi, > >> I've been following the AD integration guide for IPAv3: > >> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup > >> > >> My setup is: > >> ? 5 domain controllers with Windows 2008 R2 AD DC -> example.com as > >> Forest > >> Root Domain and acme.example.com as transitive child domain > >> ? RHEL7 as IPA server with domain: linux.acme.example.com > >> ? RHEL6.5 as IPA client server ipatst03.linux.acme.example.com > >> > >> Everything works correctly around IPA Server, but the problem is within > >> IPA > >> Client. > >> > >> I can not login by SSH or by su -: > >> > >> [leszek at ipatst03 ~]$ su - user1 at acme.example.com > >> Password: > >> su: incorrect password > >> > >> I found this error in /var/log/sssd/krb5_child.log : > >> > >> (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [validate_tgt] > >> (0x0020): TGT failed verification using key for [host/ > >> ipatst03.linux.acme.example.com at LINUX.ACME.EXAMPLE.COM]. > >> (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [get_and_save_tgt] > >> (0x0020): 988: [-1765328341][Illegal cross-realm ticket] > >> (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [map_krb5_error] > >> (0x0020): 1043: [-1765328341][Illegal cross-realm ticket] > >> (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [k5c_send_data] > >> (0x0200): Received error code 1432158209 > >> (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] > >> [pack_response_packet] (0x2000): response packet size: [20] > >> (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [k5c_send_data] > >> (0x4000): Response sent. > >> (Wed Oct 15 13:49:59 2014) [[sssd[krb5_child[1880]]]] [main] (0x0400): > >> krb5_child completed successfully > >> > > Yes, this is known issue for transitive trusts. MIT Kerberos requires > > for non-hierarchical trusts that [capaths] section contains proper map > > of relationships between the realms. We've got an API to manage this map > > from IPA KDC driver and we also write it down on the IPA masters with > > the help of SSSD for KDC to use but on IPA clients it is not generated > > as we hoped that receiving referrals from KDC would be enough. > > > > You can see that this is the issue by copying > > /var/lib/sss/pubconf/krb5conf.d/domain_realm_linux_acme_example_com to > > your client and placing it as > > /var/lib/sss/pubconf/krb5conf.d/domain_realm_linux_acme_ > > example_com_capaths > > > > On next authentication attempt things will work. > > > > -- > > / Alexander Bokovoy > > > > > > -- > Pozdrawiam Leszek Mi? > www: http://cronylab.pl > www: http://emerge.pl > Nothing is secure, paranoia is your friend. > -- > 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 From herlo1 at gmail.com Wed Oct 15 16:29:30 2014 From: herlo1 at gmail.com (Clint Savage) Date: Wed, 15 Oct 2014 10:29:30 -0600 Subject: [Freeipa-users] Migration fails with custom objectClasses In-Reply-To: <20141015090237.018d642b@willson.usersys.redhat.com> References: <20141015090237.018d642b@willson.usersys.redhat.com> Message-ID: I have extended the schema with the custom objectclasses. They show up properly in /etc/dirsrv/slapd-EXAMPLE-COM/schema/99user.ldif. I did the import with ldapmodify using the following schemas. It's a bit long, but hopefully it helps. # cat customPersonAttributes.ldif dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 1.3.6.1.5.5.7.13.421 NAME 'noGmail' DESC 'Opt user out of Gmail' SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 X-ORIGIN ( 'Local custom' 'user defined' ) ) - add: attributeTypes attributeTypes: ( 1.3.6.1.5.5.7.13.420 NAME 'emailPassword' DESC 'Unsalted SHA-1 for Gmail' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN ( 'Local custom' 'user defined' ) ) - add: objectClasses objectClasses: ( 2.16.840.1.117370.999.1.2.3 NAME 'customPersonAttributes' DESC 'Local customizations' SUP top AUXILIARY MAY ( emailPassword $ noGmail) X-ORIGIN ( 'Local custom attributes' 'user defined' ) ) # cat radiusProfile.ldif dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.38 NAME 'radiusTunnelPreference' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.35 NAME 'radiusTunnelAssignmentId' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.20 NAME 'radiusFramedRouting' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.42 NAME 'radiusVSA' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.28 NAME 'radiusLoginTCPPort' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.25 NAME 'radiusLoginLATPort' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.47 NAME 'radiusHint' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.8 NAME 'radiusClass' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.10 NAME 'radiusFramedAppleTalkLink' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.32 NAME 'radiusServiceType' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.54 NAME 'radiusLoginTime' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.18 NAME 'radiusFramedProtocol' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.61 NAME 'radiusNASIpAddress' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.3 NAME 'radiusArapZoneAccess' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 0.9.2342.19200300.100.1.31 NAME 'CNAMERecord' DESC 'Pilot attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'Internet dir ectory pilot' ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.15 NAME 'radiusFramedIPNetmask' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.37 NAME 'radiusTunnelPassword' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.22 NAME 'radiusLoginIPHost' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.44 NAME 'radiusAuthType' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.51 NAME 'radiusReplicateToRealm' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.6 NAME 'radiusCalledStationId' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.27 NAME 'radiusLoginService' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.59 NAME 'radiusCheckItem' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.12 NAME 'radiusFramedAppleTalkZone' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.34 NAME 'radiusTerminationAction' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.56 NAME 'radiusStripUserName' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.41 NAME 'radiusTunnelType' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.1 NAME 'radiusArapFeatures' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.17 NAME 'radiusFramedMTU' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.49 NAME 'radiusProfileDn' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.24 NAME 'radiusLoginLATNode' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.46 NAME 'radiusGroupName' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.9 NAME 'radiusFilterId' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.31 NAME 'radiusPrompt' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.53 NAME 'radiusSimultaneousUse' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.4 NAME 'radiusCallbackId' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.60 NAME 'radiusReplyItem' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.39 NAME 'radiusTunnelPrivateGroupId' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.14 NAME 'radiusFramedIPAddress' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.36 NAME 'radiusTunnelMediumType' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.21 NAME 'radiusIdleTimeout' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.43 NAME 'radiusTunnelClientEndpoint' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.50 NAME 'radiusProxyToRealm' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.7 NAME 'radiusCallingStationId' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.29 NAME 'radiusPasswordRetry' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.26 NAME 'radiusLoginLATService' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.58 NAME 'radiusExpiration' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.11 NAME 'radiusFramedAppleTalkNetwork' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.33 NAME 'radiusSessionTimeout' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.55 NAME 'radiusUserCategory' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.40 NAME 'radiusTunnelServerEndpoint' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.19 NAME 'radiusFramedRoute' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.62 NAME 'radiusReplyMessage' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.2 NAME 'radiusArapSecurity' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.16 NAME 'radiusFramedIPXNetwork' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.48 NAME 'radiusHuntgroupName' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.23 NAME 'radiusLoginLATGroup' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.45 NAME 'radiusClientIPAddress' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.30 NAME 'radiusPortLimit' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.52 NAME 'radiusRealm' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.5 NAME 'radiusCallbackNumber' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: attributeTypes attributeTypes: ( 2.16.840.1.113730.3.1.684 NAME 'nsds5ReplicaChangeCount' DESC 'Netscape defined attribute type' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.13 NAME 'radiusFramedCompression' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.3317.4.3.1.57 NAME 'dialupAccess' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - add: objectClasses objectClasses: ( 1.3.6.1.4.1.3317.4.3.2.1 NAME 'radiusprofile' DESC '' SUP top AUXILIARY MUST cn MAY ( radiusArapFeatures $ radiusArapSecurity $ radius ArapZoneAccess $ radiusAuthType $ radiusCallbackId $ radiusCallbackNumber $ radiusCalledStationId $ radiusCallingStationId $ radiusClass $ radiusClientIPAddress $ radiusFilterId $ radiusFramedAppleTalkLink $ radiusFramedAppleTalkNetwork $ radiusFramedAppleTalkZone $ radiusFramedCompression $ radiusFramedIPAddress $ radiusFramedIPNetmask $ radiusFramedIPXNetwork $ radiusFramedMTU $ radiusFramedProtocol $ radiusCheckItem $ radiusReplyItem $ radiusFramedRoute $ radiusFramedRouting $ radiusIdleTimeout $ radiusGroupName $ radiusHint $ radiusHuntgroupName $ radiusLoginIPHost $ radiusLoginLATGroup $ radiusLoginLATNode $ radiusLoginLATPort $ radiusLoginLATService $ radiusLoginService $ radiusLoginTCPPort $ radiusLoginTime $ radiusPasswordRetry $ radiusPortLimit $ radiusPrompt $ radiusProxyToRealm $ radiusRealm $ radiusReplicateToRealm $ radiusServiceType $ radiusSessionTimeout $ radiusStripUserName $ radiusTerminationAction $ radiusTunnelClientEndpoint $ radiusProfileDn $ radiusSimultaneousUse $ radiusTunnelAssignmentId $ radiusTunnelMediumType $ radiusTunnelPassword $ radiusTunnelPreference $ radiusTunnelPrivateGroupId $ radiusTunnelServerEndpoint $ radiusTunnelType $ radiusUserCategory $ radiusVSA $ radiusExpiration $ dialupAccess $ radiusNASIpAddress $ radiusReplyMessage ) ) I'm happy to provide any other data necessary as well. Thanks, Clint On Wed, Oct 15, 2014 at 7:02 AM, Simo Sorce wrote: > On Tue, 14 Oct 2014 10:58:36 -0600 > Clint Savage wrote: > > > Hi all, > > > > I've been working on a migration plan using three custom user > > objectClasses and one group objectclass. In my attempt, I've setup an > > openldap server with the proper schemas, imported the ldif and have > > records that look something like this in ldif format. > > > > ----------------------------------------------------------------------- > > > > dn: dc=example,dc=com > > objectClass: top > > objectClass: domain > > dc: example > > > > dn: ou=Groups,dc=example,dc=com > > objectClass: top > > objectClass: organizationalunit > > ou: Groups > > > > dn: ou=People,dc=example,dc=com > > objectClass: top > > objectClass: organizationalunit > > ou: People > > > > dn: uid=amyengh,ou=People,dc=example,dc=com > > objectClass: inetOrgPerson > > objectClass: posixAccount > > objectClass: top > > objectClass: organizationalPerson > > objectClass: person > > objectClass: radiusProfile > > objectClass: sambaSamAccount > > objectClass: customPersonAttributes > > cn: Amy Engh > > gidNumber: 1141801056 > > homeDirectory: /home/amyengh > > sn: Engh > > uid: amyengh > > uidNumber: 1141801056 > > displayName: Amy Engh > > givenName: Amy > > loginShell: /sbin/nologin > > mail: amyengh at attask.com > > userPassword:: REDACTED > > dialupAccess: yes > > radiusTunnelMediumType: IEEE-802 > > radiusTunnelPrivateGroupId: 1421 > > radiusTunnelType: VLAN > > emailPassword:: REDACTED > > sambaAcctFlags: [U ] > > sambaLMPassword: REDACTED > > sambaNTPassword: REDACTED > > sambaPasswordHistory: > > 000000000000000000000000000000000000000000000000000000 0000000000 > > sambaPwdLastSet: 1402698001 > > sambaSID: S-1-5-21-2332447373-4108748234-3602490535-3146 > > > > dn: cn=amyengh,ou=Groups,dc=example,dc=com > > objectClass: top > > objectClass: posixGroup > > cn: amyengh > > gidNumber: 1141801056 > > memberUid: amyengh > > > > -------------------------------------------------------------------- > > > > I then run the migration (with or without compat makes no difference) > > and get the following: > > > > ipa migrate-ds --with-compat --user-container="ou=People" > > --group-container="ou=Groups" --user-objectclass=posixAccount > > --group-objectclass=posixgroup ldap://192.168.122.210 > > --bind-dn="cn=Manager,dc=example,dc=com" > > Password: > > ----------- > > migrate-ds: > > ----------- > > Migrated: > > Failed user: > > amyengh: Type or value exists: > > Failed group: > > amyengh: This entry already exists. Check GID of the existing > > group. Use --group-overwrite-gid option to overwrite the GID > > ---------- > > Passwords have been migrated in pre-hashed format. > > IPA is unable to generate Kerberos keys unless provided > > with clear text passwords. All migrated users need to > > login at https://your.domain/ipa/migration/ before they > > can use their Kerberos accounts. > > > > The objectclasses are listed in the configuration properly: > > > > # ipa config-show --all > > ..snip.. > > Default group objectclasses: top, groupofnames, nestedgroup, > > ipausergroup, ipaobject, sambaGroupMapping > > Default user objectclasses: top, person, organizationalperson, > > inetorgperson, inetuser, posixaccount, krbprincipalaux, > > krbticketpolicyaux, ipaobject, ipasshuser, radiusProfile, > > customPersonAttributes, sambaSamAccount > > ..snip.. > > > > I can verify the objectclasses appear to work when I add a user > > manually, though I have not updated the plugins to allow entries for > > the above objectClasses. > > > > --------------------------- > > My question exists around the error ' amyengh: Type or value > > exists:'. I can take out the custom objectclasses, and this error > > goes away. I've looked into all of the custom objectclasses and don't > > see anything that would indicate errors. I have some 5k+ records to > > migrate and don't want to have to manipulate the ldif and then create > > modify records just to get the data into IPA. > > > > Any suggestions to help me identify why this is happening? I'd be > > happy to provide further information as requested. > > Have you extended the IPA schema with the custom objectclasses ? > Or is your intention to drop them during the import ? > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgiger at verizon.com Wed Oct 15 16:31:22 2014 From: jgiger at verizon.com (Giger, Justean) Date: Wed, 15 Oct 2014 12:31:22 -0400 Subject: [Freeipa-users] Solaris 10 client configuration using profile In-Reply-To: <59833.81.167.145.195.1413051967.squirrel@www.nixtra.com> References: <1412986404.75392.YahooMailBasic@web122503.mail.ne1.yahoo.com> <5439646E.3010906@redhat.com> <20141011175449.GG2328@redhat.com> <59833.81.167.145.195.1413051967.squirrel@www.nixtra.com> Message-ID: <903DF15B7B9D3B4D9137A06F63687859171A8B16A6@FHDP1LUMXC7V33.us.one.verizon.com> Thank you both. I successfully set up a new profile on the server and am able to use it with authentication. It seems to work for existing users but I am having issues when I add new user access via HBAC so I am trying to figure that part out. There are a few options I can invoke using ldapclient manual that I cannot seem to add to the profile (mainly attributeMap settings) but I don't think that is the issue. I will plug away at it more tomorrow and see if I can figure it out. -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Sigbjorn Lie Sent: Saturday, October 11, 2014 11:26 AM To: Alexander Bokovoy Cc: sipazzo; Freeipa-users at redhat.com Subject: Re: [Freeipa-users] Solaris 10 client configuration using profile On Sat, October 11, 2014 19:54, Alexander Bokovoy wrote: > On Sat, 11 Oct 2014, Rob Crittenden wrote: > >> sipazzo wrote: >>> Thank you,I know where the profile is in the directory tree and how >>> I would invoke it were it there...I don't know how to get it into >>> the directory tree so that it is available to clients. I see posts >>> giving examples of different profilesthat could be used but no post as to how to add it to the directory. Sorry if I am missing something obvious. >>> >>> >>> -------------------------------------------- >>> On Fri, 10/10/14, Rob Crittenden wrote: >>> >>> >>> Subject: Re: [Freeipa-users] Solaris 10 client configuration using >>> profile >>> To: "sipazzo" , freeipa-users at redhat.com >>> Date: Friday, October 10, 2014, 4:53 PM >>> >>> >>> sipazzo wrote: >>>> >>> Hello, I am trying to set up a default profile for my Solaris 10 IPA >>> clients as recommended. I generated a profile on a Solaris with the >>> attributes I needed except I got an "invalid parameter" error when >>> specifying the domainName attribute like this -a >>> domainName=example.com even though this parameter works when I use >>> it in ldapclient manual. More of an issue though is I have been >>> unable to find documentation on getting the profile incorporated >>> into the ipa server. How do I get this profile on the ipa server and >>> make it available to my Solaris clients? Also, my understanding is >>> the clients periodically check this profile so they stay updated with the latest configuration information. What generates this check? Is it time based, a restart of a service or ?? >>>> >>>> Thank you for any >>>> >>> assistance. >>>> >>> >>> It's been forever since I configured a Solaris anything client but I >>> can tell you where the profile gets stored: >>> cn=profilename,cn=default,ou=profile,$SUFFIX >>> >>> IPA ships with a default >>> profile of: >>> >>> dn: >>> cn=default,ou=profile,$SUFFIX ObjectClass: >>> top ObjectClass: DUAConfigProfile >>> defaultServerList: $FQDN >>> defaultSearchBase: $SUFFIX >>> authenticationMethod: none >>> searchTimeLimit: 15 >>> cn: >>> default serviceSearchDescriptor: >>> passwd:cn=users,cn=accounts,$SUFFIX >>> serviceSearchDescriptor: >>> group:cn=groups,cn=compat,$SUFFIX >>> bindTimeLimit: 5 >>> objectClassMap: >>> shadow:shadowAccount=posixAccount >>> followReferrals:TRUE >>> >>> >>> The full schema can be found at >>> http://docs.oracle.com/cd/E23824_01/html/821-1455/schemas-17.html >>> >>> >>> So if your profile is named >>> foo you'd invoke it with something like: >>> >>> # ldapclient init -a >>> profileName=foo ipa.example.com >>> >>> rob >>> >>> >> >> Here is an example inspired by >> https://bugzilla.redhat.com/show_bug.cgi?id=815515 >> >> >> $ ldapmodify -x -D 'cn=Directory Manager' -W >> dn: cn=solaris_authssl_test,ou=profile,dc=example,dc=com >> objectClass: top >> objectClass: DUAConfigProfile >> cn: solaris_authssl_test >> authenticationMethod: tls:simple >> bindTimeLimit: 5 >> credentialLevel: proxy >> defaultSearchBase: dc=example,dc=com >> defaultSearchScope: one >> defaultServerList: ipa01.example.com ipa02.example.com >> ipa03.example.com >> followReferrals: TRUE >> objectclassMap: shadow:shadowAccount=posixAccount >> objectclassMap: printers:sunPrinter=printerService >> preferredServerList: ipa01.example.com ipa02.example.com >> profileTTL: 6000 >> searchTimeLimit: 10 >> serviceSearchDescriptor: >> passwd:cn=users,cn=accounts,dc=example,dc=com >> serviceSearchDescriptor: group:cn=groups,cn=compat,dc=example,dc=com >> serviceSearchDescriptor: netgroup:cn=ng,cn=compat,dc=example,dc=com >> serviceSearchDescriptor: >> ethers:cn=computers,cn=accounts,dc=example,dc=com >> serviceSearchDescriptor: >> automount:cn=default,cn=automount,dc=example,dc=com >> serviceSearchDescriptor: >> auto_master:automountMapName=auto.master,cn=defualt,cn=automount,dc=e >> xample,dc=com >> serviceSearchDescriptor: aliases:ou=aliases,ou=test,dc=example,dc=com >> serviceSearchDescriptor: >> printers:ou=printers,ou=test,dc=example,dc=com >> >> ^D >> >> >> You may want to check out >> https://bugzilla.redhat.com/show_bug.cgi?id=815533 as well. >> > Should the profile be available anonymously? It is not in 4.x: > $ ldapsearch -x -b ou=profile,dc=ipacloud,dc=test # extended LDIF # # > LDAPv3 # base with scope subtree # > filter: (objectclass=*) # requesting: ALL # > > > # search result > search: 2 > result: 0 Success > > > # numResponses: 1 > $ kinit admin > Password for admin at IPACLOUD.TEST: > $ ldapsearch -Y GSSAPI -b ou=profile,dc=ipacloud,dc=test SASL/GSSAPI > authentication started SASL username: admin at IPACLOUD.TEST SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with scope subtree # filter: > (objectclass=*) # requesting: ALL # > > > # profile, ipacloud.test > dn: ou=profile,dc=ipacloud,dc=test > objectClass: top > objectClass: organizationalUnit > ou: profiles > ou: profile > > > # default, profile, ipacloud.test > dn: cn=default,ou=profile,dc=ipacloud,dc=test > defaultServerList: cc21.ipacloud.test > defaultSearchBase: dc=ipacloud,dc=test > objectClass: top > objectClass: DUAConfigProfile > serviceSearchDescriptor: > passwd:cn=users,cn=accounts,dc=ipacloud,dc=test > serviceSearchDescriptor: group:cn=groups,cn=compat,dc=ipacloud,dc=test > searchTimeLimit: 15 > followReferrals: TRUE > objectclassMap: shadow:shadowAccount=posixAccount > bindTimeLimit: 5 > authenticationMethod: none > cn: default > > > # search result > search: 4 > result: 0 Success > > > # numResponses: 3 > # numEntries: 2 > > > > I think it should be available anonymously too, so we need to add a > specialized ACI for that. -- Hi, The DUA profile does not need to be available anonymously. Additional parameters (-D to specify a ldap user DN and -w or -W for password for the ldap user, if memory serves correctly) can be specified to allow the ldapclient script to bind to the LDAP server before looking for a DUA profile. The ldapclient script had an issue in earlier Solaris 10, which prevented the additional bind parameters from working, however later patches (released a few years ago now) has solved this issue. I?ve also configured Solaris 8 with the IPA LDAP server being closed for anonymous connections, and it works just fine. I do however use the "rootdse" option when closing the LDAP server for anonymous connections. If I remember correctly this has to be done to make the Solaris "ldapclient" script to work. For the bugzillas referred to by Rob, these are the instructions I wrote after I completed migration of several environments having Solaris 10 (and some Solaris 8) from a NIS environment to an IPA environment, and these DUA profiles are in production today and working just fine. Regards, Siggi -- 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 From lkrispen at redhat.com Wed Oct 15 17:55:43 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 15 Oct 2014 19:55:43 +0200 Subject: [Freeipa-users] Migration fails with custom objectClasses In-Reply-To: References: Message-ID: <543EB51F.2030307@redhat.com> On 10/14/2014 06:58 PM, Clint Savage wrote: > Hi all, > > I've been working on a migration plan using three custom user > objectClasses and one group objectclass. In my attempt, I've setup an > openldap server with the proper schemas, imported the ldif and have > records that look something like this in ldif format. > > ----------------------------------------------------------------------- > > dn: dc=example,dc=com > objectClass: top > objectClass: domain > dc: example > > dn: ou=Groups,dc=example,dc=com > objectClass: top > objectClass: organizationalunit > ou: Groups > > dn: ou=People,dc=example,dc=com > objectClass: top > objectClass: organizationalunit > ou: People > > dn: uid=amyengh,ou=People,dc=example,dc=com > objectClass: inetOrgPerson > objectClass: posixAccount > objectClass: top > objectClass: organizationalPerson > objectClass: person > objectClass: radiusProfile > objectClass: sambaSamAccount > objectClass: customPersonAttributes > cn: Amy Engh > gidNumber: 1141801056 > homeDirectory: /home/amyengh > sn: Engh > uid: amyengh > uidNumber: 1141801056 > displayName: Amy Engh > givenName: Amy > loginShell: /sbin/nologin > mail: amyengh at attask.com > userPassword:: REDACTED > dialupAccess: yes > radiusTunnelMediumType: IEEE-802 > radiusTunnelPrivateGroupId: 1421 > radiusTunnelType: VLAN > emailPassword:: REDACTED > sambaAcctFlags: [U ] > sambaLMPassword: REDACTED > sambaNTPassword: REDACTED > sambaPasswordHistory: > 000000000000000000000000000000000000000000000000000000 > 0000000000 > sambaPwdLastSet: 1402698001 > sambaSID: S-1-5-21-2332447373-4108748234-3602490535-3146 > > dn: cn=amyengh,ou=Groups,dc=example,dc=com > objectClass: top > objectClass: posixGroup > cn: amyengh > gidNumber: 1141801056 > memberUid: amyengh > > -------------------------------------------------------------------- > > I then run the migration (with or without compat makes no difference) > and get the following: > > ipa migrate-ds --with-compat --user-container="ou=People" > --group-container="ou=Groups" --user-objectclass=posixAccount > --group-objectclass=posixgroup ldap://192.168.122.210 > --bind-dn="cn=Manager,dc=example,dc=com" > Password: > ----------- > migrate-ds: > ----------- > Migrated: > Failed user: > amyengh: Type or value exists: > Failed group: > amyengh: This entry already exists. "type or value exists" and "This entry already exists" are just explanations of the ldap return code, do you see anything in the 389 ds error logs ? > Check GID of the existing group. Use --group-overwrite-gid option to > overwrite the GID > ---------- > Passwords have been migrated in pre-hashed format. > IPA is unable to generate Kerberos keys unless provided > with clear text passwords. All migrated users need to > login at https://your.domain/ipa/migration/ before they > can use their Kerberos accounts. > > The objectclasses are listed in the configuration properly: > > # ipa config-show --all > ..snip.. > Default group objectclasses: top, groupofnames, nestedgroup, > ipausergroup, ipaobject, sambaGroupMapping > Default user objectclasses: top, person, organizationalperson, > inetorgperson, inetuser, posixaccount, krbprincipalaux, > krbticketpolicyaux, > ipaobject, ipasshuser, radiusProfile, > customPersonAttributes, sambaSamAccount > ..snip.. > > I can verify the objectclasses appear to work when I add a user > manually, though I have not updated the plugins to allow entries for > the above objectClasses. > > --------------------------- > My question exists around the error ' amyengh: Type or value exists:'. > I can take out the custom objectclasses, and this error goes away. > I've looked into all of the custom objectclasses and don't see > anything that would indicate errors. I have some 5k+ records to > migrate and don't want to have to manipulate the ldif and then create > modify records just to get the data into IPA. > > Any suggestions to help me identify why this is happening? I'd be > happy to provide further information as requested. > > Thanks, > > herlo > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Oct 15 19:16:45 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 15 Oct 2014 15:16:45 -0400 Subject: [Freeipa-users] Migration fails with custom objectClasses In-Reply-To: <543EB51F.2030307@redhat.com> References: <543EB51F.2030307@redhat.com> Message-ID: <543EC81D.9000807@redhat.com> Ludwig Krispenz wrote: > > On 10/14/2014 06:58 PM, Clint Savage wrote: >> Hi all, >> >> I've been working on a migration plan using three custom user >> objectClasses and one group objectclass. In my attempt, I've setup an >> openldap server with the proper schemas, imported the ldif and have >> records that look something like this in ldif format. >> >> ----------------------------------------------------------------------- >> >> dn: dc=example,dc=com >> objectClass: top >> objectClass: domain >> dc: example >> >> dn: ou=Groups,dc=example,dc=com >> objectClass: top >> objectClass: organizationalunit >> ou: Groups >> >> dn: ou=People,dc=example,dc=com >> objectClass: top >> objectClass: organizationalunit >> ou: People >> >> dn: uid=amyengh,ou=People,dc=example,dc=com >> objectClass: inetOrgPerson >> objectClass: posixAccount >> objectClass: top >> objectClass: organizationalPerson >> objectClass: person >> objectClass: radiusProfile >> objectClass: sambaSamAccount >> objectClass: customPersonAttributes >> cn: Amy Engh >> gidNumber: 1141801056 >> homeDirectory: /home/amyengh >> sn: Engh >> uid: amyengh >> uidNumber: 1141801056 >> displayName: Amy Engh >> givenName: Amy >> loginShell: /sbin/nologin >> mail: amyengh at attask.com >> userPassword:: REDACTED >> dialupAccess: yes >> radiusTunnelMediumType: IEEE-802 >> radiusTunnelPrivateGroupId: 1421 >> radiusTunnelType: VLAN >> emailPassword:: REDACTED >> sambaAcctFlags: [U ] >> sambaLMPassword: REDACTED >> sambaNTPassword: REDACTED >> sambaPasswordHistory: >> 000000000000000000000000000000000000000000000000000000 >> 0000000000 >> sambaPwdLastSet: 1402698001 >> sambaSID: S-1-5-21-2332447373-4108748234-3602490535-3146 >> >> dn: cn=amyengh,ou=Groups,dc=example,dc=com >> objectClass: top >> objectClass: posixGroup >> cn: amyengh >> gidNumber: 1141801056 >> memberUid: amyengh >> >> -------------------------------------------------------------------- >> >> I then run the migration (with or without compat makes no difference) >> and get the following: >> >> ipa migrate-ds --with-compat --user-container="ou=People" >> --group-container="ou=Groups" --user-objectclass=posixAccount >> --group-objectclass=posixgroup ldap://192.168.122.210 >> --bind-dn="cn=Manager,dc=example,dc=com" >> Password: >> ----------- >> migrate-ds: >> ----------- >> Migrated: >> Failed user: >> amyengh: Type or value exists: >> Failed group: >> amyengh: This entry already exists. > "type or value exists" and "This entry already exists" are just > explanations of the ldap return code, do you see anything in the 389 ds > error logs ? I doubt that he would see any errors. The entry already existing is because this isn't his first migration, it is unrelated. I'm not able to reproduce this. What version of IPA is it? rob From herlo1 at gmail.com Wed Oct 15 19:56:56 2014 From: herlo1 at gmail.com (Clint Savage) Date: Wed, 15 Oct 2014 13:56:56 -0600 Subject: [Freeipa-users] Migration fails with custom objectClasses In-Reply-To: <543EC81D.9000807@redhat.com> References: <543EB51F.2030307@redhat.com> <543EC81D.9000807@redhat.com> Message-ID: $ rpm -q ipa-server ipa-server-3.3.3-28.el7.centos.1.x86_64 I was thinking that this might be an issue with the rhel7 version. I'm going to be trying the same migration tonight on rhel6. I know the IPA version is older, and samba stuff might not work as it does in 3.3. I haven't looked in RHEL 6.6 yet to see what version of IPA is available. Clint On Wed, Oct 15, 2014 at 1:16 PM, Rob Crittenden wrote: > Ludwig Krispenz wrote: > > > > On 10/14/2014 06:58 PM, Clint Savage wrote: > >> Hi all, > >> > >> I've been working on a migration plan using three custom user > >> objectClasses and one group objectclass. In my attempt, I've setup an > >> openldap server with the proper schemas, imported the ldif and have > >> records that look something like this in ldif format. > >> > >> ----------------------------------------------------------------------- > >> > >> dn: dc=example,dc=com > >> objectClass: top > >> objectClass: domain > >> dc: example > >> > >> dn: ou=Groups,dc=example,dc=com > >> objectClass: top > >> objectClass: organizationalunit > >> ou: Groups > >> > >> dn: ou=People,dc=example,dc=com > >> objectClass: top > >> objectClass: organizationalunit > >> ou: People > >> > >> dn: uid=amyengh,ou=People,dc=example,dc=com > >> objectClass: inetOrgPerson > >> objectClass: posixAccount > >> objectClass: top > >> objectClass: organizationalPerson > >> objectClass: person > >> objectClass: radiusProfile > >> objectClass: sambaSamAccount > >> objectClass: customPersonAttributes > >> cn: Amy Engh > >> gidNumber: 1141801056 > >> homeDirectory: /home/amyengh > >> sn: Engh > >> uid: amyengh > >> uidNumber: 1141801056 > >> displayName: Amy Engh > >> givenName: Amy > >> loginShell: /sbin/nologin > >> mail: amyengh at attask.com > >> userPassword:: REDACTED > >> dialupAccess: yes > >> radiusTunnelMediumType: IEEE-802 > >> radiusTunnelPrivateGroupId: 1421 > >> radiusTunnelType: VLAN > >> emailPassword:: REDACTED > >> sambaAcctFlags: [U ] > >> sambaLMPassword: REDACTED > >> sambaNTPassword: REDACTED > >> sambaPasswordHistory: > >> 000000000000000000000000000000000000000000000000000000 > >> 0000000000 > >> sambaPwdLastSet: 1402698001 > >> sambaSID: S-1-5-21-2332447373-4108748234-3602490535-3146 > >> > >> dn: cn=amyengh,ou=Groups,dc=example,dc=com > >> objectClass: top > >> objectClass: posixGroup > >> cn: amyengh > >> gidNumber: 1141801056 > >> memberUid: amyengh > >> > >> -------------------------------------------------------------------- > >> > >> I then run the migration (with or without compat makes no difference) > >> and get the following: > >> > >> ipa migrate-ds --with-compat --user-container="ou=People" > >> --group-container="ou=Groups" --user-objectclass=posixAccount > >> --group-objectclass=posixgroup ldap://192.168.122.210 > >> --bind-dn="cn=Manager,dc=example,dc=com" > >> Password: > >> ----------- > >> migrate-ds: > >> ----------- > >> Migrated: > >> Failed user: > >> amyengh: Type or value exists: > >> Failed group: > >> amyengh: This entry already exists. > > "type or value exists" and "This entry already exists" are just > > explanations of the ldap return code, do you see anything in the 389 ds > > error logs ? > > I doubt that he would see any errors. > > The entry already existing is because this isn't his first migration, it > is unrelated. > > I'm not able to reproduce this. What version of IPA is it? > > rob > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Oct 15 20:05:14 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 15 Oct 2014 16:05:14 -0400 Subject: [Freeipa-users] Migration fails with custom objectClasses In-Reply-To: References: <543EB51F.2030307@redhat.com> <543EC81D.9000807@redhat.com> Message-ID: <543ED37A.4060706@redhat.com> Clint Savage wrote: > $ rpm -q ipa-server > ipa-server-3.3.3-28.el7.centos.1.x86_64 > > I was thinking that this might be an issue with the rhel7 version. I'm > going to be trying the same migration tonight on rhel6. I know the IPA > version is older, and samba stuff might not work as it does in 3.3. I > haven't looked in RHEL 6.6 yet to see what version of IPA is available. I tested using a fairly recent IPA master build (4.1+). I'm not convinced it is related to any specific version, but different features are available so I thought I'd try to duplicate on a more similar footing (apples to apples comparision). The trick is to try to narrow down what attribute the LDAP server thinks already exists. We don't get a very nice error out of LDAP, like *what* attribute already exists, for example :-( It may be possible to set the 389-ds debug level to such that you get some decent output, but trying to find the right balance of output can be challenging. See their FAQ troubleshooting section. rob > > Clint > > On Wed, Oct 15, 2014 at 1:16 PM, Rob Crittenden > wrote: > > Ludwig Krispenz wrote: > > > > On 10/14/2014 06:58 PM, Clint Savage wrote: > >> Hi all, > >> > >> I've been working on a migration plan using three custom user > >> objectClasses and one group objectclass. In my attempt, I've setup an > >> openldap server with the proper schemas, imported the ldif and have > >> records that look something like this in ldif format. > >> > >> > ----------------------------------------------------------------------- > >> > >> dn: dc=example,dc=com > >> objectClass: top > >> objectClass: domain > >> dc: example > >> > >> dn: ou=Groups,dc=example,dc=com > >> objectClass: top > >> objectClass: organizationalunit > >> ou: Groups > >> > >> dn: ou=People,dc=example,dc=com > >> objectClass: top > >> objectClass: organizationalunit > >> ou: People > >> > >> dn: uid=amyengh,ou=People,dc=example,dc=com > >> objectClass: inetOrgPerson > >> objectClass: posixAccount > >> objectClass: top > >> objectClass: organizationalPerson > >> objectClass: person > >> objectClass: radiusProfile > >> objectClass: sambaSamAccount > >> objectClass: customPersonAttributes > >> cn: Amy Engh > >> gidNumber: 1141801056 > >> homeDirectory: /home/amyengh > >> sn: Engh > >> uid: amyengh > >> uidNumber: 1141801056 > >> displayName: Amy Engh > >> givenName: Amy > >> loginShell: /sbin/nologin > >> mail: amyengh at attask.com > > > >> userPassword:: REDACTED > >> dialupAccess: yes > >> radiusTunnelMediumType: IEEE-802 > >> radiusTunnelPrivateGroupId: 1421 > >> radiusTunnelType: VLAN > >> emailPassword:: REDACTED > >> sambaAcctFlags: [U ] > >> sambaLMPassword: REDACTED > >> sambaNTPassword: REDACTED > >> sambaPasswordHistory: > >> 000000000000000000000000000000000000000000000000000000 > >> 0000000000 > >> sambaPwdLastSet: 1402698001 > >> sambaSID: S-1-5-21-2332447373-4108748234-3602490535-3146 > >> > >> dn: cn=amyengh,ou=Groups,dc=example,dc=com > >> objectClass: top > >> objectClass: posixGroup > >> cn: amyengh > >> gidNumber: 1141801056 > >> memberUid: amyengh > >> > >> -------------------------------------------------------------------- > >> > >> I then run the migration (with or without compat makes no difference) > >> and get the following: > >> > >> ipa migrate-ds --with-compat --user-container="ou=People" > >> --group-container="ou=Groups" --user-objectclass=posixAccount > >> --group-objectclass=posixgroup ldap://192.168.122.210 > > >> --bind-dn="cn=Manager,dc=example,dc=com" > >> Password: > >> ----------- > >> migrate-ds: > >> ----------- > >> Migrated: > >> Failed user: > >> amyengh: Type or value exists: > >> Failed group: > >> amyengh: This entry already exists. > > "type or value exists" and "This entry already exists" are just > > explanations of the ldap return code, do you see anything in the 389 ds > > error logs ? > > I doubt that he would see any errors. > > The entry already existing is because this isn't his first migration, it > is unrelated. > > I'm not able to reproduce this. What version of IPA is it? > > rob > > -- > 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 > > From rmeggins at redhat.com Wed Oct 15 20:33:43 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 15 Oct 2014 14:33:43 -0600 Subject: [Freeipa-users] Migration fails with custom objectClasses In-Reply-To: <543ED37A.4060706@redhat.com> References: <543EB51F.2030307@redhat.com> <543EC81D.9000807@redhat.com> <543ED37A.4060706@redhat.com> Message-ID: <543EDA27.905@redhat.com> On 10/15/2014 02:05 PM, Rob Crittenden wrote: > Clint Savage wrote: >> $ rpm -q ipa-server >> ipa-server-3.3.3-28.el7.centos.1.x86_64 >> >> I was thinking that this might be an issue with the rhel7 version. I'm >> going to be trying the same migration tonight on rhel6. I know the IPA >> version is older, and samba stuff might not work as it does in 3.3. I >> haven't looked in RHEL 6.6 yet to see what version of IPA is available. > I tested using a fairly recent IPA master build (4.1+). I'm not > convinced it is related to any specific version, but different features > are available so I thought I'd try to duplicate on a more similar > footing (apples to apples comparision). > > The trick is to try to narrow down what attribute the LDAP server thinks > already exists. We don't get a very nice error out of LDAP, like *what* > attribute already exists, for example :-( > > It may be possible to set the 389-ds debug level to such that you get > some decent output, but trying to find the right balance of output can > be challenging. See their FAQ troubleshooting section. http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting Try the ARGS (Heavy trace output debugging) level > > rob > > >> Clint >> >> On Wed, Oct 15, 2014 at 1:16 PM, Rob Crittenden > > wrote: >> >> Ludwig Krispenz wrote: >> > >> > On 10/14/2014 06:58 PM, Clint Savage wrote: >> >> Hi all, >> >> >> >> I've been working on a migration plan using three custom user >> >> objectClasses and one group objectclass. In my attempt, I've setup an >> >> openldap server with the proper schemas, imported the ldif and have >> >> records that look something like this in ldif format. >> >> >> >> >> ----------------------------------------------------------------------- >> >> >> >> dn: dc=example,dc=com >> >> objectClass: top >> >> objectClass: domain >> >> dc: example >> >> >> >> dn: ou=Groups,dc=example,dc=com >> >> objectClass: top >> >> objectClass: organizationalunit >> >> ou: Groups >> >> >> >> dn: ou=People,dc=example,dc=com >> >> objectClass: top >> >> objectClass: organizationalunit >> >> ou: People >> >> >> >> dn: uid=amyengh,ou=People,dc=example,dc=com >> >> objectClass: inetOrgPerson >> >> objectClass: posixAccount >> >> objectClass: top >> >> objectClass: organizationalPerson >> >> objectClass: person >> >> objectClass: radiusProfile >> >> objectClass: sambaSamAccount >> >> objectClass: customPersonAttributes >> >> cn: Amy Engh >> >> gidNumber: 1141801056 >> >> homeDirectory: /home/amyengh >> >> sn: Engh >> >> uid: amyengh >> >> uidNumber: 1141801056 >> >> displayName: Amy Engh >> >> givenName: Amy >> >> loginShell: /sbin/nologin >> >> mail: amyengh at attask.com >> > >> >> userPassword:: REDACTED >> >> dialupAccess: yes >> >> radiusTunnelMediumType: IEEE-802 >> >> radiusTunnelPrivateGroupId: 1421 >> >> radiusTunnelType: VLAN >> >> emailPassword:: REDACTED >> >> sambaAcctFlags: [U ] >> >> sambaLMPassword: REDACTED >> >> sambaNTPassword: REDACTED >> >> sambaPasswordHistory: >> >> 000000000000000000000000000000000000000000000000000000 >> >> 0000000000 >> >> sambaPwdLastSet: 1402698001 >> >> sambaSID: S-1-5-21-2332447373-4108748234-3602490535-3146 >> >> >> >> dn: cn=amyengh,ou=Groups,dc=example,dc=com >> >> objectClass: top >> >> objectClass: posixGroup >> >> cn: amyengh >> >> gidNumber: 1141801056 >> >> memberUid: amyengh >> >> >> >> -------------------------------------------------------------------- >> >> >> >> I then run the migration (with or without compat makes no difference) >> >> and get the following: >> >> >> >> ipa migrate-ds --with-compat --user-container="ou=People" >> >> --group-container="ou=Groups" --user-objectclass=posixAccount >> >> --group-objectclass=posixgroup ldap://192.168.122.210 >> >> >> --bind-dn="cn=Manager,dc=example,dc=com" >> >> Password: >> >> ----------- >> >> migrate-ds: >> >> ----------- >> >> Migrated: >> >> Failed user: >> >> amyengh: Type or value exists: >> >> Failed group: >> >> amyengh: This entry already exists. >> > "type or value exists" and "This entry already exists" are just >> > explanations of the ldap return code, do you see anything in the 389 ds >> > error logs ? >> >> I doubt that he would see any errors. >> >> The entry already existing is because this isn't his first migration, it >> is unrelated. >> >> I'm not able to reproduce this. What version of IPA is it? >> >> rob >> >> -- >> 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 >> >> From amurty at deloitte.com Wed Oct 15 22:33:53 2014 From: amurty at deloitte.com (Murty, Ajeet (US - Arlington)) Date: Wed, 15 Oct 2014 22:33:53 +0000 Subject: [Freeipa-users] Replace Self-Signed Cert In-Reply-To: <543D284C.3010608@redhat.com> References: <543C2540.60507@redhat.com> <543C52B0.9030400@redhat.com> <543C59E5.2000202@redhat.com> <543D284C.3010608@redhat.com> Message-ID: <013068C38BB187448B7AB350AE98B35B38D62049@USNDC1453.us.deloitte.com> Thanks for all the info. I think I will wait for the 4.1 update. This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. v.E.1 -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rob Crittenden Sent: Tuesday, October 14, 2014 9:43 AM To: quest monger; dpal at redhat.com Cc: FreeIPA Subject: Re: [Freeipa-users] Replace Self-Signed Cert quest monger wrote: > makes sense. > i will still try out that cert add command in my test environment, just > to see if it works. > looks like for now, 4.1 upgrade is my best option. IPA 3.x includes a command, ipa-server-certinstall, which will do what you need. This can be a bumpy process with clients and such which is why Dmitri suggested using 4.1, but it should still basically work. It depends greatly on whether the CA issuing the certs is already known by clients (for example being a default CA shipped by NSS and openssl). But I'd step cautiously and ask a lot of questions before you proceed. The IPA certificates are not self-signed. They are issued by a CA controlled by IPA. I think your admin's concerns are related to users getting an unknown CA/cert error. It can be confusing and can train users to accept any SSL certificate they see which is bad. There are some downsides to not using the IPA CA: - no automatic renewal of certificates. This means you need to manually monitor your infrastructure and renew the certificates before they expire. Otherwise your identity infrastructure could go down. - for every replica you set up you will need to get a web and ldap certificate in advance rob > > > On Mon, Oct 13, 2014 at 7:01 PM, Dmitri Pal > wrote: > > On 10/13/2014 06:45 PM, quest monger wrote: >> I did the default IPA install, didnt change any certs or anything. >> As part of that install, it now shows 2 certs, one on port 443 >> (HTTPS) and one on port 636 (LDAPS). These certs dont have a trust >> chain, hence i called them self-signed. >> We have a contract with a third party CA that issues TLS certs for >> us. I was asked to find a way to replace those 2 self signed certs >> with certs from this third party CA. >> I was wondering if there was a way i could do that. >> >> I found this >> - http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP >> >> I am currently running 3.0.0. >> >> > > AFAIU the biggest issue will be with the clients. > I suspect that they might be quite confused if you just drop in the > certs from the 3rd party. > If you noticed the page has the following line: > "The certificate in mysite.crt must be signed by the CA used when > installing FreeIPA." I think it should say by "external" CA to be clear. > It is not the case in your situation. If it were the situation the > CA would have been already in trust chain on the clients and > procedure would have worked but I do not think it would work now. > You would need to use the cert chaining tool that was was built in > 4.1 when 4.1 gets released on CentOS. > > > > >> >> On Mon, Oct 13, 2014 at 6:31 PM, Dmitri Pal > > wrote: >> >> On 10/13/2014 03:39 PM, quest monger wrote: >>> I found some documentation for getting certificate signed by >>> external CA (2.3.3.2. Using Different CA Configurations) - >>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/creating-server.html >>> >>> >>> But looks like those instructions apply to a first time fresh >>> install, not for upgrading an existing install. >>> >>> >>> >>> On Mon, Oct 13, 2014 at 3:24 PM, quest monger >>> > wrote: >>> >>> I was told by my admin team that Self-signed certs pose a >>> security risk. >>> >>> >>> On Mon, Oct 13, 2014 at 3:17 PM, Rob Crittenden >>> > wrote: >>> >>> quest monger wrote: >>> > Hello All, >>> > >>> > I installed FreeIPA server on a CentOS host. I have >>> 20+ Linux and >>> > Solaris clients hooked up to it. SSH and Sudo works >>> on all clients. >>> > >>> > I would like to replace the self-signed cert that >>> is used on Port 389 >>> > and 636. >>> > >>> > Is there a way to do this without re-installing the >>> server and clients. >>> >>> Why do you want to do this? >>> >>> rob >>> >>> >>> >>> >>> >> >> Do I get it right that you installed IPA using self-signed >> certificate and now want to change it? >> What version of IPA you have? Did you use self-signed CA-less >> install or using self-signed CA? >> The tools to change the chaining are only being released in >> 4.1 so you might have to move to latest when we release 4.1 >> for CentOS. >> >> >> -- >> 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 From herlo1 at gmail.com Wed Oct 15 22:43:20 2014 From: herlo1 at gmail.com (Clint Savage) Date: Wed, 15 Oct 2014 16:43:20 -0600 Subject: [Freeipa-users] Migration fails with custom objectClasses In-Reply-To: <543EDA27.905@redhat.com> References: <543EB51F.2030307@redhat.com> <543EC81D.9000807@redhat.com> <543ED37A.4060706@redhat.com> <543EDA27.905@redhat.com> Message-ID: On Wed, Oct 15, 2014 at 2:33 PM, Rich Megginson wrote: > On 10/15/2014 02:05 PM, Rob Crittenden wrote: > >> Clint Savage wrote: >> >>> $ rpm -q ipa-server >>> ipa-server-3.3.3-28.el7.centos.1.x86_64 >>> >>> I was thinking that this might be an issue with the rhel7 version. I'm >>> going to be trying the same migration tonight on rhel6. I know the IPA >>> version is older, and samba stuff might not work as it does in 3.3. I >>> haven't looked in RHEL 6.6 yet to see what version of IPA is available. >>> >> I tested using a fairly recent IPA master build (4.1+). I'm not >> convinced it is related to any specific version, but different features >> are available so I thought I'd try to duplicate on a more similar >> footing (apples to apples comparision). >> >> The trick is to try to narrow down what attribute the LDAP server thinks >> already exists. We don't get a very nice error out of LDAP, like *what* >> attribute already exists, for example :-( >> >> It may be possible to set the 389-ds debug level to such that you get >> some decent output, but trying to find the right balance of output can >> be challenging. See their FAQ troubleshooting section. >> > > http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting > > Try the ARGS (Heavy trace output debugging) level > > > >> rob >> >> >> Clint >>> >>> On Wed, Oct 15, 2014 at 1:16 PM, Rob Crittenden >> > wrote: >>> >>> Ludwig Krispenz wrote: >>> > >>> > On 10/14/2014 06:58 PM, Clint Savage wrote: >>> >> Hi all, >>> >> >>> >> I've been working on a migration plan using three custom user >>> >> objectClasses and one group objectclass. In my attempt, I've >>> setup an >>> >> openldap server with the proper schemas, imported the ldif and >>> have >>> >> records that look something like this in ldif format. >>> >> >>> >> >>> ------------------------------------------------------------ >>> ----------- >>> >> >>> >> dn: dc=example,dc=com >>> >> objectClass: top >>> >> objectClass: domain >>> >> dc: example >>> >> >>> >> dn: ou=Groups,dc=example,dc=com >>> >> objectClass: top >>> >> objectClass: organizationalunit >>> >> ou: Groups >>> >> >>> >> dn: ou=People,dc=example,dc=com >>> >> objectClass: top >>> >> objectClass: organizationalunit >>> >> ou: People >>> >> >>> >> dn: uid=amyengh,ou=People,dc=example,dc=com >>> >> objectClass: inetOrgPerson >>> >> objectClass: posixAccount >>> >> objectClass: top >>> >> objectClass: organizationalPerson >>> >> objectClass: person >>> >> objectClass: radiusProfile >>> >> objectClass: sambaSamAccount >>> >> objectClass: customPersonAttributes >>> >> cn: Amy Engh >>> >> gidNumber: 1141801056 >>> >> homeDirectory: /home/amyengh >>> >> sn: Engh >>> >> uid: amyengh >>> >> uidNumber: 1141801056 >>> >> displayName: Amy Engh >>> >> givenName: Amy >>> >> loginShell: /sbin/nologin >>> >> mail: amyengh at attask.com >>> > >>> >> userPassword:: REDACTED >>> >> dialupAccess: yes >>> >> radiusTunnelMediumType: IEEE-802 >>> >> radiusTunnelPrivateGroupId: 1421 >>> >> radiusTunnelType: VLAN >>> >> emailPassword:: REDACTED >>> >> sambaAcctFlags: [U ] >>> >> sambaLMPassword: REDACTED >>> >> sambaNTPassword: REDACTED >>> >> sambaPasswordHistory: >>> >> 000000000000000000000000000000000000000000000000000000 >>> >> 0000000000 >>> >> sambaPwdLastSet: 1402698001 >>> >> sambaSID: S-1-5-21-2332447373-4108748234-3602490535-3146 >>> >> >>> >> dn: cn=amyengh,ou=Groups,dc=example,dc=com >>> >> objectClass: top >>> >> objectClass: posixGroup >>> >> cn: amyengh >>> >> gidNumber: 1141801056 >>> >> memberUid: amyengh >>> >> >>> >> ------------------------------------------------------------ >>> -------- >>> >> >>> >> I then run the migration (with or without compat makes no >>> difference) >>> >> and get the following: >>> >> >>> >> ipa migrate-ds --with-compat --user-container="ou=People" >>> >> --group-container="ou=Groups" --user-objectclass=posixAccount >>> >> --group-objectclass=posixgroup ldap://192.168.122.210 >>> >>> >> --bind-dn="cn=Manager,dc= >>> example,dc=com" >>> >> Password: >>> >> ----------- >>> >> migrate-ds: >>> >> ----------- >>> >> Migrated: >>> >> Failed user: >>> >> amyengh: Type or value exists: >>> >> Failed group: >>> >> amyengh: This entry already exists. >>> > "type or value exists" and "This entry already exists" are just >>> > explanations of the ldap return code, do you see anything in the >>> 389 ds >>> > error logs ? >>> >>> I doubt that he would see any errors. >>> >>> The entry already existing is because this isn't his first >>> migration, it >>> is unrelated. >>> >>> I'm not able to reproduce this. What version of IPA is it? >>> >>> rob >>> >>> -- >>> 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 > This is what I get in the logs when running the migration: ==> access <== [15/Oct/2014:18:35:46 -0400] conn=8 op=166 SRCH base="idnsName=_tcp,idnsname=example.com,cn=dns,dc=example,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL [15/Oct/2014:18:35:46 -0400] conn=8 op=166 RESULT err=32 tag=101 nentries=0 etime=0 [15/Oct/2014:18:35:48 -0400] conn=606 fd=79 slot=79 connection from 192.168.122.200 to 192.168.122.200 [15/Oct/2014:18:35:48 -0400] conn=4 op=960 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=krbtgt/ EXAMPLE.COM at EXAMPLE.COM))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [15/Oct/2014:18:35:48 -0400] conn=4 op=960 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2014:18:35:48 -0400] conn=4 op=961 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ldap/ ipa7.example.com at EXAMPLE.COM)(krbPrincipalName=ldap/ ipa7.example.com at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [15/Oct/2014:18:35:48 -0400] conn=4 op=961 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2014:18:35:48 -0400] conn=4 op=962 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [15/Oct/2014:18:35:48 -0400] conn=4 op=962 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2014:18:35:48 -0400] conn=4 op=963 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=HTTP/ ipa7.example.com at EXAMPLE.COM))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [15/Oct/2014:18:35:48 -0400] conn=4 op=963 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2014:18:35:48 -0400] conn=4 op=964 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [15/Oct/2014:18:35:48 -0400] conn=4 op=964 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2014:18:35:48 -0400] conn=4 op=965 SRCH base="dc=example,dc=com" scope=2 filter="(&(objectClass=ipaKrb5DelegationACL)(memberPrincipal=HTTP/ ipa7.example.com at EXAMPLE.COM))" attrs="objectClass memberPrincipal" [15/Oct/2014:18:35:48 -0400] conn=4 op=965 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2014:18:35:48 -0400] conn=4 op=966 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName= admin at EXAMPLE.COM))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [15/Oct/2014:18:35:48 -0400] conn=4 op=966 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2014:18:35:48 -0400] conn=4 op=967 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [15/Oct/2014:18:35:48 -0400] conn=4 op=967 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2014:18:35:48 -0400] conn=606 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [15/Oct/2014:18:35:48 -0400] conn=606 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [15/Oct/2014:18:35:48 -0400] conn=606 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [15/Oct/2014:18:35:48 -0400] conn=606 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [15/Oct/2014:18:35:48 -0400] conn=606 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [15/Oct/2014:18:35:48 -0400] conn=606 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com" [15/Oct/2014:18:35:48 -0400] conn=606 op=3 SRCH base="cn=ipaconfig,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [15/Oct/2014:18:35:48 -0400] conn=606 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2014:18:35:48 -0400] conn=606 op=4 SRCH base="cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="gidNumber cn" [15/Oct/2014:18:35:48 -0400] conn=606 op=4 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2014:18:35:48 -0400] conn=606 op=5 SRCH base="cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="* aci" [15/Oct/2014:18:35:48 -0400] conn=606 op=5 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2014:18:35:48 -0400] conn=606 op=6 SRCH base="cn=ipaconfig,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [15/Oct/2014:18:35:48 -0400] conn=606 op=6 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2014:18:35:48 -0400] conn=606 op=7 SRCH base="cn=users,cn=accounts,dc=example,dc=com" scope=2 filter="(&(objectClass=krbprincipalaux)(krbPrincipalName=amyengh at EXAMPLE.COM))" attrs="" [15/Oct/2014:18:35:48 -0400] conn=606 op=7 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2014:18:35:48 -0400] conn=606 op=8 ADD dn="uid=amyengh,cn=users,cn=accounts,dc=example,dc=com", add values for type objectClass failed [15/Oct/2014:18:35:48 -0400] conn=606 op=8 RESULT err=20 tag=105 nentries=0 etime=0 [15/Oct/2014:18:35:48 -0400] conn=606 op=9 SRCH base="cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="gidNumber cn" [15/Oct/2014:18:35:48 -0400] conn=606 op=9 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2014:18:35:48 -0400] conn=606 op=10 SRCH base="cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="* aci" [15/Oct/2014:18:35:48 -0400] conn=606 op=10 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2014:18:35:48 -0400] conn=606 op=11 ADD dn="cn=amyengh,cn=groups,cn=accounts,dc=example,dc=com" [15/Oct/2014:18:35:48 -0400] conn=606 op=11 RESULT err=68 tag=105 nentries=0 etime=0 [15/Oct/2014:18:35:48 -0400] conn=606 op=12 SRCH base="cn=users,cn=accounts,dc=example,dc=com" scope=2 filter="(&(objectClass=posixAccount)(!(memberOf=cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com)))" attrs="" [15/Oct/2014:18:35:48 -0400] conn=606 op=12 RESULT err=0 tag=101 nentries=0 etime=0 [15/Oct/2014:18:35:48 -0400] conn=606 op=13 UNBIND [15/Oct/2014:18:35:48 -0400] conn=606 op=13 fd=79 closed - U1 It kind of looks like there's some sort of failure with my gidNumber or cn, but both the user and group objects have these values. Any idea what is going on there? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Oct 15 22:46:56 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 15 Oct 2014 18:46:56 -0400 Subject: [Freeipa-users] Migration fails with custom objectClasses In-Reply-To: References: <543EB51F.2030307@redhat.com> <543EC81D.9000807@redhat.com> <543ED37A.4060706@redhat.com> <543EDA27.905@redhat.com> Message-ID: <543EF960.4040102@redhat.com> On 10/15/2014 06:43 PM, Clint Savage wrote: > On Wed, Oct 15, 2014 at 2:33 PM, Rich Megginson > wrote: > > On 10/15/2014 02:05 PM, Rob Crittenden wrote: > > Clint Savage wrote: > > $ rpm -q ipa-server > ipa-server-3.3.3-28.el7.centos.1.x86_64 > > I was thinking that this might be an issue with the rhel7 > version. I'm > going to be trying the same migration tonight on rhel6. I > know the IPA > version is older, and samba stuff might not work as it > does in 3.3. I > haven't looked in RHEL 6.6 yet to see what version of IPA > is available. > > I tested using a fairly recent IPA master build (4.1+). I'm not > convinced it is related to any specific version, but different > features > are available so I thought I'd try to duplicate on a more similar > footing (apples to apples comparision). > > The trick is to try to narrow down what attribute the LDAP > server thinks > already exists. We don't get a very nice error out of LDAP, > like *what* > attribute already exists, for example :-( > > It may be possible to set the 389-ds debug level to such that > you get > some decent output, but trying to find the right balance of > output can > be challenging. See their FAQ troubleshooting section. > > > http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting > > Try the ARGS (Heavy trace output debugging) level > > > > rob > > > Clint > > On Wed, Oct 15, 2014 at 1:16 PM, Rob Crittenden > > >> > wrote: > > Ludwig Krispenz wrote: > > > > On 10/14/2014 06:58 PM, Clint Savage wrote: > >> Hi all, > >> > >> I've been working on a migration plan using three > custom user > >> objectClasses and one group objectclass. In my > attempt, I've setup an > >> openldap server with the proper schemas, imported > the ldif and have > >> records that look something like this in ldif format. > >> > >> > > ----------------------------------------------------------------------- > >> > >> dn: dc=example,dc=com > >> objectClass: top > >> objectClass: domain > >> dc: example > >> > >> dn: ou=Groups,dc=example,dc=com > >> objectClass: top > >> objectClass: organizationalunit > >> ou: Groups > >> > >> dn: ou=People,dc=example,dc=com > >> objectClass: top > >> objectClass: organizationalunit > >> ou: People > >> > >> dn: uid=amyengh,ou=People,dc=example,dc=com > >> objectClass: inetOrgPerson > >> objectClass: posixAccount > >> objectClass: top > >> objectClass: organizationalPerson > >> objectClass: person > >> objectClass: radiusProfile > >> objectClass: sambaSamAccount > >> objectClass: customPersonAttributes > >> cn: Amy Engh > >> gidNumber: 1141801056 > >> homeDirectory: /home/amyengh > >> sn: Engh > >> uid: amyengh > >> uidNumber: 1141801056 > >> displayName: Amy Engh > >> givenName: Amy > >> loginShell: /sbin/nologin > >> mail: amyengh at attask.com > > > >> > >> userPassword:: REDACTED > >> dialupAccess: yes > >> radiusTunnelMediumType: IEEE-802 > >> radiusTunnelPrivateGroupId: 1421 > >> radiusTunnelType: VLAN > >> emailPassword:: REDACTED > >> sambaAcctFlags: [U ] > >> sambaLMPassword: REDACTED > >> sambaNTPassword: REDACTED > >> sambaPasswordHistory: > >> 000000000000000000000000000000000000000000000000000000 > >> 0000000000 > >> sambaPwdLastSet: 1402698001 > >> sambaSID: > S-1-5-21-2332447373-4108748234-3602490535-3146 > >> > >> dn: cn=amyengh,ou=Groups,dc=example,dc=com > >> objectClass: top > >> objectClass: posixGroup > >> cn: amyengh > >> gidNumber: 1141801056 > >> memberUid: amyengh > >> > >> > -------------------------------------------------------------------- > >> > >> I then run the migration (with or without compat > makes no difference) > >> and get the following: > >> > >> ipa migrate-ds --with-compat > --user-container="ou=People" > >> --group-container="ou=Groups" > --user-objectclass=posixAccount > >> --group-objectclass=posixgroup > ldap://192.168.122.210 > > >> > --bind-dn="cn=Manager,dc=example,dc=com" > >> Password: > >> ----------- > >> migrate-ds: > >> ----------- > >> Migrated: > >> Failed user: > >> amyengh: Type or value exists: > >> Failed group: > >> amyengh: This entry already exists. > > "type or value exists" and "This entry already > exists" are just > > explanations of the ldap return code, do you see > anything in the 389 ds > > error logs ? > > I doubt that he would see any errors. > > The entry already existing is because this isn't his > first migration, it > is unrelated. > > I'm not able to reproduce this. What version of IPA > is it? > > rob > > -- > 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 > > > This is what I get in the logs when running the migration: > > ==> access <== > [15/Oct/2014:18:35:46 -0400] conn=8 op=166 SRCH > base="idnsName=_tcp,idnsname=example.com > ,cn=dns,dc=example,dc=com" scope=0 > filter="(objectClass=idnsRecord)" attrs=ALL > [15/Oct/2014:18:35:46 -0400] conn=8 op=166 RESULT err=32 tag=101 > nentries=0 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 fd=79 slot=79 connection from > 192.168.122.200 to 192.168.122.200 > [15/Oct/2014:18:35:48 -0400] conn=4 op=960 SRCH > base="dc=example,dc=com" scope=2 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=krbtgt/EXAMPLE.COM at EXAMPLE.COM > ))" attrs="krbPrincipalName > krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey > krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration > krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange > krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth > krbLoginFailedCount krbExtraData krbLastAdminUnlock > krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge > nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] conn=4 op=960 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=961 SRCH > base="dc=example,dc=com" scope=2 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ldap/ipa7.example.com at EXAMPLE.COM > )(krbPrincipalName=ldap/ipa7.example.com at EXAMPLE.COM > )))" attrs="krbPrincipalName > krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey > krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration > krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange > krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth > krbLoginFailedCount krbExtraData krbLastAdminUnlock > krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge > nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] conn=4 op=961 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=962 SRCH base="cn=EXAMPLE.COM > ,cn=kerberos,dc=example,dc=com" scope=0 > filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife > krbMaxRenewableAge krbTicketFlags" > [15/Oct/2014:18:35:48 -0400] conn=4 op=962 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=963 SRCH > base="dc=example,dc=com" scope=2 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=HTTP/ipa7.example.com at EXAMPLE.COM > ))" attrs="krbPrincipalName > krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey > krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration > krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange > krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth > krbLoginFailedCount krbExtraData krbLastAdminUnlock > krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge > nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] conn=4 op=963 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=964 SRCH base="cn=EXAMPLE.COM > ,cn=kerberos,dc=example,dc=com" scope=0 > filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife > krbMaxRenewableAge krbTicketFlags" > [15/Oct/2014:18:35:48 -0400] conn=4 op=964 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=965 SRCH > base="dc=example,dc=com" scope=2 > filter="(&(objectClass=ipaKrb5DelegationACL)(memberPrincipal=HTTP/ipa7.example.com at EXAMPLE.COM > ))" attrs="objectClass > memberPrincipal" > [15/Oct/2014:18:35:48 -0400] conn=4 op=965 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=966 SRCH > base="dc=example,dc=com" scope=2 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=admin at EXAMPLE.COM > ))" attrs="krbPrincipalName krbCanonicalName > ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey > krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration > krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange > krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth > krbLoginFailedCount krbExtraData krbLastAdminUnlock > krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge > nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] conn=4 op=966 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=967 SRCH base="cn=EXAMPLE.COM > ,cn=kerberos,dc=example,dc=com" scope=0 > filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife > krbMaxRenewableAge krbTicketFlags" > [15/Oct/2014:18:35:48 -0400] conn=4 op=967 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=0 BIND dn="" method=sasl > version=3 mech=GSSAPI > [15/Oct/2014:18:35:48 -0400] conn=606 op=0 RESULT err=14 tag=97 > nentries=0 etime=0, SASL bind in progress > [15/Oct/2014:18:35:48 -0400] conn=606 op=1 BIND dn="" method=sasl > version=3 mech=GSSAPI > [15/Oct/2014:18:35:48 -0400] conn=606 op=1 RESULT err=14 tag=97 > nentries=0 etime=0, SASL bind in progress > [15/Oct/2014:18:35:48 -0400] conn=606 op=2 BIND dn="" method=sasl > version=3 mech=GSSAPI > [15/Oct/2014:18:35:48 -0400] conn=606 op=2 RESULT err=0 tag=97 > nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com" > [15/Oct/2014:18:35:48 -0400] conn=606 op=3 SRCH > base="cn=ipaconfig,cn=etc,dc=example,dc=com" scope=0 > filter="(objectClass=*)" attrs=ALL > [15/Oct/2014:18:35:48 -0400] conn=606 op=3 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=4 SRCH > base="cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com" scope=0 > filter="(objectClass=*)" attrs="gidNumber cn" > [15/Oct/2014:18:35:48 -0400] conn=606 op=4 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=5 SRCH base="cn=UPG > Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc=example,dc=com" > scope=0 filter="(objectClass=*)" attrs="* aci" > [15/Oct/2014:18:35:48 -0400] conn=606 op=5 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=6 SRCH > base="cn=ipaconfig,cn=etc,dc=example,dc=com" scope=0 > filter="(objectClass=*)" attrs=ALL > [15/Oct/2014:18:35:48 -0400] conn=606 op=6 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=7 SRCH > base="cn=users,cn=accounts,dc=example,dc=com" scope=2 > filter="(&(objectClass=krbprincipalaux)(krbPrincipalName=amyengh at EXAMPLE.COM > ))" attrs="" > [15/Oct/2014:18:35:48 -0400] conn=606 op=7 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=8 ADD > dn="uid=amyengh,cn=users,cn=accounts,dc=example,dc=com", add values > for type objectClass failed > [15/Oct/2014:18:35:48 -0400] conn=606 op=8 RESULT err=20 tag=105 > nentries=0 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=9 SRCH > base="cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com" scope=0 > filter="(objectClass=*)" attrs="gidNumber cn" > [15/Oct/2014:18:35:48 -0400] conn=606 op=9 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=10 SRCH base="cn=UPG > Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc=example,dc=com" > scope=0 filter="(objectClass=*)" attrs="* aci" > [15/Oct/2014:18:35:48 -0400] conn=606 op=10 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=11 ADD > dn="cn=amyengh,cn=groups,cn=accounts,dc=example,dc=com" > [15/Oct/2014:18:35:48 -0400] conn=606 op=11 RESULT err=68 tag=105 > nentries=0 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=12 SRCH > base="cn=users,cn=accounts,dc=example,dc=com" scope=2 > filter="(&(objectClass=posixAccount)(!(memberOf=cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com)))" > attrs="" > [15/Oct/2014:18:35:48 -0400] conn=606 op=12 RESULT err=0 tag=101 > nentries=0 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=13 UNBIND > [15/Oct/2014:18:35:48 -0400] conn=606 op=13 fd=79 closed - U1 > > It kind of looks like there's some sort of failure with my gidNumber > or cn, but both the user and group objects have these values. Any idea > what is going on there? > > Do you have a group GID that is also a UID? IPA automatically creates private groups that have GID same as UID of the user. But this means that if you have an explicit group with the same GID it will collide. Just a thought. I have not actually inspected the log above. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Oct 15 23:04:24 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 15 Oct 2014 17:04:24 -0600 Subject: [Freeipa-users] Migration fails with custom objectClasses In-Reply-To: References: <543EB51F.2030307@redhat.com> <543EC81D.9000807@redhat.com> <543ED37A.4060706@redhat.com> <543EDA27.905@redhat.com> Message-ID: <543EFD78.9060004@redhat.com> On 10/15/2014 04:43 PM, Clint Savage wrote: > On Wed, Oct 15, 2014 at 2:33 PM, Rich Megginson > wrote: > > On 10/15/2014 02:05 PM, Rob Crittenden wrote: > > Clint Savage wrote: > > $ rpm -q ipa-server > ipa-server-3.3.3-28.el7.centos.1.x86_64 > > I was thinking that this might be an issue with the rhel7 > version. I'm > going to be trying the same migration tonight on rhel6. I > know the IPA > version is older, and samba stuff might not work as it > does in 3.3. I > haven't looked in RHEL 6.6 yet to see what version of IPA > is available. > > I tested using a fairly recent IPA master build (4.1+). I'm not > convinced it is related to any specific version, but different > features > are available so I thought I'd try to duplicate on a more similar > footing (apples to apples comparision). > > The trick is to try to narrow down what attribute the LDAP > server thinks > already exists. We don't get a very nice error out of LDAP, > like *what* > attribute already exists, for example :-( > > It may be possible to set the 389-ds debug level to such that > you get > some decent output, but trying to find the right balance of > output can > be challenging. See their FAQ troubleshooting section. > > > http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting > > Try the ARGS (Heavy trace output debugging) level > > > > rob > > > Clint > > On Wed, Oct 15, 2014 at 1:16 PM, Rob Crittenden > > >> > wrote: > > Ludwig Krispenz wrote: > > > > On 10/14/2014 06:58 PM, Clint Savage wrote: > >> Hi all, > >> > >> I've been working on a migration plan using three > custom user > >> objectClasses and one group objectclass. In my > attempt, I've setup an > >> openldap server with the proper schemas, imported > the ldif and have > >> records that look something like this in ldif format. > >> > >> > > ----------------------------------------------------------------------- > >> > >> dn: dc=example,dc=com > >> objectClass: top > >> objectClass: domain > >> dc: example > >> > >> dn: ou=Groups,dc=example,dc=com > >> objectClass: top > >> objectClass: organizationalunit > >> ou: Groups > >> > >> dn: ou=People,dc=example,dc=com > >> objectClass: top > >> objectClass: organizationalunit > >> ou: People > >> > >> dn: uid=amyengh,ou=People,dc=example,dc=com > >> objectClass: inetOrgPerson > >> objectClass: posixAccount > >> objectClass: top > >> objectClass: organizationalPerson > >> objectClass: person > >> objectClass: radiusProfile > >> objectClass: sambaSamAccount > >> objectClass: customPersonAttributes > >> cn: Amy Engh > >> gidNumber: 1141801056 > >> homeDirectory: /home/amyengh > >> sn: Engh > >> uid: amyengh > >> uidNumber: 1141801056 > >> displayName: Amy Engh > >> givenName: Amy > >> loginShell: /sbin/nologin > >> mail: amyengh at attask.com > > > >> > >> userPassword:: REDACTED > >> dialupAccess: yes > >> radiusTunnelMediumType: IEEE-802 > >> radiusTunnelPrivateGroupId: 1421 > >> radiusTunnelType: VLAN > >> emailPassword:: REDACTED > >> sambaAcctFlags: [U ] > >> sambaLMPassword: REDACTED > >> sambaNTPassword: REDACTED > >> sambaPasswordHistory: > >> 000000000000000000000000000000000000000000000000000000 > >> 0000000000 > >> sambaPwdLastSet: 1402698001 > >> sambaSID: > S-1-5-21-2332447373-4108748234-3602490535-3146 > >> > >> dn: cn=amyengh,ou=Groups,dc=example,dc=com > >> objectClass: top > >> objectClass: posixGroup > >> cn: amyengh > >> gidNumber: 1141801056 > >> memberUid: amyengh > >> > >> > -------------------------------------------------------------------- > >> > >> I then run the migration (with or without compat > makes no difference) > >> and get the following: > >> > >> ipa migrate-ds --with-compat > --user-container="ou=People" > >> --group-container="ou=Groups" > --user-objectclass=posixAccount > >> --group-objectclass=posixgroup > ldap://192.168.122.210 > > >> > --bind-dn="cn=Manager,dc=example,dc=com" > >> Password: > >> ----------- > >> migrate-ds: > >> ----------- > >> Migrated: > >> Failed user: > >> amyengh: Type or value exists: > >> Failed group: > >> amyengh: This entry already exists. > > "type or value exists" and "This entry already > exists" are just > > explanations of the ldap return code, do you see > anything in the 389 ds > > error logs ? > > I doubt that he would see any errors. > > The entry already existing is because this isn't his > first migration, it > is unrelated. > > I'm not able to reproduce this. What version of IPA > is it? > > rob > > -- > 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 > > > This is what I get in the logs when running the migration: > > ==> access <== > [15/Oct/2014:18:35:46 -0400] conn=8 op=166 SRCH > base="idnsName=_tcp,idnsname=example.com > ,cn=dns,dc=example,dc=com" scope=0 > filter="(objectClass=idnsRecord)" attrs=ALL > [15/Oct/2014:18:35:46 -0400] conn=8 op=166 RESULT err=32 tag=101 > nentries=0 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 fd=79 slot=79 connection from > 192.168.122.200 to 192.168.122.200 > [15/Oct/2014:18:35:48 -0400] conn=4 op=960 SRCH > base="dc=example,dc=com" scope=2 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=krbtgt/EXAMPLE.COM at EXAMPLE.COM > ))" attrs="krbPrincipalName > krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey > krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration > krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange > krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth > krbLoginFailedCount krbExtraData krbLastAdminUnlock > krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge > nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] conn=4 op=960 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=961 SRCH > base="dc=example,dc=com" scope=2 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ldap/ipa7.example.com at EXAMPLE.COM > )(krbPrincipalName=ldap/ipa7.example.com at EXAMPLE.COM > )))" attrs="krbPrincipalName > krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey > krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration > krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange > krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth > krbLoginFailedCount krbExtraData krbLastAdminUnlock > krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge > nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] conn=4 op=961 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=962 SRCH base="cn=EXAMPLE.COM > ,cn=kerberos,dc=example,dc=com" scope=0 > filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife > krbMaxRenewableAge krbTicketFlags" > [15/Oct/2014:18:35:48 -0400] conn=4 op=962 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=963 SRCH > base="dc=example,dc=com" scope=2 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=HTTP/ipa7.example.com at EXAMPLE.COM > ))" attrs="krbPrincipalName > krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey > krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration > krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange > krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth > krbLoginFailedCount krbExtraData krbLastAdminUnlock > krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge > nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] conn=4 op=963 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=964 SRCH base="cn=EXAMPLE.COM > ,cn=kerberos,dc=example,dc=com" scope=0 > filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife > krbMaxRenewableAge krbTicketFlags" > [15/Oct/2014:18:35:48 -0400] conn=4 op=964 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=965 SRCH > base="dc=example,dc=com" scope=2 > filter="(&(objectClass=ipaKrb5DelegationACL)(memberPrincipal=HTTP/ipa7.example.com at EXAMPLE.COM > ))" attrs="objectClass > memberPrincipal" > [15/Oct/2014:18:35:48 -0400] conn=4 op=965 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=966 SRCH > base="dc=example,dc=com" scope=2 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=admin at EXAMPLE.COM > ))" attrs="krbPrincipalName krbCanonicalName > ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey > krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration > krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange > krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth > krbLoginFailedCount krbExtraData krbLastAdminUnlock > krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge > nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] conn=4 op=966 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=967 SRCH base="cn=EXAMPLE.COM > ,cn=kerberos,dc=example,dc=com" scope=0 > filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife > krbMaxRenewableAge krbTicketFlags" > [15/Oct/2014:18:35:48 -0400] conn=4 op=967 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=0 BIND dn="" method=sasl > version=3 mech=GSSAPI > [15/Oct/2014:18:35:48 -0400] conn=606 op=0 RESULT err=14 tag=97 > nentries=0 etime=0, SASL bind in progress > [15/Oct/2014:18:35:48 -0400] conn=606 op=1 BIND dn="" method=sasl > version=3 mech=GSSAPI > [15/Oct/2014:18:35:48 -0400] conn=606 op=1 RESULT err=14 tag=97 > nentries=0 etime=0, SASL bind in progress > [15/Oct/2014:18:35:48 -0400] conn=606 op=2 BIND dn="" method=sasl > version=3 mech=GSSAPI > [15/Oct/2014:18:35:48 -0400] conn=606 op=2 RESULT err=0 tag=97 > nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com" > [15/Oct/2014:18:35:48 -0400] conn=606 op=3 SRCH > base="cn=ipaconfig,cn=etc,dc=example,dc=com" scope=0 > filter="(objectClass=*)" attrs=ALL > [15/Oct/2014:18:35:48 -0400] conn=606 op=3 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=4 SRCH > base="cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com" scope=0 > filter="(objectClass=*)" attrs="gidNumber cn" > [15/Oct/2014:18:35:48 -0400] conn=606 op=4 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=5 SRCH base="cn=UPG > Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc=example,dc=com" > scope=0 filter="(objectClass=*)" attrs="* aci" > [15/Oct/2014:18:35:48 -0400] conn=606 op=5 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=6 SRCH > base="cn=ipaconfig,cn=etc,dc=example,dc=com" scope=0 > filter="(objectClass=*)" attrs=ALL > [15/Oct/2014:18:35:48 -0400] conn=606 op=6 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=7 SRCH > base="cn=users,cn=accounts,dc=example,dc=com" scope=2 > filter="(&(objectClass=krbprincipalaux)(krbPrincipalName=amyengh at EXAMPLE.COM > ))" attrs="" > [15/Oct/2014:18:35:48 -0400] conn=606 op=7 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=8 ADD > dn="uid=amyengh,cn=users,cn=accounts,dc=example,dc=com", add values > for type objectClass failed > [15/Oct/2014:18:35:48 -0400] conn=606 op=8 RESULT err=20 tag=105 > nentries=0 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=9 SRCH > base="cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com" scope=0 > filter="(objectClass=*)" attrs="gidNumber cn" > [15/Oct/2014:18:35:48 -0400] conn=606 op=9 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=10 SRCH base="cn=UPG > Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc=example,dc=com" > scope=0 filter="(objectClass=*)" attrs="* aci" > [15/Oct/2014:18:35:48 -0400] conn=606 op=10 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=11 ADD > dn="cn=amyengh,cn=groups,cn=accounts,dc=example,dc=com" > [15/Oct/2014:18:35:48 -0400] conn=606 op=11 RESULT err=68 tag=105 > nentries=0 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=12 SRCH > base="cn=users,cn=accounts,dc=example,dc=com" scope=2 > filter="(&(objectClass=posixAccount)(!(memberOf=cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com)))" > attrs="" > [15/Oct/2014:18:35:48 -0400] conn=606 op=12 RESULT err=0 tag=101 > nentries=0 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=13 UNBIND > [15/Oct/2014:18:35:48 -0400] conn=606 op=13 fd=79 closed - U1 > > It kind of looks like there's some sort of failure with my gidNumber > or cn, but both the user and group objects have these values. Any idea > what is going on there? Did you enable the ARGS level error logging in the errors log? If so, what's in the errors log? -------------- next part -------------- An HTML attachment was scrubbed... URL: From herlo1 at gmail.com Wed Oct 15 23:29:56 2014 From: herlo1 at gmail.com (Clint Savage) Date: Wed, 15 Oct 2014 17:29:56 -0600 Subject: [Freeipa-users] Migration fails with custom objectClasses In-Reply-To: <543EFD78.9060004@redhat.com> References: <543EB51F.2030307@redhat.com> <543EC81D.9000807@redhat.com> <543ED37A.4060706@redhat.com> <543EDA27.905@redhat.com> <543EFD78.9060004@redhat.com> Message-ID: On Wed, Oct 15, 2014 at 5:04 PM, Rich Megginson wrote: > On 10/15/2014 04:43 PM, Clint Savage wrote: > > On Wed, Oct 15, 2014 at 2:33 PM, Rich Megginson > wrote: > >> On 10/15/2014 02:05 PM, Rob Crittenden wrote: >> >>> Clint Savage wrote: >>> >>>> $ rpm -q ipa-server >>>> ipa-server-3.3.3-28.el7.centos.1.x86_64 >>>> >>>> I was thinking that this might be an issue with the rhel7 version. I'm >>>> going to be trying the same migration tonight on rhel6. I know the IPA >>>> version is older, and samba stuff might not work as it does in 3.3. I >>>> haven't looked in RHEL 6.6 yet to see what version of IPA is available. >>>> >>> I tested using a fairly recent IPA master build (4.1+). I'm not >>> convinced it is related to any specific version, but different features >>> are available so I thought I'd try to duplicate on a more similar >>> footing (apples to apples comparision). >>> >>> The trick is to try to narrow down what attribute the LDAP server thinks >>> already exists. We don't get a very nice error out of LDAP, like *what* >>> attribute already exists, for example :-( >>> >>> It may be possible to set the 389-ds debug level to such that you get >>> some decent output, but trying to find the right balance of output can >>> be challenging. See their FAQ troubleshooting section. >>> >> >> http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting >> >> Try the ARGS (Heavy trace output debugging) level >> >> >> >>> rob >>> >>> >>> Clint >>>> >>>> On Wed, Oct 15, 2014 at 1:16 PM, Rob Crittenden >>> > wrote: >>>> >>>> Ludwig Krispenz wrote: >>>> > >>>> > On 10/14/2014 06:58 PM, Clint Savage wrote: >>>> >> Hi all, >>>> >> >>>> >> I've been working on a migration plan using three custom user >>>> >> objectClasses and one group objectclass. In my attempt, I've >>>> setup an >>>> >> openldap server with the proper schemas, imported the ldif and >>>> have >>>> >> records that look something like this in ldif format. >>>> >> >>>> >> >>>> >>>> ----------------------------------------------------------------------- >>>> >> >>>> >> dn: dc=example,dc=com >>>> >> objectClass: top >>>> >> objectClass: domain >>>> >> dc: example >>>> >> >>>> >> dn: ou=Groups,dc=example,dc=com >>>> >> objectClass: top >>>> >> objectClass: organizationalunit >>>> >> ou: Groups >>>> >> >>>> >> dn: ou=People,dc=example,dc=com >>>> >> objectClass: top >>>> >> objectClass: organizationalunit >>>> >> ou: People >>>> >> >>>> >> dn: uid=amyengh,ou=People,dc=example,dc=com >>>> >> objectClass: inetOrgPerson >>>> >> objectClass: posixAccount >>>> >> objectClass: top >>>> >> objectClass: organizationalPerson >>>> >> objectClass: person >>>> >> objectClass: radiusProfile >>>> >> objectClass: sambaSamAccount >>>> >> objectClass: customPersonAttributes >>>> >> cn: Amy Engh >>>> >> gidNumber: 1141801056 >>>> >> homeDirectory: /home/amyengh >>>> >> sn: Engh >>>> >> uid: amyengh >>>> >> uidNumber: 1141801056 >>>> >> displayName: Amy Engh >>>> >> givenName: Amy >>>> >> loginShell: /sbin/nologin >>>> >> mail: amyengh at attask.com >>>> > >>>> >> userPassword:: REDACTED >>>> >> dialupAccess: yes >>>> >> radiusTunnelMediumType: IEEE-802 >>>> >> radiusTunnelPrivateGroupId: 1421 >>>> >> radiusTunnelType: VLAN >>>> >> emailPassword:: REDACTED >>>> >> sambaAcctFlags: [U ] >>>> >> sambaLMPassword: REDACTED >>>> >> sambaNTPassword: REDACTED >>>> >> sambaPasswordHistory: >>>> >> 000000000000000000000000000000000000000000000000000000 >>>> >> 0000000000 >>>> >> sambaPwdLastSet: 1402698001 >>>> >> sambaSID: S-1-5-21-2332447373-4108748234-3602490535-3146 >>>> >> >>>> >> dn: cn=amyengh,ou=Groups,dc=example,dc=com >>>> >> objectClass: top >>>> >> objectClass: posixGroup >>>> >> cn: amyengh >>>> >> gidNumber: 1141801056 >>>> >> memberUid: amyengh >>>> >> >>>> >> >>>> -------------------------------------------------------------------- >>>> >> >>>> >> I then run the migration (with or without compat makes no >>>> difference) >>>> >> and get the following: >>>> >> >>>> >> ipa migrate-ds --with-compat --user-container="ou=People" >>>> >> --group-container="ou=Groups" --user-objectclass=posixAccount >>>> >> --group-objectclass=posixgroup ldap://192.168.122.210 >>>> >>>> >> >>>> --bind-dn="cn=Manager,dc=example,dc=com" >>>> >> Password: >>>> >> ----------- >>>> >> migrate-ds: >>>> >> ----------- >>>> >> Migrated: >>>> >> Failed user: >>>> >> amyengh: Type or value exists: >>>> >> Failed group: >>>> >> amyengh: This entry already exists. >>>> > "type or value exists" and "This entry already exists" are just >>>> > explanations of the ldap return code, do you see anything in the >>>> 389 ds >>>> > error logs ? >>>> >>>> I doubt that he would see any errors. >>>> >>>> The entry already existing is because this isn't his first >>>> migration, it >>>> is unrelated. >>>> >>>> I'm not able to reproduce this. What version of IPA is it? >>>> >>>> rob >>>> >>>> -- >>>> 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 >> > > This is what I get in the logs when running the migration: > > ==> access <== > [15/Oct/2014:18:35:46 -0400] conn=8 op=166 SRCH > base="idnsName=_tcp,idnsname=example.com,cn=dns,dc=example,dc=com" > scope=0 filter="(objectClass=idnsRecord)" attrs=ALL > [15/Oct/2014:18:35:46 -0400] conn=8 op=166 RESULT err=32 tag=101 > nentries=0 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 fd=79 slot=79 connection from > 192.168.122.200 to 192.168.122.200 > [15/Oct/2014:18:35:48 -0400] conn=4 op=960 SRCH base="dc=example,dc=com" > scope=2 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=krbtgt/ > EXAMPLE.COM at EXAMPLE.COM))" attrs="krbPrincipalName krbCanonicalName > ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference > krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference > krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases > krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData > krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife > krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData > ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] conn=4 op=960 RESULT err=0 tag=101 nentries=1 > etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=961 SRCH base="dc=example,dc=com" > scope=2 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ldap/ > ipa7.example.com at EXAMPLE.COM)(krbPrincipalName=ldap/ > ipa7.example.com at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName > ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference > krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference > krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases > krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData > krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife > krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData > ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] conn=4 op=961 RESULT err=0 tag=101 nentries=1 > etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=962 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" > scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife > krbMaxRenewableAge krbTicketFlags" > [15/Oct/2014:18:35:48 -0400] conn=4 op=962 RESULT err=0 tag=101 nentries=1 > etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=963 SRCH base="dc=example,dc=com" > scope=2 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=HTTP/ > ipa7.example.com at EXAMPLE.COM))" attrs="krbPrincipalName krbCanonicalName > ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference > krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference > krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases > krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData > krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife > krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData > ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] conn=4 op=963 RESULT err=0 tag=101 nentries=1 > etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=964 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" > scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife > krbMaxRenewableAge krbTicketFlags" > [15/Oct/2014:18:35:48 -0400] conn=4 op=964 RESULT err=0 tag=101 nentries=1 > etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=965 SRCH base="dc=example,dc=com" > scope=2 filter="(&(objectClass=ipaKrb5DelegationACL)(memberPrincipal=HTTP/ > ipa7.example.com at EXAMPLE.COM))" attrs="objectClass memberPrincipal" > [15/Oct/2014:18:35:48 -0400] conn=4 op=965 RESULT err=0 tag=101 nentries=1 > etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=966 SRCH base="dc=example,dc=com" > scope=2 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName= > admin at EXAMPLE.COM))" attrs="krbPrincipalName krbCanonicalName > ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference > krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference > krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases > krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData > krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife > krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData > ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] conn=4 op=966 RESULT err=0 tag=101 nentries=1 > etime=0 > [15/Oct/2014:18:35:48 -0400] conn=4 op=967 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" > scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife > krbMaxRenewableAge krbTicketFlags" > [15/Oct/2014:18:35:48 -0400] conn=4 op=967 RESULT err=0 tag=101 nentries=1 > etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=0 BIND dn="" method=sasl > version=3 mech=GSSAPI > [15/Oct/2014:18:35:48 -0400] conn=606 op=0 RESULT err=14 tag=97 nentries=0 > etime=0, SASL bind in progress > [15/Oct/2014:18:35:48 -0400] conn=606 op=1 BIND dn="" method=sasl > version=3 mech=GSSAPI > [15/Oct/2014:18:35:48 -0400] conn=606 op=1 RESULT err=14 tag=97 nentries=0 > etime=0, SASL bind in progress > [15/Oct/2014:18:35:48 -0400] conn=606 op=2 BIND dn="" method=sasl > version=3 mech=GSSAPI > [15/Oct/2014:18:35:48 -0400] conn=606 op=2 RESULT err=0 tag=97 nentries=0 > etime=0 dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com" > [15/Oct/2014:18:35:48 -0400] conn=606 op=3 SRCH > base="cn=ipaconfig,cn=etc,dc=example,dc=com" scope=0 > filter="(objectClass=*)" attrs=ALL > [15/Oct/2014:18:35:48 -0400] conn=606 op=3 RESULT err=0 tag=101 nentries=1 > etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=4 SRCH > base="cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com" scope=0 > filter="(objectClass=*)" attrs="gidNumber cn" > [15/Oct/2014:18:35:48 -0400] conn=606 op=4 RESULT err=0 tag=101 nentries=1 > etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=5 SRCH base="cn=UPG > Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc=example,dc=com" > scope=0 filter="(objectClass=*)" attrs="* aci" > [15/Oct/2014:18:35:48 -0400] conn=606 op=5 RESULT err=0 tag=101 nentries=1 > etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=6 SRCH > base="cn=ipaconfig,cn=etc,dc=example,dc=com" scope=0 > filter="(objectClass=*)" attrs=ALL > [15/Oct/2014:18:35:48 -0400] conn=606 op=6 RESULT err=0 tag=101 nentries=1 > etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=7 SRCH > base="cn=users,cn=accounts,dc=example,dc=com" scope=2 > filter="(&(objectClass=krbprincipalaux)(krbPrincipalName= > amyengh at EXAMPLE.COM))" attrs="" > [15/Oct/2014:18:35:48 -0400] conn=606 op=7 RESULT err=0 tag=101 nentries=1 > etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=8 ADD > dn="uid=amyengh,cn=users,cn=accounts,dc=example,dc=com", add values for > type objectClass failed > [15/Oct/2014:18:35:48 -0400] conn=606 op=8 RESULT err=20 tag=105 > nentries=0 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=9 SRCH > base="cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com" scope=0 > filter="(objectClass=*)" attrs="gidNumber cn" > [15/Oct/2014:18:35:48 -0400] conn=606 op=9 RESULT err=0 tag=101 nentries=1 > etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=10 SRCH base="cn=UPG > Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc=example,dc=com" > scope=0 filter="(objectClass=*)" attrs="* aci" > [15/Oct/2014:18:35:48 -0400] conn=606 op=10 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=11 ADD > dn="cn=amyengh,cn=groups,cn=accounts,dc=example,dc=com" > [15/Oct/2014:18:35:48 -0400] conn=606 op=11 RESULT err=68 tag=105 > nentries=0 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=12 SRCH > base="cn=users,cn=accounts,dc=example,dc=com" scope=2 > filter="(&(objectClass=posixAccount)(!(memberOf=cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com)))" > attrs="" > [15/Oct/2014:18:35:48 -0400] conn=606 op=12 RESULT err=0 tag=101 > nentries=0 etime=0 > [15/Oct/2014:18:35:48 -0400] conn=606 op=13 UNBIND > [15/Oct/2014:18:35:48 -0400] conn=606 op=13 fd=79 closed - U1 > > It kind of looks like there's some sort of failure with my gidNumber or > cn, but both the user and group objects have these values. Any idea what is > going on there? > > > Did you enable the ARGS level error logging in the errors log? If so, > what's in the errors log? > > > -- > 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 > Ha! I debated sending the error logs. I think Dmitri may be right about the group value. I'll try that too. ==> errors <== [15/Oct/2014:18:35:46 -0400] - SRCH base="(null)" scope=0 deref=0 sizelimit=0 timelimit=0 attrsonly=0 filter="(objectClass=idnsRecord)" attrs=ALL [15/Oct/2014:18:35:46 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:46 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 sizelimit=0 timelimit=300 attrsonly=0 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=krbtgt/ EXAMPLE.COM at EXAMPLE.COM))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0xa [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 sizelimit=0 timelimit=300 attrsonly=0 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ldap/ ipa7.example.com at EXAMPLE.COM)(krbPrincipalName=ldap/ ipa7.example.com at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0xa [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 sizelimit=0 timelimit=300 attrsonly=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 sizelimit=0 timelimit=300 attrsonly=0 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=HTTP/ ipa7.example.com at EXAMPLE.COM))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0xa [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 sizelimit=0 timelimit=300 attrsonly=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 sizelimit=0 timelimit=300 attrsonly=0 filter="(&(objectClass=ipaKrb5DelegationACL)(memberPrincipal=HTTP/ ipa7.example.com at EXAMPLE.COM))" attrs="objectClass memberPrincipal" [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 sizelimit=0 timelimit=300 attrsonly=0 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName= admin at EXAMPLE.COM))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0xa [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 sizelimit=0 timelimit=300 attrsonly=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : frontend-internal [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : frontend-internal [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : frontend-internal [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : frontend-internal [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : frontend-internal [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : frontend-internal [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : frontend-internal [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : frontend-internal [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : frontend-internal [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : frontend-internal [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0xa [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA Lockout,cn=plugins,cn=config [15/Oct/2014:18:35:48 -0400] - replace: modifiersname [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA Lockout,cn=plugins,cn=config [15/Oct/2014:18:35:48 -0400] - replace: modifiersname [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA Lockout,cn=plugins,cn=config [15/Oct/2014:18:35:48 -0400] - replace: modifiersname [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - entryusn: 3439 [15/Oct/2014:18:35:48 -0400] - replace: entryusn [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - index_addordel_values_ext_sv indexmask 0x2 [15/Oct/2014:18:35:48 -0400] - index_addordel_values_ext_sv indexmask 0x2 [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA Lockout,cn=plugins,cn=config [15/Oct/2014:18:35:48 -0400] - replace: modifiersname [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA Lockout,cn=plugins,cn=config [15/Oct/2014:18:35:48 -0400] - replace: modifiersname [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA Lockout,cn=plugins,cn=config [15/Oct/2014:18:35:48 -0400] - replace: modifiersname [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - entryusn: 3440 [15/Oct/2014:18:35:48 -0400] - replace: entryusn [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - index_addordel_values_ext_sv indexmask 0x2 [15/Oct/2014:18:35:48 -0400] - index_addordel_values_ext_sv indexmask 0x2 [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 sizelimit=10 timelimit=2 attrsonly=0 filter="(objectClass=*)" attrs=ALL [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA Lockout,cn=plugins,cn=config [15/Oct/2014:18:35:48 -0400] - replace: modifiersname [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA Lockout,cn=plugins,cn=config [15/Oct/2014:18:35:48 -0400] - replace: modifiersname [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA Lockout,cn=plugins,cn=config [15/Oct/2014:18:35:48 -0400] - replace: modifiersname [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - entryusn: 3441 [15/Oct/2014:18:35:48 -0400] - replace: entryusn [15/Oct/2014:18:35:48 -0400] - - [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - index_addordel_values_ext_sv indexmask 0x2 [15/Oct/2014:18:35:48 -0400] - index_addordel_values_ext_sv indexmask 0x2 [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 sizelimit=100 timelimit=2 attrsonly=0 filter="(objectClass=*)" attrs="gidNumber cn" [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 sizelimit=0 timelimit=0 attrsonly=0 filter="(objectClass=*)" attrs="* aci" [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 sizelimit=10 timelimit=2 attrsonly=0 filter="(objectClass=*)" attrs=ALL [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 sizelimit=100 timelimit=2 attrsonly=0 filter="(&(objectClass=krbprincipalaux)(krbPrincipalName=amyengh at EXAMPLE.COM))" attrs="" [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0xa [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - do_add: dn (uid=amyengh,cn=users,cn=accounts,dc=example,dc=com) [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 sizelimit=100 timelimit=2 attrsonly=0 filter="(objectClass=*)" attrs="gidNumber cn" [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 sizelimit=0 timelimit=0 attrsonly=0 filter="(objectClass=*)" attrs="* aci" [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - do_add: dn (cn=amyengh,cn=groups,cn=accounts,dc=example,dc=com) [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - removing entire attribute hassubordinates [15/Oct/2014:18:35:48 -0400] - removing entire attribute numsubordinates [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 sizelimit=100 timelimit=0 attrsonly=0 filter="(&(objectClass=posixAccount)(!(memberOf=cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com)))" attrs="" [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Oct 16 03:51:28 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 15 Oct 2014 21:51:28 -0600 Subject: [Freeipa-users] Migration fails with custom objectClasses In-Reply-To: References: <543EB51F.2030307@redhat.com> <543EC81D.9000807@redhat.com> <543ED37A.4060706@redhat.com> <543EDA27.905@redhat.com> <543EFD78.9060004@redhat.com> Message-ID: <543F40C0.5010903@redhat.com> On 10/15/2014 05:29 PM, Clint Savage wrote: > On Wed, Oct 15, 2014 at 5:04 PM, Rich Megginson > wrote: > > On 10/15/2014 04:43 PM, Clint Savage wrote: >> On Wed, Oct 15, 2014 at 2:33 PM, Rich Megginson >> > wrote: >> >> On 10/15/2014 02:05 PM, Rob Crittenden wrote: >> >> Clint Savage wrote: >> >> $ rpm -q ipa-server >> ipa-server-3.3.3-28.el7.centos.1.x86_64 >> >> I was thinking that this might be an issue with the >> rhel7 version. I'm >> going to be trying the same migration tonight on >> rhel6. I know the IPA >> version is older, and samba stuff might not work as >> it does in 3.3. I >> haven't looked in RHEL 6.6 yet to see what version of >> IPA is available. >> >> I tested using a fairly recent IPA master build (4.1+). >> I'm not >> convinced it is related to any specific version, but >> different features >> are available so I thought I'd try to duplicate on a more >> similar >> footing (apples to apples comparision). >> >> The trick is to try to narrow down what attribute the >> LDAP server thinks >> already exists. We don't get a very nice error out of >> LDAP, like *what* >> attribute already exists, for example :-( >> >> It may be possible to set the 389-ds debug level to such >> that you get >> some decent output, but trying to find the right balance >> of output can >> be challenging. See their FAQ troubleshooting section. >> >> >> http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting >> >> Try the ARGS (Heavy trace output debugging) level >> >> >> >> rob >> >> >> Clint >> >> On Wed, Oct 15, 2014 at 1:16 PM, Rob Crittenden >> >> > >> wrote: >> >> Ludwig Krispenz wrote: >> > >> > On 10/14/2014 06:58 PM, Clint Savage wrote: >> >> Hi all, >> >> >> >> I've been working on a migration plan using >> three custom user >> >> objectClasses and one group objectclass. In >> my attempt, I've setup an >> >> openldap server with the proper schemas, >> imported the ldif and have >> >> records that look something like this in ldif >> format. >> >> >> >> >> ----------------------------------------------------------------------- >> >> >> >> dn: dc=example,dc=com >> >> objectClass: top >> >> objectClass: domain >> >> dc: example >> >> >> >> dn: ou=Groups,dc=example,dc=com >> >> objectClass: top >> >> objectClass: organizationalunit >> >> ou: Groups >> >> >> >> dn: ou=People,dc=example,dc=com >> >> objectClass: top >> >> objectClass: organizationalunit >> >> ou: People >> >> >> >> dn: uid=amyengh,ou=People,dc=example,dc=com >> >> objectClass: inetOrgPerson >> >> objectClass: posixAccount >> >> objectClass: top >> >> objectClass: organizationalPerson >> >> objectClass: person >> >> objectClass: radiusProfile >> >> objectClass: sambaSamAccount >> >> objectClass: customPersonAttributes >> >> cn: Amy Engh >> >> gidNumber: 1141801056 >> >> homeDirectory: /home/amyengh >> >> sn: Engh >> >> uid: amyengh >> >> uidNumber: 1141801056 >> >> displayName: Amy Engh >> >> givenName: Amy >> >> loginShell: /sbin/nologin >> >> mail: amyengh at attask.com >> >> > >> > >> >> >> >> userPassword:: REDACTED >> >> dialupAccess: yes >> >> radiusTunnelMediumType: IEEE-802 >> >> radiusTunnelPrivateGroupId: 1421 >> >> radiusTunnelType: VLAN >> >> emailPassword:: REDACTED >> >> sambaAcctFlags: [U ] >> >> sambaLMPassword: REDACTED >> >> sambaNTPassword: REDACTED >> >> sambaPasswordHistory: >> >> >> 000000000000000000000000000000000000000000000000000000 >> >> 0000000000 >> >> sambaPwdLastSet: 1402698001 >> >> sambaSID: >> S-1-5-21-2332447373-4108748234-3602490535-3146 >> >> >> >> dn: cn=amyengh,ou=Groups,dc=example,dc=com >> >> objectClass: top >> >> objectClass: posixGroup >> >> cn: amyengh >> >> gidNumber: 1141801056 >> >> memberUid: amyengh >> >> >> >> >> -------------------------------------------------------------------- >> >> >> >> I then run the migration (with or without >> compat makes no difference) >> >> and get the following: >> >> >> >> ipa migrate-ds --with-compat >> --user-container="ou=People" >> >> --group-container="ou=Groups" >> --user-objectclass=posixAccount >> >> --group-objectclass=posixgroup >> ldap://192.168.122.210 >> >> >> >> --bind-dn="cn=Manager,dc=example,dc=com" >> >> Password: >> >> ----------- >> >> migrate-ds: >> >> ----------- >> >> Migrated: >> >> Failed user: >> >> amyengh: Type or value exists: >> >> Failed group: >> >> amyengh: This entry already exists. >> > "type or value exists" and "This entry already >> exists" are just >> > explanations of the ldap return code, do you >> see anything in the 389 ds >> > error logs ? >> >> I doubt that he would see any errors. >> >> The entry already existing is because this isn't >> his first migration, it >> is unrelated. >> >> I'm not able to reproduce this. What version of >> IPA is it? >> >> rob >> >> -- >> 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 >> >> >> This is what I get in the logs when running the migration: >> >> ==> access <== >> [15/Oct/2014:18:35:46 -0400] conn=8 op=166 SRCH >> base="idnsName=_tcp,idnsname=example.com >> ,cn=dns,dc=example,dc=com" scope=0 >> filter="(objectClass=idnsRecord)" attrs=ALL >> [15/Oct/2014:18:35:46 -0400] conn=8 op=166 RESULT err=32 tag=101 >> nentries=0 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 fd=79 slot=79 connection >> from 192.168.122.200 to 192.168.122.200 >> [15/Oct/2014:18:35:48 -0400] conn=4 op=960 SRCH >> base="dc=example,dc=com" scope=2 >> filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=krbtgt/EXAMPLE.COM at EXAMPLE.COM >> ))" attrs="krbPrincipalName >> krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled >> krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration >> krbPasswordExpiration krbPwdPolicyReference krbPrincipalType >> krbPwdHistory krbLastPwdChange krbPrincipalAliases >> krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount >> krbExtraData krbLastAdminUnlock krbObjectReferences >> krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock >> passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" >> [15/Oct/2014:18:35:48 -0400] conn=4 op=960 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=4 op=961 SRCH >> base="dc=example,dc=com" scope=2 >> filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ldap/ipa7.example.com at EXAMPLE.COM >> )(krbPrincipalName=ldap/ipa7.example.com at EXAMPLE.COM >> )))" attrs="krbPrincipalName >> krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled >> krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration >> krbPasswordExpiration krbPwdPolicyReference krbPrincipalType >> krbPwdHistory krbLastPwdChange krbPrincipalAliases >> krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount >> krbExtraData krbLastAdminUnlock krbObjectReferences >> krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock >> passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" >> [15/Oct/2014:18:35:48 -0400] conn=4 op=961 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=4 op=962 SRCH >> base="cn=EXAMPLE.COM >> ,cn=kerberos,dc=example,dc=com" scope=0 >> filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife >> krbMaxRenewableAge krbTicketFlags" >> [15/Oct/2014:18:35:48 -0400] conn=4 op=962 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=4 op=963 SRCH >> base="dc=example,dc=com" scope=2 >> filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=HTTP/ipa7.example.com at EXAMPLE.COM >> ))" attrs="krbPrincipalName >> krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled >> krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration >> krbPasswordExpiration krbPwdPolicyReference krbPrincipalType >> krbPwdHistory krbLastPwdChange krbPrincipalAliases >> krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount >> krbExtraData krbLastAdminUnlock krbObjectReferences >> krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock >> passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" >> [15/Oct/2014:18:35:48 -0400] conn=4 op=963 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=4 op=964 SRCH >> base="cn=EXAMPLE.COM >> ,cn=kerberos,dc=example,dc=com" scope=0 >> filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife >> krbMaxRenewableAge krbTicketFlags" >> [15/Oct/2014:18:35:48 -0400] conn=4 op=964 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=4 op=965 SRCH >> base="dc=example,dc=com" scope=2 >> filter="(&(objectClass=ipaKrb5DelegationACL)(memberPrincipal=HTTP/ipa7.example.com at EXAMPLE.COM >> ))" attrs="objectClass >> memberPrincipal" >> [15/Oct/2014:18:35:48 -0400] conn=4 op=965 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=4 op=966 SRCH >> base="dc=example,dc=com" scope=2 >> filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=admin at EXAMPLE.COM >> ))" attrs="krbPrincipalName >> krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled >> krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration >> krbPasswordExpiration krbPwdPolicyReference krbPrincipalType >> krbPwdHistory krbLastPwdChange krbPrincipalAliases >> krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount >> krbExtraData krbLastAdminUnlock krbObjectReferences >> krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock >> passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" >> [15/Oct/2014:18:35:48 -0400] conn=4 op=966 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=4 op=967 SRCH >> base="cn=EXAMPLE.COM >> ,cn=kerberos,dc=example,dc=com" scope=0 >> filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife >> krbMaxRenewableAge krbTicketFlags" >> [15/Oct/2014:18:35:48 -0400] conn=4 op=967 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=0 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [15/Oct/2014:18:35:48 -0400] conn=606 op=0 RESULT err=14 tag=97 >> nentries=0 etime=0, SASL bind in progress >> [15/Oct/2014:18:35:48 -0400] conn=606 op=1 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [15/Oct/2014:18:35:48 -0400] conn=606 op=1 RESULT err=14 tag=97 >> nentries=0 etime=0, SASL bind in progress >> [15/Oct/2014:18:35:48 -0400] conn=606 op=2 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [15/Oct/2014:18:35:48 -0400] conn=606 op=2 RESULT err=0 tag=97 >> nentries=0 etime=0 >> dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com" >> [15/Oct/2014:18:35:48 -0400] conn=606 op=3 SRCH >> base="cn=ipaconfig,cn=etc,dc=example,dc=com" scope=0 >> filter="(objectClass=*)" attrs=ALL >> [15/Oct/2014:18:35:48 -0400] conn=606 op=3 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=4 SRCH >> base="cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com" >> scope=0 filter="(objectClass=*)" attrs="gidNumber cn" >> [15/Oct/2014:18:35:48 -0400] conn=606 op=4 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=5 SRCH base="cn=UPG >> Definition,cn=Definitions,cn=Managed >> Entries,cn=etc,dc=example,dc=com" scope=0 >> filter="(objectClass=*)" attrs="* aci" >> [15/Oct/2014:18:35:48 -0400] conn=606 op=5 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=6 SRCH >> base="cn=ipaconfig,cn=etc,dc=example,dc=com" scope=0 >> filter="(objectClass=*)" attrs=ALL >> [15/Oct/2014:18:35:48 -0400] conn=606 op=6 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=7 SRCH >> base="cn=users,cn=accounts,dc=example,dc=com" scope=2 >> filter="(&(objectClass=krbprincipalaux)(krbPrincipalName=amyengh at EXAMPLE.COM >> ))" attrs="" >> [15/Oct/2014:18:35:48 -0400] conn=606 op=7 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=8 ADD >> dn="uid=amyengh,cn=users,cn=accounts,dc=example,dc=com", add >> values for type objectClass failed >> [15/Oct/2014:18:35:48 -0400] conn=606 op=8 RESULT err=20 tag=105 >> nentries=0 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=9 SRCH >> base="cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com" >> scope=0 filter="(objectClass=*)" attrs="gidNumber cn" >> [15/Oct/2014:18:35:48 -0400] conn=606 op=9 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=10 SRCH base="cn=UPG >> Definition,cn=Definitions,cn=Managed >> Entries,cn=etc,dc=example,dc=com" scope=0 >> filter="(objectClass=*)" attrs="* aci" >> [15/Oct/2014:18:35:48 -0400] conn=606 op=10 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=11 ADD >> dn="cn=amyengh,cn=groups,cn=accounts,dc=example,dc=com" >> [15/Oct/2014:18:35:48 -0400] conn=606 op=11 RESULT err=68 tag=105 >> nentries=0 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=12 SRCH >> base="cn=users,cn=accounts,dc=example,dc=com" scope=2 >> filter="(&(objectClass=posixAccount)(!(memberOf=cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com)))" >> attrs="" >> [15/Oct/2014:18:35:48 -0400] conn=606 op=12 RESULT err=0 tag=101 >> nentries=0 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=13 UNBIND >> [15/Oct/2014:18:35:48 -0400] conn=606 op=13 fd=79 closed - U1 >> >> It kind of looks like there's some sort of failure with my >> gidNumber or cn, but both the user and group objects have these >> values. Any idea what is going on there? > > Did you enable the ARGS level error logging in the errors log? If > so, what's in the errors log? > > > -- > 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 > > > Ha! I debated sending the error logs. I think Dmitri may be right > about the group value. I'll try that too. Looks like the errors log was truncated. Can you put it on some file sharing site? If not, just email it to me directly. > > > ==> errors <== > [15/Oct/2014:18:35:46 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=0 timelimit=0 attrsonly=0 filter="(objectClass=idnsRecord)" > attrs=ALL > [15/Oct/2014:18:35:46 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:46 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 > sizelimit=0 timelimit=300 attrsonly=0 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=krbtgt/EXAMPLE.COM at EXAMPLE.COM > ))" attrs="krbPrincipalName > krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey > krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration > krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange > krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth > krbLoginFailedCount krbExtraData krbLastAdminUnlock > krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge > nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0xa > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 > sizelimit=0 timelimit=300 attrsonly=0 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ldap/ipa7.example.com at EXAMPLE.COM > )(krbPrincipalName=ldap/ipa7.example.com at EXAMPLE.COM > )))" attrs="krbPrincipalName > krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey > krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration > krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange > krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth > krbLoginFailedCount krbExtraData krbLastAdminUnlock > krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge > nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0xa > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=0 timelimit=300 attrsonly=0 > filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife > krbMaxRenewableAge krbTicketFlags" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 > sizelimit=0 timelimit=300 attrsonly=0 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=HTTP/ipa7.example.com at EXAMPLE.COM > ))" attrs="krbPrincipalName > krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey > krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration > krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange > krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth > krbLoginFailedCount krbExtraData krbLastAdminUnlock > krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge > nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0xa > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=0 timelimit=300 attrsonly=0 > filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife > krbMaxRenewableAge krbTicketFlags" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 > sizelimit=0 timelimit=300 attrsonly=0 > filter="(&(objectClass=ipaKrb5DelegationACL)(memberPrincipal=HTTP/ipa7.example.com at EXAMPLE.COM > ))" attrs="objectClass > memberPrincipal" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 > sizelimit=0 timelimit=300 attrsonly=0 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=admin at EXAMPLE.COM > ))" attrs="krbPrincipalName krbCanonicalName > ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey > krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration > krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange > krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth > krbLoginFailedCount krbExtraData krbLastAdminUnlock > krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge > nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0xa > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=0 timelimit=300 attrsonly=0 > filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife > krbMaxRenewableAge krbTicketFlags" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0xa > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA > Lockout,cn=plugins,cn=config > [15/Oct/2014:18:35:48 -0400] - replace: modifiersname > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA > Lockout,cn=plugins,cn=config > [15/Oct/2014:18:35:48 -0400] - replace: modifiersname > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA > Lockout,cn=plugins,cn=config > [15/Oct/2014:18:35:48 -0400] - replace: modifiersname > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - entryusn: 3439 > [15/Oct/2014:18:35:48 -0400] - replace: entryusn > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - index_addordel_values_ext_sv > indexmask 0x2 > [15/Oct/2014:18:35:48 -0400] - index_addordel_values_ext_sv > indexmask 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA > Lockout,cn=plugins,cn=config > [15/Oct/2014:18:35:48 -0400] - replace: modifiersname > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA > Lockout,cn=plugins,cn=config > [15/Oct/2014:18:35:48 -0400] - replace: modifiersname > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA > Lockout,cn=plugins,cn=config > [15/Oct/2014:18:35:48 -0400] - replace: modifiersname > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - entryusn: 3440 > [15/Oct/2014:18:35:48 -0400] - replace: entryusn > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - index_addordel_values_ext_sv > indexmask 0x2 > [15/Oct/2014:18:35:48 -0400] - index_addordel_values_ext_sv > indexmask 0x2 > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=10 timelimit=2 attrsonly=0 filter="(objectClass=*)" attrs=ALL > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA > Lockout,cn=plugins,cn=config > [15/Oct/2014:18:35:48 -0400] - replace: modifiersname > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA > Lockout,cn=plugins,cn=config > [15/Oct/2014:18:35:48 -0400] - replace: modifiersname > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA > Lockout,cn=plugins,cn=config > [15/Oct/2014:18:35:48 -0400] - replace: modifiersname > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - entryusn: 3441 > [15/Oct/2014:18:35:48 -0400] - replace: entryusn > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - index_addordel_values_ext_sv > indexmask 0x2 > [15/Oct/2014:18:35:48 -0400] - index_addordel_values_ext_sv > indexmask 0x2 > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=100 timelimit=2 attrsonly=0 filter="(objectClass=*)" > attrs="gidNumber cn" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=0 timelimit=0 attrsonly=0 filter="(objectClass=*)" attrs="* aci" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=10 timelimit=2 attrsonly=0 filter="(objectClass=*)" attrs=ALL > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 > sizelimit=100 timelimit=2 attrsonly=0 > filter="(&(objectClass=krbprincipalaux)(krbPrincipalName=amyengh at EXAMPLE.COM > ))" attrs="" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0xa > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - do_add: dn > (uid=amyengh,cn=users,cn=accounts,dc=example,dc=com) > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=100 timelimit=2 attrsonly=0 filter="(objectClass=*)" > attrs="gidNumber cn" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=0 timelimit=0 attrsonly=0 filter="(objectClass=*)" attrs="* aci" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - do_add: dn > (cn=amyengh,cn=groups,cn=accounts,dc=example,dc=com) > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - removing entire attribute hassubordinates > [15/Oct/2014:18:35:48 -0400] - removing entire attribute numsubordinates > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 > sizelimit=100 timelimit=0 attrsonly=0 > filter="(&(objectClass=posixAccount)(!(memberOf=cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com)))" > attrs="" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From herlo1 at gmail.com Thu Oct 16 05:18:12 2014 From: herlo1 at gmail.com (Clint Savage) Date: Wed, 15 Oct 2014 23:18:12 -0600 Subject: [Freeipa-users] Migration fails with custom objectClasses In-Reply-To: <543F40C0.5010903@redhat.com> References: <543EB51F.2030307@redhat.com> <543EC81D.9000807@redhat.com> <543ED37A.4060706@redhat.com> <543EDA27.905@redhat.com> <543EFD78.9060004@redhat.com> <543F40C0.5010903@redhat.com> Message-ID: Rich, Sorry about that. Thanks for the help. http://ur1.ca/idu6a <-- should be there at least for a few days. Clint On Wed, Oct 15, 2014 at 9:51 PM, Rich Megginson wrote: > On 10/15/2014 05:29 PM, Clint Savage wrote: > > On Wed, Oct 15, 2014 at 5:04 PM, Rich Megginson > wrote: > >> On 10/15/2014 04:43 PM, Clint Savage wrote: >> >> On Wed, Oct 15, 2014 at 2:33 PM, Rich Megginson >> wrote: >> >>> On 10/15/2014 02:05 PM, Rob Crittenden wrote: >>> >>>> Clint Savage wrote: >>>> >>>>> $ rpm -q ipa-server >>>>> ipa-server-3.3.3-28.el7.centos.1.x86_64 >>>>> >>>>> I was thinking that this might be an issue with the rhel7 version. I'm >>>>> going to be trying the same migration tonight on rhel6. I know the IPA >>>>> version is older, and samba stuff might not work as it does in 3.3. I >>>>> haven't looked in RHEL 6.6 yet to see what version of IPA is available. >>>>> >>>> I tested using a fairly recent IPA master build (4.1+). I'm not >>>> convinced it is related to any specific version, but different features >>>> are available so I thought I'd try to duplicate on a more similar >>>> footing (apples to apples comparision). >>>> >>>> The trick is to try to narrow down what attribute the LDAP server thinks >>>> already exists. We don't get a very nice error out of LDAP, like *what* >>>> attribute already exists, for example :-( >>>> >>>> It may be possible to set the 389-ds debug level to such that you get >>>> some decent output, but trying to find the right balance of output can >>>> be challenging. See their FAQ troubleshooting section. >>>> >>> >>> http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting >>> >>> Try the ARGS (Heavy trace output debugging) level >>> >>> >>> >>>> rob >>>> >>>> >>>> Clint >>>>> >>>>> On Wed, Oct 15, 2014 at 1:16 PM, Rob Crittenden >>>> > wrote: >>>>> >>>>> Ludwig Krispenz wrote: >>>>> > >>>>> > On 10/14/2014 06:58 PM, Clint Savage wrote: >>>>> >> Hi all, >>>>> >> >>>>> >> I've been working on a migration plan using three custom user >>>>> >> objectClasses and one group objectclass. In my attempt, I've >>>>> setup an >>>>> >> openldap server with the proper schemas, imported the ldif and >>>>> have >>>>> >> records that look something like this in ldif format. >>>>> >> >>>>> >> >>>>> >>>>> ----------------------------------------------------------------------- >>>>> >> >>>>> >> dn: dc=example,dc=com >>>>> >> objectClass: top >>>>> >> objectClass: domain >>>>> >> dc: example >>>>> >> >>>>> >> dn: ou=Groups,dc=example,dc=com >>>>> >> objectClass: top >>>>> >> objectClass: organizationalunit >>>>> >> ou: Groups >>>>> >> >>>>> >> dn: ou=People,dc=example,dc=com >>>>> >> objectClass: top >>>>> >> objectClass: organizationalunit >>>>> >> ou: People >>>>> >> >>>>> >> dn: uid=amyengh,ou=People,dc=example,dc=com >>>>> >> objectClass: inetOrgPerson >>>>> >> objectClass: posixAccount >>>>> >> objectClass: top >>>>> >> objectClass: organizationalPerson >>>>> >> objectClass: person >>>>> >> objectClass: radiusProfile >>>>> >> objectClass: sambaSamAccount >>>>> >> objectClass: customPersonAttributes >>>>> >> cn: Amy Engh >>>>> >> gidNumber: 1141801056 >>>>> >> homeDirectory: /home/amyengh >>>>> >> sn: Engh >>>>> >> uid: amyengh >>>>> >> uidNumber: 1141801056 >>>>> >> displayName: Amy Engh >>>>> >> givenName: Amy >>>>> >> loginShell: /sbin/nologin >>>>> >> mail: amyengh at attask.com >>>>> > >>>>> >> userPassword:: REDACTED >>>>> >> dialupAccess: yes >>>>> >> radiusTunnelMediumType: IEEE-802 >>>>> >> radiusTunnelPrivateGroupId: 1421 >>>>> >> radiusTunnelType: VLAN >>>>> >> emailPassword:: REDACTED >>>>> >> sambaAcctFlags: [U ] >>>>> >> sambaLMPassword: REDACTED >>>>> >> sambaNTPassword: REDACTED >>>>> >> sambaPasswordHistory: >>>>> >> 000000000000000000000000000000000000000000000000000000 >>>>> >> 0000000000 >>>>> >> sambaPwdLastSet: 1402698001 >>>>> >> sambaSID: S-1-5-21-2332447373-4108748234-3602490535-3146 >>>>> >> >>>>> >> dn: cn=amyengh,ou=Groups,dc=example,dc=com >>>>> >> objectClass: top >>>>> >> objectClass: posixGroup >>>>> >> cn: amyengh >>>>> >> gidNumber: 1141801056 >>>>> >> memberUid: amyengh >>>>> >> >>>>> >> >>>>> -------------------------------------------------------------------- >>>>> >> >>>>> >> I then run the migration (with or without compat makes no >>>>> difference) >>>>> >> and get the following: >>>>> >> >>>>> >> ipa migrate-ds --with-compat --user-container="ou=People" >>>>> >> --group-container="ou=Groups" --user-objectclass=posixAccount >>>>> >> --group-objectclass=posixgroup ldap://192.168.122.210 >>>>> >>>>> >> >>>>> --bind-dn="cn=Manager,dc=example,dc=com" >>>>> >> Password: >>>>> >> ----------- >>>>> >> migrate-ds: >>>>> >> ----------- >>>>> >> Migrated: >>>>> >> Failed user: >>>>> >> amyengh: Type or value exists: >>>>> >> Failed group: >>>>> >> amyengh: This entry already exists. >>>>> > "type or value exists" and "This entry already exists" are just >>>>> > explanations of the ldap return code, do you see anything in >>>>> the 389 ds >>>>> > error logs ? >>>>> >>>>> I doubt that he would see any errors. >>>>> >>>>> The entry already existing is because this isn't his first >>>>> migration, it >>>>> is unrelated. >>>>> >>>>> I'm not able to reproduce this. What version of IPA is it? >>>>> >>>>> rob >>>>> >>>>> -- >>>>> 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 >>> >> >> This is what I get in the logs when running the migration: >> >> ==> access <== >> [15/Oct/2014:18:35:46 -0400] conn=8 op=166 SRCH >> base="idnsName=_tcp,idnsname=example.com,cn=dns,dc=example,dc=com" >> scope=0 filter="(objectClass=idnsRecord)" attrs=ALL >> [15/Oct/2014:18:35:46 -0400] conn=8 op=166 RESULT err=32 tag=101 >> nentries=0 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 fd=79 slot=79 connection from >> 192.168.122.200 to 192.168.122.200 >> [15/Oct/2014:18:35:48 -0400] conn=4 op=960 SRCH base="dc=example,dc=com" >> scope=2 >> filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=krbtgt/ >> EXAMPLE.COM at EXAMPLE.COM))" attrs="krbPrincipalName krbCanonicalName >> ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference >> krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference >> krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases >> krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData >> krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife >> krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData >> ipaUserAuthType objectClass" >> [15/Oct/2014:18:35:48 -0400] conn=4 op=960 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=4 op=961 SRCH base="dc=example,dc=com" >> scope=2 >> filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ldap/ >> ipa7.example.com at EXAMPLE.COM)(krbPrincipalName=ldap/ >> ipa7.example.com at EXAMPLE.COM)))" attrs="krbPrincipalName >> krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey >> krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration >> krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange >> krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth >> krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences >> krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock >> passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" >> [15/Oct/2014:18:35:48 -0400] conn=4 op=961 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=4 op=962 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" >> scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife >> krbMaxRenewableAge krbTicketFlags" >> [15/Oct/2014:18:35:48 -0400] conn=4 op=962 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=4 op=963 SRCH base="dc=example,dc=com" >> scope=2 >> filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=HTTP/ >> ipa7.example.com at EXAMPLE.COM))" attrs="krbPrincipalName krbCanonicalName >> ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference >> krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference >> krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases >> krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData >> krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife >> krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData >> ipaUserAuthType objectClass" >> [15/Oct/2014:18:35:48 -0400] conn=4 op=963 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=4 op=964 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" >> scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife >> krbMaxRenewableAge krbTicketFlags" >> [15/Oct/2014:18:35:48 -0400] conn=4 op=964 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=4 op=965 SRCH base="dc=example,dc=com" >> scope=2 filter="(&(objectClass=ipaKrb5DelegationACL)(memberPrincipal=HTTP/ >> ipa7.example.com at EXAMPLE.COM))" attrs="objectClass memberPrincipal" >> [15/Oct/2014:18:35:48 -0400] conn=4 op=965 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=4 op=966 SRCH base="dc=example,dc=com" >> scope=2 >> filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName= >> admin at EXAMPLE.COM))" attrs="krbPrincipalName krbCanonicalName >> ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference >> krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference >> krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases >> krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData >> krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife >> krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData >> ipaUserAuthType objectClass" >> [15/Oct/2014:18:35:48 -0400] conn=4 op=966 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=4 op=967 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" >> scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife >> krbMaxRenewableAge krbTicketFlags" >> [15/Oct/2014:18:35:48 -0400] conn=4 op=967 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=0 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [15/Oct/2014:18:35:48 -0400] conn=606 op=0 RESULT err=14 tag=97 >> nentries=0 etime=0, SASL bind in progress >> [15/Oct/2014:18:35:48 -0400] conn=606 op=1 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [15/Oct/2014:18:35:48 -0400] conn=606 op=1 RESULT err=14 tag=97 >> nentries=0 etime=0, SASL bind in progress >> [15/Oct/2014:18:35:48 -0400] conn=606 op=2 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [15/Oct/2014:18:35:48 -0400] conn=606 op=2 RESULT err=0 tag=97 nentries=0 >> etime=0 dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com" >> [15/Oct/2014:18:35:48 -0400] conn=606 op=3 SRCH >> base="cn=ipaconfig,cn=etc,dc=example,dc=com" scope=0 >> filter="(objectClass=*)" attrs=ALL >> [15/Oct/2014:18:35:48 -0400] conn=606 op=3 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=4 SRCH >> base="cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com" scope=0 >> filter="(objectClass=*)" attrs="gidNumber cn" >> [15/Oct/2014:18:35:48 -0400] conn=606 op=4 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=5 SRCH base="cn=UPG >> Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc=example,dc=com" >> scope=0 filter="(objectClass=*)" attrs="* aci" >> [15/Oct/2014:18:35:48 -0400] conn=606 op=5 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=6 SRCH >> base="cn=ipaconfig,cn=etc,dc=example,dc=com" scope=0 >> filter="(objectClass=*)" attrs=ALL >> [15/Oct/2014:18:35:48 -0400] conn=606 op=6 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=7 SRCH >> base="cn=users,cn=accounts,dc=example,dc=com" scope=2 >> filter="(&(objectClass=krbprincipalaux)(krbPrincipalName= >> amyengh at EXAMPLE.COM))" attrs="" >> [15/Oct/2014:18:35:48 -0400] conn=606 op=7 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=8 ADD >> dn="uid=amyengh,cn=users,cn=accounts,dc=example,dc=com", add values for >> type objectClass failed >> [15/Oct/2014:18:35:48 -0400] conn=606 op=8 RESULT err=20 tag=105 >> nentries=0 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=9 SRCH >> base="cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com" scope=0 >> filter="(objectClass=*)" attrs="gidNumber cn" >> [15/Oct/2014:18:35:48 -0400] conn=606 op=9 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=10 SRCH base="cn=UPG >> Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc=example,dc=com" >> scope=0 filter="(objectClass=*)" attrs="* aci" >> [15/Oct/2014:18:35:48 -0400] conn=606 op=10 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=11 ADD >> dn="cn=amyengh,cn=groups,cn=accounts,dc=example,dc=com" >> [15/Oct/2014:18:35:48 -0400] conn=606 op=11 RESULT err=68 tag=105 >> nentries=0 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=12 SRCH >> base="cn=users,cn=accounts,dc=example,dc=com" scope=2 >> filter="(&(objectClass=posixAccount)(!(memberOf=cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com)))" >> attrs="" >> [15/Oct/2014:18:35:48 -0400] conn=606 op=12 RESULT err=0 tag=101 >> nentries=0 etime=0 >> [15/Oct/2014:18:35:48 -0400] conn=606 op=13 UNBIND >> [15/Oct/2014:18:35:48 -0400] conn=606 op=13 fd=79 closed - U1 >> >> It kind of looks like there's some sort of failure with my gidNumber or >> cn, but both the user and group objects have these values. Any idea what is >> going on there? >> >> >> Did you enable the ARGS level error logging in the errors log? If so, >> what's in the errors log? >> >> >> -- >> 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 >> > > Ha! I debated sending the error logs. I think Dmitri may be right about > the group value. I'll try that too. > > > Looks like the errors log was truncated. Can you put it on some file > sharing site? If not, just email it to me directly. > > > > > ==> errors <== > [15/Oct/2014:18:35:46 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=0 timelimit=0 attrsonly=0 filter="(objectClass=idnsRecord)" > attrs=ALL > [15/Oct/2014:18:35:46 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:46 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 > sizelimit=0 timelimit=300 attrsonly=0 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=krbtgt/ > EXAMPLE.COM at EXAMPLE.COM))" attrs="krbPrincipalName krbCanonicalName > ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference > krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference > krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases > krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData > krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife > krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData > ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0xa > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 > sizelimit=0 timelimit=300 attrsonly=0 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ldap/ > ipa7.example.com at EXAMPLE.COM)(krbPrincipalName=ldap/ > ipa7.example.com at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName > ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference > krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference > krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases > krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData > krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife > krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData > ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0xa > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=0 timelimit=300 attrsonly=0 > filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife > krbMaxRenewableAge krbTicketFlags" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 > sizelimit=0 timelimit=300 attrsonly=0 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=HTTP/ > ipa7.example.com at EXAMPLE.COM))" attrs="krbPrincipalName krbCanonicalName > ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference > krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference > krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases > krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData > krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife > krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData > ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0xa > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=0 timelimit=300 attrsonly=0 > filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife > krbMaxRenewableAge krbTicketFlags" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 > sizelimit=0 timelimit=300 attrsonly=0 > filter="(&(objectClass=ipaKrb5DelegationACL)(memberPrincipal=HTTP/ > ipa7.example.com at EXAMPLE.COM))" attrs="objectClass memberPrincipal" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 > sizelimit=0 timelimit=300 attrsonly=0 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName= > admin at EXAMPLE.COM))" attrs="krbPrincipalName krbCanonicalName > ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference > krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference > krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases > krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData > krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife > krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData > ipaUserAuthType objectClass" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0xa > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=0 timelimit=300 attrsonly=0 > filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife > krbMaxRenewableAge krbTicketFlags" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : > frontend-internal > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0xa > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA > Lockout,cn=plugins,cn=config > [15/Oct/2014:18:35:48 -0400] - replace: modifiersname > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA > Lockout,cn=plugins,cn=config > [15/Oct/2014:18:35:48 -0400] - replace: modifiersname > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA > Lockout,cn=plugins,cn=config > [15/Oct/2014:18:35:48 -0400] - replace: modifiersname > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - entryusn: 3439 > [15/Oct/2014:18:35:48 -0400] - replace: entryusn > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - index_addordel_values_ext_sv indexmask > 0x2 > [15/Oct/2014:18:35:48 -0400] - index_addordel_values_ext_sv indexmask > 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA > Lockout,cn=plugins,cn=config > [15/Oct/2014:18:35:48 -0400] - replace: modifiersname > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA > Lockout,cn=plugins,cn=config > [15/Oct/2014:18:35:48 -0400] - replace: modifiersname > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA > Lockout,cn=plugins,cn=config > [15/Oct/2014:18:35:48 -0400] - replace: modifiersname > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - entryusn: 3440 > [15/Oct/2014:18:35:48 -0400] - replace: entryusn > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - index_addordel_values_ext_sv indexmask > 0x2 > [15/Oct/2014:18:35:48 -0400] - index_addordel_values_ext_sv indexmask > 0x2 > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=10 timelimit=2 attrsonly=0 filter="(objectClass=*)" attrs=ALL > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA > Lockout,cn=plugins,cn=config > [15/Oct/2014:18:35:48 -0400] - replace: modifiersname > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA > Lockout,cn=plugins,cn=config > [15/Oct/2014:18:35:48 -0400] - replace: modifiersname > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - krbLastSuccessfulAuth: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: krbLastSuccessfulAuth > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifiersname: cn=IPA > Lockout,cn=plugins,cn=config > [15/Oct/2014:18:35:48 -0400] - replace: modifiersname > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - modifytimestamp: 20141015223548Z > [15/Oct/2014:18:35:48 -0400] - replace: modifytimestamp > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - entryusn: 3441 > [15/Oct/2014:18:35:48 -0400] - replace: entryusn > [15/Oct/2014:18:35:48 -0400] - - > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - index_addordel_values_ext_sv indexmask > 0x2 > [15/Oct/2014:18:35:48 -0400] - index_addordel_values_ext_sv indexmask > 0x2 > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=100 timelimit=2 attrsonly=0 filter="(objectClass=*)" > attrs="gidNumber cn" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=0 timelimit=0 attrsonly=0 filter="(objectClass=*)" attrs="* aci" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=10 timelimit=2 attrsonly=0 filter="(objectClass=*)" attrs=ALL > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 > sizelimit=100 timelimit=2 attrsonly=0 > filter="(&(objectClass=krbprincipalaux)(krbPrincipalName= > amyengh at EXAMPLE.COM))" attrs="" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0xa > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - do_add: dn > (uid=amyengh,cn=users,cn=accounts,dc=example,dc=com) > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=100 timelimit=2 attrsonly=0 filter="(objectClass=*)" > attrs="gidNumber cn" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=0 deref=0 > sizelimit=0 timelimit=0 attrsonly=0 filter="(objectClass=*)" attrs="* aci" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - do_add: dn > (cn=amyengh,cn=groups,cn=accounts,dc=example,dc=com) > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - removing entire attribute hassubordinates > [15/Oct/2014:18:35:48 -0400] - removing entire attribute numsubordinates > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > [15/Oct/2014:18:35:48 -0400] - SRCH base="(null)" scope=2 deref=0 > sizelimit=100 timelimit=0 attrsonly=0 > filter="(&(objectClass=posixAccount)(!(memberOf=cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com)))" > attrs="" > [15/Oct/2014:18:35:48 -0400] - mapping tree selected backend : userRoot > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - indextype: "eq" indexmask: 0x2 > [15/Oct/2014:18:35:48 -0400] - mapping tree release backend : userRoot > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Thu Oct 16 07:05:19 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 16 Oct 2014 09:05:19 +0200 Subject: [Freeipa-users] Migration fails with custom objectClasses In-Reply-To: <543ED37A.4060706@redhat.com> References: <543EB51F.2030307@redhat.com> <543EC81D.9000807@redhat.com> <543ED37A.4060706@redhat.com> Message-ID: <543F6E2F.5010506@redhat.com> On 10/15/2014 10:05 PM, Rob Crittenden wrote: > Clint Savage wrote: >> $ rpm -q ipa-server >> ipa-server-3.3.3-28.el7.centos.1.x86_64 >> >> I was thinking that this might be an issue with the rhel7 version. I'm >> going to be trying the same migration tonight on rhel6. I know the IPA >> version is older, and samba stuff might not work as it does in 3.3. I >> haven't looked in RHEL 6.6 yet to see what version of IPA is available. > I tested using a fairly recent IPA master build (4.1+). I'm not > convinced it is related to any specific version, but different features > are available so I thought I'd try to duplicate on a more similar > footing (apples to apples comparision). > > The trick is to try to narrow down what attribute the LDAP server thinks > already exists. We don't get a very nice error out of LDAP, like *what* > attribute already exists, for example :-( It is all there: [15/Oct/2014:18:35:48 -0400] conn=606 op=8 ADD dn="uid=amyengh,cn=users,cn=accounts,dc=example,dc=com", add values for type objectClass failed [15/Oct/2014:18:35:48 -0400] conn=606 op=8 RESULT err=20 tag=105 nentries=0 etime=0 and err=20 is type_or_value_exists. Now this confirms Clint's observation that the problem goes away if the custom objectclass is removed. And he said that adding the entry manually (I assume ldapmodify) works. Is there a possibility that the migrate script adds the custom objectclass again ? > > It may be possible to set the 389-ds debug level to such that you get > some decent output, but trying to find the right balance of output can > be challenging. See their FAQ troubleshooting section. > > rob > > >> Clint >> >> On Wed, Oct 15, 2014 at 1:16 PM, Rob Crittenden > > wrote: >> >> Ludwig Krispenz wrote: >> > >> > On 10/14/2014 06:58 PM, Clint Savage wrote: >> >> Hi all, >> >> >> >> I've been working on a migration plan using three custom user >> >> objectClasses and one group objectclass. In my attempt, I've setup an >> >> openldap server with the proper schemas, imported the ldif and have >> >> records that look something like this in ldif format. >> >> >> >> >> ----------------------------------------------------------------------- >> >> >> >> dn: dc=example,dc=com >> >> objectClass: top >> >> objectClass: domain >> >> dc: example >> >> >> >> dn: ou=Groups,dc=example,dc=com >> >> objectClass: top >> >> objectClass: organizationalunit >> >> ou: Groups >> >> >> >> dn: ou=People,dc=example,dc=com >> >> objectClass: top >> >> objectClass: organizationalunit >> >> ou: People >> >> >> >> dn: uid=amyengh,ou=People,dc=example,dc=com >> >> objectClass: inetOrgPerson >> >> objectClass: posixAccount >> >> objectClass: top >> >> objectClass: organizationalPerson >> >> objectClass: person >> >> objectClass: radiusProfile >> >> objectClass: sambaSamAccount >> >> objectClass: customPersonAttributes >> >> cn: Amy Engh >> >> gidNumber: 1141801056 >> >> homeDirectory: /home/amyengh >> >> sn: Engh >> >> uid: amyengh >> >> uidNumber: 1141801056 >> >> displayName: Amy Engh >> >> givenName: Amy >> >> loginShell: /sbin/nologin >> >> mail: amyengh at attask.com >> > >> >> userPassword:: REDACTED >> >> dialupAccess: yes >> >> radiusTunnelMediumType: IEEE-802 >> >> radiusTunnelPrivateGroupId: 1421 >> >> radiusTunnelType: VLAN >> >> emailPassword:: REDACTED >> >> sambaAcctFlags: [U ] >> >> sambaLMPassword: REDACTED >> >> sambaNTPassword: REDACTED >> >> sambaPasswordHistory: >> >> 000000000000000000000000000000000000000000000000000000 >> >> 0000000000 >> >> sambaPwdLastSet: 1402698001 >> >> sambaSID: S-1-5-21-2332447373-4108748234-3602490535-3146 >> >> >> >> dn: cn=amyengh,ou=Groups,dc=example,dc=com >> >> objectClass: top >> >> objectClass: posixGroup >> >> cn: amyengh >> >> gidNumber: 1141801056 >> >> memberUid: amyengh >> >> >> >> -------------------------------------------------------------------- >> >> >> >> I then run the migration (with or without compat makes no difference) >> >> and get the following: >> >> >> >> ipa migrate-ds --with-compat --user-container="ou=People" >> >> --group-container="ou=Groups" --user-objectclass=posixAccount >> >> --group-objectclass=posixgroup ldap://192.168.122.210 >> >> >> --bind-dn="cn=Manager,dc=example,dc=com" >> >> Password: >> >> ----------- >> >> migrate-ds: >> >> ----------- >> >> Migrated: >> >> Failed user: >> >> amyengh: Type or value exists: >> >> Failed group: >> >> amyengh: This entry already exists. >> > "type or value exists" and "This entry already exists" are just >> > explanations of the ldap return code, do you see anything in the 389 ds >> > error logs ? >> >> I doubt that he would see any errors. >> >> The entry already existing is because this isn't his first migration, it >> is unrelated. >> >> I'm not able to reproduce this. What version of IPA is it? >> >> rob >> >> -- >> 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 >> >> From orkhan-azeri at mail.ru Thu Oct 16 08:04:48 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Thu, 16 Oct 2014 13:04:48 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CD1F1.603@mail.ru> <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> <20141014131305.GE3104@mail.corp.redhat.com> <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> Message-ID: <543F7C20.5040105@mail.ru> OK, back to FreeIPA - FreeBSD setup. I changed my setup: instead of 2 VMs now I have 4 VMs: 1: DNS server - set up as shown by Rajnesh Kumar Siwal in http://www.youtube.com/watch?v=0SmiwFoHVeI&index=4&list=PLdKXnZQzEG-KmtKq-LelPn5RTKfJig0Wc 2 and 3: IPA server & IPA linux client - set up as shown by Rajnesh Kumar Siwal in http://www.youtube.com/watch?v=_zlcxjkbayk 4: IPA BSD client - set up as described in the post at FreeBSD forums. Results: 1) my IPA linux client interacts fine with the IPA server; 2) my IPA BSD client also interacts with the IPA server: it sees IPA users when issuing "getent passwd" or "getent shadow". (Previously when I used just 2 VMs and no DNS server, that didn`t happen.) Problems after I start sssd on the FreeBSD client: 1) I can`t ssh into my IPA BSD client either as an IPA user (rsiwal) or local user (root); 2) if I restart my IPA BSD client, I also can`t login to it locally as either "root" or "rsiwal". I get totally locked out of the machine. FreeBSD displays some errors on the screen when using: 1) SSH: https://cloud.mail.ru/public/888b415dac43%2Fssh_error_IPA_user_and_root.JPG 2) local login: https://cloud.mail.ru/public/3399c5b67c33%2Flogin_error_root_and_IPA_user.JPG FreeBSD complains about line 19 in /etc/pam.d/system. That line reads: account required /usr/local/lib/pam_sss.so ignore unknown user The file "pam_sss.so" exists on my FreeBSD machine in the specified location. Deleting "ignore unknown user" from that line doesn`t help. Changing the position of that line so that it preceeds account required pam_unix.so also gives no result. Please help me to understand, what can I do in such a situation? Is it a bug in pam_sss.so? 15-Oct-14 06:14, Fraser Tweedale ?????: > On Tue, Oct 14, 2014 at 03:13:06PM +0200, Lukas Slebodnik wrote: >> On (14/10/14 17:48), Fraser Tweedale wrote: >>> On Tue, Oct 14, 2014 at 12:34:09PM +0500, Orkhan Gasimov wrote: >>>> With help from Alexander Bokovoy I found correct log destinations: >>>> >>>> sssd-domain-log: >>>> https://cloud.mail.ru/public/1e803a00989e%2Fsssd_eurosel.az.log >>>> sssd-nss-log: https://cloud.mail.ru/public/ae41ae3b44b6%2Fsssd_nss.log >>>> >>>> These files are from my second Fedora - FreeBSD setup, they have different >>>> domain name, but everything else is identical. >>>> >>>> Interestingly enough, there are lines in sssd_nss.log telling that there are >>>> no users or groups in the domain. But as I said, I can ssh to the IPA server >>>> as an IPA user. >>>> >>> Hi Orkhan, >>> >>> Thanks for the logs. What were their actual locations? >>> >>> I'm going to try and reproduce your setup and see whether I get the >>> same outcome. I have been building and installing the ports as >>> indicated in the forum post, and one thing I have noticed is that >>> there are a lot of configuration options on some of the important >>> ports - perhaps there was an important option that the author forgot >>> to mention. >>> >> You needn't build sssd from ports. You can install sssd with pkg utility. >> The only necessary step is to build openldap client with SASL support, >> because default version of openldap client is build without SASL support. >> sssd cannot initialize ipa_provider with openldap libraries without SASL >> support. On the other hand, {ldap,krb5,ad} providers can be used without any >> problem. >> >> The steps, how to build openldap client with SASL support, are described >> in freebsd forum. >> >>> It is the end of the day for me, but sssd is now installed so I >>> should let you know tomorrow whether I am running into the same >>> issues as you, or whether I find success. >>> >>> (As a side node: once I get to a working setup I will create and >>> publish a pkg(8) repo with the needed ports built with the correct >>> options and make.conf variables. This should make it easier and >>> certainly quicker to use FreeBSD as a FreeIPA client.) >> I am not sure what you are trying to do. Everything is described on forum. >> If there isn't something clear feel free to send rephrased(updated) version of >> howto. I can contact an author of that post. >> > Since there are non-default options and make variables to be set, is > it not desirable that there be a pkg(8) repository people can use to > install the packages needed for ipa integration? > > I think it is desirable. It is easy to thanks to > ports-mgmt/poudriere. > > Fraser > >> LS From lslebodn at redhat.com Thu Oct 16 09:57:12 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 16 Oct 2014 11:57:12 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <543F7C20.5040105@mail.ru> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CD1F1.603@mail.ru> <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> <20141014131305.GE3104@mail.corp.redhat.com> <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> Message-ID: <20141016095711.GC19767@mail.corp.redhat.com> On (16/10/14 13:04), Orkhan Gasimov wrote: >OK, back to FreeIPA - FreeBSD setup. >I changed my setup: instead of 2 VMs now I have 4 VMs: > >1: DNS server - set up as shown by Rajnesh Kumar Siwal in http://www.youtube.com/watch?v=0SmiwFoHVeI&index=4&list=PLdKXnZQzEG-KmtKq-LelPn5RTKfJig0Wc > >2 and 3: IPA server & IPA linux client - set up as shown by Rajnesh Kumar >Siwal in http://www.youtube.com/watch?v=_zlcxjkbayk > >4: IPA BSD client - set up as described in the post at FreeBSD forums. > > >Results: > >1) my IPA linux client interacts fine with the IPA server; > >2) my IPA BSD client also interacts with the IPA server: it sees IPA users >when issuing "getent passwd" or "getent shadow". (Previously when I used just >2 VMs and no DNS server, that didn`t happen.) > >Problems after I start sssd on the FreeBSD client: > >1) I can`t ssh into my IPA BSD client either as an IPA user (rsiwal) or local >user (root); > >2) if I restart my IPA BSD client, I also can`t login to it locally as either >"root" or "rsiwal". I get totally locked out of the machine. > >FreeBSD displays some errors on the screen when using: > >1) SSH: >https://cloud.mail.ru/public/888b415dac43%2Fssh_error_IPA_user_and_root.JPG > >2) local login: >https://cloud.mail.ru/public/3399c5b67c33%2Flogin_error_root_and_IPA_user.JPG > >FreeBSD complains about line 19 in /etc/pam.d/system. That line reads: >account required /usr/local/lib/pam_sss.so ignore unknown user ^^^^^^^^^^^^^^^^^^^ it should we one word connected with underscores "_" See details in: man pam_sss -> OPTIONS It would be good to use also argument ignore_authinfo_unavail in pam system config otherwise you will not be able to connect as local user if sssd will be down. LS From orkhan-azeri at mail.ru Thu Oct 16 10:13:27 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Thu, 16 Oct 2014 15:13:27 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141016095711.GC19767@mail.corp.redhat.com> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CD1F1.603@mail.ru> <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> <20141014131305.GE3104@mail.corp.redhat.com> <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> Message-ID: <543F9A47.3010505@mail.ru> Please excuse me for that silly typo in the letter. The typo doesn`t exist either in /etc/pam.d/system or /etc/pam.d/sshd - in those files I typed "ignore_unknown_user". I'll try "ignore_authinfo_unavail" to see if it prevents me from being locked out of the machine. Here are the log files: sssd_eurosel.az.log: https://cloud.mail.ru/public/1e803a00989e%2Fsssd_eurosel.az.log sssd_nss.log: https://cloud.mail.ru/public/ae41ae3b44b6%2Fsssd_nss.log sssd_pam.log: https://cloud.mail.ru/public/85d311ec1d4e%2Fsssd_pam.log krb5_child.log: https://cloud.mail.ru/public/c0e6712b7f1b%2Fkrb5_child.log ldap_child.log: https://cloud.mail.ru/public/d9b0b1eb0da6%2Fldap_child.log sssd_log: https://cloud.mail.ru/public/d4032b8e6645%2Fsssd.log 16-Oct-14 14:57, Lukas Slebodnik ?????: > On (16/10/14 13:04), Orkhan Gasimov wrote: >> OK, back to FreeIPA - FreeBSD setup. >> I changed my setup: instead of 2 VMs now I have 4 VMs: >> >> 1: DNS server - set up as shown by Rajnesh Kumar Siwal in http://www.youtube.com/watch?v=0SmiwFoHVeI&index=4&list=PLdKXnZQzEG-KmtKq-LelPn5RTKfJig0Wc >> >> 2 and 3: IPA server & IPA linux client - set up as shown by Rajnesh Kumar >> Siwal in http://www.youtube.com/watch?v=_zlcxjkbayk >> >> 4: IPA BSD client - set up as described in the post at FreeBSD forums. >> >> >> Results: >> >> 1) my IPA linux client interacts fine with the IPA server; >> >> 2) my IPA BSD client also interacts with the IPA server: it sees IPA users >> when issuing "getent passwd" or "getent shadow". (Previously when I used just >> 2 VMs and no DNS server, that didn`t happen.) >> >> Problems after I start sssd on the FreeBSD client: >> >> 1) I can`t ssh into my IPA BSD client either as an IPA user (rsiwal) or local >> user (root); >> >> 2) if I restart my IPA BSD client, I also can`t login to it locally as either >> "root" or "rsiwal". I get totally locked out of the machine. >> >> FreeBSD displays some errors on the screen when using: >> >> 1) SSH: >> https://cloud.mail.ru/public/888b415dac43%2Fssh_error_IPA_user_and_root.JPG >> >> 2) local login: >> https://cloud.mail.ru/public/3399c5b67c33%2Flogin_error_root_and_IPA_user.JPG >> >> FreeBSD complains about line 19 in /etc/pam.d/system. That line reads: >> account required /usr/local/lib/pam_sss.so ignore unknown user > ^^^^^^^^^^^^^^^^^^^ > it should we one word connected with underscores "_" > > See details in: > man pam_sss -> OPTIONS > > It would be good to use also argument ignore_authinfo_unavail > in pam system config otherwise you will not be able to connect as local user > if sssd will be down. > > LS > From tevfik.ceydeliler at astron.yasar.com.tr Thu Oct 16 12:17:53 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Thu, 16 Oct 2014 15:17:53 +0300 Subject: [Freeipa-users] A Specific Problem freeipa user rights Message-ID: <543FB771.2020802@astron.yasar.com.tr> Hi, I have user that have" sudo su " right. And we have to use checkpoint ssl VPN connection. Becouse of SSL VPN connection, VPN want ot create virtual interface for tunneling and needs root right. My clients work on ubuntu desktop. How can I give a permission to my user to create this tunnel interface? --


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. From christof.schulze at ww.uni-erlangen.de Thu Oct 16 09:08:24 2014 From: christof.schulze at ww.uni-erlangen.de (Christof Schulze) Date: Thu, 16 Oct 2014 11:08:24 +0200 Subject: [Freeipa-users] ipa-client-install (Invalid Request) - no Host-Certificate Message-ID: <543F8B08.9000601@ww.uni-erlangen.de> Hello all, i am running a FreeIPA server on CentOS for 2 years now with mostly Ubuntu 12.04 and some Fedora 20 clients. Since one week (or more) it is not possible any more to install new clients (whether ubuntu nor fedora). The Host gets created on the IPA-server but it can not create/exchange a Host-Certificate. The only thing happened (except regular updates) was a complete certificate renewal with no obvious problems some weeks ago. Web-interface and certmonger show the same error. ipa-getcert list on the new Hosts: status: CA_UNREACHABLE ca-error: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: FAILURE (Invalid Request)). stuck: yes Debug Log from server as Attachment C. Schuze -------------- next part -------------- [16/Oct/2014:10:15:02][TP-Processor3]: according to ccMode, authorization for servlet: caProfileSubmitSSLClient is LDAP based, not XML {1}, use default authz mgr: {2}. [16/Oct/2014:10:15:02][TP-Processor3]: according to ccMode, authorization for servlet: caProfileSubmitSSLClient is LDAP based, not XML {1}, use default authz mgr: {2}. [16/Oct/2014:10:15:02][TP-Processor3]: CMSServlet:service() uri = //ca/eeca/ca/profileSubmitSSLClient [16/Oct/2014:10:15:02][TP-Processor3]: CMSServlet::service() param name='cert_request_type' value='pkcs10' [16/Oct/2014:10:15:02][TP-Processor3]: CMSServlet::service() param name='cert_request' value='-----BEGIN NEW CERTIFICATE REQUEST----- MIIDojCCAooCAQAwSTEfMB0GA1UEChMWV1c4LldXLlVOSS1FUkxBTkdFTi5ERTEm ************************* KUcSD/bprTEoF8xn/sX9SpUhxd9yEAYANxFTo610rSd/eeWDXXItFbnbWvkbUqLQ /Tfh+zAN4gEEDVHWa1avLr5bckXYIA== -----END NEW CERTIFICATE REQUEST-----' [16/Oct/2014:10:15:02][TP-Processor3]: CMSServlet::service() param name='xml' value='true' [16/Oct/2014:10:15:02][TP-Processor3]: CMSServlet::service() param name='profileId' value='caIPAserviceCert' [16/Oct/2014:10:15:02][TP-Processor3]: CMSServlet: caProfileSubmitSSLClient start to service. [16/Oct/2014:10:15:02][TP-Processor3]: xmlOutput true [16/Oct/2014:10:15:02][TP-Processor3]: Start of ProfileSubmitServlet Input Parameters [16/Oct/2014:10:15:02][TP-Processor3]: ProfileSubmitServlet Input Parameter cert_request_type='pkcs10' [16/Oct/2014:10:15:02][TP-Processor3]: ProfileSubmitServlet Input Parameter cert_request='-----BEGIN NEW CERTIFICATE REQUEST----- MIIDojCCAooCAQAwSTEfMB0GA1UEChMWV1c4LldXLlVOSS1FUkxBTkdFTi5ERTEm ************************* KUcSD/bprTEoF8xn/sX9SpUhxd9yEAYANxFTo610rSd/eeWDXXItFbnbWvkbUqLQ /Tfh+zAN4gEEDVHWa1avLr5bckXYIA== -----END NEW CERTIFICATE REQUEST-----' [16/Oct/2014:10:15:02][TP-Processor3]: ProfileSubmitServlet Input Parameter xml='true' [16/Oct/2014:10:15:02][TP-Processor3]: ProfileSubmitServlet Input Parameter profileId='caIPAserviceCert' [16/Oct/2014:10:15:02][TP-Processor3]: End of ProfileSubmitServlet Input Parameters [16/Oct/2014:10:15:02][TP-Processor3]: ProfileSubmitServlet: start serving [16/Oct/2014:10:15:02][TP-Processor3]: ProfileSubmitServlet: SubId=profile [16/Oct/2014:10:15:02][TP-Processor3]: ProfileSubmitServlet: isRenewal false [16/Oct/2014:10:15:02][TP-Processor3]: ProfileSubmitServlet: profileId caIPAserviceCert [16/Oct/2014:10:15:02][TP-Processor3]: ProfileSubmitServlet: authenticator raCertAuth found [16/Oct/2014:10:15:02][TP-Processor3]: ProfileSubmitServlet:setCredentialsIntoContext() authIds` null [16/Oct/2014:10:15:02][TP-Processor3]: ProfileSubmistServlet: set Inputs into profile Context [16/Oct/2014:10:15:02][TP-Processor3]: ProfileSubmitServlet: set sslClientCertProvider [16/Oct/2014:10:15:02][TP-Processor3]: AgentCertAuthentication: start [16/Oct/2014:10:15:02][TP-Processor3]: authenticator instance name is raCertAuth [16/Oct/2014:10:15:02][TP-Processor3]: AgentCertAuthenticator: got provider [16/Oct/2014:10:15:02][TP-Processor3]: AgentCertAuthenticator: retrieving client certificate [16/Oct/2014:10:15:02][TP-Processor3]: AgentCertAuthenticator: got certificates [16/Oct/2014:10:15:02][TP-Processor3]: In LdapBoundConnFactory::getConn() [16/Oct/2014:10:15:02][TP-Processor3]: masterConn is connected: true [16/Oct/2014:10:15:02][TP-Processor3]: getConn: conn is connected true [16/Oct/2014:10:15:02][TP-Processor3]: getConn: mNumConns now 2 [16/Oct/2014:10:15:02][TP-Processor3]: returnConn: mNumConns now 3 [16/Oct/2014:10:15:02][TP-Processor3]: In LdapBoundConnFactory::getConn() [16/Oct/2014:10:15:02][TP-Processor3]: masterConn is connected: true [16/Oct/2014:10:15:02][TP-Processor3]: getConn: conn is connected true [16/Oct/2014:10:15:02][TP-Processor3]: getConn: mNumConns now 2 [16/Oct/2014:10:15:02][TP-Processor3]: returnConn: mNumConns now 3 [16/Oct/2014:10:15:02][TP-Processor3]: check if ipara is in group Registration Manager Agents [16/Oct/2014:10:15:02][TP-Processor3]: UGSubsystem.isMemberOf() using new lookup code [16/Oct/2014:10:15:02][TP-Processor3]: In LdapBoundConnFactory::getConn() [16/Oct/2014:10:15:02][TP-Processor3]: masterConn is connected: true [16/Oct/2014:10:15:02][TP-Processor3]: getConn: conn is connected true [16/Oct/2014:10:15:02][TP-Processor3]: getConn: mNumConns now 2 [16/Oct/2014:10:15:02][TP-Processor3]: authorization search base: cn=Registration Manager Agents,ou=groups,o=ipaca [16/Oct/2014:10:15:02][TP-Processor3]: authorization search filter: (uniquemember=uid=ipara,ou=people,o=ipaca) [16/Oct/2014:10:15:02][TP-Processor3]: authorization result: true [16/Oct/2014:10:15:02][TP-Processor3]: returnConn: mNumConns now 3 [16/Oct/2014:10:15:02][TP-Processor3]: AgentCertAuthentication: authenticated uid=ipara,ou=people,o=ipaca [16/Oct/2014:10:15:02][TP-Processor3]: ProfileSubmitServlet authToken not null [16/Oct/2014:10:15:02][TP-Processor3]: ProfileSubmitServlet: authz using acl: [16/Oct/2014:10:15:02][TP-Processor3]: Start parsePKCS10(): -----BEGIN NEW CERTIFICATE REQUEST----- MIIDojCCAooCAQAwSTEfMB0GA1UEChMWV1c4LldXLlVOSS1FUkxBTkdFTi5ERTEm ************************* KUcSD/bprTEoF8xn/sX9SpUhxd9yEAYANxFTo610rSd/eeWDXXItFbnbWvkbUqLQ /Tfh+zAN4gEEDVHWa1avLr5bckXYIA== -----END NEW CERTIFICATE REQUEST----- [16/Oct/2014:10:15:02][TP-Processor3]: EnrollProfile: parsePKCS10: signature verification enabled [16/Oct/2014:10:15:02][TP-Processor3]: EnrollProfile: parsePKCS10 org.mozilla.jss.NoSuchTokenException [16/Oct/2014:10:15:02][TP-Processor3]: EnrollProfile: parsePKCS10 restoring thread token Invalid Request at com.netscape.cms.profile.common.EnrollProfile.parsePKCS10(EnrollProfile.java:953) at com.netscape.cms.profile.common.EnrollProfile.createRequests(EnrollProfile.java:102) at com.netscape.cms.servlet.profile.ProfileSubmitServlet.process(ProfileSubmitServlet.java:1001) at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:501) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.netscape.cms.servlet.filter.EEClientAuthRequestFilter.doFilter(EEClientAuthRequestFilter.java:123) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:698) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:891) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) at java.lang.Thread.run(Thread.java:701) [16/Oct/2014:10:15:02][TP-Processor3]: ProfileSubmitServlet: createRequests Invalid Request [16/Oct/2014:10:15:03][TP-Processor3]: CMSServlet: curDate=Thu Oct 16 10:15:03 CEST 2014 id=caProfileSubmitSSLClient time=124 [16/Oct/2014:10:16:43][Timer-0]: CMSEngine: getPasswordStore(): password store initialized before. [16/Oct/2014:10:16:43][Timer-0]: CMSEngine: getPasswordStore(): password store initialized. [16/Oct/2014:10:16:43][Timer-0]: SecurityDomainSessionTable: getSessionIds(): no sessions have been created From orkhan-azeri at mail.ru Thu Oct 16 13:23:55 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Thu, 16 Oct 2014 18:23:55 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <543F9A47.3010505@mail.ru> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CD1F1.603@mail.ru> <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> <20141014131305.GE3104@mail.corp.redhat.com> <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> Message-ID: <543FC6EB.1070509@mail.ru> Here`s what I have at the end of the day after various checks. SSH-ing as existing IPA user "rsiwal" to my FreeBSD client fails. The same user can SSH or locally login to my Linux client. If I create a new user in IPA, he can`t initially SSH into FreeBSD client. BSD says: "password expired", but doesn`t take new password. The same new user can SSH into my Linux client. Linux says: "password expired" and allows to set a new password with a message: "All authentication tokens updated successfully." After I set a new password for my newly created user via Linux, I can SSH into my BSD client as that user. Using this hack I can create new users in IPA, SSH into Linux to change their passwords and then use those new users to SSH into FreeBSD. At the same time I cannot locally login to my FreeBSD host as either IPA user or local user. I think there`s something wrong with Kerberos setup on my FreeBSD client. I suspect that because both /etc/pam.d/system and /etc/pam.d/sshd files on the BSD client have a string: password sufficient /usr/local/lib/pam_sss.so use_authtok but BSD doesn`t let update authentication tokens when trying to change expired password for a new user. There was minimal info about Kerberos setup on FreeBSD client in the post at FreeBSD forums. Just this: "create a keytab on the IPA server and copy it to /etc/krb5.keytab" on the FreeBSD client. Someone here wrote that he can contact the author of that post. If so, please tell the author to spend a couple of hours to: 1) check everything he advised on a blank setup with VMs; 2) provide more details about correct sequence of actions. Any help will be highly appreciated! 16-Oct-14 15:13, Orkhan Gasimov ?????: > Please excuse me for that silly typo in the letter. The typo doesn`t > exist either in /etc/pam.d/system or /etc/pam.d/sshd - in those files > I typed "ignore_unknown_user". > > I'll try "ignore_authinfo_unavail" to see if it prevents me from being > locked out of the machine. > > Here are the log files: > > sssd_eurosel.az.log: > https://cloud.mail.ru/public/1e803a00989e%2Fsssd_eurosel.az.log > sssd_nss.log: https://cloud.mail.ru/public/ae41ae3b44b6%2Fsssd_nss.log > sssd_pam.log: https://cloud.mail.ru/public/85d311ec1d4e%2Fsssd_pam.log > krb5_child.log: > https://cloud.mail.ru/public/c0e6712b7f1b%2Fkrb5_child.log > ldap_child.log: > https://cloud.mail.ru/public/d9b0b1eb0da6%2Fldap_child.log > sssd_log: https://cloud.mail.ru/public/d4032b8e6645%2Fsssd.log > > > 16-Oct-14 14:57, Lukas Slebodnik ?????: >> On (16/10/14 13:04), Orkhan Gasimov wrote: >>> OK, back to FreeIPA - FreeBSD setup. >>> I changed my setup: instead of 2 VMs now I have 4 VMs: >>> >>> 1: DNS server - set up as shown by Rajnesh Kumar Siwal in >>> http://www.youtube.com/watch?v=0SmiwFoHVeI&index=4&list=PLdKXnZQzEG-KmtKq-LelPn5RTKfJig0Wc >>> >>> 2 and 3: IPA server & IPA linux client - set up as shown by Rajnesh >>> Kumar >>> Siwal in http://www.youtube.com/watch?v=_zlcxjkbayk >>> >>> 4: IPA BSD client - set up as described in the post at FreeBSD forums. >>> >>> >>> Results: >>> >>> 1) my IPA linux client interacts fine with the IPA server; >>> >>> 2) my IPA BSD client also interacts with the IPA server: it sees IPA >>> users >>> when issuing "getent passwd" or "getent shadow". (Previously when I >>> used just >>> 2 VMs and no DNS server, that didn`t happen.) >>> >>> Problems after I start sssd on the FreeBSD client: >>> >>> 1) I can`t ssh into my IPA BSD client either as an IPA user (rsiwal) >>> or local >>> user (root); >>> >>> 2) if I restart my IPA BSD client, I also can`t login to it locally >>> as either >>> "root" or "rsiwal". I get totally locked out of the machine. >>> >>> FreeBSD displays some errors on the screen when using: >>> >>> 1) SSH: >>> https://cloud.mail.ru/public/888b415dac43%2Fssh_error_IPA_user_and_root.JPG >>> >>> >>> 2) local login: >>> https://cloud.mail.ru/public/3399c5b67c33%2Flogin_error_root_and_IPA_user.JPG >>> >>> >>> FreeBSD complains about line 19 in /etc/pam.d/system. That line reads: >>> account required /usr/local/lib/pam_sss.so ignore unknown user >> ^^^^^^^^^^^^^^^^^^^ >> it should we one word connected with >> underscores "_" >> >> See details in: >> man pam_sss -> OPTIONS >> >> It would be good to use also argument ignore_authinfo_unavail >> in pam system config otherwise you will not be able to connect as >> local user >> if sssd will be down. >> >> LS >> > From rcritten at redhat.com Thu Oct 16 14:41:12 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 16 Oct 2014 10:41:12 -0400 Subject: [Freeipa-users] ipa-client-install (Invalid Request) - no Host-Certificate In-Reply-To: <543F8B08.9000601@ww.uni-erlangen.de> References: <543F8B08.9000601@ww.uni-erlangen.de> Message-ID: <543FD908.5050202@redhat.com> Christof Schulze wrote: > Hello all, > > i am running a FreeIPA server on CentOS for 2 years now with mostly > Ubuntu 12.04 and some Fedora 20 clients. > > Since one week (or more) it is not possible any more to install new > clients (whether ubuntu nor fedora). The Host gets created on the > IPA-server but it can not create/exchange a Host-Certificate. > > The only thing happened (except regular updates) was a complete > certificate renewal with no obvious problems some weeks ago. > > Web-interface and certmonger show the same error. > > ipa-getcert list on the new Hosts: > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: 4301 (RPC failed at > server. Certificate operation cannot be completed: FAILURE (Invalid > Request)). > stuck: yes Given the timeline I'd guess that your CA subsystem certificates have expired. On the IPA master run: getcert list (not ipa-getcert) This will show the current status of things. What version of IPA is this? rob From Christof.Schulze at ww.uni-erlangen.de Thu Oct 16 15:48:56 2014 From: Christof.Schulze at ww.uni-erlangen.de (Christof.Schulze at ww.uni-erlangen.de) Date: Thu, 16 Oct 2014 17:48:56 +0200 Subject: [Freeipa-users] ipa-client-install (Invalid Request) - no Host-Certificate In-Reply-To: <543FD908.5050202@redhat.com> References: <543F8B08.9000601@ww.uni-erlangen.de> <543FD908.5050202@redhat.com> Message-ID: <84e1d53609e4ab5eae7acaca0f34951a.squirrel@faumail.uni-erlangen.de> The FreeIPA is 3.0.0 server is running on CentOS 6.5. The CA subsystem certificates have all been renewed and will expire not until 2016. In the I think the problems come from "modifications" a colleague did to /etc/httpd/ipa-pki-proxy.conf , /etc/httpd/nss.conf and /var/lib/pki-ca/conf/server.xml (without dokumentation, but they have different timestamps) when he wanted to enforce/enable higher level encrytion. I was able to reproduce some of his changes like StrictCypher and sslOptions he did, but I am not sure with the configuraion of the ports of the connectors in /var/lib/pki-ca/conf/server.xml and the /etc/httpd/conf.d/ipa-pki-proxy.conf # VERSION 2 - DO NOT REMOVE THIS LINE ProxyRequests Off # matches for ee port NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient none # ProxyPassMatch ajp://localhost:9443 # ProxyPassReverse ajp://localhost:9443 ProxyPassMatch ajp://localhost:9447 ProxyPassReverse ajp://localhost:9447 # matches for admin port and installer NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient none # ProxyPassMatch ajp://localhost:9443 # ProxyPassReverse ajp://localhost:9443 ProxyPassMatch ajp://localhost:9447 ProxyPassReverse ajp://localhost:9447 # matches for agent port and eeca port NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient require # ProxyPassMatch ajp://localhost:9443 # ProxyPassReverse ajp://localhost:9443 ProxyPassMatch ajp://localhost:9447 ProxyPassReverse ajp://localhost:9447 # Only enable this on servers that are not generating a CRL #RewriteRule ^/ipa/crl/MasterCRL.bin https://ww8-idm.ww.uni-erlangen.de/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC] Is there somewhere a example configuration? When I deployed the system it was a rather default installation. > Christof Schulze wrote: >> Hello all, >> >> i am running a FreeIPA server on CentOS for 2 years now with mostly >> Ubuntu 12.04 and some Fedora 20 clients. >> >> Since one week (or more) it is not possible any more to install new >> clients (whether ubuntu nor fedora). The Host gets created on the >> IPA-server but it can not create/exchange a Host-Certificate. >> >> The only thing happened (except regular updates) was a complete >> certificate renewal with no obvious problems some weeks ago. >> >> Web-interface and certmonger show the same error. >> >> ipa-getcert list on the new Hosts: >> status: CA_UNREACHABLE >> ca-error: Server failed request, will retry: 4301 (RPC failed at >> server. Certificate operation cannot be completed: FAILURE (Invalid >> Request)). >> stuck: yes > > Given the timeline I'd guess that your CA subsystem certificates have > expired. > > On the IPA master run: getcert list (not ipa-getcert) > > This will show the current status of things. > > What version of IPA is this? > > rob > From herlo1 at gmail.com Thu Oct 16 19:47:48 2014 From: herlo1 at gmail.com (Clint Savage) Date: Thu, 16 Oct 2014 13:47:48 -0600 Subject: [Freeipa-users] Migration fails with custom objectClasses In-Reply-To: <544015A8.1050200@redhat.com> References: <543EB51F.2030307@redhat.com> <543EC81D.9000807@redhat.com> <543ED37A.4060706@redhat.com> <543EDA27.905@redhat.com> <543EFD78.9060004@redhat.com> <543F40C0.5010903@redhat.com> <543FD15F.3030406@redhat.com> <543FFA0C.8030107@redhat.com> <543FFF7F.4050403@redhat.com> <544015A8.1050200@redhat.com> Message-ID: On Thu, Oct 16, 2014 at 12:59 PM, Rich Megginson wrote: > On 10/16/2014 11:42 AM, Clint Savage wrote: > > The access log had that information. And this error log: > https://www.dropbox.com/s/ak6za0dkr0cn7ay/errors.20141010-132318 > > > There unfortunately doesn't seem to be a debug log level that will tell > the server to dump the add request with all arguments. > > The best bet would be to get the ipa migrate tool to dump it's commands to > LDIF format, then we can look at it and figure out what it is doing wrong. > I don't know if that's possible. > Does anyone know how to accomplish what Rich suggests above? Thanks, Clint -------------- next part -------------- An HTML attachment was scrubbed... URL: From vaclav.adamec at suchy-zleb.cz Fri Oct 17 01:04:06 2014 From: vaclav.adamec at suchy-zleb.cz (Vaclav Adamec) Date: Fri, 17 Oct 2014 03:04:06 +0200 Subject: [Freeipa-users] Valid documentation for sudo setup for version 4.0.3 Message-ID: Hi, is there any valid documentation/setup to get sudo working? http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/example-configuring-sudo.html is not usable, modification of another files are needed to get at least attempts to ldap (for example on CentOS /etc/sudo-ldap.conf). Other documentation or googled setup seems to sometimes mixture of not very compatible settings. So far all attempts fails, if you want to see actual setup and state see public gist - https://gist.github.com/VAdamec/58880b3bb476a0b826e6#file-freeipa-403-debug-log Any help would be appreciated, also if there is any public training/certification please get me know (I found only RedHat which is based on older versions) Vasek -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Oct 17 01:21:46 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 16 Oct 2014 21:21:46 -0400 Subject: [Freeipa-users] Valid documentation for sudo setup for version 4.0.3 In-Reply-To: References: Message-ID: <54406F2A.6080108@redhat.com> On 10/16/2014 09:04 PM, Vaclav Adamec wrote: > Hi, > is there any valid documentation/setup to get sudo working? > http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/example-configuring-sudo.html > is not usable, modification of another files are needed to get at > least attempts to ldap (for example on CentOS /etc/sudo-ldap.conf). > Other documentation or googled setup seems to sometimes mixture of not > very compatible settings. > > So far all attempts fails, if you want to see actual setup and state > see public gist - > https://gist.github.com/VAdamec/58880b3bb476a0b826e6#file-freeipa-403-debug-log > > Any help would be appreciated, also if there is any public > training/certification please get me know (I found only RedHat which > is based on older versions) > > Vasek > > > Let us start with the version and the platform that you want to integrate. But generally the materials about how to configure SUDO using SSSD and IPA can be found here: http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf For future a lot of practical recommendations and HowTos is linked off the following page. http://www.freeipa.org/page/Documentation -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Oct 17 05:59:22 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 17 Oct 2014 08:59:22 +0300 Subject: [Freeipa-users] Valid documentation for sudo setup for version 4.0.3 In-Reply-To: References: Message-ID: <20141017055922.GA5446@redhat.com> On Fri, 17 Oct 2014, Vaclav Adamec wrote: >Hi, > is there any valid documentation/setup to get sudo working? >http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/example-configuring-sudo.html >is not usable, modification of another files are needed to get at least >attempts to ldap (for example on CentOS /etc/sudo-ldap.conf). Other >documentation or googled setup seems to sometimes mixture of not very >compatible settings. > >So far all attempts fails, if you want to see actual setup and state see >public gist - >https://gist.github.com/VAdamec/58880b3bb476a0b826e6#file-freeipa-403-debug-log > >Any help would be appreciated, also if there is any public >training/certification please get me know (I found only RedHat which is >based on older versions) FreeIPA 4.0.3 has sudo configuration integrated into ipa-client-install by default. If you don't want to use that, you can run ipa-client-install --no-sudo. Now, I'm confused by your logs. They are a mixture of unrelated things: - you have nslcd and sssd configured at the same time. Why? - you don't need to configure /etc/sudo-ldap.conf if you are using sssd. As Dmitri said, configuration described in http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf and also covered in SSSD manual pages, sssd-sudo(5). In particular, it says since sssd 1.10.0: ----------- When the SSSD is configured to use IPA as the ID provider, the sudo provider is automatically enabled. The sudo search base is configured to use the compat tree (ou=sudoers,$DC). ----------- Prior to that it included detailed configuration how to set up sudo for SSSD with IPA provider. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Oct 17 06:39:20 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 17 Oct 2014 09:39:20 +0300 Subject: [Freeipa-users] Valid documentation for sudo setup for version 4.0.3 In-Reply-To: References: <20141017055922.GA5446@redhat.com> Message-ID: <20141017063920.GB5446@redhat.com> On Fri, 17 Oct 2014, Vaclav Adamec wrote: >Mixture of bot method is result of testing, just registration via >ipa-client (maybe CentOS 6 has only ipa-client-3.0.0-37 ?) definitely not >setup anything about sudo. I'll try to build 4.0.3 client for CentOS 6, but >right now: Installing 4.x (client or server) is not supported on CentOS 6.x. You can use whatever IPA version is available there (3.0).It will not automatically configure sudo for you, there you have to follow what sssd-sudo(5) tells you to do. My primary point was that we have this documentation available on every machine where SSSD is in use, no need to search over internet. P.S. Please reply to the list, not personally. -- / Alexander Bokovoy From vaclav.adamec at suchy-zleb.cz Fri Oct 17 07:13:33 2014 From: vaclav.adamec at suchy-zleb.cz (Vaclav Adamec) Date: Fri, 17 Oct 2014 09:13:33 +0200 Subject: [Freeipa-users] Valid documentation for sudo setup for version 4.0.3 In-Reply-To: <20141017063920.GB5446@redhat.com> References: <20141017055922.GA5446@redhat.com> <20141017063920.GB5446@redhat.com> Message-ID: Thanks for your time. Man pages were the first, but it's not working just base on that. Find out that libsss_sudo is desperately needed and it's not required by ipa-client rpm. So now I only need to check sudo policy in IPA, as there is obviously some issue, but connection is working. yum install ipa-client libsss_sudo ipa-client-install ... modify: /etc/sssd/sssd.conf (ldap setup based on man) /etc/nsswitch.conf (sss provider for sudoers based on man) and result: [vaclav.adamec at ipa-client~]$ groups vaclav.adamec admins [vaclav.adamec at ipa-client ~]$ sudo -l vaclav.adamec is not allowed to run sudo on ipa-client. This incident will be reported. (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting rules for [vaclav.adamec] from [] (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requesting info about [vaclav.adamec at test] (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [vaclav.adamec at test] (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving rules for [vaclav.adamec] from [test] (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=vaclav.adamec)(sudoUser=#1085800001)(sudoUser=%admins)(sudoUser=%vaclav.adamec)(sudoUser=+*))(&(dataExpireTimestamp<=1413529436)))] (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to get sudo rules from cache (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=vaclav.adamec)(sudoUser=#1085800001)(sudoUser=%admins)(sudoUser=%vaclav.adamec)(sudoUser=+*)))] (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 1 rules for [vaclav.adamec at test] but ldap search: ldapsearch -x -h localhost -p 389 -b ou=sudoers,dc=test # sudoers, test dn: ou=sudoers,dc=test objectClass: extensibleObject ou: sudoers # Admins_can_do_anything, sudoers, test dn: cn=Admins_can_run_whomai_as_root,ou=sudoers,dc=test sudoUser: %admins sudoHost: +all objectClass: sudoRole objectClass: top sudoRunAsUser: root sudoCommand: /usr/bin/whoami cn: Admins_can_run_whomai_as_root # search result search: 2 result: 0 Success On Fri, Oct 17, 2014 at 8:39 AM, Alexander Bokovoy wrote: > On Fri, 17 Oct 2014, Vaclav Adamec wrote: > >> Mixture of bot method is result of testing, just registration via >> ipa-client (maybe CentOS 6 has only ipa-client-3.0.0-37 ?) definitely not >> setup anything about sudo. I'll try to build 4.0.3 client for CentOS 6, >> but >> right now: >> > Installing 4.x (client or server) is not supported on CentOS 6.x. You > can use whatever IPA version is available there (3.0).It will not > automatically configure sudo for you, there you have to follow what > sssd-sudo(5) tells you to do. > > My primary point was that we have this documentation available on every > machine where SSSD is in use, no need to search over internet. > > P.S. Please reply to the list, not personally. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From orkhan-azeri at mail.ru Fri Oct 17 07:27:51 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Fri, 17 Oct 2014 12:27:51 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <543FC6EB.1070509@mail.ru> References: <1413223812.36347990@f357.i.mail.ru> <20141013183307.GH3279@hendrix.brq.redhat.com> <20141013193245.GA27164@mail.corp.redhat.com> <543CD1F1.603@mail.ru> <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> <20141014131305.GE3104@mail.corp.redhat.com> <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> Message-ID: <5440C4F7.3080400@mail.ru> Replying to myself is great... Anyway, maybe this info will be useful for people like me, trying to integrate FreeBSD with FreeIPA. Solved some problems: 1. "SSH-ing as existing IPA user "rsiwal" to my FreeBSD client fails. The same user can SSH or locally login to my Linux client. " That happened because the shell specified for user "rsiwal" was /bin/bash. After changing it to /bin/sh that problem disappeared. 2. "At the same time I cannot locally login to my FreeBSD host as either IPA user or local user." I posted the cause and solution at FreeBSD forums: https://forums.freebsd.org/threads/freebsd-freeipa-via-sssd.46526/ 3. "If I create a new user in IPA, he can`t initially SSH into FreeBSD client. BSD says: "password expired", but doesn`t take new password. The same new user can SSH into my Linux client. Linux says: "password expired" and allows to set a new password with a message: "All authentication tokens updated successfully." After I set a new password for my newly created user via Linux, I can SSH into my BSD client as that user. Using this hack I can create new users in IPA, SSH into Linux to change their passwords and then use those new users to SSH into FreeBSD." Didn`t find a solution yet. But I think this is caused by lack of proper configuration of Kerberos on my FreeBSD client. On my Linux client I found such a configuration in /etc/krb5.conf file. However, there's no such file on my FreeBSD client, as the post on FreeBSD forums didn't say anything about such a file. I'll do some more checks and share the results here. 16-Oct-14 18:23, Orkhan Gasimov ?????: > Here`s what I have at the end of the day after various checks. > > SSH-ing as existing IPA user "rsiwal" to my FreeBSD client fails. > The same user can SSH or locally login to my Linux client. > If I create a new user in IPA, he can`t initially SSH into FreeBSD > client. > BSD says: "password expired", but doesn`t take new password. > The same new user can SSH into my Linux client. > Linux says: "password expired" and allows to set a new password with a > message: "All authentication tokens updated successfully." > After I set a new password for my newly created user via Linux, I can > SSH into my BSD client as that user. > Using this hack I can create new users in IPA, SSH into Linux to > change their passwords and then use those new users to SSH into FreeBSD. > At the same time I cannot locally login to my FreeBSD host as either > IPA user or local user. > > I think there`s something wrong with Kerberos setup on my FreeBSD > client. I suspect that because both /etc/pam.d/system and > /etc/pam.d/sshd files on the BSD client have a string: > password sufficient /usr/local/lib/pam_sss.so use_authtok > but BSD doesn`t let update authentication tokens when trying to change > expired password for a new user. > > There was minimal info about Kerberos setup on FreeBSD client in the > post at FreeBSD forums. Just this: "create a keytab on the IPA server > and copy it to /etc/krb5.keytab" on the FreeBSD client. > > Someone here wrote that he can contact the author of that post. If so, > please tell the author to spend a couple of hours to: > 1) check everything he advised on a blank setup with VMs; > 2) provide more details about correct sequence of actions. > > Any help will be highly appreciated! > > 16-Oct-14 15:13, Orkhan Gasimov ?????: >> Please excuse me for that silly typo in the letter. The typo doesn`t >> exist either in /etc/pam.d/system or /etc/pam.d/sshd - in those files >> I typed "ignore_unknown_user". >> >> I'll try "ignore_authinfo_unavail" to see if it prevents me from >> being locked out of the machine. >> >> Here are the log files: >> >> sssd_eurosel.az.log: >> https://cloud.mail.ru/public/1e803a00989e%2Fsssd_eurosel.az.log >> sssd_nss.log: https://cloud.mail.ru/public/ae41ae3b44b6%2Fsssd_nss.log >> sssd_pam.log: https://cloud.mail.ru/public/85d311ec1d4e%2Fsssd_pam.log >> krb5_child.log: >> https://cloud.mail.ru/public/c0e6712b7f1b%2Fkrb5_child.log >> ldap_child.log: >> https://cloud.mail.ru/public/d9b0b1eb0da6%2Fldap_child.log >> sssd_log: https://cloud.mail.ru/public/d4032b8e6645%2Fsssd.log >> >> >> 16-Oct-14 14:57, Lukas Slebodnik ?????: >>> On (16/10/14 13:04), Orkhan Gasimov wrote: >>>> OK, back to FreeIPA - FreeBSD setup. >>>> I changed my setup: instead of 2 VMs now I have 4 VMs: >>>> >>>> 1: DNS server - set up as shown by Rajnesh Kumar Siwal in >>>> http://www.youtube.com/watch?v=0SmiwFoHVeI&index=4&list=PLdKXnZQzEG-KmtKq-LelPn5RTKfJig0Wc >>>> >>>> 2 and 3: IPA server & IPA linux client - set up as shown by Rajnesh >>>> Kumar >>>> Siwal in http://www.youtube.com/watch?v=_zlcxjkbayk >>>> >>>> 4: IPA BSD client - set up as described in the post at FreeBSD forums. >>>> >>>> >>>> Results: >>>> >>>> 1) my IPA linux client interacts fine with the IPA server; >>>> >>>> 2) my IPA BSD client also interacts with the IPA server: it sees >>>> IPA users >>>> when issuing "getent passwd" or "getent shadow". (Previously when I >>>> used just >>>> 2 VMs and no DNS server, that didn`t happen.) >>>> >>>> Problems after I start sssd on the FreeBSD client: >>>> >>>> 1) I can`t ssh into my IPA BSD client either as an IPA user >>>> (rsiwal) or local >>>> user (root); >>>> >>>> 2) if I restart my IPA BSD client, I also can`t login to it locally >>>> as either >>>> "root" or "rsiwal". I get totally locked out of the machine. >>>> >>>> FreeBSD displays some errors on the screen when using: >>>> >>>> 1) SSH: >>>> https://cloud.mail.ru/public/888b415dac43%2Fssh_error_IPA_user_and_root.JPG >>>> >>>> >>>> 2) local login: >>>> https://cloud.mail.ru/public/3399c5b67c33%2Flogin_error_root_and_IPA_user.JPG >>>> >>>> >>>> FreeBSD complains about line 19 in /etc/pam.d/system. That line reads: >>>> account required /usr/local/lib/pam_sss.so ignore unknown user >>> ^^^^^^^^^^^^^^^^^^^ >>> it should we one word connected with >>> underscores "_" >>> >>> See details in: >>> man pam_sss -> OPTIONS >>> >>> It would be good to use also argument ignore_authinfo_unavail >>> in pam system config otherwise you will not be able to connect as >>> local user >>> if sssd will be down. >>> >>> LS >>> >> > From abokovoy at redhat.com Fri Oct 17 08:21:05 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 17 Oct 2014 11:21:05 +0300 Subject: [Freeipa-users] Valid documentation for sudo setup for version 4.0.3 In-Reply-To: References: <20141017055922.GA5446@redhat.com> <20141017063920.GB5446@redhat.com> Message-ID: <20141017082105.GC5446@redhat.com> On Fri, 17 Oct 2014, Vaclav Adamec wrote: >Thanks for your time. Man pages were the first, but it's not working just >base on that. Find out that libsss_sudo is desperately needed and it's not >required by ipa-client rpm. So now I only need to check sudo policy in IPA, >as there is obviously some issue, but connection is working. This was work in progress in RHEL6.x, we didn't setup sudo from ipa-client-instal, we weren't forcing it rpm-wise. Now, with SSSD 1.10 and above SSSD packages libsss_sudo in the main SSSD package, sssd-common, so there is no need to add more dependencies. >yum install ipa-client libsss_sudo >ipa-client-install ... >modify: >/etc/sssd/sssd.conf (ldap setup based on man) >/etc/nsswitch.conf (sss provider for sudoers based on man) > >and result: > >[vaclav.adamec at ipa-client~]$ groups >vaclav.adamec admins > >[vaclav.adamec at ipa-client ~]$ sudo -l >vaclav.adamec is not allowed to run sudo on ipa-client. This incident will >be reported. > >(Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_cmd_parse_query_done] >(0x0200): Requesting rules for [vaclav.adamec] from [] >(Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_user] (0x0200): >Requesting info about [vaclav.adamec at test] >(Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_user] (0x0400): >Returning info for user [vaclav.adamec at test] >(Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_rules] (0x0400): >Retrieving rules for [vaclav.adamec] from [test] >(Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] >(0x0200): Searching sysdb with >[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=vaclav.adamec)(sudoUser=#1085800001)(sudoUser=%admins)(sudoUser=%vaclav.adamec)(sudoUser=+*))(&(dataExpireTimestamp<=1413529436)))] >(Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About >to get sudo rules from cache >(Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] >(0x0200): Searching sysdb with >[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=vaclav.adamec)(sudoUser=#1085800001)(sudoUser=%admins)(sudoUser=%vaclav.adamec)(sudoUser=+*)))] >(Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] >(0x0400): Returning 1 rules for [vaclav.adamec at test] > >but ldap search: > > ldapsearch -x -h localhost -p 389 -b ou=sudoers,dc=test > ># sudoers, test >dn: ou=sudoers,dc=test >objectClass: extensibleObject >ou: sudoers > ># Admins_can_do_anything, sudoers, test >dn: cn=Admins_can_run_whomai_as_root,ou=sudoers,dc=test >sudoUser: %admins >sudoHost: +all >objectClass: sudoRole >objectClass: top >sudoRunAsUser: root >sudoCommand: /usr/bin/whoami >cn: Admins_can_run_whomai_as_root > ># search result >search: 2 >result: 0 Success Both the SSSD logs and your ldapsearch say that they found the rule. However, you didn't show logs for applying the rule. Sudo integration is a bit complex. Since sudo 1.8.8, there is a code in sudo which implements sudoers support through SSSD and there is a code in SSSD which complements the sudo's part by supplying actual data to the sudo part. Sudo code dynamically loads SSSD module and actual debugging info about parsing rules is available from the sudo. To enable the debugging, make a /etc/sudo.conf file with a line: Debug sudo /var/log/sudo_debug all at info If you would run a sudo command that wouldn't match any of the rules, you'd see following output in /var/log/sudo_debug: Oct 17 11:16:36 sudo[3794] username=admin Oct 17 11:16:36 sudo[3794] domainname=NULL Oct 17 11:16:36 sudo[3794] Received 1 rule(s) Oct 17 11:16:36 sudo[3794] netgroup c21.ipacloud.test has no leading '+' Oct 17 11:16:36 sudo[3794] sssd/ldap sudoHost 'cc21.ipacloud.test' ... MATCH! Oct 17 11:16:36 sudo[3794] netgroup admins has no leading '+' Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=6 Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=1 Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=1 Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=1 Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=1 Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=1 Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=1 Oct 17 11:16:36 sudo[3794] searching SSSD/LDAP for sudoers entries Oct 17 11:16:36 sudo[3794] sssd/ldap sudoRunAsUser 'root' ... MATCH! Oct 17 11:16:36 sudo[3794] sssd/ldap sudoCommand '/usr/bin/whoami' ... not Oct 17 11:16:36 sudo[3794] Done with LDAP searches The last 'not' is an indicator the command is refused thanks to the rule. For correct match you'd get something like this: Oct 17 11:19:36 sudo[3835] username=admin Oct 17 11:19:36 sudo[3835] domainname=NULL Oct 17 11:19:36 sudo[3835] Received 1 rule(s) Oct 17 11:19:36 sudo[3835] netgroup c21.ipacloud.test has no leading '+' Oct 17 11:19:36 sudo[3835] sssd/ldap sudoHost 'cc21.ipacloud.test' ... MATCH! Oct 17 11:19:36 sudo[3835] netgroup admins has no leading '+' Oct 17 11:19:36 sudo[3835] sudo_emalloc: cnt=6 Oct 17 11:19:36 sudo[3835] sudo_emalloc: cnt=1 Oct 17 11:19:36 sudo[3835] sudo_emalloc: cnt=1 Oct 17 11:19:36 sudo[3835] sudo_emalloc: cnt=1 Oct 17 11:19:36 sudo[3835] sudo_emalloc: cnt=1 Oct 17 11:19:36 sudo[3835] sudo_emalloc: cnt=1 Oct 17 11:19:36 sudo[3835] sudo_emalloc: cnt=1 Oct 17 11:19:36 sudo[3835] searching SSSD/LDAP for sudoers entries Oct 17 11:19:36 sudo[3835] sssd/ldap sudoRunAsUser 'root' ... MATCH! Oct 17 11:19:36 sudo[3835] sssd/ldap sudoCommand '/usr/bin/whoami' ... MATCH! Oct 17 11:19:36 sudo[3835] Command allowed Oct 17 11:19:36 sudo[3835] No result. Oct 17 11:19:36 sudo[3835] Done with LDAP searches # ipa sudorule-show admins_can_run_as_root Rule name: admins_can_run_as_root Description: Admins can run as root Enabled: TRUE User Groups: admins Hosts: cc21.ipacloud.test Sudo Allow Commands: /usr/bin/whoami RunAs External User: root # su - admin $ sudo whoami root $ sudo -l [sudo] password for admin: Matching Defaults entries for admin on cc21: !visiblepw, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin User admin may run the following commands on cc21: (root) /usr/bin/whoami $ logout > >On Fri, Oct 17, 2014 at 8:39 AM, Alexander Bokovoy >wrote: > >> On Fri, 17 Oct 2014, Vaclav Adamec wrote: >> >>> Mixture of bot method is result of testing, just registration via >>> ipa-client (maybe CentOS 6 has only ipa-client-3.0.0-37 ?) definitely not >>> setup anything about sudo. I'll try to build 4.0.3 client for CentOS 6, >>> but >>> right now: >>> >> Installing 4.x (client or server) is not supported on CentOS 6.x. You >> can use whatever IPA version is available there (3.0).It will not >> automatically configure sudo for you, there you have to follow what >> sssd-sudo(5) tells you to do. >> >> My primary point was that we have this documentation available on every >> machine where SSSD is in use, no need to search over internet. >> >> P.S. Please reply to the list, not personally. >> >> -- >> / Alexander Bokovoy >> >-- >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 -- / Alexander Bokovoy From abokovoy at redhat.com Fri Oct 17 09:01:28 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 17 Oct 2014 12:01:28 +0300 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <5440C4F7.3080400@mail.ru> References: <20141013193245.GA27164@mail.corp.redhat.com> <543CD1F1.603@mail.ru> <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> <20141014131305.GE3104@mail.corp.redhat.com> <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> Message-ID: <20141017090128.GD5446@redhat.com> On Fri, 17 Oct 2014, Orkhan Gasimov wrote: >Replying to myself is great... Anyway, maybe this info will be useful >for people like me, trying to integrate FreeBSD with FreeIPA. > >Solved some problems: > >1. "SSH-ing as existing IPA user "rsiwal" to my FreeBSD client fails. >The same user can SSH or locally login to my Linux client. " > >That happened because the shell specified for user "rsiwal" was >/bin/bash. After changing it to /bin/sh that problem disappeared. SSH does multi-level checks. Not only user should exist on the system and authentication should pass but also there should be a correct shell to run. Unfortunately, FreeBSD doesn't have bash in the default installation. It is up to admins to provide appropriate configuration either by setting right shell in IPA or by preparing system environment on all hosts where the selected shell is required. With FreeIPA 4.1 we are going to provide a mechanism to re-define some of user attributes per-host but it would require a newer SSSD (or use of compat tree) at the client side. > >2. "At the same time I cannot locally login to my FreeBSD host as >either IPA user or local user." > >I posted the cause and solution at FreeBSD forums: >https://forums.freebsd.org/threads/freebsd-freeipa-via-sssd.46526/ Well, note that since FreeIPA 3.3 we have support for so-called 'advices' in FreeIPA. See ipa-advise tool on IPA server. Currently it only provides you with config-freebsd-nss-pam-ldapd advise to configure FreeBSD with nss-pam-ldapd, but we can extend that to have SSSD covered too. > >3. "If I create a new user in IPA, he can`t initially SSH into FreeBSD >client. >BSD says: "password expired", but doesn`t take new password. >The same new user can SSH into my Linux client. >Linux says: "password expired" and allows to set a new password with a >message: "All authentication tokens updated successfully." >After I set a new password for my newly created user via Linux, I can >SSH into my BSD client as that user. >Using this hack I can create new users in IPA, SSH into Linux to >change their passwords and then use those new users to SSH into >FreeBSD." > >Didn`t find a solution yet. But I think this is caused by lack of >proper configuration of Kerberos on my FreeBSD client. On my Linux >client I found such a configuration in /etc/krb5.conf file. However, >there's no such file on my FreeBSD client, as the post on FreeBSD >forums didn't say anything about such a file. I'll do some more checks >and share the results here. Well, follow your Kerberos library defaults. By default FreeBSD is built with Heimdal so if your system uses Heimdal and SSSD is build against it, then configure /etc/krb5.conf as [libdefaults] default_realm = EXAMPLE.ORG [realms] EXAMPLE.ORG = { kdc = kerberos.example.org admin_server = kerberos.example.org } [domain_realm] .example.org = EXAMPLE.ORG Where kerberos.example.org is your IPA master. -- / Alexander Bokovoy From lslebodn at redhat.com Fri Oct 17 09:15:30 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 17 Oct 2014 11:15:30 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <5440C4F7.3080400@mail.ru> References: <20141013193245.GA27164@mail.corp.redhat.com> <543CD1F1.603@mail.ru> <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> <20141014131305.GE3104@mail.corp.redhat.com> <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> Message-ID: <20141017091529.GC27524@mail.corp.redhat.com> On (17/10/14 12:27), Orkhan Gasimov wrote: >Replying to myself is great... Anyway, maybe this info will be useful for >people like me, trying to integrate FreeBSD with FreeIPA. > >Solved some problems: > >1. "SSH-ing as existing IPA user "rsiwal" to my FreeBSD client fails. The >same user can SSH or locally login to my Linux client. " > >That happened because the shell specified for user "rsiwal" was /bin/bash. >After changing it to /bin/sh that problem disappeared. It needn't be changed in LDAP(IPA). You can change(overrride) shell on client side. For details see: man sssd.conf -> override_shell > >2. "At the same time I cannot locally login to my FreeBSD host as either IPA >user or local user." > >I posted the cause and solution at FreeBSD forums: >https://forums.freebsd.org/threads/freebsd-freeipa-via-sssd.46526/ > In post you wrote: The problem is in this string in the /etc/pam.d/system file: account required /usr/local/lib/pam_sss.so ignore_unknown_user That string gives login errors, with or without ignore_unknown_user part. The only solution I found for now is to comment that string out and add it explicitly into /etc/pam.d/login file. Then local login process proceeds without errors. File /etc/pam.d/system is included by /etc/pam.d/login. I cannot see a difference. BTW: You tested access with sshd, but file /etc/pam.d/system needn't be used in /etc/pam.d/sshd which is used by sshd. I would reccomend to have next line in /etc/pam.d/system and /etc/pam.d/sshd. Without this line, access control will not work. (HBAC) account required /usr/local/lib/pam_sss.so ignore_unknown_user ignore_authinfo_unavail >3. "If I create a new user in IPA, he can`t initially SSH into FreeBSD >client. >BSD says: "password expired", but doesn`t take new password. >The same new user can SSH into my Linux client. >Linux says: "password expired" and allows to set a new password with a >message: "All authentication tokens updated successfully." >After I set a new password for my newly created user via Linux, I can SSH >into my BSD client as that user. >Using this hack I can create new users in IPA, SSH into Linux to change their >passwords and then use those new users to SSH into FreeBSD." > >Didn`t find a solution yet. But I think this is caused by lack of proper >configuration of Kerberos on my FreeBSD client. On my Linux client I found >such a configuration in /etc/krb5.conf file. However, there's no such file on >my FreeBSD client, as the post on FreeBSD forums didn't say anything about >such a file. I'll do some more checks and share the results here. FreeIPA requires to change password for new users. Unfortunatelly, it is not possible to change password for ldap (sssd) users in FreeBSD. It is described in FreeBSD ldap client documentation (which uses nss-pam-ldapd) https://www.freebsd.org/doc/en/articles/ldap-auth/client.html#caveats LS From lslebodn at redhat.com Fri Oct 17 09:21:49 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 17 Oct 2014 11:21:49 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141017090128.GD5446@redhat.com> References: <543CD1F1.603@mail.ru> <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> <20141014131305.GE3104@mail.corp.redhat.com> <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017090128.GD5446@redhat.com> Message-ID: <20141017092148.GD27524@mail.corp.redhat.com> On (17/10/14 12:01), Alexander Bokovoy wrote: >>Didn`t find a solution yet. But I think this is caused by lack of proper >>configuration of Kerberos on my FreeBSD client. On my Linux client I found >>such a configuration in /etc/krb5.conf file. However, there's no such file >>on my FreeBSD client, as the post on FreeBSD forums didn't say anything >>about such a file. I'll do some more checks and share the results here. >Well, follow your Kerberos library defaults. By default FreeBSD is built >with Heimdal so if your system uses Heimdal and SSSD is build against It is true that default Kerberos library on FreeBSD is Heimdal. It is stored in default paths (/usr/bin, /usr/lib). SSSD does not work with Heimdal, therefore it is linked with MIT krb5 >= 1.10 on FreeBSD, which is stored in (/usr/local/bin, /usr/local/lib) LS From orkhan-azeri at mail.ru Fri Oct 17 10:14:32 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Fri, 17 Oct 2014 15:14:32 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141017091529.GC27524@mail.corp.redhat.com> References: <20141013193245.GA27164@mail.corp.redhat.com> <543CD1F1.603@mail.ru> <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> <20141014131305.GE3104@mail.corp.redhat.com> <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017091529.GC27524@mail.corp.redhat.com> Message-ID: <5440EC08.7090304@mail.ru> 1. You wrote: File /etc/pam.d/system is included by /etc/pam.d/login. I cannot see a difference. There should not be any difference, but the frustrating point is - THERE IS DIFFERENCE! That's why I replied to that post at FreeBSD forums. A bug might be present either in PAM modules or in SSSD (I'm not a programmer, so can't determine where exactly). 2. Another moment: BTW: You tested access with sshd, but file /etc/pam.d/system needn't be used in /etc/pam.d/sshd which is used by sshd. I was talking about local logins, not about SSH access: "At the same time I cannot locally login to my FreeBSD host as either IPA user or local user." 3. About changing passwords: Unfortunatelly, it is not possible to change password for ldap (sssd) users in FreeBSD. It is described in FreeBSD ldap client documentation (which uses nss-pam-ldapd) https://www.freebsd.org/doc/en/articles/ldap-auth/client.html#caveats This really explains a lot, thanks for this link. They write :"...most administrators are left to implement a solution themselves." As of now, my solution is to create a dummy Linux client just for changing passwords. 17-Oct-14 14:15, Lukas Slebodnik ?????: > On (17/10/14 12:27), Orkhan Gasimov wrote: >> Replying to myself is great... Anyway, maybe this info will be useful for >> people like me, trying to integrate FreeBSD with FreeIPA. >> >> Solved some problems: >> >> 1. "SSH-ing as existing IPA user "rsiwal" to my FreeBSD client fails. The >> same user can SSH or locally login to my Linux client. " >> >> That happened because the shell specified for user "rsiwal" was /bin/bash. >> After changing it to /bin/sh that problem disappeared. > It needn't be changed in LDAP(IPA). You can change(overrride) shell on client > side. > For details see: > man sssd.conf -> override_shell > >> 2. "At the same time I cannot locally login to my FreeBSD host as either IPA >> user or local user." >> >> I posted the cause and solution at FreeBSD forums: >> https://forums.freebsd.org/threads/freebsd-freeipa-via-sssd.46526/ >> > In post you wrote: > The problem is in this string in the /etc/pam.d/system file: > account required /usr/local/lib/pam_sss.so ignore_unknown_user > > That string gives login errors, with or without ignore_unknown_user part. > The only solution I found for now is to comment that string out and add it > explicitly into /etc/pam.d/login file. Then local login process proceeds > without errors. > > File /etc/pam.d/system is included by /etc/pam.d/login. I cannot see a > difference. > > BTW: You tested access with sshd, but file /etc/pam.d/system needn't be used > in /etc/pam.d/sshd which is used by sshd. > > I would reccomend to have next line in /etc/pam.d/system and /etc/pam.d/sshd. > Without this line, access control will not work. (HBAC) > account required /usr/local/lib/pam_sss.so ignore_unknown_user ignore_authinfo_unavail > > >> 3. "If I create a new user in IPA, he can`t initially SSH into FreeBSD >> client. >> BSD says: "password expired", but doesn`t take new password. >> The same new user can SSH into my Linux client. >> Linux says: "password expired" and allows to set a new password with a >> message: "All authentication tokens updated successfully." >> After I set a new password for my newly created user via Linux, I can SSH >> into my BSD client as that user. >> Using this hack I can create new users in IPA, SSH into Linux to change their >> passwords and then use those new users to SSH into FreeBSD." >> >> Didn`t find a solution yet. But I think this is caused by lack of proper >> configuration of Kerberos on my FreeBSD client. On my Linux client I found >> such a configuration in /etc/krb5.conf file. However, there's no such file on >> my FreeBSD client, as the post on FreeBSD forums didn't say anything about >> such a file. I'll do some more checks and share the results here. > FreeIPA requires to change password for new users. > Unfortunatelly, it is not possible to change password for ldap (sssd) users > in FreeBSD. It is described in FreeBSD ldap client documentation (which uses > nss-pam-ldapd) > https://www.freebsd.org/doc/en/articles/ldap-auth/client.html#caveats > > LS -------------- next part -------------- An HTML attachment was scrubbed... URL: From orkhan-azeri at mail.ru Fri Oct 17 10:22:30 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Fri, 17 Oct 2014 15:22:30 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141017090128.GD5446@redhat.com> References: <20141013193245.GA27164@mail.corp.redhat.com> <543CD1F1.603@mail.ru> <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> <20141014131305.GE3104@mail.corp.redhat.com> <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017090128.GD5446@redhat.com> Message-ID: <5440EDE6.2060306@mail.ru> This idea is great, it would be invaluable for many people trying to integrate FreeBSD with FreeIPA. Currently there's only one post about this at FreeBSD forums, but it's not detailed and tells nothing about many cavets of the process. You would have helped a lot of people to avoid frustration. 17-Oct-14 14:01, Alexander Bokovoy ?????: > See ipa-advise tool on IPA server. Currently it > only provides you with config-freebsd-nss-pam-ldapd advise to configure > FreeBSD with nss-pam-ldapd, but we can extend that to have SSSD covered > too. From abokovoy at redhat.com Fri Oct 17 10:37:59 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 17 Oct 2014 13:37:59 +0300 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <5440EDE6.2060306@mail.ru> References: <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> <20141014131305.GE3104@mail.corp.redhat.com> <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017090128.GD5446@redhat.com> <5440EDE6.2060306@mail.ru> Message-ID: <20141017103759.GF5446@redhat.com> On Fri, 17 Oct 2014, Orkhan Gasimov wrote: >This idea is great, it would be invaluable for many people trying to >integrate FreeBSD with FreeIPA. Currently there's only one post about >this at FreeBSD forums, but it's not detailed and tells nothing about >many cavets of the process. >You would have helped a lot of people to avoid frustration. FreeIPA is an open source project where anyone can contribute in their areas of interest. You are welcome to contribute recipes for FreeBSD. The code is around https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/advise/plugins/legacy_clients.py As you can see, most recipes are structured in easy way and adding new is as simple as adding new class definition there. > >17-Oct-14 14:01, Alexander Bokovoy ?????: >>See ipa-advise tool on IPA server. Currently it >>only provides you with config-freebsd-nss-pam-ldapd advise to configure >>FreeBSD with nss-pam-ldapd, but we can extend that to have SSSD covered >>too. > -- / Alexander Bokovoy From orkhan-azeri at mail.ru Fri Oct 17 10:44:48 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Fri, 17 Oct 2014 15:44:48 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141017091529.GC27524@mail.corp.redhat.com> References: <20141013193245.GA27164@mail.corp.redhat.com> <543CD1F1.603@mail.ru> <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> <20141014131305.GE3104@mail.corp.redhat.com> <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017091529.GC27524@mail.corp.redhat.com> Message-ID: <5440F320.4010106@mail.ru> Unfortunately, putting that line in /etc/pam.d/system prevents me from being able to locally login to the BSD client. At the same time, the same line in /etc/pam.d/sshd or /etc/pam.d/login doesn't give unexpected behaviours. Bug, bug, bug... 17-Oct-14 14:15, Lukas Slebodnik ?????: > I would reccomend to have next line in /etc/pam.d/system and /etc/pam.d/sshd. > Without this line, access control will not work. (HBAC) > account required /usr/local/lib/pam_sss.so ignore_unknown_user ignore_authinfo_unavail From mkosek at redhat.com Fri Oct 17 10:50:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 17 Oct 2014 12:50:53 +0200 Subject: [Freeipa-users] Valid documentation for sudo setup for version 4.0.3 In-Reply-To: <20141017082105.GC5446@redhat.com> References: <20141017055922.GA5446@redhat.com> <20141017063920.GB5446@redhat.com> <20141017082105.GC5446@redhat.com> Message-ID: <5440F48D.90806@redhat.com> On 10/17/2014 10:21 AM, Alexander Bokovoy wrote: > On Fri, 17 Oct 2014, Vaclav Adamec wrote: >> Thanks for your time. Man pages were the first, but it's not working just >> base on that. Find out that libsss_sudo is desperately needed and it's not >> required by ipa-client rpm. So now I only need to check sudo policy in IPA, >> as there is obviously some issue, but connection is working. > This was work in progress in RHEL6.x, we didn't setup sudo from > ipa-client-instal, we weren't forcing it rpm-wise. Now, with SSSD 1.10 > and above SSSD packages libsss_sudo in the main SSSD package, > sssd-common, so there is no need to add more dependencies. Please note that ipa-client-install in RHEL-6.6 now also configures sudo automatically! See https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.6_Release_Notes/authentication.html for the release note. Martin From orkhan-azeri at mail.ru Fri Oct 17 11:01:25 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Fri, 17 Oct 2014 16:01:25 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141017103759.GF5446@redhat.com> References: <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> <20141014131305.GE3104@mail.corp.redhat.com> <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017090128.GD5446@redhat.com> <5440EDE6.2060306@mail.ru> <20141017103759.GF5446@redhat.com> Message-ID: <5440F705.9060402@mail.ru> That format is not simple for me, as I'm not a programmer. But after I check, double-check and triple-check my FreeBSD - FreeIPA integration via SSSD and assure that it works without unexpected behaviors, I'll probably write a HOW-TO on this process and post it at FreeBSD forums. I'll then share the link to my post here, so that: 1) FreeIPA community could also check the post for any errors; 2) someone more prepared could translate the whole process into the format appropriate for the ipa-advise tool. 17-Oct-14 15:37, Alexander Bokovoy ?????: > FreeIPA is an open source project where anyone can contribute in their > areas of interest. You are welcome to contribute recipes for FreeBSD. > > The code is around > https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/advise/plugins/legacy_clients.py > > > As you can see, most recipes are structured in easy way and adding new > is as simple as adding new class definition there. From mkosek at redhat.com Fri Oct 17 11:17:11 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 17 Oct 2014 13:17:11 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <5440F705.9060402@mail.ru> References: <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> <20141014131305.GE3104@mail.corp.redhat.com> <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017090128.GD5446@redhat.com> <5440EDE6.2060306@mail.ru> <20141017103759.GF5446@redhat.com> <5440F705.9060402@mail.ru> Message-ID: <5440FAB7.2090801@redhat.com> On 10/17/2014 01:01 PM, Orkhan Gasimov wrote: > That format is not simple for me, as I'm not a programmer. But after I check, > double-check and triple-check my FreeBSD - FreeIPA integration via SSSD and > assure that it works without unexpected behaviors, I'll probably write a HOW-TO > on this process and post it at FreeBSD forums. Thanks! Would you consider also adding the HOWTO to http://www.freeipa.org/page/HowTos so that other people can follow your steps? > I'll then share the link to my > post here, so that: > 1) FreeIPA community could also check the post for any errors; > 2) someone more prepared could translate the whole process into the format > appropriate for the ipa-advise tool. > > 17-Oct-14 15:37, Alexander Bokovoy ?????: >> FreeIPA is an open source project where anyone can contribute in their >> areas of interest. You are welcome to contribute recipes for FreeBSD. >> >> The code is around >> https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/advise/plugins/legacy_clients.py >> >> >> As you can see, most recipes are structured in easy way and adding new >> is as simple as adding new class definition there. > From orkhan-azeri at mail.ru Fri Oct 17 11:28:35 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Fri, 17 Oct 2014 16:28:35 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <5440FAB7.2090801@redhat.com> References: <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> <20141014131305.GE3104@mail.corp.redhat.com> <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017090128.GD5446@redhat.com> <5440EDE6.2060306@mail.ru> <20141017103759.GF5446@redhat.com> <5440F705.9060402@mail.ru> <5440FAB7.2090801@redhat.com> Message-ID: <5440FD63.1040309@mail.ru> Of course! But for now I'm in process of checking my integration and there are some things I don't like. First and foremost, any change on the IPA server is not automatically reflected on the BSD client. Only after SSSD is manually restarted on the client, something like it's cache is cleared happens and new rules apply. For now I'm not even checking something complex like sudo rule groups with host groups, it's just a simple sudo rule for a single user. I hope for collaboration with other interested people to find a stable solution for FreeIPA - FreeBSD interaction via SSSD, so that as a result of all this effort a well-detailed tutorial could be written and shared with all *nix users. 17-Oct-14 16:17, Martin Kosek ?????: > On 10/17/2014 01:01 PM, Orkhan Gasimov wrote: >> That format is not simple for me, as I'm not a programmer. But after I check, >> double-check and triple-check my FreeBSD - FreeIPA integration via SSSD and >> assure that it works without unexpected behaviors, I'll probably write a HOW-TO >> on this process and post it at FreeBSD forums. > Thanks! Would you consider also adding the HOWTO to > http://www.freeipa.org/page/HowTos > so that other people can follow your steps? > >> I'll then share the link to my >> post here, so that: >> 1) FreeIPA community could also check the post for any errors; >> 2) someone more prepared could translate the whole process into the format >> appropriate for the ipa-advise tool. >> >> 17-Oct-14 15:37, Alexander Bokovoy ?????: >>> FreeIPA is an open source project where anyone can contribute in their >>> areas of interest. You are welcome to contribute recipes for FreeBSD. >>> >>> The code is around >>> https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/advise/plugins/legacy_clients.py >>> >>> >>> As you can see, most recipes are structured in easy way and adding new >>> is as simple as adding new class definition there. From lslebodn at redhat.com Fri Oct 17 11:30:23 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 17 Oct 2014 13:30:23 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <5440F320.4010106@mail.ru> References: <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> <20141014131305.GE3104@mail.corp.redhat.com> <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017091529.GC27524@mail.corp.redhat.com> <5440F320.4010106@mail.ru> Message-ID: <20141017113022.GE27524@mail.corp.redhat.com> On (17/10/14 15:44), Orkhan Gasimov wrote: >Unfortunately, putting that line in /etc/pam.d/system prevents me from being >able to locally login to the BSD client. >At the same time, the same line in /etc/pam.d/sshd or /etc/pam.d/login >doesn't give unexpected behaviours. >Bug, bug, bug... > It works for me with FreeBSD 9.3. It is possible that your pam stack is misconfigured. Which version of FreBSD do you use? Could you send me all files from /etc/pam.d/? LS From mkosek at redhat.com Fri Oct 17 11:33:41 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 17 Oct 2014 13:33:41 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <5440FD63.1040309@mail.ru> References: <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> <20141014131305.GE3104@mail.corp.redhat.com> <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017090128.GD5446@redhat.com> <5440EDE6.2060306@mail.ru> <20141017103759.GF5446@redhat.com> <5440F705.9060402@mail.ru> <5440FAB7.2090801@redhat.com> <5440FD63.1040309@mail.ru> Message-ID: <5440FE95.504@redhat.com> On 10/17/2014 01:28 PM, Orkhan Gasimov wrote: > Of course! But for now I'm in process of checking my integration and there are > some things I don't like. > First and foremost, any change on the IPA server is not automatically reflected > on the BSD client. > Only after SSSD is manually restarted on the client, something like it's cache > is cleared happens and new rules apply. > For now I'm not even checking something complex like sudo rule groups with host > groups, it's just a simple sudo rule for a single user. > I hope for collaboration with other interested people to find a stable solution > for FreeIPA - FreeBSD interaction via SSSD, so that as a result of all this > effort a well-detailed tutorial could be written and shared with all *nix users. +1. Or, even better approach would be if ipa-client-install script gets ported some nice day to FreeBSD so that sssd&assorted services do not need to be configured automatically and can use autodiscover features of ipa-client-install. But this is even farther future :-) > 17-Oct-14 16:17, Martin Kosek ?????: >> On 10/17/2014 01:01 PM, Orkhan Gasimov wrote: >>> That format is not simple for me, as I'm not a programmer. But after I check, >>> double-check and triple-check my FreeBSD - FreeIPA integration via SSSD and >>> assure that it works without unexpected behaviors, I'll probably write a HOW-TO >>> on this process and post it at FreeBSD forums. >> Thanks! Would you consider also adding the HOWTO to >> http://www.freeipa.org/page/HowTos >> so that other people can follow your steps? >> >>> I'll then share the link to my >>> post here, so that: >>> 1) FreeIPA community could also check the post for any errors; >>> 2) someone more prepared could translate the whole process into the format >>> appropriate for the ipa-advise tool. >>> >>> 17-Oct-14 15:37, Alexander Bokovoy ?????: >>>> FreeIPA is an open source project where anyone can contribute in their >>>> areas of interest. You are welcome to contribute recipes for FreeBSD. >>>> >>>> The code is around >>>> https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/advise/plugins/legacy_clients.py >>>> >>>> >>>> >>>> As you can see, most recipes are structured in easy way and adding new >>>> is as simple as adding new class definition there. > From lslebodn at redhat.com Fri Oct 17 11:39:32 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 17 Oct 2014 13:39:32 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <5440FD63.1040309@mail.ru> References: <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017090128.GD5446@redhat.com> <5440EDE6.2060306@mail.ru> <20141017103759.GF5446@redhat.com> <5440F705.9060402@mail.ru> <5440FAB7.2090801@redhat.com> <5440FD63.1040309@mail.ru> Message-ID: <20141017113932.GF27524@mail.corp.redhat.com> On (17/10/14 16:28), Orkhan Gasimov wrote: >Of course! But for now I'm in process of checking my integration and there >are some things I don't like. >First and foremost, any change on the IPA server is not automatically >reflected on the BSD client. sssd uses few levels of caches. If you want to have up-to-date data you need to invalidate sssd cache (sss_cache -UG). Details are in man sss_cache. It is not related to FreeBSD. The same behaviour is on LInux. If user authenticates to machine with sssd then fresh data is downloaded from server. That's the only exception. >Only after SSSD is manually restarted on the client, something like it's >cache is cleared happens and new rules apply. >For now I'm not even checking something complex like sudo rule groups with >host groups, it's just a simple sudo rule for a single user. sudo is much more tricky about up-to-date data. sssd uses peridic tasks for refreshing rules. It is not possible to invalidate sudo rules with tool sss_cache. Detail description of sudo rules caching mechanism is in manual page man sssd-sudo -> "THE SUDO RULE CACHING MECHANISM" LS From lslebodn at redhat.com Fri Oct 17 11:42:37 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 17 Oct 2014 13:42:37 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <5440FE95.504@redhat.com> References: <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017090128.GD5446@redhat.com> <5440EDE6.2060306@mail.ru> <20141017103759.GF5446@redhat.com> <5440F705.9060402@mail.ru> <5440FAB7.2090801@redhat.com> <5440FD63.1040309@mail.ru> <5440FE95.504@redhat.com> Message-ID: <20141017114236.GG27524@mail.corp.redhat.com> On (17/10/14 13:33), Martin Kosek wrote: >On 10/17/2014 01:28 PM, Orkhan Gasimov wrote: >> Of course! But for now I'm in process of checking my integration and there are >> some things I don't like. >> First and foremost, any change on the IPA server is not automatically reflected >> on the BSD client. >> Only after SSSD is manually restarted on the client, something like it's cache >> is cleared happens and new rules apply. >> For now I'm not even checking something complex like sudo rule groups with host >> groups, it's just a simple sudo rule for a single user. >> I hope for collaboration with other interested people to find a stable solution >> for FreeIPA - FreeBSD interaction via SSSD, so that as a result of all this >> effort a well-detailed tutorial could be written and shared with all *nix users. > >+1. Or, even better approach would be if ipa-client-install script gets ported >some nice day to FreeBSD so that sssd&assorted services do not need to be >configured automatically and can use autodiscover features of >ipa-client-install. But this is even farther future :-) > FreeBSD and FreeIPA are opensource projects. Feel free to send patches :-) LS From orkhan-azeri at mail.ru Fri Oct 17 11:46:29 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Fri, 17 Oct 2014 16:46:29 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141017113022.GE27524@mail.corp.redhat.com> References: <20141014074820.GL5346@dhcp-40-8.bne.redhat.com> <20141014131305.GE3104@mail.corp.redhat.com> <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017091529.GC27524@mail.corp.redhat.com> <5440F320.4010106@mail.ru> <20141017113022.GE27524@mail.corp.redhat.com> Message-ID: <54410195.4020305@mail.ru> 1. I use FreeBSD 10.0 64-bit. (For some files bits are also important - for example, on a 32-bit machine the same configuration of /usr/local/etc/sssd/sssd.conf file introduces problems because of the line "enumerate = True" in the [domain] section; only after that line is commented out, sssd starts.) 2. The files you requested are at https://cloud.mail.ru/public/afa7e1fad817/pam.d 17-Oct-14 16:30, Lukas Slebodnik ?????: > On (17/10/14 15:44), Orkhan Gasimov wrote: >> Unfortunately, putting that line in /etc/pam.d/system prevents me from being >> able to locally login to the BSD client. >> At the same time, the same line in /etc/pam.d/sshd or /etc/pam.d/login >> doesn't give unexpected behaviours. >> Bug, bug, bug... >> > It works for me with FreeBSD 9.3. It is possible that your pam stack is > misconfigured. > > Which version of FreBSD do you use? > > Could you send me all files from /etc/pam.d/? > > LS From orkhan-azeri at mail.ru Fri Oct 17 12:05:55 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Fri, 17 Oct 2014 17:05:55 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141017113932.GF27524@mail.corp.redhat.com> References: <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017090128.GD5446@redhat.com> <5440EDE6.2060306@mail.ru> <20141017103759.GF5446@redhat.com> <5440F705.9060402@mail.ru> <5440FAB7.2090801@redhat.com> <5440FD63.1040309@mail.ru> <20141017113932.GF27524@mail.corp.redhat.com> Message-ID: <54410623.3010701@mail.ru> I found another solution (currently checked it only for adding/deleting a sudo rule for a user, and also enabling/disabling a user) - add to the [domain] section of the sssd.conf file: "entry_cache_timeout = 5". 17-Oct-14 16:39, Lukas Slebodnik ?????: > sssd uses few levels of caches. If you want to have up-to-date data > you need to invalidate sssd cache (sss_cache -UG). From lkrispen at redhat.com Fri Oct 17 12:14:49 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 17 Oct 2014 14:14:49 +0200 Subject: [Freeipa-users] Migration fails with custom objectClasses In-Reply-To: References: <543EB51F.2030307@redhat.com> <543EC81D.9000807@redhat.com> <543ED37A.4060706@redhat.com> <543EDA27.905@redhat.com> <543EFD78.9060004@redhat.com> <543F40C0.5010903@redhat.com> <543FD15F.3030406@redhat.com> <543FFA0C.8030107@redhat.com> <543FFF7F.4050403@redhat.com> <544015A8.1050200@redhat.com> Message-ID: <54410839.6090207@redhat.com> Hi, maybe there is a case problem, if I try the following command, note some capital letters: # ipa config-mod --userobjectclasses=ipaObject --userobjectclasses=ine*tO*rgperson --userobjectclasses=person --userobjectclasses=posixaccount --userobjectclasses=inetuser --userobjectclasses=organizational*P*erson --userobjectclasses=krbticketpolicyaux --userobjectclasses=krbprincipalaux ipa: ERROR: Type or value exists: it fails, doing the same with all lowercase succeeds: # ipa config-mod --userobjectclasses=ipaobject --userobjectclasses=inetorgperson --userobjectclasses=person --userobjectclasses=posixaccount --userobjectclasses=inetuser --userobjectclasses=organizationalperson --userobjectclasses=krbticketpolicyaux --userobjectclasses=krbprincipalaux ..... Default user objectclasses: ipaobject, person, inetorgperson, organizationalperson, krbticketpolicyaux, krbprincipalaux, inetuser, posixaccount You posted your default oc earlier to be: Default user objectclasses: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser, radiusProfile, customPersonAttributes, sambaSamAccount and in the migration code we have code like: entry_attrs['objectclass'] = list( set( config.get( ldap_obj.object_class_config, ldap_obj.object_class ) + [o.lower() for o in entry_attrs['objectclass']] ) ) so i assume it will try to add an entry with objectclass: customPersonAttributes objectclass: custompersonattributes I don't know how to get ipa to log this, but you could do: tcpdump 'tcp port 389' -i any -w migrat.pcap and then run migrate-ds to verify On 10/16/2014 09:47 PM, Clint Savage wrote: > > > On Thu, Oct 16, 2014 at 12:59 PM, Rich Megginson > wrote: > > On 10/16/2014 11:42 AM, Clint Savage wrote: >> The access log had that information. And this error log: >> https://www.dropbox.com/s/ak6za0dkr0cn7ay/errors.20141010-132318 >> > > There unfortunately doesn't seem to be a debug log level that will > tell the server to dump the add request with all arguments. > > The best bet would be to get the ipa migrate tool to dump it's > commands to LDIF format, then we can look at it and figure out > what it is doing wrong. I don't know if that's possible. > > > Does anyone know how to accomplish what Rich suggests above? > > Thanks, > > Clint > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Oct 17 14:38:54 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 17 Oct 2014 10:38:54 -0400 Subject: [Freeipa-users] ipa-client-install (Invalid Request) - no Host-Certificate In-Reply-To: <84e1d53609e4ab5eae7acaca0f34951a.squirrel@faumail.uni-erlangen.de> References: <543F8B08.9000601@ww.uni-erlangen.de> <543FD908.5050202@redhat.com> <84e1d53609e4ab5eae7acaca0f34951a.squirrel@faumail.uni-erlangen.de> Message-ID: <544129FE.9080801@redhat.com> Christof.Schulze at ww.uni-erlangen.de wrote: > The FreeIPA is 3.0.0 server is running on CentOS 6.5. > > The CA subsystem certificates have all been renewed and will expire not > until 2016. In the > > I think the problems come from "modifications" a colleague did to > /etc/httpd/ipa-pki-proxy.conf , /etc/httpd/nss.conf and > /var/lib/pki-ca/conf/server.xml (without dokumentation, but they have > different timestamps) when he wanted to enforce/enable higher level > encrytion. > > I was able to reproduce some of his changes like StrictCypher and > sslOptions he did, but I am not sure with the configuraion of the ports > of the connectors in /var/lib/pki-ca/conf/server.xml > > > > > > > > > > > > > > and the /etc/httpd/conf.d/ipa-pki-proxy.conf > > > > > # VERSION 2 - DO NOT REMOVE THIS LINE > > ProxyRequests Off > > # matches for ee port > "^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange|^/ca/ee/ca/getCRL"> > NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate > NSSVerifyClient none > # ProxyPassMatch ajp://localhost:9443 > # ProxyPassReverse ajp://localhost:9443 > ProxyPassMatch ajp://localhost:9447 > ProxyPassReverse ajp://localhost:9447 > > > # matches for admin port and installer > "^/ca/admin/ca/getCertChain|^/ca/admin/ca/getConfigEntries|^/ca/admin/ca/getCookie|^/ca/admin/ca/getStatus|^/ca/admin/ca/securityDomainLogin|^/ca/admin/ca/getDomainXML|^/ca/rest/installer/installToken"> > NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate > NSSVerifyClient none > # ProxyPassMatch ajp://localhost:9443 > # ProxyPassReverse ajp://localhost:9443 > ProxyPassMatch ajp://localhost:9447 > ProxyPassReverse ajp://localhost:9447 > > > # matches for agent port and eeca port > "^/ca/agent/ca/displayBySerial|^/ca/agent/ca/doRevoke|^/ca/agent/ca/doUnrevoke|^/ca/agent/ca/updateDomainXML|^/ca/eeca/ca/profileSubmitSSLClient"> > NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate > NSSVerifyClient require > # ProxyPassMatch ajp://localhost:9443 > # ProxyPassReverse ajp://localhost:9443 > ProxyPassMatch ajp://localhost:9447 > ProxyPassReverse ajp://localhost:9447 > > > # Only enable this on servers that are not generating a CRL > #RewriteRule ^/ipa/crl/MasterCRL.bin > https://ww8-idm.ww.uni-erlangen.de/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL > [L,R=301,NC] > > > Is there somewhere a example configuration? When I deployed the system it > was a rather default installation. I've attached the config files from one of my working 3.0.0 masters. rob > > > >> Christof Schulze wrote: >>> Hello all, >>> >>> i am running a FreeIPA server on CentOS for 2 years now with mostly >>> Ubuntu 12.04 and some Fedora 20 clients. >>> >>> Since one week (or more) it is not possible any more to install new >>> clients (whether ubuntu nor fedora). The Host gets created on the >>> IPA-server but it can not create/exchange a Host-Certificate. >>> >>> The only thing happened (except regular updates) was a complete >>> certificate renewal with no obvious problems some weeks ago. >>> >>> Web-interface and certmonger show the same error. >>> >>> ipa-getcert list on the new Hosts: >>> status: CA_UNREACHABLE >>> ca-error: Server failed request, will retry: 4301 (RPC failed at >>> server. Certificate operation cannot be completed: FAILURE (Invalid >>> Request)). >>> stuck: yes >> >> Given the timeline I'd guess that your CA subsystem certificates have >> expired. >> >> On the IPA master run: getcert list (not ipa-getcert) >> >> This will show the current status of things. >> >> What version of IPA is this? >> >> rob >> > > -------------- next part -------------- # VERSION 2 - DO NOT REMOVE THIS LINE ProxyRequests Off # matches for ee port NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient none ProxyPassMatch ajp://localhost:9447 ProxyPassReverse ajp://localhost:9447 # matches for admin port and installer NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient none ProxyPassMatch ajp://localhost:9447 ProxyPassReverse ajp://localhost:9447 # matches for agent port and eeca port NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient require ProxyPassMatch ajp://localhost:9447 ProxyPassReverse ajp://localhost:9447 # Only enable this on servers that are not generating a CRL #RewriteRule ^/ipa/crl/MasterCRL.bin https://ipa.example.com/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC] -------------- next part -------------- # # This is the Apache server configuration file providing SSL support using. # the mod_nss plugin. It contains the configuration directives to instruct # the server how to serve pages over an https connection. # # Do NOT simply read the instructions in here without understanding # what they do. They're here only as hints or reminders. If you are unsure # consult the online docs. You have been warned. # LoadModule nss_module modules/libmodnss.so # # When we also provide SSL we have to listen to the # standard HTTP port (see above) and to the HTTPS port # # Note: Configurations that use IPv6 but not IPv4-mapped addresses need two # Listen directives: "Listen [::]:443" and "Listen 0.0.0.0:443" # Listen 443 ## ## SSL Global Context ## ## All SSL configuration in this context applies both to ## the main server and all SSL-enabled virtual hosts. ## # # Some MIME-types for downloading Certificates and CRLs # AddType application/x-x509-ca-cert .crt AddType application/x-pkcs7-crl .crl # Pass Phrase Dialog: # Configure the pass phrase gathering process. # The filtering dialog program (`builtin' is a internal # terminal dialog) has to provide the pass phrase on stdout. NSSPassPhraseDialog "file:/etc/httpd/conf/password.conf" # Pass Phrase Helper: # This helper program stores the token password pins between # restarts of Apache. NSSPassPhraseHelper /usr/sbin/nss_pcache # Configure the SSL Session Cache. # NSSSessionCacheSize is the number of entries in the cache. # NSSSessionCacheTimeout is the SSL2 session timeout (in seconds). # NSSSession3CacheTimeout is the SSL3/TLS session timeout (in seconds). NSSSessionCacheSize 10000 NSSSessionCacheTimeout 100 NSSSession3CacheTimeout 86400 # # Pseudo Random Number Generator (PRNG): # Configure one or more sources to seed the PRNG of the SSL library. # The seed data should be of good random quality. # WARNING! On some platforms /dev/random blocks if not enough entropy # is available. Those platforms usually also provide a non-blocking # device, /dev/urandom, which may be used instead. # # This does not support seeding the RNG with each connection. NSSRandomSeed startup builtin #NSSRandomSeed startup file:/dev/random 512 #NSSRandomSeed startup file:/dev/urandom 512 # # TLS Negotiation configuration under RFC 5746 # # Only renegotiate if the peer's hello bears the TLS renegotiation_info # extension. Default off. NSSRenegotiation on # Peer must send Signaling Cipher Suite Value (SCSV) or # Renegotiation Info (RI) extension in ALL handshakes. Default: off NSSRequireSafeNegotiation on ## ## SSL Virtual Host Context ## # General setup for the virtual host #DocumentRoot "/etc/httpd/htdocs" #ServerName www.example.com:443 #ServerAdmin you at example.com # mod_nss can log to separate log files, you can choose to do that if you'd like # LogLevel is not inherited from httpd.conf. ErrorLog /etc/httpd/logs/error_log TransferLog /etc/httpd/logs/access_log LogLevel warn # SSL Engine Switch: # Enable/Disable SSL for this virtual host. NSSEngine on # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_nss documentation for a complete list. # SSL 3 ciphers. SSL 2 is disabled by default. NSSCipherSuite +rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha # SSL 3 ciphers + ECC ciphers. SSL 2 is disabled by default. # # Comment out the NSSCipherSuite line above and use the one below if you have # ECC enabled NSS and mod_nss and want to use Elliptical Curve Cryptography #NSSCipherSuite +rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha,-ecdh_ecdsa_null_sha,+ecdh_ecdsa_rc4_128_sha,+ecdh_ecdsa_3des_sha,+ecdh_ecdsa_aes_128_sha,+ecdh_ecdsa_aes_256_sha,-ecdhe_ecdsa_null_sha,+ecdhe_ecdsa_rc4_128_sha,+ecdhe_ecdsa_3des_sha,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,-ecdh_rsa_null_sha,+ecdh_rsa_128_sha,+ecdh_rsa_3des_sha,+ecdh_rsa_aes_128_sha,+ecdh_rsa_aes_256_sha,-echde_rsa_null,+ecdhe_rsa_rc4_128_sha,+ecdhe_rsa_3des_sha,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha # SSL Protocol: # Cryptographic protocols that provide communication security. # NSS handles the specified protocols as "ranges", and automatically # negotiates the use of the strongest protocol for a connection starting # with the maximum specified protocol and downgrading as necessary to the # minimum specified protocol that can be used between two processes. # Since all protocol ranges are completely inclusive, and no protocol in the # middle of a range may be excluded, the entry "NSSProtocol SSLv3,TLSv1.1" # is identical to the entry "NSSProtocol SSLv3,TLSv1.0,TLSv1.1". NSSProtocol SSLv3,TLSv1.0,TLSv1.1 # SSL Certificate Nickname: # The nickname of the RSA server certificate you are going to use. NSSNickname Server-Cert # SSL Certificate Nickname: # The nickname of the ECC server certificate you are going to use, if you # have an ECC-enabled version of NSS and mod_nss #NSSECCNickname Server-Cert-ecc # Server Certificate Database: # The NSS security database directory that holds the certificates and # keys. The database consists of 3 files: cert8.db, key3.db and secmod.db. # Provide the directory that these files exist. NSSCertificateDatabase /etc/httpd/alias # Database Prefix: # In order to be able to store multiple NSS databases in one directory # they need unique names. This option sets the database prefix used for # cert8.db and key3.db. #NSSDBPrefix my-prefix- # Client Authentication (Type): # Client certificate verification type. Types are none, optional and # require. #NSSVerifyClient none # # Online Certificate Status Protocol (OCSP). # Verify that certificates have not been revoked before accepting them. #NSSOCSP off # # Use a default OCSP responder. If enabled this will be used regardless # of whether one is included in a client certificate. Note that the # server certificate is verified during startup. # # NSSOCSPDefaultURL defines the service URL of the OCSP responder # NSSOCSPDefaultName is the nickname of the certificate to trust to # sign the OCSP responses. #NSSOCSPDefaultResponder on #NSSOCSPDefaultURL http://example.com/ocsp/status #NSSOCSPDefaultName ocsp-nickname # Access Control: # With SSLRequire you can do per-directory access control based # on arbitrary complex boolean expressions containing server # variable checks and other lookup directives. The syntax is a # mixture between C and Perl. See the mod_nss documentation # for more details. # #NSSRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \ # and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \ # and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \ # and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \ # and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \ # or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/ # # SSL Engine Options: # Set various options for the SSL engine. # o FakeBasicAuth: # Translate the client X.509 into a Basic Authorisation. This means that # the standard Auth/DBMAuth methods can be used for access control. The # user name is the `one line' version of the client's X.509 certificate. # Note that no password is obtained from the user. Every entry in the user # file needs this password: `xxj31ZMTZzkVA'. # o ExportCertData: # This exports two additional environment variables: SSL_CLIENT_CERT and # SSL_SERVER_CERT. These contain the PEM-encoded certificates of the # server (always existing) and the client (only existing when client # authentication is used). This can be used to import the certificates # into CGI scripts. # o StdEnvVars: # This exports the standard SSL/TLS related `SSL_*' environment variables. # Per default this exportation is switched off for performance reasons, # because the extraction step is an expensive operation and is usually # useless for serving static content. So one usually enables the # exportation for CGI and SSI requests only. # o StrictRequire: # This denies access when "NSSRequireSSL" or "NSSRequire" applied even # under a "Satisfy any" situation, i.e. when it applies access is denied # and no other module can change it. # o OptRenegotiate: # This enables optimized SSL connection renegotiation handling when SSL # directives are used in per-directory context. #NSSOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire NSSOptions +StdEnvVars +ExportCertData NSSOptions +StdEnvVars +ExportCertData # Per-Server Logging: # The home of a custom SSL log file. Use this when you want a # compact non-error SSL logfile on a virtual host basis. #CustomLog /home/rcrit/redhat/apache/logs/ssl_request_log \ # "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" Include conf.d/ipa-rewrite.conf -------------- next part -------------- A non-text attachment was scrubbed... Name: server.xml Type: text/xml Size: 16860 bytes Desc: not available URL: From lslebodn at redhat.com Sat Oct 18 21:35:45 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Sat, 18 Oct 2014 23:35:45 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <54410195.4020305@mail.ru> References: <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017091529.GC27524@mail.corp.redhat.com> <5440F320.4010106@mail.ru> <20141017113022.GE27524@mail.corp.redhat.com> <54410195.4020305@mail.ru> Message-ID: <20141018213544.GB26289@mail.corp.redhat.com> On (17/10/14 16:46), Orkhan Gasimov wrote: >1. I use FreeBSD 10.0 64-bit. >(For some files bits are also important - for example, on a 32-bit machine >the same configuration of >/usr/local/etc/sssd/sssd.conf file introduces problems because of the line >"enumerate = True" in the [domain] section; only after that line is commented Firstly, We do not recommend to have enabled enumeration. Secondly, You did not have "enumerate = True" in your domain section. You have "enumerate = True #to enumerate users and groups" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I wrote you in another email that comments should be on different line >out, sssd starts.) > >2. The files you requested are at >https://cloud.mail.ru/public/afa7e1fad817/pam.d > >17-Oct-14 16:30, Lukas Slebodnik ?????: >>On (17/10/14 15:44), Orkhan Gasimov wrote: >>>Unfortunately, putting that line in /etc/pam.d/system prevents me from being I checked your apm configuration and you had wrong line in /etc/pam.d/system Currently, it is is commented out. "#acconut required /usr/local/lib/pam_sss.so" and the correct one is in /etc/pam.d/login "account required /usr/local/lib/pam_sss.so ignore_unknown_user ignore_authinfo_unavail" You were wrong in comment https://forums.freebsd.org/threads/freebsd-freeipa-via-sssd.46526/ Plese move line from login -> system >>>able to locally login to the BSD client. >>>At the same time, the same line in /etc/pam.d/sshd or /etc/pam.d/login >>>doesn't give unexpected behaviours. >>>Bug, bug, bug... no, no, no, The problem was between chair and keybord. Sorry, I could not resist :-) >>> >>It works for me with FreeBSD 9.3. It is possible that your pam stack is >>misconfigured. >> BTW After fixing problems with my freeipa 4.0.3, I was able to connect with ssh to FreeBSD 10 as freeipa_user and local_user. If I have time in next weeks I will try with clean FreeBSD 10 and will write some notes. LS From orkhan-azeri at mail.ru Sun Oct 19 03:45:55 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Sun, 19 Oct 2014 08:45:55 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141018213544.GB26289@mail.corp.redhat.com> References: <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017091529.GC27524@mail.corp.redhat.com> <5440F320.4010106@mail.ru> <20141017113022.GE27524@mail.corp.redhat.com> <54410195.4020305@mail.ru> <20141018213544.GB26289@mail.corp.redhat.com> Message-ID: <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> 1. About enumerate with comments on the same line - it doesn't cause any problems on my FreeBSD 10 64-bit. Enumerate causes problems on my FreeBSD 10 32-bit - that could be because of a comment on the same line & I could check it, but if it's not recommended to have enumerate at all, then I'll leave it. 2. About my pam.d files - please read carefully my previous posts. I commented out the line in pam.d -> system and added it explicitly to pam.d -> login because otherwise I get locked out from the machine. I sent you the WORKING configuration and not the one which was recommended at FreeBSD posts (and also by you). And yes, in pam.d -> system there's no "ignore bla bla bla part" because in that file the line "account? required? /usr/local/lib/pam_sss.so" just doesn't work, with or without that part. That's what I was talking about in my reply to the post at FreeBSD forums and that's why I considered unimportant readding that "ignore ..." part in the commented "account ..." line when sending pam.d files to you. 3. I like your idea of checking everything on a blank FreeaBSD 10 setup - that way you will really determine whether the problem is between the chair and the keyboard or not. ?????????? ?? Blue Mail ?? 2:36, 19.10.2014, ? 2:36, Lukas Slebodnik ???????:?>On (17/10/14 16:46), Orkhan Gasimov wrote: >>1. I use FreeBSD 10.0 64-bit. >>(For some files bits are also important - for example, on a 32-bit >machine >>the same configuration of >>/usr/local/etc/sssd/sssd.conf file introduces problems because of the >line >>"enumerate = True" in the [domain] section; only after that line is >commented >Firstly, We do not recommend to have enabled enumeration. >Secondly, You did not have "enumerate = True" in your domain section. >You have "enumerate = True #to enumerate users and groups" > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >I wrote you in another email that comments should be on different line > >>out, sssd starts.) >> >>2. The files you requested are at >>https://cloud.mail.ru/public/afa7e1fad817/pam.d >> >>17-Oct-14 16:30, Lukas Slebodnik ?????: >>>On (17/10/14 15:44), Orkhan Gasimov wrote: >>>>Unfortunately, putting that line in /etc/pam.d/system prevents me >from being >I checked your apm configuration and you had wrong line in >/etc/pam.d/system >Currently, it is is commented out. > "#acconut required /usr/local/lib/pam_sss.so" >and the correct one is in /etc/pam.d/login >"account required /usr/local/lib/pam_sss.so >ignore_unknown_user ignore_authinfo_unavail" > >You were wrong in comment >https://forums.freebsd.org/threads/freebsd-freeipa-via-sssd.46526/ >Plese move line from login -> system > >>>>able to locally login to the BSD client. >>>>At the same time, the same line in /etc/pam.d/sshd or >/etc/pam.d/login >>>>doesn't give unexpected behaviours. >>>>Bug, bug, bug... > no, no, no, >The problem was between chair and keybord. >Sorry, I could not resist :-) > >>>> >>>It works for me with FreeBSD 9.3. It is possible that your pam stack >is >>>misconfigured. >>> > >BTW >After fixing problems with my freeipa 4.0.3, I was able to connect with >ssh >to FreeBSD 10 as freeipa_user and local_user. > >If I have time in next weeks I will try with clean FreeBSD 10 and will >write >some notes. > >LS -------------- next part -------------- An HTML attachment was scrubbed... URL: From vaclav.adamec at suchy-zleb.cz Sun Oct 19 07:08:07 2014 From: vaclav.adamec at suchy-zleb.cz (Vaclav Adamec) Date: Sun, 19 Oct 2014 09:08:07 +0200 Subject: [Freeipa-users] Valid documentation for sudo setup for version 4.0.3 In-Reply-To: <20141017082105.GC5446@redhat.com> References: <20141017055922.GA5446@redhat.com> <20141017063920.GB5446@redhat.com> <20141017082105.GC5446@redhat.com> Message-ID: Thanks everyone for help, for centos65 latest, I really need to do these steps: yum install ipa-client libsss_sudo ipa-client-install ... modify: /etc/sssd/sssd.conf (ldap setup based on man) /etc/nsswitch.conf (sss provider for sudoers based on man) and set nisdomainname than sudo starts to work. One last thing is that latest CentOS65 64b ipa client and openssh is not fully compatible, during client registration it said "Installed openssh does not support dynamically loading authorized user keys" so no access via key is possible, but if you add "AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys" to sshd config it's ok, so probably some bad detection of openssh version. Vasek -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sun Oct 19 12:08:43 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 19 Oct 2014 08:08:43 -0400 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> References: <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017091529.GC27524@mail.corp.redhat.com> <5440F320.4010106@mail.ru> <20141017113022.GE27524@mail.corp.redhat.com> <54410195.4020305@mail.ru> <20141018213544.GB26289@mail.corp.redhat.com> <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> Message-ID: <5443A9CB.4090602@redhat.com> On 10/18/2014 11:45 PM, Orkhan Gasimov wrote: > > 1. About enumerate with comments on the same line - it doesn't cause > any problems on my FreeBSD 10 64-bit. Enumerate causes problems on my > FreeBSD 10 32-bit - that could be because of a comment on the same > line & I could check it, but if it's not recommended to have enumerate > at all, then I'll leave it. > Just FYI, comments on the same line are treated as part of value i.e. not interpreted as comments. I do not know how the value is treated by SSSD in the case of boolean. It might try to parse it and come to conclusion that it is true or false but I do not know which conclusion it actually comes to. BTW for those who are familiar with the internals and some other threads - using ding-libs interpretation functions would have caught that. One more argument to switch to ding-libs checking (when it is ready). As for enumeration - it is not needed in 90% of cases so we recommend not to configure it. > 2. About my pam.d files - please read carefully my previous posts. I > commented out the line in pam.d -> system and added it explicitly to > pam.d -> login because otherwise I get locked out from the machine. I > sent you the WORKING configuration and not the one which was > recommended at FreeBSD posts (and also by you). And yes, in pam.d -> > system there's no "ignore bla bla bla part" because in that file the > line "account required /usr/local/lib/pam_sss.so " > just doesn't work, with or without that part. That's what I was > talking about in my reply to the post at FreeBSD forums and that's why > I considered unimportant readding that "ignore ..." part in the > commented "account ..." line when sending pam.d files to you. > > 3. I like your idea of checking everything on a blank FreeaBSD 10 > setup - that way you will really determine whether the problem is > between the chair and the keyboard or not. > Yeah we should develop tools in this area. +1. > ?????????? ?? Blue Mail > > ?? 19.10.2014, ? 2:36, Lukas Slebodnik > ???????:? > > On (17/10/14 16:46), Orkhan Gasimov wrote: > > 1. I use FreeBSD 10.0 64-bit. (For some files bits are also > important - for example, on a 32-bit machine the same > configuration of /usr/local/etc/sssd/sssd.conf file introduces > problems because of the line "enumerate = True" in the > [domain] section; only after that line is commented > > Firstly, We do not recommend to have enabled enumeration. > Secondly, You did not have "enumerate = True" in your domain section. > You have "enumerate = True #to enumerate users and groups" > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I wrote you in another email that comments should be on different line > > out, sssd starts.) 2. The files you requested are at > https://cloud.mail.ru/public/afa7e1fad817/pam.d 17-Oct-14 > 16:30, Lukas Slebodnik ?????: > > On (17/10/14 15:44), Orkhan Gasimov wrote: > > Unfortunately, putting that line in /etc/pam.d/system > prevents me from being > > I checked your apm configuration and you had wrong line in /etc/pam.d/system > Currently, it is is commented out. > "#acconut required /usr/local/lib/pam_sss.so " > and the correct one is in /etc/pam.d/login > "account required /usr/local/lib/pam_sss.so ignore_unknown_user ignore_authinfo_unavail" > > Yo! > u were > wrong in commenthttps://forums.freebsd.org/threads/freebsd-freeipa-via-sssd.46526/ > Plese move line from login -> system > > able to locally login to the BSD client. At the same > time, the same line in /etc/pam.d/sshd or > /etc/pam.d/login doesn't give unexpected behaviours. > Bug, bug, bug... > > no, no, no, > The problem was between chair and keybord. > Sorry, I could not resist :-) > > It works for me with FreeBSD 9.3. It is possible that your > pam stack is misconfigured. > > > BTW > After fixing problems with my freeipa 4.0.3, I was able to connect with ssh > to FreeBSD 10 as freeipa_user and local_user. > > If I have time in next weeks I will try with clean FreeBSD 10 and will write > some notes. > > LS > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From genadipost at gmail.com Sun Oct 19 21:27:15 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Sun, 19 Oct 2014 23:27:15 +0200 Subject: [Freeipa-users] Using Selective authentication on AD->IPA trust. Message-ID: Hello all ! I am working on integrating IPA in a Microsoft dominated organization. After playing around with Cross forest trust and Directory server synchronization i came to the conclusion that Trust is the right way to go. Because it involves less configuration on AD side and its the direction the development community is focusing on. As i started discussing with AD administrators team, they expressed their concerns on the two-way trust needed. I have found the following thread in the freeipa archives: https://www.redhat.com/archives/freeipa-users/2012-June/msg00206.html where Simo Sorce explained why the two way trust is necessary. But then this thread appeared: https://www.redhat.com/archives/freeipa-users/2014-September/msg00276.html The discussion in the thread helped me *a lot* (especially the summary https://www.redhat.com/archives/freeipa-users/2014-September/msg00303.html) to explain the AD team why two-way trust is necessary and *not *a security risk. After convincing them that two-way trust in necessary, they still have put up a demand that the out-going AD->IPA trust authentication will be configured as *Selective **authentication.* Selective authentication is described as follows: *"Windows will not automatically authenticate users form the specified forest for any resources in the local forest. After you close this dialog. grant individual access to each domain and server that you want to make available to users in the specified forest."* While the default is Forest- wide authentication: *"Windows will automatically athenticate users from the specified forest for the recourses in the local forest."* Can this be done? Or it will break how IPA operates the trust? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Sun Oct 19 21:53:25 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 20 Oct 2014 00:53:25 +0300 Subject: [Freeipa-users] Using Selective authentication on AD->IPA trust. In-Reply-To: References: Message-ID: <20141019215325.GK5446@redhat.com> On Sun, 19 Oct 2014, Genadi Postrilko wrote: >Hello all ! > >I am working on integrating IPA in a Microsoft dominated organization. >After playing around with Cross forest trust and Directory server >synchronization >i came to the conclusion that Trust is the right way to go. Because it >involves less configuration on AD side and its the direction >the development community is focusing on. > >As i started discussing with AD administrators team, they expressed their >concerns on the two-way trust needed. > >I have found the following thread in the freeipa archives: >https://www.redhat.com/archives/freeipa-users/2012-June/msg00206.html >where Simo Sorce explained why the two way trust is necessary. > >But then this thread appeared: >https://www.redhat.com/archives/freeipa-users/2014-September/msg00276.html > >The discussion in the thread helped me *a lot* (especially the summary >https://www.redhat.com/archives/freeipa-users/2014-September/msg00303.html) >to explain the AD team why two-way trust is necessary and *not *a security >risk. > >After convincing them that two-way trust in necessary, they still have put >up a demand that the out-going AD->IPA trust authentication will be >configured as *Selective **authentication.* > >Selective authentication is described as follows: >*"Windows will not automatically authenticate users form the specified >forest for any resources in the local forest. After you close this dialog. >grant individual access to each domain and server that you want to make >available to users in the specified forest."* > >While the default is Forest- wide authentication: > >*"Windows will automatically athenticate users from the specified forest >for the recourses in the local forest."* > > >Can this be done? Or it will break how IPA operates the trust? I haven't tried it and my understanding is that it will break badly for the same reason why AD->IPA trust path is required today but is not presenting a security risk: as IPA side does not provide a way for AD to map SIDs to user/group names, Windows management tools will not be able to provide means to grant actual access rights to IPA principals. We need to get host/ipa.master and HTTP/ipa.master principals to get authenticated read only access to AD DC and LDAP servers. The problem with granting this access in 'Selective authentication' case will prevent the trust from working. We are planning on implementing one-way trust in near future but it is not there yet. -- / Alexander Bokovoy From lslebodn at redhat.com Mon Oct 20 08:01:28 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 20 Oct 2014 10:01:28 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> References: <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017091529.GC27524@mail.corp.redhat.com> <5440F320.4010106@mail.ru> <20141017113022.GE27524@mail.corp.redhat.com> <54410195.4020305@mail.ru> <20141018213544.GB26289@mail.corp.redhat.com> <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> Message-ID: <20141020080128.GA14974@mail.corp.redhat.com> On (19/10/14 08:45), Orkhan Gasimov wrote: > 2. About my pam.d files - please read carefully my previous posts. > I commented > out the line in pam.d -> system and added it explicitly to You didn't have "account required /usr/local/lib/pam_sss.so ignore_unknown_user" in pam.d/system. The line is commented out, but there *IS NOT* argument ignore_unknown_use Howto on FreeBSD forum[1] has argument ignore_unknown_user on the lines starting with account in both pam configuration files (system, sshd) > pam.d -> login because otherwise I get locked out from the machine. I sent I didn't touch "pam.d/login". I put "account .. pam_sss.so ignore_unknown_user" into "pam.d/system" (the same as in [1]) and I can login as sssd user and local user. I know that pam configuration isn't the easiest think for newbies, but your post will be even more confusing for others. Please do not give advices if you do not understand where is the problem and why it works with that change. > you the WORKING configuration and not the one which was recommended at > FreeBSD posts (and also by you). And yes, in pam.d -> system there's no > "ignore bla bla bla part" because in that file the line > "account? required? /usr/local/lib/pam_sss.so" just doesn't work, with or > without that part. I don't know what you did wrong, but it *works* with argument ignore_unknown_user How did you test? LS From orkhan-azeri at mail.ru Mon Oct 20 10:06:02 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Mon, 20 Oct 2014 15:06:02 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141020080128.GA14974@mail.corp.redhat.com> References: <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017091529.GC27524@mail.corp.redhat.com> <5440F320.4010106@mail.ru> <20141017113022.GE27524@mail.corp.redhat.com> <54410195.4020305@mail.ru> <20141018213544.GB26289@mail.corp.redhat.com> <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> <20141020080128.GA14974@mail.corp.redhat.com> Message-ID: <5444DE8A.4000304@mail.ru> OK, Lukas, I did as you say: 1) reset my pam.d -> login to its defaul state 2) added to my pam.d -> system: "account required /usr/local/lib/pam_sss.so ignore_unknown_user ignore_authinfo_unavail"; 3) commented out "enumerate = True" in my /usr/local/etc/sssd/sssd.conf. Now I cannot locally login as either root or IPA user. Seems like we built our SSSDs differently or from different ports. Would you be so kind to share info about your choices when building SSSD? You're right, I'm a newbie in FreeIPA setups. But I've worked with pam stack before, when configuring OpenLDAP on servers. That knowledge of pam let me solve the problem of local logins with sssd by adding the appropriate line in pam.d -> login instead of pam.d -> system. This setup works fine for me; another setup, which you and FreeBSD forums suppose, doesn't work. Did you check everything on a blank FreeBSD 10 setup? There are indeed nuances that the post at FreeBSD forums didn't address: 1) what choices should be made when building SSSD and other ports - VERY IMPORTANT, but missing information; 2) how ldap.conf should be configured on a FreeBSD client for ldapsearch to work; 3) how krb5.conf should be configured on a FreeBSD client; 4) how SSH files should be configured on a FreeBSD client for single sign-on to behave properly (GSS-API part); 5) how cron script file's executability, IPA user's shell and automatic creation of home directories should be considered - there are some caveats for newbies; 6) why a user can't initially SSH or locally login to a FreeBSD client even with correct configuration files (password change problem); 7) how to setup SSSD so that it doesn't cache information too long (this is not what we always want, right?). In short: a person who posted the info on FreeBSD - FreeIPA integration at FreeBSD forums shared a lot of info, but at the same time he didn't share other very important pieces of information, and this can cause great frustration to people trying to follow his post. And although you recommend me not to share my experience of setting up FreeBSD - FreeIPA integration, I just want people to get a REALLY WORKING HowTo. I've already tested HBAC, centralized sudo and other things in my setup, and everything is working fine. So in near future I plan to make a REAL, DETAILED HowTo on this subject, and I think that at least some pieces of information in it will help people to avoid great deal of frustration. 20-Oct-14 13:01, Lukas Slebodnik ?????: > On (19/10/14 08:45), Orkhan Gasimov wrote: >> 2. About my pam.d files - please read carefully my previous posts. >> I commented > out the line in pam.d -> system and added it explicitly to > You didn't have "account required /usr/local/lib/pam_sss.so ignore_unknown_user" > in pam.d/system. The line is commented out, but there *IS NOT* argument > ignore_unknown_use > > Howto on FreeBSD forum[1] has argument ignore_unknown_user on the lines > starting with account in both pam configuration files (system, sshd) > >> pam.d -> login because otherwise I get locked out from the machine. I sent > I didn't touch "pam.d/login". I put "account .. pam_sss.so ignore_unknown_user" > into "pam.d/system" (the same as in [1]) and I can login as sssd user and > local user. I know that pam configuration isn't the easiest think for newbies, > but your post will be even more confusing for others. Please do not give > advices if you do not understand where is the problem and why it works with > that change. > >> you the WORKING configuration and not the one which was recommended at >> FreeBSD posts (and also by you). And yes, in pam.d -> system there's no >> "ignore bla bla bla part" because in that file the line >> "account required /usr/local/lib/pam_sss.so" just doesn't work, with or >> without that part. > I don't know what you did wrong, but it *works* with argument ignore_unknown_user > How did you test? > > LS From loris at lgs.com.ve Mon Oct 20 13:15:52 2014 From: loris at lgs.com.ve (Loris Santamaria) Date: Mon, 20 Oct 2014 08:45:52 -0430 Subject: [Freeipa-users] Woes adding a samba server to the ipa domain Message-ID: <1413810952.3012.22.camel@toron.pzo.lgs.com.ve> Hi all, I wanted to install a samba server (or more precisely a winbind server for pptp authentication) in a IPA domain which trusts an AD domain. I know that this configuration is not supported but since it works with plain samba or samba+ldap I wanted to get it a shot to see how far one could get. First step, added a group for Domain Computers in ipa, with SID S-1-XXXX-515: dn: cn=domaincomputers,cn=groups,cn=accounts,YYYYYYYYYYY ipaNTSecurityIdentifier: S-1-5-21-XXXXXXXXXX-515 objectClass: top objectClass: groupofnames objectClass: nestedgroup objectClass: ipausergroup objectClass: ipaobject objectClass: posixgroup objectClass: ipantgroupattrs cn: domaincomputers description: domain computers ipaUniqueID: 5916daa0-57cd-11e4-a15b-000d3a7004fb gidNumber: 1870500500 Second step, added posix attributes to the ipa host object where samba would be installed, added SID information, and made it a member of the domain computers group: dn: fqdn=gcentralproxy.YYYY,cn=computers,cn=accounts,XXXX displayName: gcentralproxy sn: proxy givenName: gcentral gecos: gcentralproxy uidNumber: 1870400015 gidNumber: 1870500500 homeDirectory: /dev/null loginShell: /sbin/nologin uid: gcentralproxy$ ipaNTSecurityIdentifier: S-1-5-21-1967106394-3235870896-3821617943-14301 cn: gcentralproxy.cosmeticosgenesis.com objectClass: ipaobject objectClass: nshost objectClass: ipahost objectClass: pkiuser objectClass: ipaservice objectClass: krbprincipalaux objectClass: krbprincipal objectClass: ieee802device objectClass: ipasshhost objectClass: top objectClass: ipaSshGroupOfPubKeys objectClass: ipantuserattrs objectClass: posixAccount objectClass: inetorgperson objectClass: organizationalPerson objectClass: person fqdn: gcentralproxy.YYYYY krbPrincipalName: host/gcentralproxy.cosmeticosgenesis.com at YYYY serverHostName: gcentralproxy Third step, I added a cifs service for the host in ipa, and exported the keytab on the samba server. Fourth step, added a simple samba configuration file on the future samba server: [global] workgroup = YYYY realm = XXXX dedicated keytab file = FILE:/etc/samba/samba.keytab kerberos method = dedicated keytab log file = /var/log/samba/log.%m max log size = 100000 security = domain Trying to join the server to the domain (net rpc join -U domainadmin -S ipaserver) fails, and it causes a samba crash on the ipa server. Investigating the cause of the crash I found that pdbedit crashes as well (backtrace attached). I couldn't get a meaningful backtrace from the samba crash however I attached it as well. Seems to me that the samba ipasam backend on ipa doesn't like something in the host or the "domain computers" group object in ldap, but I cannot see what could be the problem. Perhaps someone more familiar with the ipasam code can spot it quickly. Best regards -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford -------------- next part -------------- [New LWP 2559] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Failed to read a valid object file image from memory. Core was generated by `/usr/sbin/smbd'. Program terminated with signal 6, Aborted. #0 0x00007fe01c9f15c9 in __GI_raise (sig=6, sig at entry=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); -------------- next part -------------- Core was generated by `pdbedit -L gcentralproxy$'. Program terminated with signal 11, Segmentation fault. #0 0x00007faea177db5b in _IO_vfprintf_internal (s=s at entry=0x7ffff4db20d0, format=, format at entry=0x7faea1d09718 "talloc: access after free error - first free may be at %s\n", ap=ap at entry=0x7ffff4db2260) at vfprintf.c:1635 1635 process_string_arg (((struct printf_spec *) NULL)); (gdb) bt #0 0x00007faea177db5b in _IO_vfprintf_internal (s=s at entry=0x7ffff4db20d0, format=, format at entry=0x7faea1d09718 "talloc: access after free error - first free may be at %s\n", ap=ap at entry=0x7ffff4db2260) at vfprintf.c:1635 #1 0x00007faea18401b5 in ___vsnprintf_chk (s=s at entry=0x7ffff4db225f "", maxlen=, maxlen at entry=1, flags=flags at entry=1, slen=slen at entry=1, format=format at entry=0x7faea1d09718 "talloc: access after free error - first free may be at %s\n", args=args at entry=0x7ffff4db2260) at vsnprintf_chk.c:63 #2 0x00007faea1d055c5 in vsnprintf (__ap=0x7ffff4db2260, __fmt=, __n=1, __s=0x7ffff4db225f "") at /usr/include/bits/stdio2.h:77 #3 talloc_vasprintf (t=t at entry=0x0, fmt=fmt at entry=0x7faea1d09718 "talloc: access after free error - first free may be at %s\n", ap=ap at entry=0x7ffff4db22c0) at ../talloc.c:2223 #4 0x00007faea1d02c89 in talloc_log (fmt=fmt at entry=0x7faea1d09718 "talloc: access after free error - first free may be at %s\n") at ../talloc.c:309 #5 0x00007faea1d02413 in talloc_chunk_from_ptr (ptr=ptr at entry=0x7fae91416ace) at ../talloc.c:377 #6 0x00007faea1d047a6 in talloc_chunk_from_ptr (ptr=0x7fae91416ace) at ../talloc.c:376 #7 __talloc (size=0, context=0x7fae91416ace) at ../talloc.c:578 #8 _talloc_named_const (name=0x7fae91416ab3 "talloc_new: ipa_sam.c:2950", size=0, context=0x7fae91416ace) at ../talloc.c:717 #9 talloc_named_const (context=context at entry=0x7fae91416ace, size=size at entry=0, name=name at entry=0x7fae91416ab3 "talloc_new: ipa_sam.c:2950") at ../talloc.c:1429 #10 0x00007fae91410a29 in ipasam_get_sid_by_gid (ldap_state=, ldap_state=, _sid=0x7faea5056b10, gid=1870500500) at ipa_sam.c:2950 #11 ipasam_get_primary_group_sid (_group_sid=, entry=0x7faea503bde0, ldap_state=0x7faea5048360, mem_ctx=0x7faea5057120) at ipa_sam.c:3059 #12 init_sam_from_ldap (entry=0x7faea503bde0, sampass=0x7faea50565f0, ldap_state=0x7faea5048360) at ipa_sam.c:3145 #13 ldapsam_getsampwnam (methods=, user=0x7faea50565f0, sname=) at ipa_sam.c:3371 #14 0x00007faea2138bed in pdb_getsampwnam (sam_acct=sam_acct at entry=0x7faea50565f0, username=username at entry=0x7ffff4db36bb "gcentralproxy$") at ../source3/passdb/pdb_interface.c:333 #15 0x00007faea35081bd in print_user_info (username=0x7ffff4db36bb "gcentralproxy$", verbosity=, smbpwdstyle=) at ../source3/utils/pdbedit.c:361 #16 0x00007faea35060f1 in main (argc=, argv=) at ../source3/utils/pdbedit.c:1257 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5693 bytes Desc: not available URL: From dpal at redhat.com Tue Oct 21 01:19:20 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 20 Oct 2014 21:19:20 -0400 Subject: [Freeipa-users] Woes adding a samba server to the ipa domain In-Reply-To: <1413810952.3012.22.camel@toron.pzo.lgs.com.ve> References: <1413810952.3012.22.camel@toron.pzo.lgs.com.ve> Message-ID: <5445B498.9090608@redhat.com> On 10/20/2014 09:15 AM, Loris Santamaria wrote: > Hi all, > > I wanted to install a samba server (or more precisely a winbind server > for pptp authentication) in a IPA domain which trusts an AD domain. > > I know that this configuration is not supported but since it works with > plain samba or samba+ldap I wanted to get it a shot to see how far one > could get. > > First step, added a group for Domain Computers in ipa, with SID > S-1-XXXX-515: > > dn: cn=domaincomputers,cn=groups,cn=accounts,YYYYYYYYYYY > ipaNTSecurityIdentifier: S-1-5-21-XXXXXXXXXX-515 > objectClass: top > objectClass: groupofnames > objectClass: nestedgroup > objectClass: ipausergroup > objectClass: ipaobject > objectClass: posixgroup > objectClass: ipantgroupattrs > cn: domaincomputers > description: domain computers > ipaUniqueID: 5916daa0-57cd-11e4-a15b-000d3a7004fb > gidNumber: 1870500500 > > Second step, added posix attributes to the ipa host object where samba > would be installed, added SID information, and made it a member of the > domain computers group: > > dn: fqdn=gcentralproxy.YYYY,cn=computers,cn=accounts,XXXX > displayName: gcentralproxy > sn: proxy > givenName: gcentral > gecos: gcentralproxy > uidNumber: 1870400015 > gidNumber: 1870500500 > homeDirectory: /dev/null > loginShell: /sbin/nologin > uid: gcentralproxy$ > ipaNTSecurityIdentifier: S-1-5-21-1967106394-3235870896-3821617943-14301 > cn: gcentralproxy.cosmeticosgenesis.com > objectClass: ipaobject > objectClass: nshost > objectClass: ipahost > objectClass: pkiuser > objectClass: ipaservice > objectClass: krbprincipalaux > objectClass: krbprincipal > objectClass: ieee802device > objectClass: ipasshhost > objectClass: top > objectClass: ipaSshGroupOfPubKeys > objectClass: ipantuserattrs > objectClass: posixAccount > objectClass: inetorgperson > objectClass: organizationalPerson > objectClass: person > fqdn: gcentralproxy.YYYYY > krbPrincipalName: host/gcentralproxy.cosmeticosgenesis.com at YYYY > serverHostName: gcentralproxy > > Third step, I added a cifs service for the host in ipa, and exported the > keytab on the samba server. > > Fourth step, added a simple samba configuration file on the future samba > server: > > [global] > workgroup = YYYY > realm = XXXX > dedicated keytab file = FILE:/etc/samba/samba.keytab > kerberos method = dedicated keytab > log file = /var/log/samba/log.%m > max log size = 100000 > security = domain > > Trying to join the server to the domain (net rpc join -U domainadmin -S > ipaserver) fails, and it causes a samba crash on the ipa server. > Investigating the cause of the crash I found that pdbedit crashes as > well (backtrace attached). I couldn't get a meaningful backtrace from > the samba crash however I attached it as well. > > Seems to me that the samba ipasam backend on ipa doesn't like something > in the host or the "domain computers" group object in ldap, but I cannot > see what could be the problem. Perhaps someone more familiar with the > ipasam code can spot it quickly. > > Best regards > > > Do I get it right that you really looking for https://fedorahosted.org/sssd/ticket/1588 that was just released upstream? It would be cool if you can try using SSSD 1.12.1 under Samba FS in the use case you have and provide feedback on how it works for you. AFAIU you install Samba FS and then use ipa-client to configure SSSD under it and it should work. If not we probably should document it (but I do not see any special design page which leads me to the above expectation). -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From loris at lgs.com.ve Tue Oct 21 12:19:11 2014 From: loris at lgs.com.ve (Loris Santamaria) Date: Tue, 21 Oct 2014 07:49:11 -0430 Subject: [Freeipa-users] Woes adding a samba server to the ipa domain In-Reply-To: <5445B498.9090608@redhat.com> References: <1413810952.3012.22.camel@toron.pzo.lgs.com.ve> <5445B498.9090608@redhat.com> Message-ID: <1413893951.3184.15.camel@toron.pzo.lgs.com.ve> El lun, 20-10-2014 a las 21:19 -0400, Dmitri Pal escribi?: > On 10/20/2014 09:15 AM, Loris Santamaria wrote: [...] > > > > Trying to join the server to the domain (net rpc join -U domainadmin -S > > ipaserver) fails, and it causes a samba crash on the ipa server. > > Investigating the cause of the crash I found that pdbedit crashes as > > well (backtrace attached). I couldn't get a meaningful backtrace from > > the samba crash however I attached it as well. > > > > Seems to me that the samba ipasam backend on ipa doesn't like something > > in the host or the "domain computers" group object in ldap, but I cannot > > see what could be the problem. Perhaps someone more familiar with the > > ipasam code can spot it quickly. > Do I get it right that you really looking for > https://fedorahosted.org/sssd/ticket/1588 that was just released > upstream? > It would be cool if you can try using SSSD 1.12.1 under Samba FS in > the use case you have and provide feedback on how it works for you. > > AFAIU you install Samba FS and then use ipa-client to configure SSSD > under it and it should work. > If not we probably should document it (but I do not see any special > design page which leads me to the above expectation). Ok, I'll happily try sssd 1.12.1. Just a question, in smb.conf one should use "security = domain" or "security = ads"? Best regards -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5693 bytes Desc: not available URL: From lslebodn at redhat.com Tue Oct 21 17:57:18 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 21 Oct 2014 19:57:18 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <54410195.4020305@mail.ru> References: <20141015011442.GN5346@dhcp-40-8.bne.redhat.com> <543F7C20.5040105@mail.ru> <20141016095711.GC19767@mail.corp.redhat.com> <543F9A47.3010505@mail.ru> <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017091529.GC27524@mail.corp.redhat.com> <5440F320.4010106@mail.ru> <20141017113022.GE27524@mail.corp.redhat.com> <54410195.4020305@mail.ru> Message-ID: <20141021175718.GF31312@mail.corp.redhat.com> On (17/10/14 16:46), Orkhan Gasimov wrote: >1. I use FreeBSD 10.0 64-bit. >(For some files bits are also important - for example, on a 32-bit machine >the same configuration of >/usr/local/etc/sssd/sssd.conf file introduces problems because of the line >"enumerate = True" in the [domain] section; only after that line is commented >out, sssd starts.) > >2. The files you requested are at >https://cloud.mail.ru/public/afa7e1fad817/pam.d > Previously, I was editing my pam stack I had to overwrite my files with yours to reproduce problem. As I thought it was your misconfiguration. You have a typo in pam.d/system Here is a word-diff: [-account-]{+acconut+} required /usr/local/lib/pam_sss.so ignore_unknown_user ignore_authinfo_unavail There is also syslog message (/var/log/messages): login: in openpam_parse_chain(): /etc/pam.d/system(19): missing or invalid facility login: pam_start(): system error Please update(remove) your post on FreeBSD forum. LS From lslebodn at redhat.com Tue Oct 21 18:31:17 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 21 Oct 2014 20:31:17 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <5444DE8A.4000304@mail.ru> References: <543FC6EB.1070509@mail.ru> <5440C4F7.3080400@mail.ru> <20141017091529.GC27524@mail.corp.redhat.com> <5440F320.4010106@mail.ru> <20141017113022.GE27524@mail.corp.redhat.com> <54410195.4020305@mail.ru> <20141018213544.GB26289@mail.corp.redhat.com> <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> <20141020080128.GA14974@mail.corp.redhat.com> <5444DE8A.4000304@mail.ru> Message-ID: <20141021183116.GG31312@mail.corp.redhat.com> On (20/10/14 15:06), Orkhan Gasimov wrote: >OK, Lukas, I did as you say: >1) reset my pam.d -> login to its defaul state >2) added to my pam.d -> system: "account required /usr/local/lib/pam_sss.so >ignore_unknown_user ignore_authinfo_unavail"; >3) commented out "enumerate = True" in my /usr/local/etc/sssd/sssd.conf. >Now I cannot locally login as either root or IPA user. Seems like we built >our SSSDs differently or from different ports. >Would you be so kind to share info about your choices when building SSSD? > >You're right, I'm a newbie in FreeIPA setups. But I've worked with pam stack >before, when configuring OpenLDAP on servers. That knowledge of pam let me >solve the problem of local logins with sssd by adding the appropriate line in >pam.d -> login instead of pam.d -> system. This setup works fine for me; >another setup, which you and FreeBSD forums suppose, doesn't work. Did you >check everything on a blank FreeBSD 10 setup? > Basically, you should do all (ipa-client-install) steps manually. I would recommend you to look into log file from linux machine /var/log/ipaclient-install.log. The main difference between linux and FreeBSD will be location of configuration files(/etc vs /usr/local/etc) >There are indeed nuances that the post at FreeBSD forums didn't address: I would say that post was more focused on integration sssd with sudo and expected more experienced user with better knowledge of FreeIPA. It is the most difficult part. >1) what choices should be made when building SSSD and other ports - VERY >IMPORTANT, but missing information; I am use to using install packages with utility pkg. Just some packages need to be build from source. (they are listed in the begging of post) >2) how ldap.conf should be configured on a FreeBSD client for ldapsearch to >work; I don't have configured ldap.conf. On the other hand, it can be useful for troubleshooting with utility ldapsearch. >3) how krb5.conf should be configured on a FreeBSD client; The same as on linux. (sssd is linked with MIT kerberos) >4) how SSH files should be configured on a FreeBSD client for single sign-on >to behave properly (GSS-API part); Linux and FreeBSD use openssh. You can inspire in changes done by script ipa-client-install >5) how cron script file's executability, IPA user's shell and automatic >creation of home directories should be considered - there are some caveats why do you need cron? User shell can be changed on FreeIPA server or you can change sssd configuration man sssd.conf (see *shell*) >for newbies; Do you mean "admin newbies" or "FreeIPA newbies"? admin should know how to configure automatic creation of directories. (another pam module) ipa-client install just simplify it on linux. >6) why a user can't initially SSH or locally login to a FreeBSD client even >with correct configuration files (password change problem); FreeBSD admins should already have experiences with ldap configuration on FreeBSD (or at least read FreeBSD documentation). Official documentation is very good (ldap client configuration with nss-pam-ldapd) https://www.freebsd.org/doc/en/articles/ldap-auth/client.html >7) how to setup SSSD so that it doesn't cache information too long (this is >not what we always want, right?). > sssd use cache by design. If you don't want to cache LDAP users, you can use nss-pam-ldapd. BTW this point is not related to FreeBSD Summary: Fee free to write detailed howto for newbies. We will be very glad to help with review and fixing problematic parts. LS From orkhan-azeri at mail.ru Tue Oct 21 19:20:14 2014 From: orkhan-azeri at mail.ru (=?UTF-8?B?0J7RgNGF0LDQvSDQmtCw0YHRg9C80L7Qsg==?=) Date: Tue, 21 Oct 2014 23:20:14 +0400 Subject: [Freeipa-users] =?utf-8?q?No_result_when_trying_to_integrate_a_Fr?= =?utf-8?q?eeBSD_client_with_the_FreeIPA_server?= In-Reply-To: <20141021183116.GG31312@mail.corp.redhat.com> References: <543FC6EB.1070509@mail.ru> <5444DE8A.4000304@mail.ru> <20141021183116.GG31312@mail.corp.redhat.com> Message-ID: <1413919213.311487165@f301.i.mail.ru> 1. Yes, being able to find simple typos is what distinguishes a good troubleshooter from a bad one. The problem really was between the chair and the keyboard. 2. Not only you were right in this aspect, but also regarding the idea that comments in sssd.conf file shouldn't be on the same line as directives. Putting a comment on a separate line allows sssd to start normally instead of giving error messages. 3. I already updated my post at FreeBSD forums and included your comments there. Thanks for taking time to find the cause of the problems. 4. I consider this thread closed, but still plan to write a detailed HowTo about FreeBSD - FreeIPA integration, i.e. about full setup of 5 VMs: a) a DNS server; b) the first IPA server; c) the second IPA server for multi-master replication; d) a Linux IPA client (for changing LDAP users' passwords in behalf of FreeBSD); b) a FreeBSD client - detailed steps, including many things that current post at FreeBSD forums misses. I will then send my HowTo to both FreeBSD forums and FreeIPA team, and it's up to them to decide if the HowTo is worth publishing or not. If the HowTo is OK, I'll translate it to another two languages: Russian and Azeri. Tue, 21 Oct 2014 20:31:17 +0200 ?? Lukas Slebodnik : >On (20/10/14 15:06), Orkhan Gasimov wrote: >>OK, Lukas, I did as you say: >>1) reset my pam.d -> login to its defaul state >>2) added to my pam.d -> system: "account required /usr/local/lib/pam_sss.so >>ignore_unknown_user ignore_authinfo_unavail"; >>3) commented out "enumerate = True" in my /usr/local/etc/sssd/sssd.conf. >>Now I cannot locally login as either root or IPA user. Seems like we built >>our SSSDs differently or from different ports. >>Would you be so kind to share info about your choices when building SSSD? >> >>You're right, I'm a newbie in FreeIPA setups. But I've worked with pam stack >>before, when configuring OpenLDAP on servers. That knowledge of pam let me >>solve the problem of local logins with sssd by adding the appropriate line in >>pam.d -> login instead of pam.d -> system. This setup works fine for me; >>another setup, which you and FreeBSD forums suppose, doesn't work. Did you >>check everything on a blank FreeBSD 10 setup? >> >Basically, you should do all (ipa-client-install) steps manually. >I would recommend you to look into log file from linux machine >/var/log/ipaclient-install.log. The main difference between linux and FreeBSD >will be location of configuration files(/etc vs /usr/local/etc) > >>There are indeed nuances that the post at FreeBSD forums didn't address: >I would say that post was more focused on integration sssd with sudo >and expected more experienced user with better knowledge of FreeIPA. >It is the most difficult part. > >>1) what choices should be made when building SSSD and other ports - VERY >>IMPORTANT, but missing information; >I am use to using install packages with utility pkg. Just some packages need >to be build from source. (they are listed in the begging of post) > >>2) how ldap.conf should be configured on a FreeBSD client for ldapsearch to >>work; >I don't have configured ldap.conf. On the other hand, it can be useful for >troubleshooting with utility ldapsearch. > >>3) how krb5.conf should be configured on a FreeBSD client; >The same as on linux. (sssd is linked with MIT kerberos) > >>4) how SSH files should be configured on a FreeBSD client for single sign-on >>to behave properly (GSS-API part); >Linux and FreeBSD use openssh. You can inspire in changes done by script >ipa-client-install > >>5) how cron script file's executability, IPA user's shell and automatic >>creation of home directories should be considered - there are some caveats >why do you need cron? >User shell can be changed on FreeIPA server or you can change sssd >configuration man sssd.conf (see *shell*) > >>for newbies; >Do you mean "admin newbies" or "FreeIPA newbies"? >admin should know how to configure automatic creation of directories. >(another pam module) ipa-client install just simplify it on linux. > >>6) why a user can't initially SSH or locally login to a FreeBSD client even >>with correct configuration files (password change problem); >FreeBSD admins should already have experiences with ldap configuration on >FreeBSD (or at least read FreeBSD documentation). Official documentation is >very good (ldap client configuration with nss-pam-ldapd) >https://www.freebsd.org/doc/en/articles/ldap-auth/client.html > >>7) how to setup SSSD so that it doesn't cache information too long (this is >>not what we always want, right?). >> >sssd use cache by design. If you don't want to cache LDAP users, you can use >nss-pam-ldapd. BTW this point is not related to FreeBSD > >Summary: >Fee free to write detailed howto for newbies. We will be very glad to help with >review and fixing problematic parts. > >LS -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Tue Oct 21 19:52:27 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 21 Oct 2014 21:52:27 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <1413919213.311487165@f301.i.mail.ru> References: <543FC6EB.1070509@mail.ru> <5444DE8A.4000304@mail.ru> <20141021183116.GG31312@mail.corp.redhat.com> <1413919213.311487165@f301.i.mail.ru> Message-ID: <20141021195227.GL31312@mail.corp.redhat.com> On (21/10/14 23:20), ????? ??????? wrote: > >1. Yes, being able to find simple typos is what distinguishes a good troubleshooter from a bad one. The problem really was between the chair and the keyboard. >2. Not only you were right in this aspect, but also regarding the idea that comments in sssd.conf file shouldn't be on the same line as directives. Putting a comment on a separate line allows sssd to start normally instead of giving error messages. >3. I already updated my post at FreeBSD forums and included your comments there. Thanks for taking time to find the cause of the problems. >4. I consider this thread closed, but still plan to write a detailed HowTo about FreeBSD - FreeIPA integration, i.e. about full setup of 5 VMs: >a) a DNS server; You do not need extra server for dns. FreeIPA is integrated solutiona and DNS server can be installed as part of FreeIPA. ipa-server-install --setup-dns >b) the first IPA server; >c) the second IPA server for multi-master replication; >d) a Linux IPA client (for changing LDAP users' passwords in behalf of FreeBSD); user can change password in ipa web UI (tested with FreeIPA 4) but it is good idea to have linux client for testing purposes. >b) a FreeBSD client - detailed steps, including many things that current post at FreeBSD forums misses. >I will then send my HowTo to both FreeBSD forums and FreeIPA team, and it's up to them to decide if the HowTo is worth publishing or not. >If the HowTo is OK, I'll translate it to another two languages: Russian and Azeri. Awesome. LS From ftweedal at redhat.com Wed Oct 22 02:06:28 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 22 Oct 2014 12:06:28 +1000 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141021183116.GG31312@mail.corp.redhat.com> References: <5440C4F7.3080400@mail.ru> <20141017091529.GC27524@mail.corp.redhat.com> <5440F320.4010106@mail.ru> <20141017113022.GE27524@mail.corp.redhat.com> <54410195.4020305@mail.ru> <20141018213544.GB26289@mail.corp.redhat.com> <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> <20141020080128.GA14974@mail.corp.redhat.com> <5444DE8A.4000304@mail.ru> <20141021183116.GG31312@mail.corp.redhat.com> Message-ID: <20141022020628.GH5346@dhcp-40-8.bne.redhat.com> On Tue, Oct 21, 2014 at 08:31:17PM +0200, Lukas Slebodnik wrote: > On (20/10/14 15:06), Orkhan Gasimov wrote: > >OK, Lukas, I did as you say: > >1) reset my pam.d -> login to its defaul state > >2) added to my pam.d -> system: "account required /usr/local/lib/pam_sss.so > >ignore_unknown_user ignore_authinfo_unavail"; > >3) commented out "enumerate = True" in my /usr/local/etc/sssd/sssd.conf. > >Now I cannot locally login as either root or IPA user. Seems like we built > >our SSSDs differently or from different ports. > >Would you be so kind to share info about your choices when building SSSD? > > > >You're right, I'm a newbie in FreeIPA setups. But I've worked with pam stack > >before, when configuring OpenLDAP on servers. That knowledge of pam let me > >solve the problem of local logins with sssd by adding the appropriate line in > >pam.d -> login instead of pam.d -> system. This setup works fine for me; > >another setup, which you and FreeBSD forums suppose, doesn't work. Did you > >check everything on a blank FreeBSD 10 setup? > > > Basically, you should do all (ipa-client-install) steps manually. > I would recommend you to look into log file from linux machine > /var/log/ipaclient-install.log. The main difference between linux and FreeBSD > will be location of configuration files(/etc vs /usr/local/etc) > > >There are indeed nuances that the post at FreeBSD forums didn't address: > I would say that post was more focused on integration sssd with sudo > and expected more experienced user with better knowledge of FreeIPA. > It is the most difficult part. > > >1) what choices should be made when building SSSD and other ports - VERY > >IMPORTANT, but missing information; > I am use to using install packages with utility pkg. Just some packages need > to be build from source. (they are listed in the begging of post) > I have prepared a custom pkg(8) repo with the packages built with the required options/make.conf variables. Hang tight, I'll send all the info soon. > >2) how ldap.conf should be configured on a FreeBSD client for ldapsearch to > >work; > I don't have configured ldap.conf. On the other hand, it can be useful for > troubleshooting with utility ldapsearch. > > >3) how krb5.conf should be configured on a FreeBSD client; > The same as on linux. (sssd is linked with MIT kerberos) > > >4) how SSH files should be configured on a FreeBSD client for single sign-on > >to behave properly (GSS-API part); > Linux and FreeBSD use openssh. You can inspire in changes done by script > ipa-client-install > > >5) how cron script file's executability, IPA user's shell and automatic > >creation of home directories should be considered - there are some caveats > why do you need cron? > User shell can be changed on FreeIPA server or you can change sssd > configuration man sssd.conf (see *shell*) > > >for newbies; > Do you mean "admin newbies" or "FreeIPA newbies"? > admin should know how to configure automatic creation of directories. > (another pam module) ipa-client install just simplify it on linux. > > >6) why a user can't initially SSH or locally login to a FreeBSD client even > >with correct configuration files (password change problem); > FreeBSD admins should already have experiences with ldap configuration on > FreeBSD (or at least read FreeBSD documentation). Official documentation is > very good (ldap client configuration with nss-pam-ldapd) > https://www.freebsd.org/doc/en/articles/ldap-auth/client.html > > >7) how to setup SSSD so that it doesn't cache information too long (this is > >not what we always want, right?). > > > sssd use cache by design. If you don't want to cache LDAP users, you can use > nss-pam-ldapd. BTW this point is not related to FreeBSD > > Summary: > Fee free to write detailed howto for newbies. We will be very glad to help with > review and fixing problematic parts. > > LS > > -- > 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 From orkhan-azeri at mail.ru Wed Oct 22 04:13:11 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Wed, 22 Oct 2014 09:13:11 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141022020628.GH5346@dhcp-40-8.bne.redhat.com> References: <5440C4F7.3080400@mail.ru> <20141017091529.GC27524@mail.corp.redhat.com> <5440F320.4010106@mail.ru> <20141017113022.GE27524@mail.corp.redhat.com> <54410195.4020305@mail.ru> <20141018213544.GB26289@mail.corp.redhat.com> <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> <20141020080128.GA14974@mail.corp.redhat.com> <5444DE8A.4000304@mail.ru> <20141021183116.GG31312@mail.corp.redhat.com> <20141022020628.GH5346@dhcp-40-8.bne.redhat.com> Message-ID: <54472ED7.1000800@mail.ru> Great news! If I understand correctly, a package can be equivalent to several ports? If this is correct, then could a "composite" package be built to include all necessary ports? * _security/sssd_ * _security/sudo_ (with SSSD backend) * _net/openldap24-client-sasl_ * security/cyrus-sasl2 * security/cyrus-sasl2-gssapi That package could be called something like "ipa-client", and make FreeBSD - FreeIPA integration one step closer. If not possible, even a pkg equivalent to "/security/sssd" would eliminate existing possibilities for misconfiguration. 22-Oct-14 07:06, Fraser Tweedale ?????: > I have prepared a custom pkg(8) repo with the packages built with > the required options/make.conf variables. Hang tight, I'll send all > the info soon. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Wed Oct 22 04:38:44 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 22 Oct 2014 14:38:44 +1000 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <54472ED7.1000800@mail.ru> References: <5440F320.4010106@mail.ru> <20141017113022.GE27524@mail.corp.redhat.com> <54410195.4020305@mail.ru> <20141018213544.GB26289@mail.corp.redhat.com> <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> <20141020080128.GA14974@mail.corp.redhat.com> <5444DE8A.4000304@mail.ru> <20141021183116.GG31312@mail.corp.redhat.com> <20141022020628.GH5346@dhcp-40-8.bne.redhat.com> <54472ED7.1000800@mail.ru> Message-ID: <20141022043844.GJ5346@dhcp-40-8.bne.redhat.com> On Wed, Oct 22, 2014 at 09:13:11AM +0500, Orkhan Gasimov wrote: > Great news! If I understand correctly, a package can be > equivalent to several ports? If this is correct, then could a > "composite" package be built to include all necessary ports? > This is not correct. One package corresponds to one port, but like most package managers, any missing dependencies will be brought in when installing a package. There are some "meta-ports" (and corresponding packages) however, that don't contain anything themselves but exist just to bring in a bunch of related software. Meta-ports also have limited control over the options with which dependencies are built. > * _security/sssd_ > * _security/sudo_ (with SSSD > backend) > * _net/openldap24-client-sasl_ > > * security/cyrus-sasl2 > * security/cyrus-sasl2-gssapi > Of these five packages, assuming correct options and make.conf settings, there are only two "leaf" packages: sudo and cyrus-sasl-gssapi. So even without a meta-port, it is not burdensome to install the required software from the custom repo. > That package could be called something like "ipa-client", and make FreeBSD - > FreeIPA integration one step closer. > If not possible, even a pkg equivalent to "/security/sssd" would eliminate > existing possibilities for misconfiguration. > I don't think it is possible to do it at the moment, in a way that is useful to FreeBSD users at large, without using a custom pkg(8) repo. This is because there is no way for building packages with different "flavours" and having them coexist in the same repo. Support for "flavours" is a high priority, though; it is actively being worked on. Until that feature arrives, custom pkg repo is the best alternative to setting options/variables and building ports oneself. > 22-Oct-14 07:06, Fraser Tweedale ?????: > >I have prepared a custom pkg(8) repo with the packages built with > >the required options/make.conf variables. Hang tight, I'll send all > >the info soon. > From ftweedal at redhat.com Wed Oct 22 07:10:55 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 22 Oct 2014 17:10:55 +1000 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <54472ED7.1000800@mail.ru> References: <5440F320.4010106@mail.ru> <20141017113022.GE27524@mail.corp.redhat.com> <54410195.4020305@mail.ru> <20141018213544.GB26289@mail.corp.redhat.com> <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> <20141020080128.GA14974@mail.corp.redhat.com> <5444DE8A.4000304@mail.ru> <20141021183116.GG31312@mail.corp.redhat.com> <20141022020628.GH5346@dhcp-40-8.bne.redhat.com> <54472ED7.1000800@mail.ru> Message-ID: <20141022071055.GK5346@dhcp-40-8.bne.redhat.com> Further to my earlier email, I have written a blog post about all these matters, with a particular focus on the custom package repo. I will update it tomorrow with a bit more about the package "flavours" topic. For now, all the details for enabling and using the custom repo are in the post. Check it out and let me know if you spot any issues. http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/ Cheers, Fraser On Wed, Oct 22, 2014 at 09:13:11AM +0500, Orkhan Gasimov wrote: > Great news! > If I understand correctly, a package can be equivalent to several ports? > If this is correct, then could a "composite" package be built to include all > necessary ports? > > * _security/sssd_ > * _security/sudo_ (with SSSD > backend) > * _net/openldap24-client-sasl_ > > * security/cyrus-sasl2 > * security/cyrus-sasl2-gssapi > > That package could be called something like "ipa-client", and make FreeBSD - > FreeIPA integration one step closer. > If not possible, even a pkg equivalent to "/security/sssd" would eliminate > existing possibilities for misconfiguration. > > 22-Oct-14 07:06, Fraser Tweedale ?????: > >I have prepared a custom pkg(8) repo with the packages built with > >the required options/make.conf variables. Hang tight, I'll send all > >the info soon. > From pspacek at redhat.com Wed Oct 22 11:26:42 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 22 Oct 2014 13:26:42 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141022071055.GK5346@dhcp-40-8.bne.redhat.com> References: <5440F320.4010106@mail.ru> <20141017113022.GE27524@mail.corp.redhat.com> <54410195.4020305@mail.ru> <20141018213544.GB26289@mail.corp.redhat.com> <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> <20141020080128.GA14974@mail.corp.redhat.com> <5444DE8A.4000304@mail.ru> <20141021183116.GG31312@mail.corp.redhat.com> <20141022020628.GH5346@dhcp-40-8.bne.redhat.com> <54472ED7.1000800@mail.ru> <20141022071055.GK5346@dhcp-40-8.bne.redhat.com> Message-ID: <54479472.9040802@redhat.com> On 22.10.2014 09:10, Fraser Tweedale wrote: > Further to my earlier email, I have written a blog post about all > these matters, with a particular focus on the custom package repo. > > I will update it tomorrow with a bit more about the package > "flavours" topic. For now, all the details for enabling and using > the custom repo are in the post. Check it out and let me know if > you spot any issues. > > http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/ Hello Fraser and others, it would be great if you could add links to your FreeIPA-related blog posts to http://www.freeipa.org/page/HowTos . We are trying to build kind of 'documentation hub' with links to relevant posts stored elsewhere. It is even fine to add links to mailing list archives if the particular post is useful to broad audience. Have a nice day! Petr^2 Spacek > > Cheers, > > Fraser > > On Wed, Oct 22, 2014 at 09:13:11AM +0500, Orkhan Gasimov wrote: >> Great news! >> If I understand correctly, a package can be equivalent to several ports? >> If this is correct, then could a "composite" package be built to include all >> necessary ports? >> >> * _security/sssd_ >> * _security/sudo_ (with SSSD >> backend) >> * _net/openldap24-client-sasl_ >> >> * security/cyrus-sasl2 >> * security/cyrus-sasl2-gssapi >> >> That package could be called something like "ipa-client", and make FreeBSD - >> FreeIPA integration one step closer. >> If not possible, even a pkg equivalent to "/security/sssd" would eliminate >> existing possibilities for misconfiguration. >> >> 22-Oct-14 07:06, Fraser Tweedale ?????: >>> I have prepared a custom pkg(8) repo with the packages built with >>> the required options/make.conf variables. Hang tight, I'll send all >>> the info soon. From lslebodn at redhat.com Wed Oct 22 13:23:56 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 22 Oct 2014 15:23:56 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141022071055.GK5346@dhcp-40-8.bne.redhat.com> References: <20141017113022.GE27524@mail.corp.redhat.com> <54410195.4020305@mail.ru> <20141018213544.GB26289@mail.corp.redhat.com> <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> <20141020080128.GA14974@mail.corp.redhat.com> <5444DE8A.4000304@mail.ru> <20141021183116.GG31312@mail.corp.redhat.com> <20141022020628.GH5346@dhcp-40-8.bne.redhat.com> <54472ED7.1000800@mail.ru> <20141022071055.GK5346@dhcp-40-8.bne.redhat.com> Message-ID: <20141022132355.GA4312@mail.corp.redhat.com> On (22/10/14 17:10), Fraser Tweedale wrote: >Further to my earlier email, I have written a blog post about all >these matters, with a particular focus on the custom package repo. > >I will update it tomorrow with a bit more about the package >"flavours" topic. For now, all the details for enabling and using >the custom repo are in the post. Check it out and let me know if >you spot any issues. > > http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/ > The disadvantage of this approach is that users need to rely on updating of non standard repo. https://frase.id.au/pkg/${ABI}_FreeIPA In my opinion, it's better to write howto (script) which will configure all necessary ports/files and portmaster will take care of updating ports. https://www.freebsd.org/doc/handbook/ports-using.html#portmaster LS From outbackdingo at gmail.com Wed Oct 22 14:03:49 2014 From: outbackdingo at gmail.com (Outback Dingo) Date: Thu, 23 Oct 2014 01:03:49 +1100 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141022132355.GA4312@mail.corp.redhat.com> References: <20141017113022.GE27524@mail.corp.redhat.com> <54410195.4020305@mail.ru> <20141018213544.GB26289@mail.corp.redhat.com> <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> <20141020080128.GA14974@mail.corp.redhat.com> <5444DE8A.4000304@mail.ru> <20141021183116.GG31312@mail.corp.redhat.com> <20141022020628.GH5346@dhcp-40-8.bne.redhat.com> <54472ED7.1000800@mail.ru> <20141022071055.GK5346@dhcp-40-8.bne.redhat.com> <20141022132355.GA4312@mail.corp.redhat.com> Message-ID: On Thu, Oct 23, 2014 at 12:23 AM, Lukas Slebodnik wrote: > On (22/10/14 17:10), Fraser Tweedale wrote: > >Further to my earlier email, I have written a blog post about all > >these matters, with a particular focus on the custom package repo. > > > >I will update it tomorrow with a bit more about the package > >"flavours" topic. For now, all the details for enabling and using > >the custom repo are in the post. Check it out and let me know if > >you spot any issues. > > > > > http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/ > > > The disadvantage of this approach is that users need to rely on updating > of non standard repo. https://frase.id.au/pkg/${ABI}_FreeIPA > > In my opinion, it's better to write howto (script) which will configure all > necessary ports/files and portmaster will take care of updating ports. > https://www.freebsd.org/doc/handbook/ports-using.html#portmaster > > LS > > As an avid BSD user, with FreeIPA cloud deployed, ill fire up some FreeBSD VMs and see if i can get a running system, using the thread here, and the doc thats been written to "sanity" check things and possibly help out with the packaging if I can. I only need to consider, that I run Launchd on my FreeBSD systems, so ill need to go deeper, with modified start scripts. Ill do a few rc based stock installs of 10.1 .... See how we go. > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Oct 22 15:39:26 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 22 Oct 2014 11:39:26 -0400 Subject: [Freeipa-users] mastercrl.bin very old In-Reply-To: References: <543C119C.8070509@redhat.com> Message-ID: <5447CFAE.2040206@redhat.com> Natxo Asenjo wrote: > On Mon, Oct 13, 2014 at 9:39 PM, Natxo Asenjo wrote: >> But if I get it from the crl generator using /ipa/crl/MasterCRL.bin I >> still get the old crl dated june 28th last year. >> >> Should I modify ipa-pki-proxy.conf as well on the CRL generator host >> to point to the /ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >> as well? > > This morning the /ipa/crl dir still had the lists of 28th June 2013 in > the crl generator host. In my test environment running centos 7 the > files get updated, so I think a process is nut running. But which one? > > Going to the /ca/ee/ca/getCRL?op=getCRL& > crlIssuingPoint=MasterCRL gives me the up to date CRL. > > -- > Groeten, > natxo > To enable CRL generation you need these set: ca.crl.MasterCRL.enableCRLCache=false ca.crl.MasterCRL.enableCRLUpdates=false Given that the CA seems to be generating a new CRL that you can fetch directly I'll assume those are set. The CA also needs configuration on how/where to publish a file-based CRL. The configuration should look like: ca.publish.publisher.instance.FileBaseCRLPublisher.crlLinkExt=bin ca.publish.publisher.instance.FileBaseCRLPublisher.directory=/var/lib/ipa/pki-ca/publish ca.publish.publisher.instance.FileBaseCRLPublisher.latestCrlLink=true ca.publish.publisher.instance.FileBaseCRLPublisher.pluginName=FileBasedPublisher ca.publish.publisher.instance.FileBaseCRLPublisher.timeStamp=LocalTime ca.publish.publisher.instance.FileBaseCRLPublisher.zipCRLs=false ca.publish.publisher.instance.FileBaseCRLPublisher.zipLevel=9 ca.publish.publisher.instance.FileBaseCRLPublisher.Filename.b64=false ca.publish.publisher.instance.FileBaseCRLPublisher.Filename.der=true ca.publish.rule.instance.FileCrlRule.publisher=FileBaseCRLPublisher rob From desantis at mail.usf.edu Wed Oct 22 15:42:28 2014 From: desantis at mail.usf.edu (John Desantis) Date: Wed, 22 Oct 2014 11:42:28 -0400 Subject: [Freeipa-users] Attempting to re-provision previous replica Message-ID: Hello all, First and foremost, a big "thank you!" to the FreeIPA developers for a great product! Now, to the point! We're trying to re-provision a previous replica using the standard documentation via the Red Hat site: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Setting_up_IPA_Replicas.html However, we're running into errors during the import process. The errors are varied and fail at random steps; there was an issue with NTP or HTTP or LDAP, etc. This did not happen when we promoted a separate node to become a replica. We had previously removed the replica via `ipa-replica-manage del` and ensured that no trace of it being a replica existed: removed DNS records and verified that the host enrollment was not present. I did not use the "--force" and "--cleanup" options. When I check RUV's against the host in question, there are several. I also queried the tombstones against the host and found two entries which have valid hex time stamps; coincidentally, out of the 9 tombstone entries, 2 have "nsds50ruv" time stamps. I'll paste sanitized output below: # ldapsaerch -x -W -LLL -D "cn=directory manager" -b "dc=our,dc=personal,dc=domain" '(objectclass=nsTombstone)' Enter LDAP Password: dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=our,dc=personal,dc=domain objectClass: top objectClass: nsTombstone objectClass: extensibleobject nsds50ruv: {replicageneration} 50ef13ae000000040000 nsds50ruv: {replica 4 ldap://master.our.personal.domain:389} 5164d147000000040000 5447bda 8000100040000 nsds50ruv: {replica 22 ldap://separatenode.our.personal.domain:389} 54107f9f000000160000 54436b 25000000160000 nsds50ruv: {replica 21 ldap://iparepbackup.our.personal.domain:389} 51b734de000000150000 51b7 34ef000200150000 nsds50ruv: {replica 19 ldap://host-in-question.our.personal.domain:389} 510d56c9000100130000 510d82 be000200130000 nsds50ruv: {replica 18 ldap://host-in-question.our.personal.domain:389} nsds50ruv: {replica 17 ldap://host-in-question.our.personal.domain:389} nsds50ruv: {replica 16 ldap://host-in-question.our.personal.domain:389} nsds50ruv: {replica 15 ldap://host-in-question.our.personal.domain:389} nsds50ruv: {replica 14 ldap://host-in-question.our.personal.domain:389} nsds50ruv: {replica 13 ldap://host-in-question.our.personal.domain:389} nsds50ruv: {replica 12 ldap://host-in-question.our.personal.domain:389} nsds50ruv: {replica 23 ldap://host-in-question.our.personal.domain:389} 54187702000200170000 541878 9a000000170000 dc: our nsruvReplicaLastModified: {replica 4 ldap://master.our.personal.domain:389} 5447bce8 nsruvReplicaLastModified: {replica 22 ldap://separatenode.our.personal.domain:389} 54436a5e nsruvReplicaLastModified: {replica 21 ldap://iparepbackup.our.personal.domain:389} 00000000 nsruvReplicaLastModified: {replica 19 ldap://host-in-question.our.personal.domain:389} 00000000 nsruvReplicaLastModified: {replica 18 ldap://host-in-question.our.personal.domain:389} 00000000 nsruvReplicaLastModified: {replica 17 ldap://host-in-question.our.personal.domain:389} 00000000 nsruvReplicaLastModified: {replica 16 ldap://host-in-question.our.personal.domain:389} 00000000 nsruvReplicaLastModified: {replica 15 ldap://host-in-question.our.personal.domain:389} 00000000 nsruvReplicaLastModified: {replica 14 ldap://host-in-question.our.personal.domain:389} 00000000 nsruvReplicaLastModified: {replica 13 ldap://host-in-question.our.personal.domain:389} 00000000 nsruvReplicaLastModified: {replica 12 ldap://host-in-question.our.personal.domain:389} 00000000 nsruvReplicaLastModified: {replica 23 ldap://host-in-question.our.personal.domain:389} 00000000 dn: nsuniqueid=c08a2803-5b5a11e2-a527ce8b-8fa47d35,cn=host-in-question.our.personal.domain,cn=maste rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain objectClass: top objectClass: nsContainer objectClass: nsTombstone cn: host-in-question.our.personal.domain nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 dn: nsuniqueid=664c4383-6d6311e2-8db6e946-de27dd8d,cn=host-in-question.our.personal.domain,cn=maste rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain objectClass: top objectClass: nsContainer objectClass: nsTombstone cn: host-in-question.our.personal.domain nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 As you can see, the "host-in-question" has many RUV's and of which two appear to be "active" and two entries which I believe (pardon my ignorance) possibly correlate with the "active" entries of the "host-in-question". Do these two tombstone entries need to be deleted with ldapdelete before we can re-provision "host-in-question" and add it back as a replica? Thank you, John DeSantis From rmeggins at redhat.com Wed Oct 22 16:09:50 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 22 Oct 2014 10:09:50 -0600 Subject: [Freeipa-users] Attempting to re-provision previous replica In-Reply-To: References: Message-ID: <5447D6CE.1020305@redhat.com> On 10/22/2014 09:42 AM, John Desantis wrote: > Hello all, > > First and foremost, a big "thank you!" to the FreeIPA developers for a > great product! > > Now, to the point! > > We're trying to re-provision a previous replica using the standard > documentation via the Red Hat site: > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Setting_up_IPA_Replicas.html > > However, we're running into errors during the import process. The > errors are varied and fail at random steps; there was an issue with > NTP or HTTP or LDAP, etc. This did not happen when we promoted a > separate node to become a replica. > > We had previously removed the replica via `ipa-replica-manage del` and > ensured that no trace of it being a replica existed: removed DNS > records and verified that the host enrollment was not present. I did > not use the "--force" and "--cleanup" options. What version of 389 are you using? rpm -q 389-ds-base > > When I check RUV's against the host in question, there are several. I > also queried the tombstones against the host and found two entries > which have valid hex time stamps; coincidentally, out of the 9 > tombstone entries, 2 have "nsds50ruv" time stamps. I'll paste > sanitized output below: > > # ldapsaerch -x -W -LLL -D "cn=directory manager" -b > "dc=our,dc=personal,dc=domain" '(objectclass=nsTombstone)' > Enter LDAP Password: > dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=our,dc=personal,dc=domain > objectClass: top > objectClass: nsTombstone > objectClass: extensibleobject > nsds50ruv: {replicageneration} 50ef13ae000000040000 > nsds50ruv: {replica 4 ldap://master.our.personal.domain:389} > 5164d147000000040000 5447bda 8000100040000 > nsds50ruv: {replica 22 ldap://separatenode.our.personal.domain:389} > 54107f9f000000160000 54436b 25000000160000 > nsds50ruv: {replica 21 ldap://iparepbackup.our.personal.domain:389} > 51b734de000000150000 51b7 34ef000200150000 > nsds50ruv: {replica 19 > ldap://host-in-question.our.personal.domain:389} 510d56c9000100130000 > 510d82 be000200130000 > nsds50ruv: {replica 18 ldap://host-in-question.our.personal.domain:389} > nsds50ruv: {replica 17 ldap://host-in-question.our.personal.domain:389} > nsds50ruv: {replica 16 ldap://host-in-question.our.personal.domain:389} > nsds50ruv: {replica 15 ldap://host-in-question.our.personal.domain:389} > nsds50ruv: {replica 14 ldap://host-in-question.our.personal.domain:389} > nsds50ruv: {replica 13 ldap://host-in-question.our.personal.domain:389} > nsds50ruv: {replica 12 ldap://host-in-question.our.personal.domain:389} > nsds50ruv: {replica 23 > ldap://host-in-question.our.personal.domain:389} 54187702000200170000 > 541878 9a000000170000 > dc: our > nsruvReplicaLastModified: {replica 4 > ldap://master.our.personal.domain:389} 5447bce8 > nsruvReplicaLastModified: {replica 22 > ldap://separatenode.our.personal.domain:389} 54436a5e > nsruvReplicaLastModified: {replica 21 > ldap://iparepbackup.our.personal.domain:389} 00000000 > nsruvReplicaLastModified: {replica 19 > ldap://host-in-question.our.personal.domain:389} 00000000 > nsruvReplicaLastModified: {replica 18 > ldap://host-in-question.our.personal.domain:389} 00000000 > nsruvReplicaLastModified: {replica 17 > ldap://host-in-question.our.personal.domain:389} 00000000 > nsruvReplicaLastModified: {replica 16 > ldap://host-in-question.our.personal.domain:389} 00000000 > nsruvReplicaLastModified: {replica 15 > ldap://host-in-question.our.personal.domain:389} 00000000 > nsruvReplicaLastModified: {replica 14 > ldap://host-in-question.our.personal.domain:389} 00000000 > nsruvReplicaLastModified: {replica 13 > ldap://host-in-question.our.personal.domain:389} 00000000 > nsruvReplicaLastModified: {replica 12 > ldap://host-in-question.our.personal.domain:389} 00000000 > nsruvReplicaLastModified: {replica 23 > ldap://host-in-question.our.personal.domain:389} 00000000 > > dn: nsuniqueid=c08a2803-5b5a11e2-a527ce8b-8fa47d35,cn=host-in-question.our.personal.domain,cn=maste > rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain > objectClass: top > objectClass: nsContainer > objectClass: nsTombstone > cn: host-in-question.our.personal.domain > nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 > > dn: nsuniqueid=664c4383-6d6311e2-8db6e946-de27dd8d,cn=host-in-question.our.personal.domain,cn=maste > rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain > objectClass: top > objectClass: nsContainer > objectClass: nsTombstone > cn: host-in-question.our.personal.domain > nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 > > As you can see, the "host-in-question" has many RUV's and of which two > appear to be "active" and two entries which I believe (pardon my > ignorance) possibly correlate with the "active" entries of the > "host-in-question". > > Do these two tombstone entries need to be deleted with ldapdelete > before we can re-provision "host-in-question" and add it back as a > replica? > > Thank you, > John DeSantis > From desantis at mail.usf.edu Wed Oct 22 16:31:12 2014 From: desantis at mail.usf.edu (John Desantis) Date: Wed, 22 Oct 2014 12:31:12 -0400 Subject: [Freeipa-users] Attempting to re-provision previous replica In-Reply-To: <5447D6CE.1020305@redhat.com> References: <5447D6CE.1020305@redhat.com> Message-ID: Richard, You helped me before in #freeipa, so I appreciate the assistance again. > What version of 389 are you using? > rpm -q 389-ds-base 389-ds-base-1.2.11.15-34.el6_5 Thanks, John DeSantis 2014-10-22 12:09 GMT-04:00 Rich Megginson : > On 10/22/2014 09:42 AM, John Desantis wrote: >> >> Hello all, >> >> First and foremost, a big "thank you!" to the FreeIPA developers for a >> great product! >> >> Now, to the point! >> >> We're trying to re-provision a previous replica using the standard >> documentation via the Red Hat site: >> >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Setting_up_IPA_Replicas.html >> >> However, we're running into errors during the import process. The >> errors are varied and fail at random steps; there was an issue with >> NTP or HTTP or LDAP, etc. This did not happen when we promoted a >> separate node to become a replica. >> >> We had previously removed the replica via `ipa-replica-manage del` and >> ensured that no trace of it being a replica existed: removed DNS >> records and verified that the host enrollment was not present. I did >> not use the "--force" and "--cleanup" options. > > > What version of 389 are you using? > rpm -q 389-ds-base >> >> >> When I check RUV's against the host in question, there are several. I >> also queried the tombstones against the host and found two entries >> which have valid hex time stamps; coincidentally, out of the 9 >> tombstone entries, 2 have "nsds50ruv" time stamps. I'll paste >> sanitized output below: >> >> # ldapsaerch -x -W -LLL -D "cn=directory manager" -b >> "dc=our,dc=personal,dc=domain" '(objectclass=nsTombstone)' >> Enter LDAP Password: >> dn: >> nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=our,dc=personal,dc=domain >> objectClass: top >> objectClass: nsTombstone >> objectClass: extensibleobject >> nsds50ruv: {replicageneration} 50ef13ae000000040000 >> nsds50ruv: {replica 4 ldap://master.our.personal.domain:389} >> 5164d147000000040000 5447bda 8000100040000 >> nsds50ruv: {replica 22 ldap://separatenode.our.personal.domain:389} >> 54107f9f000000160000 54436b 25000000160000 >> nsds50ruv: {replica 21 ldap://iparepbackup.our.personal.domain:389} >> 51b734de000000150000 51b7 34ef000200150000 >> nsds50ruv: {replica 19 >> ldap://host-in-question.our.personal.domain:389} 510d56c9000100130000 >> 510d82 be000200130000 >> nsds50ruv: {replica 18 ldap://host-in-question.our.personal.domain:389} >> nsds50ruv: {replica 17 ldap://host-in-question.our.personal.domain:389} >> nsds50ruv: {replica 16 ldap://host-in-question.our.personal.domain:389} >> nsds50ruv: {replica 15 ldap://host-in-question.our.personal.domain:389} >> nsds50ruv: {replica 14 ldap://host-in-question.our.personal.domain:389} >> nsds50ruv: {replica 13 ldap://host-in-question.our.personal.domain:389} >> nsds50ruv: {replica 12 ldap://host-in-question.our.personal.domain:389} >> nsds50ruv: {replica 23 >> ldap://host-in-question.our.personal.domain:389} 54187702000200170000 >> 541878 9a000000170000 >> dc: our >> nsruvReplicaLastModified: {replica 4 >> ldap://master.our.personal.domain:389} 5447bce8 >> nsruvReplicaLastModified: {replica 22 >> ldap://separatenode.our.personal.domain:389} 54436a5e >> nsruvReplicaLastModified: {replica 21 >> ldap://iparepbackup.our.personal.domain:389} 00000000 >> nsruvReplicaLastModified: {replica 19 >> ldap://host-in-question.our.personal.domain:389} 00000000 >> nsruvReplicaLastModified: {replica 18 >> ldap://host-in-question.our.personal.domain:389} 00000000 >> nsruvReplicaLastModified: {replica 17 >> ldap://host-in-question.our.personal.domain:389} 00000000 >> nsruvReplicaLastModified: {replica 16 >> ldap://host-in-question.our.personal.domain:389} 00000000 >> nsruvReplicaLastModified: {replica 15 >> ldap://host-in-question.our.personal.domain:389} 00000000 >> nsruvReplicaLastModified: {replica 14 >> ldap://host-in-question.our.personal.domain:389} 00000000 >> nsruvReplicaLastModified: {replica 13 >> ldap://host-in-question.our.personal.domain:389} 00000000 >> nsruvReplicaLastModified: {replica 12 >> ldap://host-in-question.our.personal.domain:389} 00000000 >> nsruvReplicaLastModified: {replica 23 >> ldap://host-in-question.our.personal.domain:389} 00000000 >> >> dn: >> nsuniqueid=c08a2803-5b5a11e2-a527ce8b-8fa47d35,cn=host-in-question.our.personal.domain,cn=maste >> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >> objectClass: top >> objectClass: nsContainer >> objectClass: nsTombstone >> cn: host-in-question.our.personal.domain >> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >> >> dn: >> nsuniqueid=664c4383-6d6311e2-8db6e946-de27dd8d,cn=host-in-question.our.personal.domain,cn=maste >> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >> objectClass: top >> objectClass: nsContainer >> objectClass: nsTombstone >> cn: host-in-question.our.personal.domain >> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >> >> As you can see, the "host-in-question" has many RUV's and of which two >> appear to be "active" and two entries which I believe (pardon my >> ignorance) possibly correlate with the "active" entries of the >> "host-in-question". >> >> Do these two tombstone entries need to be deleted with ldapdelete >> before we can re-provision "host-in-question" and add it back as a >> replica? >> >> Thank you, >> John DeSantis >> > > -- > 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 From rmeggins at redhat.com Wed Oct 22 16:51:28 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 22 Oct 2014 10:51:28 -0600 Subject: [Freeipa-users] Attempting to re-provision previous replica In-Reply-To: References: <5447D6CE.1020305@redhat.com> Message-ID: <5447E090.9000901@redhat.com> On 10/22/2014 10:31 AM, John Desantis wrote: > Richard, > > You helped me before in #freeipa, so I appreciate the assistance again. > >> What version of 389 are you using? >> rpm -q 389-ds-base > 389-ds-base-1.2.11.15-34.el6_5 > > Thanks, > John DeSantis > > 2014-10-22 12:09 GMT-04:00 Rich Megginson : >> On 10/22/2014 09:42 AM, John Desantis wrote: >>> Hello all, >>> >>> First and foremost, a big "thank you!" to the FreeIPA developers for a >>> great product! >>> >>> Now, to the point! >>> >>> We're trying to re-provision a previous replica using the standard >>> documentation via the Red Hat site: >>> >>> >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Setting_up_IPA_Replicas.html >>> >>> However, we're running into errors during the import process. The >>> errors are varied and fail at random steps; there was an issue with >>> NTP or HTTP or LDAP, etc. This did not happen when we promoted a >>> separate node to become a replica. >>> >>> We had previously removed the replica via `ipa-replica-manage del` and >>> ensured that no trace of it being a replica existed: removed DNS >>> records and verified that the host enrollment was not present. I did >>> not use the "--force" and "--cleanup" options. >> >> What version of 389 are you using? >> rpm -q 389-ds-base You should remove the unused ruv elements. I'm not sure why they were not cleaned. You may have to use cleanallruv manually. https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv note - use the cleanallruv procedure, not cleanruv. >>> >>> When I check RUV's against the host in question, there are several. I >>> also queried the tombstones against the host and found two entries >>> which have valid hex time stamps; coincidentally, out of the 9 >>> tombstone entries, 2 have "nsds50ruv" time stamps. I'll paste >>> sanitized output below: >>> >>> # ldapsaerch -x -W -LLL -D "cn=directory manager" -b >>> "dc=our,dc=personal,dc=domain" '(objectclass=nsTombstone)' >>> Enter LDAP Password: >>> dn: >>> nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=our,dc=personal,dc=domain >>> objectClass: top >>> objectClass: nsTombstone >>> objectClass: extensibleobject >>> nsds50ruv: {replicageneration} 50ef13ae000000040000 >>> nsds50ruv: {replica 4 ldap://master.our.personal.domain:389} >>> 5164d147000000040000 5447bda 8000100040000 >>> nsds50ruv: {replica 22 ldap://separatenode.our.personal.domain:389} >>> 54107f9f000000160000 54436b 25000000160000 >>> nsds50ruv: {replica 21 ldap://iparepbackup.our.personal.domain:389} >>> 51b734de000000150000 51b7 34ef000200150000 >>> nsds50ruv: {replica 19 >>> ldap://host-in-question.our.personal.domain:389} 510d56c9000100130000 >>> 510d82 be000200130000 >>> nsds50ruv: {replica 18 ldap://host-in-question.our.personal.domain:389} >>> nsds50ruv: {replica 17 ldap://host-in-question.our.personal.domain:389} >>> nsds50ruv: {replica 16 ldap://host-in-question.our.personal.domain:389} >>> nsds50ruv: {replica 15 ldap://host-in-question.our.personal.domain:389} >>> nsds50ruv: {replica 14 ldap://host-in-question.our.personal.domain:389} >>> nsds50ruv: {replica 13 ldap://host-in-question.our.personal.domain:389} >>> nsds50ruv: {replica 12 ldap://host-in-question.our.personal.domain:389} >>> nsds50ruv: {replica 23 >>> ldap://host-in-question.our.personal.domain:389} 54187702000200170000 >>> 541878 9a000000170000 >>> dc: our >>> nsruvReplicaLastModified: {replica 4 >>> ldap://master.our.personal.domain:389} 5447bce8 >>> nsruvReplicaLastModified: {replica 22 >>> ldap://separatenode.our.personal.domain:389} 54436a5e >>> nsruvReplicaLastModified: {replica 21 >>> ldap://iparepbackup.our.personal.domain:389} 00000000 >>> nsruvReplicaLastModified: {replica 19 >>> ldap://host-in-question.our.personal.domain:389} 00000000 >>> nsruvReplicaLastModified: {replica 18 >>> ldap://host-in-question.our.personal.domain:389} 00000000 >>> nsruvReplicaLastModified: {replica 17 >>> ldap://host-in-question.our.personal.domain:389} 00000000 >>> nsruvReplicaLastModified: {replica 16 >>> ldap://host-in-question.our.personal.domain:389} 00000000 >>> nsruvReplicaLastModified: {replica 15 >>> ldap://host-in-question.our.personal.domain:389} 00000000 >>> nsruvReplicaLastModified: {replica 14 >>> ldap://host-in-question.our.personal.domain:389} 00000000 >>> nsruvReplicaLastModified: {replica 13 >>> ldap://host-in-question.our.personal.domain:389} 00000000 >>> nsruvReplicaLastModified: {replica 12 >>> ldap://host-in-question.our.personal.domain:389} 00000000 >>> nsruvReplicaLastModified: {replica 23 >>> ldap://host-in-question.our.personal.domain:389} 00000000 >>> >>> dn: >>> nsuniqueid=c08a2803-5b5a11e2-a527ce8b-8fa47d35,cn=host-in-question.our.personal.domain,cn=maste >>> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >>> objectClass: top >>> objectClass: nsContainer >>> objectClass: nsTombstone >>> cn: host-in-question.our.personal.domain >>> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >>> >>> dn: >>> nsuniqueid=664c4383-6d6311e2-8db6e946-de27dd8d,cn=host-in-question.our.personal.domain,cn=maste >>> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >>> objectClass: top >>> objectClass: nsContainer >>> objectClass: nsTombstone >>> cn: host-in-question.our.personal.domain >>> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >>> >>> As you can see, the "host-in-question" has many RUV's and of which two >>> appear to be "active" and two entries which I believe (pardon my >>> ignorance) possibly correlate with the "active" entries of the >>> "host-in-question". >>> >>> Do these two tombstone entries need to be deleted with ldapdelete >>> before we can re-provision "host-in-question" and add it back as a >>> replica? No, you cannot delete tombstones manually. They will be cleaned up at some point by the dirsrv tombstone reap thread, and they should not be interfering with anything. What is the real problem you have? Did replication stop working? Are you getting error messages? >>> >>> Thank you, >>> John DeSantis >>> >> -- >> 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 From desantis at mail.usf.edu Wed Oct 22 18:55:03 2014 From: desantis at mail.usf.edu (John Desantis) Date: Wed, 22 Oct 2014 14:55:03 -0400 Subject: [Freeipa-users] Attempting to re-provision previous replica In-Reply-To: <5447E090.9000901@redhat.com> References: <5447D6CE.1020305@redhat.com> <5447E090.9000901@redhat.com> Message-ID: Richard, > You should remove the unused ruv elements. I'm not sure why they were not > cleaned. You may have to use cleanallruv manually. > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv > > note - use the cleanallruv procedure, not cleanruv. I'll try that, thanks for the guidance. > What is the real problem you have? Did replication stop working? Are you > getting error messages? I cannot get the host to be a replica. Each time I run `ipa-replica-install replica-info-host-in-question.our.personal.domain.gpg' it fails. I had assumed it was due to the fact that the host was already a replica, but had to be taken offline due to a hard disk failing. The machine was re-provisioned after the new hard drive was installed. When I enabled extra debugging during the installation process, the initial error was that the dirsrv instance couldn't be started. I checked into this and found that there were missing files in /etc/dirsrv/slapd-BLAH directory. I was then able to start dirsrv after copying some schema files from another replica. The install did move forward but then failed with Apache and its IPA configuration. I performed several uninstalls and re-installs, and at one point I got error code 3 from ipa-replica-install, which is why I was thinking that the old RUV's and tombstones were to blame. Thanks, John DeSantis 2014-10-22 12:51 GMT-04:00 Rich Megginson : > On 10/22/2014 10:31 AM, John Desantis wrote: >> >> Richard, >> >> You helped me before in #freeipa, so I appreciate the assistance again. >> >>> What version of 389 are you using? >>> rpm -q 389-ds-base >> >> 389-ds-base-1.2.11.15-34.el6_5 >> >> Thanks, >> John DeSantis >> >> 2014-10-22 12:09 GMT-04:00 Rich Megginson : >>> >>> On 10/22/2014 09:42 AM, John Desantis wrote: >>>> >>>> Hello all, >>>> >>>> First and foremost, a big "thank you!" to the FreeIPA developers for a >>>> great product! >>>> >>>> Now, to the point! >>>> >>>> We're trying to re-provision a previous replica using the standard >>>> documentation via the Red Hat site: >>>> >>>> >>>> >>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Setting_up_IPA_Replicas.html >>>> >>>> However, we're running into errors during the import process. The >>>> errors are varied and fail at random steps; there was an issue with >>>> NTP or HTTP or LDAP, etc. This did not happen when we promoted a >>>> separate node to become a replica. >>>> >>>> We had previously removed the replica via `ipa-replica-manage del` and >>>> ensured that no trace of it being a replica existed: removed DNS >>>> records and verified that the host enrollment was not present. I did >>>> not use the "--force" and "--cleanup" options. >>> >>> >>> What version of 389 are you using? >>> rpm -q 389-ds-base > > > You should remove the unused ruv elements. I'm not sure why they were not > cleaned. You may have to use cleanallruv manually. > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv > > note - use the cleanallruv procedure, not cleanruv. > >>>> >>>> When I check RUV's against the host in question, there are several. I >>>> also queried the tombstones against the host and found two entries >>>> which have valid hex time stamps; coincidentally, out of the 9 >>>> tombstone entries, 2 have "nsds50ruv" time stamps. I'll paste >>>> sanitized output below: >>>> >>>> # ldapsaerch -x -W -LLL -D "cn=directory manager" -b >>>> "dc=our,dc=personal,dc=domain" '(objectclass=nsTombstone)' >>>> Enter LDAP Password: >>>> dn: >>>> >>>> nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=our,dc=personal,dc=domain >>>> objectClass: top >>>> objectClass: nsTombstone >>>> objectClass: extensibleobject >>>> nsds50ruv: {replicageneration} 50ef13ae000000040000 >>>> nsds50ruv: {replica 4 ldap://master.our.personal.domain:389} >>>> 5164d147000000040000 5447bda 8000100040000 >>>> nsds50ruv: {replica 22 ldap://separatenode.our.personal.domain:389} >>>> 54107f9f000000160000 54436b 25000000160000 >>>> nsds50ruv: {replica 21 ldap://iparepbackup.our.personal.domain:389} >>>> 51b734de000000150000 51b7 34ef000200150000 >>>> nsds50ruv: {replica 19 >>>> ldap://host-in-question.our.personal.domain:389} 510d56c9000100130000 >>>> 510d82 be000200130000 >>>> nsds50ruv: {replica 18 ldap://host-in-question.our.personal.domain:389} >>>> nsds50ruv: {replica 17 ldap://host-in-question.our.personal.domain:389} >>>> nsds50ruv: {replica 16 ldap://host-in-question.our.personal.domain:389} >>>> nsds50ruv: {replica 15 ldap://host-in-question.our.personal.domain:389} >>>> nsds50ruv: {replica 14 ldap://host-in-question.our.personal.domain:389} >>>> nsds50ruv: {replica 13 ldap://host-in-question.our.personal.domain:389} >>>> nsds50ruv: {replica 12 ldap://host-in-question.our.personal.domain:389} >>>> nsds50ruv: {replica 23 >>>> ldap://host-in-question.our.personal.domain:389} 54187702000200170000 >>>> 541878 9a000000170000 >>>> dc: our >>>> nsruvReplicaLastModified: {replica 4 >>>> ldap://master.our.personal.domain:389} 5447bce8 >>>> nsruvReplicaLastModified: {replica 22 >>>> ldap://separatenode.our.personal.domain:389} 54436a5e >>>> nsruvReplicaLastModified: {replica 21 >>>> ldap://iparepbackup.our.personal.domain:389} 00000000 >>>> nsruvReplicaLastModified: {replica 19 >>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>> nsruvReplicaLastModified: {replica 18 >>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>> nsruvReplicaLastModified: {replica 17 >>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>> nsruvReplicaLastModified: {replica 16 >>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>> nsruvReplicaLastModified: {replica 15 >>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>> nsruvReplicaLastModified: {replica 14 >>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>> nsruvReplicaLastModified: {replica 13 >>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>> nsruvReplicaLastModified: {replica 12 >>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>> nsruvReplicaLastModified: {replica 23 >>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>> >>>> dn: >>>> >>>> nsuniqueid=c08a2803-5b5a11e2-a527ce8b-8fa47d35,cn=host-in-question.our.personal.domain,cn=maste >>>> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >>>> objectClass: top >>>> objectClass: nsContainer >>>> objectClass: nsTombstone >>>> cn: host-in-question.our.personal.domain >>>> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >>>> >>>> dn: >>>> >>>> nsuniqueid=664c4383-6d6311e2-8db6e946-de27dd8d,cn=host-in-question.our.personal.domain,cn=maste >>>> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >>>> objectClass: top >>>> objectClass: nsContainer >>>> objectClass: nsTombstone >>>> cn: host-in-question.our.personal.domain >>>> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >>>> >>>> As you can see, the "host-in-question" has many RUV's and of which two >>>> appear to be "active" and two entries which I believe (pardon my >>>> ignorance) possibly correlate with the "active" entries of the >>>> "host-in-question". >>>> >>>> Do these two tombstone entries need to be deleted with ldapdelete >>>> before we can re-provision "host-in-question" and add it back as a >>>> replica? > > > No, you cannot delete tombstones manually. They will be cleaned up at some > point by the dirsrv tombstone reap thread, and they should not be > interfering with anything. > > What is the real problem you have? Did replication stop working? Are you > getting error messages? > >>>> >>>> Thank you, >>>> John DeSantis >>>> >>> -- >>> 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 From rmeggins at redhat.com Wed Oct 22 19:18:42 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 22 Oct 2014 13:18:42 -0600 Subject: [Freeipa-users] Attempting to re-provision previous replica In-Reply-To: References: <5447D6CE.1020305@redhat.com> <5447E090.9000901@redhat.com> Message-ID: <54480312.1010409@redhat.com> On 10/22/2014 12:55 PM, John Desantis wrote: > Richard, > >> You should remove the unused ruv elements. I'm not sure why they were not >> cleaned. You may have to use cleanallruv manually. >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv >> >> note - use the cleanallruv procedure, not cleanruv. > I'll try that, thanks for the guidance. > >> What is the real problem you have? Did replication stop working? Are you >> getting error messages? > I cannot get the host to be a replica. Each time I run > `ipa-replica-install > replica-info-host-in-question.our.personal.domain.gpg' it fails. I > had assumed it was due to the fact that the host was already a > replica, but had to be taken offline due to a hard disk failing. The > machine was re-provisioned after the new hard drive was installed. Ok. I don't know if we have a documented procedure for that case. I assumed that if you first ran ipa-replica-manage del, then ipa-replica-prepare, then ipa-replica-install, that would take care of that. > > When I enabled extra debugging during the installation process, the > initial error was that the dirsrv instance couldn't be started. I > checked into this and found that there were missing files in > /etc/dirsrv/slapd-BLAH directory. I was then able to start dirsrv > after copying some schema files from another replica. The install did > move forward but then failed with Apache and its IPA configuration. > > I performed several uninstalls and re-installs, and at one point I got > error code 3 from ipa-replica-install, which is why I was thinking > that the old RUV's and tombstones were to blame. It could be. I'm really not sure what the problem is at this point. > > Thanks, > John DeSantis > > > 2014-10-22 12:51 GMT-04:00 Rich Megginson : >> On 10/22/2014 10:31 AM, John Desantis wrote: >>> Richard, >>> >>> You helped me before in #freeipa, so I appreciate the assistance again. >>> >>>> What version of 389 are you using? >>>> rpm -q 389-ds-base >>> 389-ds-base-1.2.11.15-34.el6_5 >>> >>> Thanks, >>> John DeSantis >>> >>> 2014-10-22 12:09 GMT-04:00 Rich Megginson : >>>> On 10/22/2014 09:42 AM, John Desantis wrote: >>>>> Hello all, >>>>> >>>>> First and foremost, a big "thank you!" to the FreeIPA developers for a >>>>> great product! >>>>> >>>>> Now, to the point! >>>>> >>>>> We're trying to re-provision a previous replica using the standard >>>>> documentation via the Red Hat site: >>>>> >>>>> >>>>> >>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Setting_up_IPA_Replicas.html >>>>> >>>>> However, we're running into errors during the import process. The >>>>> errors are varied and fail at random steps; there was an issue with >>>>> NTP or HTTP or LDAP, etc. This did not happen when we promoted a >>>>> separate node to become a replica. >>>>> >>>>> We had previously removed the replica via `ipa-replica-manage del` and >>>>> ensured that no trace of it being a replica existed: removed DNS >>>>> records and verified that the host enrollment was not present. I did >>>>> not use the "--force" and "--cleanup" options. >>>> >>>> What version of 389 are you using? >>>> rpm -q 389-ds-base >> >> You should remove the unused ruv elements. I'm not sure why they were not >> cleaned. You may have to use cleanallruv manually. >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv >> >> note - use the cleanallruv procedure, not cleanruv. >> >>>>> When I check RUV's against the host in question, there are several. I >>>>> also queried the tombstones against the host and found two entries >>>>> which have valid hex time stamps; coincidentally, out of the 9 >>>>> tombstone entries, 2 have "nsds50ruv" time stamps. I'll paste >>>>> sanitized output below: >>>>> >>>>> # ldapsaerch -x -W -LLL -D "cn=directory manager" -b >>>>> "dc=our,dc=personal,dc=domain" '(objectclass=nsTombstone)' >>>>> Enter LDAP Password: >>>>> dn: >>>>> >>>>> nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=our,dc=personal,dc=domain >>>>> objectClass: top >>>>> objectClass: nsTombstone >>>>> objectClass: extensibleobject >>>>> nsds50ruv: {replicageneration} 50ef13ae000000040000 >>>>> nsds50ruv: {replica 4 ldap://master.our.personal.domain:389} >>>>> 5164d147000000040000 5447bda 8000100040000 >>>>> nsds50ruv: {replica 22 ldap://separatenode.our.personal.domain:389} >>>>> 54107f9f000000160000 54436b 25000000160000 >>>>> nsds50ruv: {replica 21 ldap://iparepbackup.our.personal.domain:389} >>>>> 51b734de000000150000 51b7 34ef000200150000 >>>>> nsds50ruv: {replica 19 >>>>> ldap://host-in-question.our.personal.domain:389} 510d56c9000100130000 >>>>> 510d82 be000200130000 >>>>> nsds50ruv: {replica 18 ldap://host-in-question.our.personal.domain:389} >>>>> nsds50ruv: {replica 17 ldap://host-in-question.our.personal.domain:389} >>>>> nsds50ruv: {replica 16 ldap://host-in-question.our.personal.domain:389} >>>>> nsds50ruv: {replica 15 ldap://host-in-question.our.personal.domain:389} >>>>> nsds50ruv: {replica 14 ldap://host-in-question.our.personal.domain:389} >>>>> nsds50ruv: {replica 13 ldap://host-in-question.our.personal.domain:389} >>>>> nsds50ruv: {replica 12 ldap://host-in-question.our.personal.domain:389} >>>>> nsds50ruv: {replica 23 >>>>> ldap://host-in-question.our.personal.domain:389} 54187702000200170000 >>>>> 541878 9a000000170000 >>>>> dc: our >>>>> nsruvReplicaLastModified: {replica 4 >>>>> ldap://master.our.personal.domain:389} 5447bce8 >>>>> nsruvReplicaLastModified: {replica 22 >>>>> ldap://separatenode.our.personal.domain:389} 54436a5e >>>>> nsruvReplicaLastModified: {replica 21 >>>>> ldap://iparepbackup.our.personal.domain:389} 00000000 >>>>> nsruvReplicaLastModified: {replica 19 >>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>> nsruvReplicaLastModified: {replica 18 >>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>> nsruvReplicaLastModified: {replica 17 >>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>> nsruvReplicaLastModified: {replica 16 >>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>> nsruvReplicaLastModified: {replica 15 >>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>> nsruvReplicaLastModified: {replica 14 >>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>> nsruvReplicaLastModified: {replica 13 >>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>> nsruvReplicaLastModified: {replica 12 >>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>> nsruvReplicaLastModified: {replica 23 >>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>> >>>>> dn: >>>>> >>>>> nsuniqueid=c08a2803-5b5a11e2-a527ce8b-8fa47d35,cn=host-in-question.our.personal.domain,cn=maste >>>>> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >>>>> objectClass: top >>>>> objectClass: nsContainer >>>>> objectClass: nsTombstone >>>>> cn: host-in-question.our.personal.domain >>>>> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >>>>> >>>>> dn: >>>>> >>>>> nsuniqueid=664c4383-6d6311e2-8db6e946-de27dd8d,cn=host-in-question.our.personal.domain,cn=maste >>>>> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >>>>> objectClass: top >>>>> objectClass: nsContainer >>>>> objectClass: nsTombstone >>>>> cn: host-in-question.our.personal.domain >>>>> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >>>>> >>>>> As you can see, the "host-in-question" has many RUV's and of which two >>>>> appear to be "active" and two entries which I believe (pardon my >>>>> ignorance) possibly correlate with the "active" entries of the >>>>> "host-in-question". >>>>> >>>>> Do these two tombstone entries need to be deleted with ldapdelete >>>>> before we can re-provision "host-in-question" and add it back as a >>>>> replica? >> >> No, you cannot delete tombstones manually. They will be cleaned up at some >> point by the dirsrv tombstone reap thread, and they should not be >> interfering with anything. >> >> What is the real problem you have? Did replication stop working? Are you >> getting error messages? >> >>>>> Thank you, >>>>> John DeSantis >>>>> >>>> -- >>>> 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 From rcritten at redhat.com Wed Oct 22 19:49:23 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 22 Oct 2014 15:49:23 -0400 Subject: [Freeipa-users] Attempting to re-provision previous replica In-Reply-To: <54480312.1010409@redhat.com> References: <5447D6CE.1020305@redhat.com> <5447E090.9000901@redhat.com> <54480312.1010409@redhat.com> Message-ID: <54480A43.1020700@redhat.com> Rich Megginson wrote: > On 10/22/2014 12:55 PM, John Desantis wrote: >> Richard, >> >>> You should remove the unused ruv elements. I'm not sure why they >>> were not >>> cleaned. You may have to use cleanallruv manually. >>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv >>> >>> >>> note - use the cleanallruv procedure, not cleanruv. >> I'll try that, thanks for the guidance. >> >>> What is the real problem you have? Did replication stop working? Are >>> you >>> getting error messages? >> I cannot get the host to be a replica. Each time I run >> `ipa-replica-install >> replica-info-host-in-question.our.personal.domain.gpg' it fails. I >> had assumed it was due to the fact that the host was already a >> replica, but had to be taken offline due to a hard disk failing. The >> machine was re-provisioned after the new hard drive was installed. > > Ok. I don't know if we have a documented procedure for that case. I > assumed that if you first ran ipa-replica-manage del, then > ipa-replica-prepare, then ipa-replica-install, that would take care of > that. ipa-replica-manage del should have cleaned things up. You can clear out old RUVs with ipa-replica-manage too via list-ruv and clean-ruv. You use list-ruv to get the id# to clean and clean-ruv to do the actual cleaning. >> >> When I enabled extra debugging during the installation process, the >> initial error was that the dirsrv instance couldn't be started. I >> checked into this and found that there were missing files in >> /etc/dirsrv/slapd-BLAH directory. I was then able to start dirsrv >> after copying some schema files from another replica. The install did >> move forward but then failed with Apache and its IPA configuration. >> >> I performed several uninstalls and re-installs, and at one point I got >> error code 3 from ipa-replica-install, which is why I was thinking >> that the old RUV's and tombstones were to blame. > > It could be. I'm really not sure what the problem is at this point. I think we'd need to see ipareplica-install.log to know for sure. It could be the sort of thing where it fails early but doesn't kill the install, so the last error is a red herring. rob > >> >> Thanks, >> John DeSantis >> >> >> 2014-10-22 12:51 GMT-04:00 Rich Megginson : >>> On 10/22/2014 10:31 AM, John Desantis wrote: >>>> Richard, >>>> >>>> You helped me before in #freeipa, so I appreciate the assistance again. >>>> >>>>> What version of 389 are you using? >>>>> rpm -q 389-ds-base >>>> 389-ds-base-1.2.11.15-34.el6_5 >>>> >>>> Thanks, >>>> John DeSantis >>>> >>>> 2014-10-22 12:09 GMT-04:00 Rich Megginson : >>>>> On 10/22/2014 09:42 AM, John Desantis wrote: >>>>>> Hello all, >>>>>> >>>>>> First and foremost, a big "thank you!" to the FreeIPA developers >>>>>> for a >>>>>> great product! >>>>>> >>>>>> Now, to the point! >>>>>> >>>>>> We're trying to re-provision a previous replica using the standard >>>>>> documentation via the Red Hat site: >>>>>> >>>>>> >>>>>> >>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Setting_up_IPA_Replicas.html >>>>>> >>>>>> >>>>>> However, we're running into errors during the import process. The >>>>>> errors are varied and fail at random steps; there was an issue with >>>>>> NTP or HTTP or LDAP, etc. This did not happen when we promoted a >>>>>> separate node to become a replica. >>>>>> >>>>>> We had previously removed the replica via `ipa-replica-manage del` >>>>>> and >>>>>> ensured that no trace of it being a replica existed: removed DNS >>>>>> records and verified that the host enrollment was not present. I did >>>>>> not use the "--force" and "--cleanup" options. >>>>> >>>>> What version of 389 are you using? >>>>> rpm -q 389-ds-base >>> >>> You should remove the unused ruv elements. I'm not sure why they >>> were not >>> cleaned. You may have to use cleanallruv manually. >>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv >>> >>> >>> note - use the cleanallruv procedure, not cleanruv. >>> >>>>>> When I check RUV's against the host in question, there are >>>>>> several. I >>>>>> also queried the tombstones against the host and found two entries >>>>>> which have valid hex time stamps; coincidentally, out of the 9 >>>>>> tombstone entries, 2 have "nsds50ruv" time stamps. I'll paste >>>>>> sanitized output below: >>>>>> >>>>>> # ldapsaerch -x -W -LLL -D "cn=directory manager" -b >>>>>> "dc=our,dc=personal,dc=domain" '(objectclass=nsTombstone)' >>>>>> Enter LDAP Password: >>>>>> dn: >>>>>> >>>>>> nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=our,dc=personal,dc=domain >>>>>> >>>>>> objectClass: top >>>>>> objectClass: nsTombstone >>>>>> objectClass: extensibleobject >>>>>> nsds50ruv: {replicageneration} 50ef13ae000000040000 >>>>>> nsds50ruv: {replica 4 ldap://master.our.personal.domain:389} >>>>>> 5164d147000000040000 5447bda 8000100040000 >>>>>> nsds50ruv: {replica 22 ldap://separatenode.our.personal.domain:389} >>>>>> 54107f9f000000160000 54436b 25000000160000 >>>>>> nsds50ruv: {replica 21 ldap://iparepbackup.our.personal.domain:389} >>>>>> 51b734de000000150000 51b7 34ef000200150000 >>>>>> nsds50ruv: {replica 19 >>>>>> ldap://host-in-question.our.personal.domain:389} 510d56c9000100130000 >>>>>> 510d82 be000200130000 >>>>>> nsds50ruv: {replica 18 >>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>> nsds50ruv: {replica 17 >>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>> nsds50ruv: {replica 16 >>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>> nsds50ruv: {replica 15 >>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>> nsds50ruv: {replica 14 >>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>> nsds50ruv: {replica 13 >>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>> nsds50ruv: {replica 12 >>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>> nsds50ruv: {replica 23 >>>>>> ldap://host-in-question.our.personal.domain:389} 54187702000200170000 >>>>>> 541878 9a000000170000 >>>>>> dc: our >>>>>> nsruvReplicaLastModified: {replica 4 >>>>>> ldap://master.our.personal.domain:389} 5447bce8 >>>>>> nsruvReplicaLastModified: {replica 22 >>>>>> ldap://separatenode.our.personal.domain:389} 54436a5e >>>>>> nsruvReplicaLastModified: {replica 21 >>>>>> ldap://iparepbackup.our.personal.domain:389} 00000000 >>>>>> nsruvReplicaLastModified: {replica 19 >>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>> nsruvReplicaLastModified: {replica 18 >>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>> nsruvReplicaLastModified: {replica 17 >>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>> nsruvReplicaLastModified: {replica 16 >>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>> nsruvReplicaLastModified: {replica 15 >>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>> nsruvReplicaLastModified: {replica 14 >>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>> nsruvReplicaLastModified: {replica 13 >>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>> nsruvReplicaLastModified: {replica 12 >>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>> nsruvReplicaLastModified: {replica 23 >>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>> >>>>>> dn: >>>>>> >>>>>> nsuniqueid=c08a2803-5b5a11e2-a527ce8b-8fa47d35,cn=host-in-question.our.personal.domain,cn=maste >>>>>> >>>>>> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >>>>>> objectClass: top >>>>>> objectClass: nsContainer >>>>>> objectClass: nsTombstone >>>>>> cn: host-in-question.our.personal.domain >>>>>> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >>>>>> >>>>>> dn: >>>>>> >>>>>> nsuniqueid=664c4383-6d6311e2-8db6e946-de27dd8d,cn=host-in-question.our.personal.domain,cn=maste >>>>>> >>>>>> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >>>>>> objectClass: top >>>>>> objectClass: nsContainer >>>>>> objectClass: nsTombstone >>>>>> cn: host-in-question.our.personal.domain >>>>>> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >>>>>> >>>>>> As you can see, the "host-in-question" has many RUV's and of which >>>>>> two >>>>>> appear to be "active" and two entries which I believe (pardon my >>>>>> ignorance) possibly correlate with the "active" entries of the >>>>>> "host-in-question". >>>>>> >>>>>> Do these two tombstone entries need to be deleted with ldapdelete >>>>>> before we can re-provision "host-in-question" and add it back as a >>>>>> replica? >>> >>> No, you cannot delete tombstones manually. They will be cleaned up >>> at some >>> point by the dirsrv tombstone reap thread, and they should not be >>> interfering with anything. >>> >>> What is the real problem you have? Did replication stop working? Are >>> you >>> getting error messages? >>> >>>>>> Thank you, >>>>>> John DeSantis >>>>>> >>>>> -- >>>>> 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 > From desantis at mail.usf.edu Wed Oct 22 20:03:42 2014 From: desantis at mail.usf.edu (John Desantis) Date: Wed, 22 Oct 2014 16:03:42 -0400 Subject: [Freeipa-users] Attempting to re-provision previous replica In-Reply-To: <54480A43.1020700@redhat.com> References: <5447D6CE.1020305@redhat.com> <5447E090.9000901@redhat.com> <54480312.1010409@redhat.com> <54480A43.1020700@redhat.com> Message-ID: Rob and Rich, > ipa-replica-manage del should have cleaned things up. You can clear out > old RUVs with ipa-replica-manage too via list-ruv and clean-ruv. You use > list-ruv to get the id# to clean and clean-ruv to do the actual cleaning. I remember having previously tried this task, but it had failed on older RUV's which were not even active (the KDC was under some strain so ipa queries were timing out). However, I ran it again and have been able to delete all but 1 (it's still running) RUV referencing the previous replica. I'll report back once the tasks finishes or fails. Thanks, John DeSantis 2014-10-22 15:49 GMT-04:00 Rob Crittenden : > Rich Megginson wrote: >> On 10/22/2014 12:55 PM, John Desantis wrote: >>> Richard, >>> >>>> You should remove the unused ruv elements. I'm not sure why they >>>> were not >>>> cleaned. You may have to use cleanallruv manually. >>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv >>>> >>>> >>>> note - use the cleanallruv procedure, not cleanruv. >>> I'll try that, thanks for the guidance. >>> >>>> What is the real problem you have? Did replication stop working? Are >>>> you >>>> getting error messages? >>> I cannot get the host to be a replica. Each time I run >>> `ipa-replica-install >>> replica-info-host-in-question.our.personal.domain.gpg' it fails. I >>> had assumed it was due to the fact that the host was already a >>> replica, but had to be taken offline due to a hard disk failing. The >>> machine was re-provisioned after the new hard drive was installed. >> >> Ok. I don't know if we have a documented procedure for that case. I >> assumed that if you first ran ipa-replica-manage del, then >> ipa-replica-prepare, then ipa-replica-install, that would take care of >> that. > > ipa-replica-manage del should have cleaned things up. You can clear out > old RUVs with ipa-replica-manage too via list-ruv and clean-ruv. You use > list-ruv to get the id# to clean and clean-ruv to do the actual cleaning. > >>> >>> When I enabled extra debugging during the installation process, the >>> initial error was that the dirsrv instance couldn't be started. I >>> checked into this and found that there were missing files in >>> /etc/dirsrv/slapd-BLAH directory. I was then able to start dirsrv >>> after copying some schema files from another replica. The install did >>> move forward but then failed with Apache and its IPA configuration. >>> >>> I performed several uninstalls and re-installs, and at one point I got >>> error code 3 from ipa-replica-install, which is why I was thinking >>> that the old RUV's and tombstones were to blame. >> >> It could be. I'm really not sure what the problem is at this point. > > I think we'd need to see ipareplica-install.log to know for sure. It > could be the sort of thing where it fails early but doesn't kill the > install, so the last error is a red herring. > > rob > >> >>> >>> Thanks, >>> John DeSantis >>> >>> >>> 2014-10-22 12:51 GMT-04:00 Rich Megginson : >>>> On 10/22/2014 10:31 AM, John Desantis wrote: >>>>> Richard, >>>>> >>>>> You helped me before in #freeipa, so I appreciate the assistance again. >>>>> >>>>>> What version of 389 are you using? >>>>>> rpm -q 389-ds-base >>>>> 389-ds-base-1.2.11.15-34.el6_5 >>>>> >>>>> Thanks, >>>>> John DeSantis >>>>> >>>>> 2014-10-22 12:09 GMT-04:00 Rich Megginson : >>>>>> On 10/22/2014 09:42 AM, John Desantis wrote: >>>>>>> Hello all, >>>>>>> >>>>>>> First and foremost, a big "thank you!" to the FreeIPA developers >>>>>>> for a >>>>>>> great product! >>>>>>> >>>>>>> Now, to the point! >>>>>>> >>>>>>> We're trying to re-provision a previous replica using the standard >>>>>>> documentation via the Red Hat site: >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Setting_up_IPA_Replicas.html >>>>>>> >>>>>>> >>>>>>> However, we're running into errors during the import process. The >>>>>>> errors are varied and fail at random steps; there was an issue with >>>>>>> NTP or HTTP or LDAP, etc. This did not happen when we promoted a >>>>>>> separate node to become a replica. >>>>>>> >>>>>>> We had previously removed the replica via `ipa-replica-manage del` >>>>>>> and >>>>>>> ensured that no trace of it being a replica existed: removed DNS >>>>>>> records and verified that the host enrollment was not present. I did >>>>>>> not use the "--force" and "--cleanup" options. >>>>>> >>>>>> What version of 389 are you using? >>>>>> rpm -q 389-ds-base >>>> >>>> You should remove the unused ruv elements. I'm not sure why they >>>> were not >>>> cleaned. You may have to use cleanallruv manually. >>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv >>>> >>>> >>>> note - use the cleanallruv procedure, not cleanruv. >>>> >>>>>>> When I check RUV's against the host in question, there are >>>>>>> several. I >>>>>>> also queried the tombstones against the host and found two entries >>>>>>> which have valid hex time stamps; coincidentally, out of the 9 >>>>>>> tombstone entries, 2 have "nsds50ruv" time stamps. I'll paste >>>>>>> sanitized output below: >>>>>>> >>>>>>> # ldapsaerch -x -W -LLL -D "cn=directory manager" -b >>>>>>> "dc=our,dc=personal,dc=domain" '(objectclass=nsTombstone)' >>>>>>> Enter LDAP Password: >>>>>>> dn: >>>>>>> >>>>>>> nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=our,dc=personal,dc=domain >>>>>>> >>>>>>> objectClass: top >>>>>>> objectClass: nsTombstone >>>>>>> objectClass: extensibleobject >>>>>>> nsds50ruv: {replicageneration} 50ef13ae000000040000 >>>>>>> nsds50ruv: {replica 4 ldap://master.our.personal.domain:389} >>>>>>> 5164d147000000040000 5447bda 8000100040000 >>>>>>> nsds50ruv: {replica 22 ldap://separatenode.our.personal.domain:389} >>>>>>> 54107f9f000000160000 54436b 25000000160000 >>>>>>> nsds50ruv: {replica 21 ldap://iparepbackup.our.personal.domain:389} >>>>>>> 51b734de000000150000 51b7 34ef000200150000 >>>>>>> nsds50ruv: {replica 19 >>>>>>> ldap://host-in-question.our.personal.domain:389} 510d56c9000100130000 >>>>>>> 510d82 be000200130000 >>>>>>> nsds50ruv: {replica 18 >>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>> nsds50ruv: {replica 17 >>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>> nsds50ruv: {replica 16 >>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>> nsds50ruv: {replica 15 >>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>> nsds50ruv: {replica 14 >>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>> nsds50ruv: {replica 13 >>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>> nsds50ruv: {replica 12 >>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>> nsds50ruv: {replica 23 >>>>>>> ldap://host-in-question.our.personal.domain:389} 54187702000200170000 >>>>>>> 541878 9a000000170000 >>>>>>> dc: our >>>>>>> nsruvReplicaLastModified: {replica 4 >>>>>>> ldap://master.our.personal.domain:389} 5447bce8 >>>>>>> nsruvReplicaLastModified: {replica 22 >>>>>>> ldap://separatenode.our.personal.domain:389} 54436a5e >>>>>>> nsruvReplicaLastModified: {replica 21 >>>>>>> ldap://iparepbackup.our.personal.domain:389} 00000000 >>>>>>> nsruvReplicaLastModified: {replica 19 >>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>> nsruvReplicaLastModified: {replica 18 >>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>> nsruvReplicaLastModified: {replica 17 >>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>> nsruvReplicaLastModified: {replica 16 >>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>> nsruvReplicaLastModified: {replica 15 >>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>> nsruvReplicaLastModified: {replica 14 >>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>> nsruvReplicaLastModified: {replica 13 >>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>> nsruvReplicaLastModified: {replica 12 >>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>> nsruvReplicaLastModified: {replica 23 >>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>> >>>>>>> dn: >>>>>>> >>>>>>> nsuniqueid=c08a2803-5b5a11e2-a527ce8b-8fa47d35,cn=host-in-question.our.personal.domain,cn=maste >>>>>>> >>>>>>> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >>>>>>> objectClass: top >>>>>>> objectClass: nsContainer >>>>>>> objectClass: nsTombstone >>>>>>> cn: host-in-question.our.personal.domain >>>>>>> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >>>>>>> >>>>>>> dn: >>>>>>> >>>>>>> nsuniqueid=664c4383-6d6311e2-8db6e946-de27dd8d,cn=host-in-question.our.personal.domain,cn=maste >>>>>>> >>>>>>> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >>>>>>> objectClass: top >>>>>>> objectClass: nsContainer >>>>>>> objectClass: nsTombstone >>>>>>> cn: host-in-question.our.personal.domain >>>>>>> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >>>>>>> >>>>>>> As you can see, the "host-in-question" has many RUV's and of which >>>>>>> two >>>>>>> appear to be "active" and two entries which I believe (pardon my >>>>>>> ignorance) possibly correlate with the "active" entries of the >>>>>>> "host-in-question". >>>>>>> >>>>>>> Do these two tombstone entries need to be deleted with ldapdelete >>>>>>> before we can re-provision "host-in-question" and add it back as a >>>>>>> replica? >>>> >>>> No, you cannot delete tombstones manually. They will be cleaned up >>>> at some >>>> point by the dirsrv tombstone reap thread, and they should not be >>>> interfering with anything. >>>> >>>> What is the real problem you have? Did replication stop working? Are >>>> you >>>> getting error messages? >>>> >>>>>>> Thank you, >>>>>>> John DeSantis >>>>>>> >>>>>> -- >>>>>> 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 >> > From wgraboyes at cenic.org Wed Oct 22 20:06:35 2014 From: wgraboyes at cenic.org (William Graboyes) Date: Wed, 22 Oct 2014 13:06:35 -0700 Subject: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1. Message-ID: <54480E4B.2000207@cenic.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello List, So the whole not being able to change the CA easily is becoming a regular point of contention in meetings. If I have read the e-mails on this list correctly this issue is fixed in 4.1. After spending a large amount of time thinking about this, I believe I have come to a solution that will appease management, my coworkers, and myself. Here is what I am thinking of doing. I am thinking I will install FC21 VM with free-IPA (which should be 4.1) then migrating my current install over there, followed by changing the CA to that of my contracted CA and third party issuer. The questions that come to mind are: 1) how does one migrate the information over to a new install, in this case 3.3 to 4.1 on separate servers? 2) is there any documentation on the process of changing the CA in 4.1? 3) am I insane for wanting to introduce FC21 into my environment? 4) has anyone done this, and what was your experience with doing so? Thanks, Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUSA5LAAoJEJFMz73A1+zrVu4P/3rcjvj5Vlcf3M1mAFLIyRWS NMf5Qu+gRK9wR4MQkp3QJ46NC88TwZmwtYy6z31tMqwbRKzLR4/IUOGq89K/mjIl CuzGc5S0dW5ctfJPv+5E+shfytYtHeUsTSmMTFwazEGKq8bMEo0Lr7prZera2t8t NPeYSpECwPMU46g8ufS2oPSOQACmkIhAPfKAr5BATpM1g5JAJJ89oidd9ob7tu7n UKcTjqtEhXxbLVXi0+H65O9sZzgpDTk1Gfl52DOii/XVEgBsL8ybmk5902zAJsOg W2eamMVivFJD8SVas97DvRar0GMRNXilNZS6Q316N9mjOoVJJHONUb/VZ0t10BLc FRbc6hMRQJ3TQCdp37DYcaTblVnRanQJ9HBbih4hcErWG42mWEPzaQJljDO/If5f DfzTGai3Fd+1TIhOsX81XKH/8NCK+qpoaEJlsOJd2iScxv8f9AqMGKv1TAhZiJGY WXXma39WdoLy/p1DMDM6kg+gAnmxBxGU+5RxjXl+HkOkvK8nn3nUJa3GHD3a4Iep L6FLiRjZ8UuJbKsXPPIpKAioil8Lt1JbcFykCKFuEM6wQ5ehpOPRMYeZEqedvXPD Is3yEqtyXX+B/wEcCljL4kD9Wmntfkfh59ondcnlHZTkiQM/Fs6eY0FqEKIvcgj1 jbyjtbGUn5KRsXdGjBde =WagT -----END PGP SIGNATURE----- From ftweedal at redhat.com Thu Oct 23 00:20:40 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 23 Oct 2014 10:20:40 +1000 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141022132355.GA4312@mail.corp.redhat.com> References: <54410195.4020305@mail.ru> <20141018213544.GB26289@mail.corp.redhat.com> <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> <20141020080128.GA14974@mail.corp.redhat.com> <5444DE8A.4000304@mail.ru> <20141021183116.GG31312@mail.corp.redhat.com> <20141022020628.GH5346@dhcp-40-8.bne.redhat.com> <54472ED7.1000800@mail.ru> <20141022071055.GK5346@dhcp-40-8.bne.redhat.com> <20141022132355.GA4312@mail.corp.redhat.com> Message-ID: <20141023002040.GM5346@dhcp-40-8.bne.redhat.com> On Wed, Oct 22, 2014 at 03:23:56PM +0200, Lukas Slebodnik wrote: > On (22/10/14 17:10), Fraser Tweedale wrote: > >Further to my earlier email, I have written a blog post about all > >these matters, with a particular focus on the custom package repo. > > > >I will update it tomorrow with a bit more about the package > >"flavours" topic. For now, all the details for enabling and using > >the custom repo are in the post. Check it out and let me know if > >you spot any issues. > > > > http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/ > > > The disadvantage of this approach is that users need to rely on updating > of non standard repo. https://frase.id.au/pkg/${ABI}_FreeIPA > > In my opinion, it's better to write howto (script) which will configure all > necessary ports/files and portmaster will take care of updating ports. > https://www.freebsd.org/doc/handbook/ports-using.html#portmaster > > LS Each has its advantages and disadvantages; people can choose what works for them. Hopefully - not too far in the future - people won't have to choose, when binary package "flavours" are implemented. When that happens, a small effort will be needed to define the FreeIPA flavour and ensure it gets included in the official package repos. Fraser From outbackdingo at gmail.com Thu Oct 23 00:27:28 2014 From: outbackdingo at gmail.com (Outback Dingo) Date: Thu, 23 Oct 2014 11:27:28 +1100 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141023002040.GM5346@dhcp-40-8.bne.redhat.com> References: <54410195.4020305@mail.ru> <20141018213544.GB26289@mail.corp.redhat.com> <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> <20141020080128.GA14974@mail.corp.redhat.com> <5444DE8A.4000304@mail.ru> <20141021183116.GG31312@mail.corp.redhat.com> <20141022020628.GH5346@dhcp-40-8.bne.redhat.com> <54472ED7.1000800@mail.ru> <20141022071055.GK5346@dhcp-40-8.bne.redhat.com> <20141022132355.GA4312@mail.corp.redhat.com> <20141023002040.GM5346@dhcp-40-8.bne.redhat.com> Message-ID: On Thu, Oct 23, 2014 at 11:20 AM, Fraser Tweedale wrote: > On Wed, Oct 22, 2014 at 03:23:56PM +0200, Lukas Slebodnik wrote: > > On (22/10/14 17:10), Fraser Tweedale wrote: > > >Further to my earlier email, I have written a blog post about all > > >these matters, with a particular focus on the custom package repo. > > > > > >I will update it tomorrow with a bit more about the package > > >"flavours" topic. For now, all the details for enabling and using > > >the custom repo are in the post. Check it out and let me know if > > >you spot any issues. > > > > > > > http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/ > > > > > The disadvantage of this approach is that users need to rely on updating > > of non standard repo. https://frase.id.au/pkg/${ABI}_FreeIPA > > > > In my opinion, it's better to write howto (script) which will configure > all > > necessary ports/files and portmaster will take care of updating ports. > > https://www.freebsd.org/doc/handbook/ports-using.html#portmaster > > > > LS > > Each has its advantages and disadvantages; people can choose what > works for them. Hopefully - not too far in the future - people > won't have to choose, when binary package "flavours" are > implemented. When that happens, a small effort will be needed to > define the FreeIPA flavour and ensure it gets included in the > official package repos. > Actually I would be inclined to assist with a ports build, so it could be done correctly from the ports tree and work towards having it adopted into mainline. > > Fraser > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Thu Oct 23 01:59:32 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 23 Oct 2014 11:59:32 +1000 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <54479472.9040802@redhat.com> References: <54410195.4020305@mail.ru> <20141018213544.GB26289@mail.corp.redhat.com> <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> <20141020080128.GA14974@mail.corp.redhat.com> <5444DE8A.4000304@mail.ru> <20141021183116.GG31312@mail.corp.redhat.com> <20141022020628.GH5346@dhcp-40-8.bne.redhat.com> <54472ED7.1000800@mail.ru> <20141022071055.GK5346@dhcp-40-8.bne.redhat.com> <54479472.9040802@redhat.com> Message-ID: <20141023015932.GA21514@dhcp-40-8.bne.redhat.com> On Wed, Oct 22, 2014 at 01:26:42PM +0200, Petr Spacek wrote: > On 22.10.2014 09:10, Fraser Tweedale wrote: > >Further to my earlier email, I have written a blog post about all > >these matters, with a particular focus on the custom package repo. > > > >I will update it tomorrow with a bit more about the package > >"flavours" topic. For now, all the details for enabling and using > >the custom repo are in the post. Check it out and let me know if > >you spot any issues. > > > > http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/ > > Hello Fraser and others, > > it would be great if you could add links to your FreeIPA-related blog posts > to http://www.freeipa.org/page/HowTos . > I updated the HowTos page. Cheers, Fraser. > We are trying to build kind of 'documentation hub' with links to relevant > posts stored elsewhere. > > It is even fine to add links to mailing list archives if the particular post > is useful to broad audience. > > Have a nice day! > > Petr^2 Spacek > > > > >Cheers, > > > >Fraser > > > >On Wed, Oct 22, 2014 at 09:13:11AM +0500, Orkhan Gasimov wrote: > >>Great news! > >>If I understand correctly, a package can be equivalent to several ports? > >>If this is correct, then could a "composite" package be built to include all > >>necessary ports? > >> > >> * _security/sssd_ > >> * _security/sudo_ (with SSSD > >> backend) > >> * _net/openldap24-client-sasl_ > >> > >> * security/cyrus-sasl2 > >> * security/cyrus-sasl2-gssapi > >> > >>That package could be called something like "ipa-client", and make FreeBSD - > >>FreeIPA integration one step closer. > >>If not possible, even a pkg equivalent to "/security/sssd" would eliminate > >>existing possibilities for misconfiguration. > >> > >>22-Oct-14 07:06, Fraser Tweedale ?????: > >>>I have prepared a custom pkg(8) repo with the packages built with > >>>the required options/make.conf variables. Hang tight, I'll send all > >>>the info soon. > > -- > 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 From pspacek at redhat.com Thu Oct 23 06:47:43 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 23 Oct 2014 08:47:43 +0200 Subject: [Freeipa-users] migration 3.3->4.1 & CA change In-Reply-To: <54480E4B.2000207@cenic.org> References: <54480E4B.2000207@cenic.org> Message-ID: <5448A48F.8070200@redhat.com> On 22.10.2014 22:06, William Graboyes wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello List, > > So the whole not being able to change the CA easily is becoming a > regular point of contention in meetings. If I have read the e-mails > on this list correctly this issue is fixed in 4.1. After spending a > large amount of time thinking about this, I believe I have come to a > solution that will appease management, my coworkers, and myself. > > Here is what I am thinking of doing. I am thinking I will install > FC21 VM with free-IPA (which should be 4.1) then migrating my current > install over there, followed by changing the CA to that of my > contracted CA and third party issuer. > > The questions that come to mind are: > > 1) how does one migrate the information over to a new install, in this > case 3.3 to 4.1 on separate servers? You should be able to simply add FreeIPA 4.1 replica to existing 3.3 deployment. Please make sure that your 3.3 it updated with latest packages, older versions of DS had some problems with replication to newest version AFAIK. > 2) is there any documentation on the process of changing the CA in 4.1? Honza, can you add some details? > 3) am I insane for wanting to introduce FC21 into my environment? > 4) has anyone done this, and what was your experience with doing so? -- Petr^2 Spacek From jcholast at redhat.com Thu Oct 23 07:00:22 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 23 Oct 2014 09:00:22 +0200 Subject: [Freeipa-users] migration 3.3->4.1 & CA change In-Reply-To: <5448A48F.8070200@redhat.com> References: <54480E4B.2000207@cenic.org> <5448A48F.8070200@redhat.com> Message-ID: <5448A786.3050200@redhat.com> Hi, Dne 23.10.2014 v 08:47 Petr Spacek napsal(a): > On 22.10.2014 22:06, William Graboyes wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Hello List, >> >> So the whole not being able to change the CA easily is becoming a >> regular point of contention in meetings. If I have read the e-mails >> on this list correctly this issue is fixed in 4.1. After spending a >> large amount of time thinking about this, I believe I have come to a >> solution that will appease management, my coworkers, and myself. >> >> Here is what I am thinking of doing. I am thinking I will install >> FC21 VM with free-IPA (which should be 4.1) then migrating my current >> install over there, followed by changing the CA to that of my >> contracted CA and third party issuer. >> >> The questions that come to mind are: >> >> 1) how does one migrate the information over to a new install, in this >> case 3.3 to 4.1 on separate servers? > You should be able to simply add FreeIPA 4.1 replica to existing 3.3 > deployment. Please make sure that your 3.3 it updated with latest > packages, older versions of DS had some problems with replication to > newest version AFAIK. > >> 2) is there any documentation on the process of changing the CA in 4.1? > Honza, can you add some details? You can fid more info at > >> 3) am I insane for wanting to introduce FC21 into my environment? >> 4) has anyone done this, and what was your experience with doing so? > Honza -- Jan Cholasta From orkhan-azeri at mail.ru Thu Oct 23 07:09:59 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Thu, 23 Oct 2014 12:09:59 +0500 Subject: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1. In-Reply-To: <54480E4B.2000207@cenic.org> References: <54480E4B.2000207@cenic.org> Message-ID: <5448A9C7.9020506@mail.ru> I already deployed FreeIPA 4.1 on Fedora 21 server alpha-release. Everything is good as far as FreeIPA server operation is concerned. 23-Oct-14 01:06, William Graboyes ?????: > 3) am I insane for wanting to introduce FC21 into my environment? From lslebodn at redhat.com Thu Oct 23 07:58:33 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 23 Oct 2014 09:58:33 +0200 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: References: <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> <20141020080128.GA14974@mail.corp.redhat.com> <5444DE8A.4000304@mail.ru> <20141021183116.GG31312@mail.corp.redhat.com> <20141022020628.GH5346@dhcp-40-8.bne.redhat.com> <54472ED7.1000800@mail.ru> <20141022071055.GK5346@dhcp-40-8.bne.redhat.com> <20141022132355.GA4312@mail.corp.redhat.com> <20141023002040.GM5346@dhcp-40-8.bne.redhat.com> Message-ID: <20141023075832.GA28314@mail.corp.redhat.com> On (23/10/14 11:27), Outback Dingo wrote: >On Thu, Oct 23, 2014 at 11:20 AM, Fraser Tweedale >wrote: > >> On Wed, Oct 22, 2014 at 03:23:56PM +0200, Lukas Slebodnik wrote: >> > On (22/10/14 17:10), Fraser Tweedale wrote: >> > >Further to my earlier email, I have written a blog post about all >> > >these matters, with a particular focus on the custom package repo. >> > > >> > >I will update it tomorrow with a bit more about the package >> > >"flavours" topic. For now, all the details for enabling and using >> > >the custom repo are in the post. Check it out and let me know if >> > >you spot any issues. >> > > >> > > >> http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/ >> > > >> > The disadvantage of this approach is that users need to rely on updating >> > of non standard repo. https://frase.id.au/pkg/${ABI}_FreeIPA >> > >> > In my opinion, it's better to write howto (script) which will configure >> all >> > necessary ports/files and portmaster will take care of updating ports. >> > https://www.freebsd.org/doc/handbook/ports-using.html#portmaster >> > >> > LS >> >> Each has its advantages and disadvantages; people can choose what >> works for them. Hopefully - not too far in the future - people >> won't have to choose, when binary package "flavours" are >> implemented. When that happens, a small effort will be needed to >> define the FreeIPA flavour and ensure it gets included in the >> official package repos. >> Fraser you missed one main point of this thread. The most problematic was to *configure* all files and not install sssd. I don't want to say that installing is super easy, but configuration is much more complicated. > >Actually I would be inclined to assist with a ports build, so it could be >done correctly from the ports tree >and work towards having it adopted into mainline. > +1 LS From orkhan-azeri at mail.ru Thu Oct 23 10:12:47 2014 From: orkhan-azeri at mail.ru (=?UTF-8?B?0J7RgNGF0LDQvSDQmtCw0YHRg9C80L7Qsg==?=) Date: Thu, 23 Oct 2014 14:12:47 +0400 Subject: [Freeipa-users] =?utf-8?q?No_result_when_trying_to_integrate_a_Fr?= =?utf-8?q?eeBSD_client_with_the_FreeIPA_server?= In-Reply-To: <20141023075832.GA28314@mail.corp.redhat.com> References: <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> <20141023075832.GA28314@mail.corp.redhat.com> Message-ID: <1414059167.879585640@f414.i.mail.ru> +1. And even if talking about installation of the necessary software and not about the configuration, then why this? " The commands to enable the custom repository and install the required packages on a FreeBSD host appear below. Note that these are? Bourne ?shell commands; this script will not work in the FreeBSD default shell? csh . " After having baked ONE SET OF DEFAULTS into a custom package (to make our lives easier), you leave readers to mess with ANOTHER SET OF DEFAULTS, i.e. to change?FreeBSD's shells? Aren't there some discrepancies??It may be simple / useful / interesting to change shells, but why not make a self-sufficient article? Please update your article to provide a full picture of what a user should do to install all necessary software, and also which parts should be installed from your repo, and which parts should be installed from ports (+ the correct order). You've already done a lot of work, but with this refinement your help will be even more valuable. I'm not asking for myself personally (I've already accomplished all necessary tasks) - just IMHO everyone writing?instructions, tutorials and HowTos for the *nix world should stick to the rule: articles should be self-sufficient. I.e. if they rely on techniques not detailed in them,?they should at least include links to other WORKING articles to ensure that a reader will be able to COMPLETE a task. Thanks for your contribution, Fraser. Thu, 23 Oct 2014 09:58:33 +0200 ?? Lukas Slebodnik : >On (23/10/14 11:27), Outback Dingo wrote: >>On Thu, Oct 23, 2014 at 11:20 AM, Fraser Tweedale < ftweedal at redhat.com > >>wrote: >> >>> On Wed, Oct 22, 2014 at 03:23:56PM +0200, Lukas Slebodnik wrote: >>> > On (22/10/14 17:10), Fraser Tweedale wrote: >>> > >Further to my earlier email, I have written a blog post about all >>> > >these matters, with a particular focus on the custom package repo. >>> > > >>> > >I will update it tomorrow with a bit more about the package >>> > >"flavours" topic. For now, all the details for enabling and using >>> > >the custom repo are in the post. Check it out and let me know if >>> > >you spot any issues. >>> > > >>> > > >>> http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/ >>> > > >>> > The disadvantage of this approach is that users need to rely on updating >>> > of non standard repo. https://frase.id.au/pkg/${ABI}_FreeIPA >>> > >>> > In my opinion, it's better to write howto (script) which will configure >>> all >>> > necessary ports/files and portmaster will take care of updating ports. >>> > https://www.freebsd.org/doc/handbook/ports-using.html#portmaster >>> > >>> > LS >>> >>> Each has its advantages and disadvantages; people can choose what >>> works for them. Hopefully - not too far in the future - people >>> won't have to choose, when binary package "flavours" are >>> implemented. When that happens, a small effort will be needed to >>> define the FreeIPA flavour and ensure it gets included in the >>> official package repos. >>> >Fraser you missed one main point of this thread. The most problematic was >to *configure* all files and not install sssd. I don't want to say that >installing is super easy, but configuration is much more complicated. > >> >>Actually I would be inclined to assist with a ports build, so it could be >>done correctly from the ports tree >>and work towards having it adopted into mainline. >> >+1 > >LS > >-- >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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Thu Oct 23 10:19:18 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 23 Oct 2014 12:19:18 +0200 Subject: [Freeipa-users] Announcing FreeIPA 4.1.0 Message-ID: <5448D626.4080405@redhat.com> The FreeIPA team is proud to announce FreeIPA v4.1.0! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds will be available for Fedora 21. Builds for Fedora 20 are available in the official COPR repository [https://copr.fedoraproject.org/coprs/mkosek/freeipa/]. == Highlights in 4.1 == === Enhancements === * New concept of 'ID Views' allowing FreeIPA administrator to define or override POSIX attributes for users/groups coming from trusted domains. Such users then do not need to have POSIX attributes defined in the Active Directory to authenticate to FreeIPA clients. It also allows to assign particular view to selected hosts or hostgroups, thus allowing having a user / group with different POSIX attributes on different hosts. Per-host overrides should be used with extreme care! [http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust] * New tool ipa-cacert-manage to manually renew or change FreeIPA PKI CA certificate [http://www.freeipa.org/page/V4/CA_certificate_renewal] * DNSSEC Support * OTP authentication plugin now prevents multiple usage of token codes on a single FreeIPA server * DNS interface now supports adding DNS root zone (".") allowing admin to for example centrally override DNS root hints. * DNS zone adding interface was simplified - name server and it's IP address is no longer required. The list of authoritative name servers are read from LDAP * Seamless signing of FreeIPA CA us a subCA in Windows Certificate Services [https://fedorahosted.org/freeipa/ticket/4496] * New option --request-cert to optionally request host certificates on FreeIPA clients (to /etc/ipa/nssdb/) * CLI and Web UI for 'retrive keytab' and 'create keytab' authorization [http://www.freeipa.org/page/V4/Keytab_Retrieval_Management] * Services can now be assigned as members of RBAC roles * `ipa` command run with `-vv` option now prints JSON request and reply exchanged with the FreeIPA server. `-vvv` also prints HTTP communication. * Description attribute is no longer required (e.g. in groups, sudo command groups or others) given that it is also not required in schema. * Packages can be now built and installed on RHEL/CentOS 7.0 * ipa-replica-prepare now waits for the replica DNS record to be available to fix race conditions in automated test environments * Port 8443 is now checked before server installation to prevent failures in configuring PKI which uses the port === Bug fixes === * Server installers can now handle hosts with multiple IPv4 or IPv6 addresses * DNS zone interface no longer accepts `--class` option as it had no effect as FreeIPA DNS only supports 'IN' class. * ipa-ldap-upgrade restores Directory Server settings when upgrade fails * SSLv3.0 (CVE-2014-3566) ciphers are now disabled on new installations === DNSSEC Support === FreeIPA now automates basic key management for Domain Name System Security Extensions (DNSSEC) [http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Overview]. Before you start signing you DNS zones you have to install DNSSEC key master role to an existing FreeIPA DNS server using command: ipa-dns-install --dnssec-master It allows you to enable DNSSEC for particular DNS zone using command: ipa dnszone-mod zone.name.example. --dnssec=true This command will generate new zone keys, distribute keys to all FreeIPA DNS servers and configure all servers to independently sign the zone. Please keep in mind that it can take few minutes before all servers sign the zone. ==== Known Limitations ==== * User has to manually upload Delegation Signer (DS) record [http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Records] to parent DNS zone to establish chain of trust. * User has to manually confirm that DS record in parent zone was published otherwise Key Signing Key (KSK) [http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Key_management] will not be rotated. This confirmation has to be done on FreeIPA server with key master role using following command: sudo -u ods ods-ksmutil key ds-seen --zone zone.name.example. --keytag 12345 * Keytag can be obtained from dig output: dig +dnssec zone.name.example. DS * User is not notified about automated key rotation. This does not lower stability of the system because of `ds-seen` logic mentioned above. * Key and signing policy cannot be changed using FreeIPA tools. Currently it is stored in `/etc/opendnssec/kasp.xml` file on DNSSEC key master server. Manual changes to `kasp.xml` will be lost during next FreeIPA upgrade. * Only one FreeIPA server can have DNSSEC key master role: ** *Please plan carefully, current version does not allow you to easily move DNSSEC master role to a different server.* ** DNSSEC key management will not work when the key master is not running, i.e. DNSSEC keys will not be rotated according to the policy and keys for new zones will not be generated. == Known Issues == * Directory Server may deadlock in some situations (tracked in upstream ticket [https://fedorahosted.org/freeipa/ticket/4635]). * SSLv3.0 (CVE-2014-3566) ciphers are not disabled on upgrades. See CVE-2014-3566 and referred external articles on advise how to deal with this vulnerability. == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-ldap-updater --upgrade # ipa-upgradeconfig Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks, not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 3.3.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.0.0 == Alexander Bokovoy (15): ipaserver/dcerpc.py: if search of a closest GC failed, try to find any GC ipaserver/dcerpc.py: make PDC discovery more robust ipaserver/dcerpc.py: Avoid hitting issue with transitive trusts on Windows Server prior to 2012 ipaserver/dcerpc.py: be more open to what domains can be seen through the forest trust ipaserver/dcerpc.py: Make sure trust is established only to forest root domain Support overridding user shell in ID views Allow user overrides to specify SSH public keys Allow user overrides to specify GID of the user Allow override of gecos field in ID views Update API version for ID views support Require slapi-nis 0.54 or later for ID views support Support idviews in compat tree Change ipaOverrideTarget OID to avoid conflict with DNSSEC feature updater: enable uid uniqueness plugin for posixAccounts Default to use TLSv1.0 and TLSv1.1 on the IPA server side Ana Krivokapi? (1): Remove internaldb password from password.conf David Kupka (20): Fix ipa-client-install --uninstall crash Always record that pkicreate has been executed. Improve password validity check. Fix group-remove-member crash when group is removed from a protected group test group: remove group from protected group. Verify otptoken timespan is valid Add record(s) to /etc/host when IPA is configured as DNS server. Use certmonger D-Bus API instead of messing with its files. Do not restart apache server when not necessary. Allow user to force Kerberos realm during installation. Fix typo causing ipa-upgradeconfig to fail. Add 'host' setting into default.conf configuration file on client. Fix description in man page. Detect and configure all usable IP addresses. Do not require description in UI. Fix example usage in ipa man page. Check that port 8443 is available when installing PKI. Set IPA CA for freeipa certificates. Stop dogtag when updating its configuration in ipa-upgradeconfig. Fix printing of reverse zones in ipa-dns-install. Fix typo causing certmonger is provided with wrong path to ipa-submit. Gabe Alford (5): Fix typos in dns.py Enable debug pid in smb.conf ipa trust-add command should be interactive Fix hardcoded lib dir in freeipa.spec Missing requires on python-dns in spec file Jakub Hrozek (1): CLIENT: Explicitly require python-backports-ssl_match_hostname Jan Cholasta (100): Check if /root/ipa.csr exists when installing server with external CA. Exclude attributelevelrights from --raw result processing in baseldap. Add function for checking if certificate is self-signed to ipalib.x509. Support CA certificate renewal in dogtag-ipa-ca-renew-agent. Allow IPA master hosts to update CA certificate in LDAP. Automatically update CA certificate in LDAP on renewal. Track CA certificate using dogtag-ipa-ca-renew-agent. Add method for setting CA renewal master in LDAP to CAInstance. Provide additional functions to ipapython.certmonger. Move external cert validation from ipa-server-install to installutils. Add method for verifying CA certificates to NSSDatabase. Add permissions for CA certificate renewal. Add CA certificate management tool ipa-cacert-manage. Alert user when externally signed CA is about to expire. Load sysupgrade.state on demand. Pick new CA renewal master when deleting a replica. Remove master ACIs when deleting a replica. Do not use ldapi in certificate renewal scripts. Check that renewed certificates coming from LDAP are actually renewed. Allow IPA master hosts to read and update IPA master information. Do not treat the IPA RA cert as CA cert in DS NSS database. Remove certificate "External CA cert" from /etc/pki/nssdb on client uninstall. Allow specifying trust flags in NSSDatabase and CertDB method trust_root_cert. Fix trust flags in HTTP and DS NSS databases. Add LDAP schema for wrapped cryptographic keys. Add LDAP schema for certificate store. Add container for certificate store. Configure attribute uniqueness for certificate store. Add permissions for certificate store. Add functions for extracting certificates fields in DER to ipalib.x509. Add function for extracting extended key usage from certs to ipalib.x509. Add certificate store module ipalib.certstore. Upload CA chain from DS NSS database to certificate store on server install. Upload CA chain from DS NSS database to certificate store on server update. Rename CertDB method add_cert to import_cert. Add new add_cert method for adding certificates to NSSDatabase and CertDB. Import CA certs from certificate store to DS NSS database on replica install. Import CA certs from certificate store to HTTP NSS database on server install. Upload renewed CA cert to certificate store on renewal. Refactor CA certificate fetching code in ipa-client-install. Support multiple CA certificates in /etc/ipa/ca.crt in ipa-client-install. Add function for writing list of certificates to a PEM file to ipalib.x509. Get CA certs for /etc/ipa/ca.crt from certificate store in ipa-client-install. Allow overriding NSS database path in RPCClient. Get CA certs for /etc/pki/nssdb from certificate store in ipa-client-install. Add functions for DER encoding certificate extensions to ipalib.x509. Get CA certs for system-wide store from cert store in ipa-client-install. Get up-to-date CA certificates from certificate store in ipa-replica-install. Add client certificate update tool ipa-certupdate. Export full CA chain to /etc/ipa/ca.crt in ipa-server-install. Allow multiple CA certificates in replica info files. Add new NSSDatabase method get_cert for getting certs from NSS databases. Allow changing chaining of the IPA CA certificate in ipa-cacert-manage. Update CS.cfg on IPA CA certificate chaining change in renew_ca_cert. Allow adding CA certificates to certificate store in ipa-cacert-manage. Allow upgrading CA-less to CA-full using ipa-ca-install. Update external CA cert in Dogtag NSS DB on IPA CA cert renewal. Enable NSS PKIX certificate path discovery and validation for Dogtag. Add test for baseldap.entry_to_dict. Fix parsing of long nicknames in certutil -L output. Convert external CA chain to PKCS#7 before passing it to pkispawn. Allow changing CA renewal master in ipa-csreplica-manage. Normalize external CA cert before passing it to pkispawn Make CA-less ipa-server-install option --root-ca-file optional. Backup CS.cfg before modifying it Use autobind when updating CA people entries during certificate renewal Fix certmonger code causing the ca_renewal_master update plugin to fail Allow RPM upgrade from ipa-* packages Include ipaplatform in client-only build Include the ipa command in client-only build Allow specifying signing algorithm of the IPA CA cert in ipa-server-install. Add NSSDatabase.import_files method for importing files in various formats External CA installer options usability fixes CA-less installer options usability fixes Allow choosing CA-less server certificates by name Do stricter validation of CA certificates Introduce NSS database /etc/ipa/nssdb Move NSSDatabase from ipaserver.certs to ipapython.certdb Add NSSDatabase.has_nickname for checking nickname presence in a NSS DB Use NSSDatabase instead of direct certutil calls in client code Use /etc/ipa/nssdb to get nicknames of IPA certs installed in /etc/pki/nssdb Check if IPA client is configured in ipa-certupdate Get server hostname from jsonrpc_uri in ipa-certupdate Remove ipa-ca.crt from systemwide CA store on client uninstall and cert update Fix certmonger.wait_for_request Fix certmonger search for the CA cert in ipa-certupdate and ipa-cacert-manage Add missing imports to ipapython.certdb Remove misleading authorization error message in cert-request with --add Split off generic Red Hat-like platform code from Fedora platform code Add RHEL platform module Support building RPMs for RHEL/CentOS 7.0 Support MS CS as the external CA in ipa-server-install and ipa-ca-install Allow specifying signing algorithm of the IPA CA cert in ipa-ca-install Fix CA cert validity check for CA-less and external CA installer options Fix certmonger.request_cert Add ipa-client-install switch --request-cert to request cert for the host Do not create ipa-pki-proxy.conf if CA is not configured in ipa-upgradeconfig Do not fix trust flags in the DS NSS DB in ipa-upgradeconfig Check LDAP instead of local configuration to see if IPA CA is enabled DNSSEC: remove container_dnssec_keys Ludwig Krispenz (2): Update SSL ciphers configured in 389-ds-base Ignore irrelevant subtrees in schema compat plugin Luk?? Slebodn?k (2): Fix warning: Using uninitialized value ld. Add missing break Martin Ba?ti (48): Fix DNS upgrade plugin should check if DNS container exists FIX: named_enable_dnssec should verify if DNS is installed Allow to add host if AAAA record exists Tests: host tests with dns Fix dnsrecord-mod raise error if last record attr is removed DNSSEC: fix DS record validation Tests: DNS dsrecord validation DNS fix NS record coexistence validator Test: DNS NS validation Fix DNS record rename test FIX DNS wildcard records (RFC4592) Tests: DNS wildcard records dnszone-remove-permission should raise error DNS: remove --class option WebUI: DNS: remove --class option FIX: ldap schmema updater needs correct ordering of the updates Fix DNS plugin to allow to add root zone DNS test: allow '.' as zone name Deprecation of --name-server and --ip-address option in DNS Add correct NS records during installation DNS: autofill admin email WebUI: DNS: Remove ip-address, admin-email options DNS tests: tests update to due to change in options Remove --ip-address, --name-server otpions from DNS help Refactoring of autobind, object_exists LDAP disable service DNS missing tests Fix ipactl service ordering Add missing attributes to named.conf Make named.conf template platform independent Remove ipaContainer, ipaOrderedContainer objectclass Add mask, unmask methods for service DNSSEC: dependencies DNSSEC: schema DNSSEC: add ipapk11helper module DNSSEC: DNS key synchronization daemon DNSSEC: opendnssec services DNSSEC: platform paths and services DNSSEC: validate forwarders DNSSEC: modify named service to support dnssec DNSSEC: installation DNSSEC: uninstallation DNSSEC: upgrading DNSSEC: ACI DNSSEC: add files to backup DNSSEC: change link to ipa page fix DNSSEC restore named state fix forwarder validation errors Martin Ko?ek (8): Do not require dogtag-pki-server-theme Allow hashed passwords in DS Do not crash client basedn discovery when SSF not met ipa-adtrust-install does not re-add member in adtrust agents group Sudorule RunAsUser should work with external groups Raise better error message for permission added to generated tree Remove changetype attribute from update plugin Update contributors Nathaniel McCallum (13): Fix login password expiration detection with OTP Update freeipa-server krb5-server dependency to 1.11.5-5 Fix ipa-getkeytab for pre-4.0 servers Add TOTP watermark support Ensure ipaUserAuthTypeClass when needed on user creation Update qrcode support for newer python-qrcode Use stack allocation when writing values during otp auth Move OTP synchronization step to after counter writeback Remove token ID from self-service UI Remove token vendor, model and serial defaults Display token type when viewing token Create ipa-otp-counter 389DS plugin Configure IPA OTP Last Token plugin on upgrade Petr Viktorin (34): baseldap: Return empty string when no effective rights are found ldap2 indirect membership processing: Use global limits if greater than per-query ones test_xmlrpc: Update tests Update API.txt test_ipagetkeytab: Fix assertion in negative test Support delegating RBAC roles to service principals service: Normalize service principal in get_dn freeipa.spec.in: Add python-backports-ssl_match_hostname to BuildRequires permission plugin: Make --target available in the CLI permission plugin: Improve description of the target option Add managed read permissions for compat tree Fix: Add managed read permissions for compat tree and operational attrs Update referential integrity config for DS 1.3.3 permission plugin: Auto-add operational atttributes to read permissions Allow deleting obsolete permissions; remove operational attribute permissions ipaserver.install: Consolidate system user creation ipa_restore: Split the services list backup,restore: Don't overwrite /etc/{passwd,group} ipa_backup: Log where the backup is be stored Add basic test for backup & restore Add test for backup/delete system users/restore JSON client: Log pretty-printed request and response with -vv or above test_permission_plugin: Check legacy permissions upgradeinstance: Restore listeners on failure ipa-replica-prepare: Wait for the DNS entry to be resolvable Move setting SELinux booleans to platform code ipa-restore: Set SELinux booleans when restoring ipaserver.install.service: Don't show error message on SystemExit(0) VERSION,Makefile: Rename "pre" to "alpha" Become IPA 4.1.0 Alpha 1 test_service_plugin: Do not lowercase memberof_role test_forced_client_reenrollment: Don't check for host certificates backup/restore: Add files from /etc/ipa/nssdb sudo integration test: Remove the local user test Petr Voborn?k (81): webui: capitalize labels of undo and undo all buttons webui: improve usability of attributes widget webui: add filter to attributes widget webui: optimize (re)creation of option widget webui: custom attr in attributes widget webui: attr widget: get list of possible attrs from ipapermdefaultattr webui: option_widget_base: sort options webui: reflect readonly state webui: fix add of input group class webui: show managed fields as readonly and not disabled webui: fix selection of empty value in a select widget webui: disable ipapermbindruletype if permission in a privilege webui: fix disabled state of service's PAC type baseldap: return 'none' attr level right as unicode string webui: support wildcard attribute level rights webui: fix nested items creation in dropdown list webui: internet explorer fixes webui: detach facet nodes webui: replace action_buttons with action_widget webui: remove remaining action-button-disabled occurrences webui: add bounce url to reset_password.html webui-ci: fix reset password check webui: better error reporting webui-ci: fix table widget add webui: display expired session notification in a more visible area webui: improved info msgs on login/token sync/reset pwd pages webui: login screen - improved button switching webui: rename tooltip to title webui: tooltip support webui: better authentication types description webui: convert widget.less indentation to spaces webui: improve rule table css webui: sshkey widget - usability fixes webui: disable batch action buttons by default webui: fix group type padding webui: extract complex pkey on Add and Edit webui: adjust behavior of bounce url webui: do not show login error when switching back from otp sync screen webui: switch associators if default doesn't work webui: notify psw change success only once webui: append network.negotiate-auth.trusted-uris install: create ff krb extension on every install, replica install and upgrade webui: add measurement unit to otp token time fields webui: better otp token type label webui: add token from user page webui: add i18n for the rest of QR code strings webui: display fields based on otp token type webui: better value-change reporting webui: widget initialization webui: hide empty fields and sections webui: hide non-readable fields webui: hide otp fields based on token type webui: fix regression in association facet preop webui-ci: case-insensitive record check webui: do not offer ipa-ad-winsync and ipa-ipa-trust range types webui: improve breadcrumb navigation webui: treat value as pkey in link widget webui: do not show internal facet name to user webui: allow to skip link widget link validation webui: add simple link column support webui: new ID views section webui: facet group labels for idview's facets webui: list only not-applied hosts in "apply to host" dialog webui: add link from host to idview webui-ci: adjust dnszone-add test to recent DNS changes dns: fix privileges' memberof during dns install keytab manipulation permission management tests: management of keytab permissions idviews: error out if appling Default Trust View on hosts webui: add link to OTP token app webui: add new iduseroverride fields webui: management of keytab permissions webui: allow --force in dnszone-mod and dnsrecord-add webui: make Evented a part of base IPA.object webui: change order of idview's facet groups webui: hide applied to hosts tab for Default Trust View webui: hide (un)apply buttons for Default Trust View webui: do not offer ipa users to Default Trust View webui: do not show closed dialog webui: update combobox input on list click Become IPA 4.1.0 Petr ?pa?ek (1): DNSSEC: add ipa dnssec daemons Rob Crittenden (1): No longer generate a machine certificate on client installs Stephen Gallagher (1): Change BuildRequires for Java Sumit Bose (4): ipa-kdb: fix unit tests extdom: add support for new version extdom: add support for sss_nss_getorigbyname() extdom: remove unused dependency to libsss_idmap Tom?? Babej (44): trusts: Validate missing trust secret properly ipatests: tasks: Fix dns configuration for trusts trusts: Make cn=adtrust agents sysaccount nestedgroup baseldap: Remove redundant search from LDAPAddReverseMember and LDAPRemoveReverseMember ipalib: idrange: Make non-implemented range types fail the validation ipatests: test_trust: Add test to cover lookup of trusdomains ipa-client-install: Do not add already configured sources to nsswitch.conf entries ipalib: host_del: Extend LDAPDelete's takes_options instead of overriding Set the default attributes for RootDSE baseldap: Properly handle the case of renaming object to the same name idviews: Add necessary schema for the ID views idviews: Create container for ID views under cn=accounts idviews: Add ipaAssignedIDVIew reference to the host object ipalib: Remove redundant and star imports from host plugin ipalib: PEP8 fixes for host plugin idviews: Create basic idview plugin structure idvies: Add managed permissions for idview and idoverride objects hostgroup: Add helper that returns all members of a hostgroup hostgroup: Remove redundant and star imports hostgroup: Selected PEP8 fixes for the hostgroup plugin idviews: Add ipa idview-apply and idview-unapply commands idviews: Extend idview-show command to display assigned idoverrides and hosts trusts: Add conversion from SID to object name idviews: Support specifying object names instead of raw anchors only idviews: Split the idoverride object into iduseroverride and idgroupoverride idviews: Split the idoverride commands into iduseroverride and idgroupoverride idviews: Alter idoverride methods to work with splitted objects idviews: Change format of IPA anchor to include domain idviews: Raise NotFound errors if object to override could not be found idviews: Resolve anchors to object names in idview-show ipatests: Add xmlrpc tests for idviews plugin idviews: Add ipaOriginalUid idviews: Update the referential plugin config to watch for ipaAssignedIDView idviews: Fix casing of ID Views to be consistent idviews: Make description optional for the ID View object idviews: Add Default Trust View as part of adtrustinstall idviews: Handle Default Trust View properly in the framework idviews: Make sure the dict.get method is not abused for MUST attributes idviews: Catch errors on unsuccessful AD object lookup when resolving object name to anchor idviews: Display the list of hosts when using --all idviews: Make sure only regular IPA objects are allowed to be overriden idviews: Create Default Trust View for upgraded servers idviews: Fix typo in upgrade handling of the Default Trust View spec: Bump SSSD requires to 1.12.2 -- Petr Vobornik From orkhan-azeri at mail.ru Thu Oct 23 10:21:09 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Thu, 23 Oct 2014 15:21:09 +0500 Subject: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1. In-Reply-To: <5448A9C7.9020506@mail.ru> References: <54480E4B.2000207@cenic.org> <5448A9C7.9020506@mail.ru> Message-ID: <5448D695.9020405@mail.ru> Yet with FreeIPA v4 we've got another thing to keep in mind regarding FreeBSD - FreeIPA integration: the cron script proposed at FreeBSD forums won't work. Here's what was said in the post: "The tricky part was gettingsudoto work with host groups. FreeIPA keeps host groups in netgroups, and FreeBSD's support for netgroups is limited. One solution would have been to enable NIS services on the FreeIPA server so that we could use proper netgroups on FreeBSD clients. We didn't like that solution, so instead we wrote a script that pulls all netgroup data from FreeIPA and stores it in/etc/netgroup. We run the script every hour viacron." The script looks for host groups in 'cn=hostgroups,cn=accounts,dc=', and that works with FreeIPA 3.3. But in FreeIPA v4 host groups get in 'cn=ng,cn=compat,dc='. So the script needs modification. 23-Oct-14 12:09, Orkhan Gasimov ?????: > I already deployed FreeIPA 4.1 on Fedora 21 server alpha-release. > Everything is good as far as FreeIPA server operation is concerned. > > > 23-Oct-14 01:06, William Graboyes ?????: >> 3) am I insane for wanting to introduce FC21 into my environment? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leszek.mis at gmail.com Thu Oct 23 10:23:49 2014 From: leszek.mis at gmail.com (crony) Date: Thu, 23 Oct 2014 12:23:49 +0200 Subject: [Freeipa-users] FreeIPA 3.3.3 and sssd segfault Message-ID: Hi, I have a FreeIPA 3.3.3 in transitive trust with AD2008. Today I saw a lot of sssd segfaults on the server side: [ 420.412011] sssd_be[734]: segfault at 8 ip 00007fa54fa73334 sp 00007fff62b2ec40 error 4 in libldb.so.1.1.16[7fa54fa66000+2c000] [ 421.763035] sssd_be[2666]: segfault at 8 ip 00007f9c5b7ff334 sp 00007fff2efadb00 error 4 in libldb.so.1.1.16[7f9c5b7f2000+2c000] [ 494.926197] sssd_be[2668]: segfault at 8 ip 00007f0e26194334 sp 00007fffd5906140 error 4 in libldb.so.1.1.16[7f0e26187000+2c000] [ 496.247496] sssd_be[2702]: segfault at 8 ip 00007feeb5b91334 sp 00007fff16a94720 error 4 in libldb.so.1.1.16[7feeb5b84000+2c000] [ 552.856890] sssd_be[2704]: segfault at 8 ip 00007f411fafe334 sp 00007fff4d551360 error 4 in libldb.so.1.1.16[7f411faf1000+2c000] [ 554.191542] sssd_be[2712]: segfault at 8 ip 00007ff55bde7334 sp 00007fffffb0d590 error 4 in libldb.so.1.1.16[7ff55bdda000+2c000] [ 558.502357] sssd_be[2714]: segfault at 8 ip 00007f811e75d334 sp 00007fff5b624090 error 4 in libldb.so.1.1.16[7f811e750000+2c000] [ 572.932207] sssd_be[2717]: segfault at 8 ip 00007ff89398e334 sp 00007fffa43f6d90 error 4 in libldb.so.1.1.16[7ff893981000+2c000] [ 2148.965812] sssd_be[2797]: segfault at 8 ip 00007fc06f51e334 sp 00007fff14f8c8a0 error 4 in libldb.so.1.1.16[7fc06f511000+2c000] [ 2150.310849] sssd_be[2907]: segfault at 8 ip 00007f9fafdef334 sp 00007fff29862f10 error 4 in libldb.so.1.1.16[7f9fafde2000+2c000] [ 2323.836156] sssd_be[2909]: segfault at 8 ip 00007f8d6648e334 sp 00007ffff1249fa0 error 4 in libldb.so.1.1.16[7f8d66481000+2c000] [ 2325.158687] sssd_be[2917]: segfault at 8 ip 00007fb8554ff334 sp 00007fffb5f073a0 error 4 in libldb.so.1.1.16[7fb8554f2000+2c000] [ 2329.361081] sssd_be[2920]: segfault at 8 ip 00007fe333e40334 sp 00007fffab520290 error 4 in libldb.so.1.1.16[7fe333e33000+2c000] [ 2343.681005] sssd_be[2922]: segfault at 8 ip 00007f0ff5612334 sp 00007fff351c9090 error 4 in libldb.so.1.1.16[7f0ff5605000+2c000] [ 3249.456297] sssd_be[2975]: segfault at 8 ip 00007f225d9bb334 sp 00007fff43002c80 error 4 in libldb.so.1.1.16[7f225d9ae000+2c000] [ 3250.661605] sssd_be[2990]: segfault at 8 ip 00007fce9bda9334 sp 00007fff80076090 error 4 in libldb.so.1.1.16[7fce9bd9c000+2c000] After the segfault appears, I can not longer login to any ipa client machine. RHEL7 - kernel 3.10.0-123.8.1.el7.x86_64, ipa-python-3.3.3-28.el7_0.1.x86_64 python-iniparse-0.4-9.el7.noarch ipa-client-3.3.3-28.el7_0.1.x86_64 libipa_hbac-python-1.11.2-68.el7_0.5.x86_64 iniparser-3.1-5.el7.x86_64 ipa-admintools-3.3.3-28.el7_0.1.x86_64 ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64 sssd-ipa-1.11.2-68.el7_0.5.x86_64 libipa_hbac-1.11.2-68.el7_0.5.x86_64 ipa-server-3.3.3-28.el7_0.1.x86_64 Any idea? The segfault appears in exactly moment of logging to the ipa client. /lm -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Thu Oct 23 10:32:56 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 23 Oct 2014 12:32:56 +0200 Subject: [Freeipa-users] Woes adding a samba server to the ipa domain In-Reply-To: <1413893951.3184.15.camel@toron.pzo.lgs.com.ve> References: <1413810952.3012.22.camel@toron.pzo.lgs.com.ve> <5445B498.9090608@redhat.com> <1413893951.3184.15.camel@toron.pzo.lgs.com.ve> Message-ID: <20141023103255.GA2826@localhost.localdomain> On Tue, Oct 21, 2014 at 07:49:11AM -0430, Loris Santamaria wrote: > El lun, 20-10-2014 a las 21:19 -0400, Dmitri Pal escribi?: > > On 10/20/2014 09:15 AM, Loris Santamaria wrote: > > [...] > > > > > > > Trying to join the server to the domain (net rpc join -U domainadmin -S > > > ipaserver) fails, and it causes a samba crash on the ipa server. > > > Investigating the cause of the crash I found that pdbedit crashes as > > > well (backtrace attached). I couldn't get a meaningful backtrace from > > > the samba crash however I attached it as well. > > > > > > Seems to me that the samba ipasam backend on ipa doesn't like something > > > in the host or the "domain computers" group object in ldap, but I cannot > > > see what could be the problem. Perhaps someone more familiar with the > > > ipasam code can spot it quickly. > > > Do I get it right that you really looking for > > https://fedorahosted.org/sssd/ticket/1588 that was just released > > upstream? > > It would be cool if you can try using SSSD 1.12.1 under Samba FS in > > the use case you have and provide feedback on how it works for you. > > > > AFAIU you install Samba FS and then use ipa-client to configure SSSD > > under it and it should work. > > If not we probably should document it (but I do not see any special > > design page which leads me to the above expectation). > > Ok, I'll happily try sssd 1.12.1. > > Just a question, in smb.conf one should use "security = domain" or > "security = ads"? 'ads' because we want to use Kerberos. But there some other configuration options which needs attention, e.g. you have to create a keytab for the cifs service and make it available to samba. I'll try to set up an small howto page listing the needed steps and come back to you early next week. bye, Sumit > > Best regards > > -- > Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve > Links Global Services, C.A. http://www.lgs.com.ve > Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve > ------------------------------------------------------------ > "If I'd asked my customers what they wanted, they'd have said > a faster horse" - Henry Ford > -- > 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 From leszek.mis at gmail.com Thu Oct 23 10:33:13 2014 From: leszek.mis at gmail.com (crony) Date: Thu, 23 Oct 2014 12:33:13 +0200 Subject: [Freeipa-users] IPA 3.3.3 in transitive trust and random group assignment Message-ID: Hi List, On IPA server I added one external group for AD group. When I log in to IPA client I can see that group: 976800007(trustlinuxgroup_from_ad2posix) but also I see few different groups came directly from Active Directory like 127310615(trustlinuxgroup at acme.example.com) or 127200513(domain users at acme.example.com): Afer clearing the cache, the group assignment looks different, few more or less groups showed by id command. Do you know the reason? I have no idea what to do with this. /lm -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Thu Oct 23 11:45:08 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 23 Oct 2014 13:45:08 +0200 Subject: [Freeipa-users] FreeIPA 3.3.3 and sssd segfault In-Reply-To: References: Message-ID: <20141023114507.GE28314@mail.corp.redhat.com> On (23/10/14 12:23), crony wrote: >Hi, >I have a FreeIPA 3.3.3 in transitive trust with AD2008. > >Today I saw a lot of sssd segfaults on the server side: > >[ 420.412011] sssd_be[734]: segfault at 8 ip 00007fa54fa73334 sp >00007fff62b2ec40 error 4 in libldb.so.1.1.16[7fa54fa66000+2c000] Could you provide coredump (backtrace) or at least log files with higher debug_level? If you have enabled abrt then coredump should be in /var/tmp/abrt/ccpp-* LS From leszek.mis at gmail.com Thu Oct 23 12:44:17 2014 From: leszek.mis at gmail.com (crony) Date: Thu, 23 Oct 2014 14:44:17 +0200 Subject: [Freeipa-users] FreeIPA 3.3.3 and sssd segfault In-Reply-To: <20141023114507.GE28314@mail.corp.redhat.com> References: <20141023114507.GE28314@mail.corp.redhat.com> Message-ID: Already sent directly to your email. /lm 2014-10-23 13:45 GMT+02:00 Lukas Slebodnik : > On (23/10/14 12:23), crony wrote: > >Hi, > >I have a FreeIPA 3.3.3 in transitive trust with AD2008. > > > >Today I saw a lot of sssd segfaults on the server side: > > > >[ 420.412011] sssd_be[734]: segfault at 8 ip 00007fa54fa73334 sp > >00007fff62b2ec40 error 4 in libldb.so.1.1.16[7fa54fa66000+2c000] > Could you provide coredump (backtrace) or at least log files with higher > debug_level? > > If you have enabled abrt then coredump should be in /var/tmp/abrt/ccpp-* > > LS > -- Pozdrawiam Leszek Mi? www: http://cronylab.pl www: http://emerge.pl Nothing is secure, paranoia is your friend. -------------- next part -------------- An HTML attachment was scrubbed... URL: From desantis at mail.usf.edu Thu Oct 23 13:01:48 2014 From: desantis at mail.usf.edu (John Desantis) Date: Thu, 23 Oct 2014 09:01:48 -0400 Subject: [Freeipa-users] Attempting to re-provision previous replica In-Reply-To: References: <5447D6CE.1020305@redhat.com> <5447E090.9000901@redhat.com> <54480312.1010409@redhat.com> <54480A43.1020700@redhat.com> Message-ID: Rob and Rich, >> ipa-replica-manage del should have cleaned things up. You can clear out >> old RUVs with ipa-replica-manage too via list-ruv and clean-ruv. You use >> list-ruv to get the id# to clean and clean-ruv to do the actual cleaning. > > I remember having previously tried this task, but it had failed on > older RUV's which were not even active (the KDC was under some strain > so ipa queries were timing out). However, I ran it again and have > been able to delete all but 1 (it's still running) RUV referencing the > previous replica. > > I'll report back once the tasks finishes or fails. The last RUV is "stuck" on another replica. It fails with the following error: [23/Oct/2014:08:55:09 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Initiating CleanAllRUV Task... [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Retrieving maxcsn... [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Found maxcsn (5447f861000000180000) [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Cleaning rid (24)... [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting to process all the updates from the deleted replica... [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to be online... [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to receive all the deleted replica updates... [23/Oct/2014:08:55:11 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Replica maxcsn (5447f56b000200180000) is not caught up with deleted replica's maxcsn(5447f861000000180000) [23/Oct/2014:08:55:11 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Replica not caught up (agmt="cn=meToiparepbackup.our.personal.domain" (iparepbackup:389)) [23/Oct/2014:08:55:11 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Not all replicas caught up, retrying in 10 seconds [23/Oct/2014:08:55:23 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Replica maxcsn (5447f56b000200180000) is not caught up with deleted replica's maxcsn(5447f861000000180000) [23/Oct/2014:08:55:23 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Replica not caught up (agmt="cn=meToiparepbackup.our.personal.domain" (iparepbackup:389)) [23/Oct/2014:08:55:23 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Not all replicas caught up, retrying in 20 seconds I then abort the task since the retrying went up to 14400 seconds. Would this be a simple re-initialization from the master on the host "iparepbackup"? Thanks, John DeSantis 2014-10-22 16:03 GMT-04:00 John Desantis : > Rob and Rich, > >> ipa-replica-manage del should have cleaned things up. You can clear out >> old RUVs with ipa-replica-manage too via list-ruv and clean-ruv. You use >> list-ruv to get the id# to clean and clean-ruv to do the actual cleaning. > > I remember having previously tried this task, but it had failed on > older RUV's which were not even active (the KDC was under some strain > so ipa queries were timing out). However, I ran it again and have > been able to delete all but 1 (it's still running) RUV referencing the > previous replica. > > I'll report back once the tasks finishes or fails. > > Thanks, > John DeSantis > > > 2014-10-22 15:49 GMT-04:00 Rob Crittenden : >> Rich Megginson wrote: >>> On 10/22/2014 12:55 PM, John Desantis wrote: >>>> Richard, >>>> >>>>> You should remove the unused ruv elements. I'm not sure why they >>>>> were not >>>>> cleaned. You may have to use cleanallruv manually. >>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv >>>>> >>>>> >>>>> note - use the cleanallruv procedure, not cleanruv. >>>> I'll try that, thanks for the guidance. >>>> >>>>> What is the real problem you have? Did replication stop working? Are >>>>> you >>>>> getting error messages? >>>> I cannot get the host to be a replica. Each time I run >>>> `ipa-replica-install >>>> replica-info-host-in-question.our.personal.domain.gpg' it fails. I >>>> had assumed it was due to the fact that the host was already a >>>> replica, but had to be taken offline due to a hard disk failing. The >>>> machine was re-provisioned after the new hard drive was installed. >>> >>> Ok. I don't know if we have a documented procedure for that case. I >>> assumed that if you first ran ipa-replica-manage del, then >>> ipa-replica-prepare, then ipa-replica-install, that would take care of >>> that. >> >> ipa-replica-manage del should have cleaned things up. You can clear out >> old RUVs with ipa-replica-manage too via list-ruv and clean-ruv. You use >> list-ruv to get the id# to clean and clean-ruv to do the actual cleaning. >> >>>> >>>> When I enabled extra debugging during the installation process, the >>>> initial error was that the dirsrv instance couldn't be started. I >>>> checked into this and found that there were missing files in >>>> /etc/dirsrv/slapd-BLAH directory. I was then able to start dirsrv >>>> after copying some schema files from another replica. The install did >>>> move forward but then failed with Apache and its IPA configuration. >>>> >>>> I performed several uninstalls and re-installs, and at one point I got >>>> error code 3 from ipa-replica-install, which is why I was thinking >>>> that the old RUV's and tombstones were to blame. >>> >>> It could be. I'm really not sure what the problem is at this point. >> >> I think we'd need to see ipareplica-install.log to know for sure. It >> could be the sort of thing where it fails early but doesn't kill the >> install, so the last error is a red herring. >> >> rob >> >>> >>>> >>>> Thanks, >>>> John DeSantis >>>> >>>> >>>> 2014-10-22 12:51 GMT-04:00 Rich Megginson : >>>>> On 10/22/2014 10:31 AM, John Desantis wrote: >>>>>> Richard, >>>>>> >>>>>> You helped me before in #freeipa, so I appreciate the assistance again. >>>>>> >>>>>>> What version of 389 are you using? >>>>>>> rpm -q 389-ds-base >>>>>> 389-ds-base-1.2.11.15-34.el6_5 >>>>>> >>>>>> Thanks, >>>>>> John DeSantis >>>>>> >>>>>> 2014-10-22 12:09 GMT-04:00 Rich Megginson : >>>>>>> On 10/22/2014 09:42 AM, John Desantis wrote: >>>>>>>> Hello all, >>>>>>>> >>>>>>>> First and foremost, a big "thank you!" to the FreeIPA developers >>>>>>>> for a >>>>>>>> great product! >>>>>>>> >>>>>>>> Now, to the point! >>>>>>>> >>>>>>>> We're trying to re-provision a previous replica using the standard >>>>>>>> documentation via the Red Hat site: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Setting_up_IPA_Replicas.html >>>>>>>> >>>>>>>> >>>>>>>> However, we're running into errors during the import process. The >>>>>>>> errors are varied and fail at random steps; there was an issue with >>>>>>>> NTP or HTTP or LDAP, etc. This did not happen when we promoted a >>>>>>>> separate node to become a replica. >>>>>>>> >>>>>>>> We had previously removed the replica via `ipa-replica-manage del` >>>>>>>> and >>>>>>>> ensured that no trace of it being a replica existed: removed DNS >>>>>>>> records and verified that the host enrollment was not present. I did >>>>>>>> not use the "--force" and "--cleanup" options. >>>>>>> >>>>>>> What version of 389 are you using? >>>>>>> rpm -q 389-ds-base >>>>> >>>>> You should remove the unused ruv elements. I'm not sure why they >>>>> were not >>>>> cleaned. You may have to use cleanallruv manually. >>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv >>>>> >>>>> >>>>> note - use the cleanallruv procedure, not cleanruv. >>>>> >>>>>>>> When I check RUV's against the host in question, there are >>>>>>>> several. I >>>>>>>> also queried the tombstones against the host and found two entries >>>>>>>> which have valid hex time stamps; coincidentally, out of the 9 >>>>>>>> tombstone entries, 2 have "nsds50ruv" time stamps. I'll paste >>>>>>>> sanitized output below: >>>>>>>> >>>>>>>> # ldapsaerch -x -W -LLL -D "cn=directory manager" -b >>>>>>>> "dc=our,dc=personal,dc=domain" '(objectclass=nsTombstone)' >>>>>>>> Enter LDAP Password: >>>>>>>> dn: >>>>>>>> >>>>>>>> nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=our,dc=personal,dc=domain >>>>>>>> >>>>>>>> objectClass: top >>>>>>>> objectClass: nsTombstone >>>>>>>> objectClass: extensibleobject >>>>>>>> nsds50ruv: {replicageneration} 50ef13ae000000040000 >>>>>>>> nsds50ruv: {replica 4 ldap://master.our.personal.domain:389} >>>>>>>> 5164d147000000040000 5447bda 8000100040000 >>>>>>>> nsds50ruv: {replica 22 ldap://separatenode.our.personal.domain:389} >>>>>>>> 54107f9f000000160000 54436b 25000000160000 >>>>>>>> nsds50ruv: {replica 21 ldap://iparepbackup.our.personal.domain:389} >>>>>>>> 51b734de000000150000 51b7 34ef000200150000 >>>>>>>> nsds50ruv: {replica 19 >>>>>>>> ldap://host-in-question.our.personal.domain:389} 510d56c9000100130000 >>>>>>>> 510d82 be000200130000 >>>>>>>> nsds50ruv: {replica 18 >>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>> nsds50ruv: {replica 17 >>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>> nsds50ruv: {replica 16 >>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>> nsds50ruv: {replica 15 >>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>> nsds50ruv: {replica 14 >>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>> nsds50ruv: {replica 13 >>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>> nsds50ruv: {replica 12 >>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>> nsds50ruv: {replica 23 >>>>>>>> ldap://host-in-question.our.personal.domain:389} 54187702000200170000 >>>>>>>> 541878 9a000000170000 >>>>>>>> dc: our >>>>>>>> nsruvReplicaLastModified: {replica 4 >>>>>>>> ldap://master.our.personal.domain:389} 5447bce8 >>>>>>>> nsruvReplicaLastModified: {replica 22 >>>>>>>> ldap://separatenode.our.personal.domain:389} 54436a5e >>>>>>>> nsruvReplicaLastModified: {replica 21 >>>>>>>> ldap://iparepbackup.our.personal.domain:389} 00000000 >>>>>>>> nsruvReplicaLastModified: {replica 19 >>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>> nsruvReplicaLastModified: {replica 18 >>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>> nsruvReplicaLastModified: {replica 17 >>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>> nsruvReplicaLastModified: {replica 16 >>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>> nsruvReplicaLastModified: {replica 15 >>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>> nsruvReplicaLastModified: {replica 14 >>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>> nsruvReplicaLastModified: {replica 13 >>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>> nsruvReplicaLastModified: {replica 12 >>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>> nsruvReplicaLastModified: {replica 23 >>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>> >>>>>>>> dn: >>>>>>>> >>>>>>>> nsuniqueid=c08a2803-5b5a11e2-a527ce8b-8fa47d35,cn=host-in-question.our.personal.domain,cn=maste >>>>>>>> >>>>>>>> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >>>>>>>> objectClass: top >>>>>>>> objectClass: nsContainer >>>>>>>> objectClass: nsTombstone >>>>>>>> cn: host-in-question.our.personal.domain >>>>>>>> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >>>>>>>> >>>>>>>> dn: >>>>>>>> >>>>>>>> nsuniqueid=664c4383-6d6311e2-8db6e946-de27dd8d,cn=host-in-question.our.personal.domain,cn=maste >>>>>>>> >>>>>>>> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >>>>>>>> objectClass: top >>>>>>>> objectClass: nsContainer >>>>>>>> objectClass: nsTombstone >>>>>>>> cn: host-in-question.our.personal.domain >>>>>>>> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >>>>>>>> >>>>>>>> As you can see, the "host-in-question" has many RUV's and of which >>>>>>>> two >>>>>>>> appear to be "active" and two entries which I believe (pardon my >>>>>>>> ignorance) possibly correlate with the "active" entries of the >>>>>>>> "host-in-question". >>>>>>>> >>>>>>>> Do these two tombstone entries need to be deleted with ldapdelete >>>>>>>> before we can re-provision "host-in-question" and add it back as a >>>>>>>> replica? >>>>> >>>>> No, you cannot delete tombstones manually. They will be cleaned up >>>>> at some >>>>> point by the dirsrv tombstone reap thread, and they should not be >>>>> interfering with anything. >>>>> >>>>> What is the real problem you have? Did replication stop working? Are >>>>> you >>>>> getting error messages? >>>>> >>>>>>>> Thank you, >>>>>>>> John DeSantis >>>>>>>> >>>>>>> -- >>>>>>> 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 >>> >> From orkhan-azeri at mail.ru Thu Oct 23 13:30:29 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Thu, 23 Oct 2014 18:30:29 +0500 Subject: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1. In-Reply-To: <5448D695.9020405@mail.ru> References: <54480E4B.2000207@cenic.org> <5448A9C7.9020506@mail.ru> <5448D695.9020405@mail.ru> Message-ID: <544902F5.7050908@mail.ru> And another interesting behaviour. Say a user "netuser" is a member of a user group "netstaff", and a host "bsd.example.com" is a member of a host group "nethosts". We then create an HBAC rule "netstaff_to_nethosts": Who: User Groups -> netstaff -- Accessing: Host Groups -> nethosts -- Via Service: Specified Services and Groups -> sshd And we create a SUDO rule "test": Who: Specified Users and Groups -> netuser -- Access this host: bsd.example.com -- Run Commands: Any Command Expected result is this: user "netuser" should be able to SSH to host "bsd.example.com" and successfully issue the command "sudo shutdown -r now". What happens instead: user "netuser" is able to SSH to host "bsd.example.com", but issuing the command "sudo shutdown -r now" produces this output (password is entered correctly): $ shutdown -r now Password: Ying Tong Iddle I Po Password: Do you think like you type? Password: Have you considered trying to match wits with a rutabaga? This is funny, and you can continue trying sudo and getting funny outputs; but the only way for the command to work properly is to change the HBAC rule: Who: User Groups -> netstaff -- Accessing: Host Groups -> nethosts -- Via Service: Specified Services and Groups -> ANY SERVICE Is this the correct behavior? I don't remember anything like this in FreeIPA 3.3. 23-Oct-14 15:21, Orkhan Gasimov ?????: > Yet with FreeIPA v4 we've got another thing to keep in mind regarding > FreeBSD - FreeIPA integration: the cron script proposed at FreeBSD > forums won't work. > Here's what was said in the post: > > "The tricky part was gettingsudoto work with host groups. FreeIPA > keeps host groups in netgroups, and FreeBSD's support for netgroups is > limited. One solution would have been to enable NIS services on the > FreeIPA server so that we could use proper netgroups on FreeBSD > clients. We didn't like that solution, so instead we wrote a script > that pulls all netgroup data from FreeIPA and stores it > in/etc/netgroup. We run the script every hour viacron." > > The script looks for host groups in > 'cn=hostgroups,cn=accounts,dc=', and that works with FreeIPA > 3.3. But in FreeIPA v4 host groups get in > 'cn=ng,cn=compat,dc='. So the script needs modification. > > 23-Oct-14 12:09, Orkhan Gasimov ?????: >> I already deployed FreeIPA 4.1 on Fedora 21 server alpha-release. >> Everything is good as far as FreeIPA server operation is concerned. >> >> >> 23-Oct-14 01:06, William Graboyes ?????: >>> 3) am I insane for wanting to introduce FC21 into my environment? >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Oct 23 13:34:56 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 23 Oct 2014 07:34:56 -0600 Subject: [Freeipa-users] Attempting to re-provision previous replica In-Reply-To: References: <5447D6CE.1020305@redhat.com> <5447E090.9000901@redhat.com> <54480312.1010409@redhat.com> <54480A43.1020700@redhat.com> Message-ID: <54490400.50803@redhat.com> On 10/23/2014 07:01 AM, John Desantis wrote: > Rob and Rich, > >>> ipa-replica-manage del should have cleaned things up. You can clear out >>> old RUVs with ipa-replica-manage too via list-ruv and clean-ruv. You use >>> list-ruv to get the id# to clean and clean-ruv to do the actual cleaning. >> I remember having previously tried this task, but it had failed on >> older RUV's which were not even active (the KDC was under some strain >> so ipa queries were timing out). However, I ran it again and have >> been able to delete all but 1 (it's still running) RUV referencing the >> previous replica. >> >> I'll report back once the tasks finishes or fails. > The last RUV is "stuck" on another replica. It fails with the following error: > > [23/Oct/2014:08:55:09 -0400] NSMMReplicationPlugin - CleanAllRUV Task: > Initiating CleanAllRUV Task... > [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: > Retrieving maxcsn... > [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: > Found maxcsn (5447f861000000180000) > [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: > Cleaning rid (24)... > [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: > Waiting to process all the updates from the deleted replica... > [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: > Waiting for all the replicas to be online... > [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: > Waiting for all the replicas to receive all the deleted replica > updates... > [23/Oct/2014:08:55:11 -0400] NSMMReplicationPlugin - CleanAllRUV Task: > Replica maxcsn (5447f56b000200180000) is not caught up with deleted > replica's maxcsn(5447f861000000180000) > [23/Oct/2014:08:55:11 -0400] NSMMReplicationPlugin - CleanAllRUV Task: > Replica not caught up (agmt="cn=meToiparepbackup.our.personal.domain" > (iparepbackup:389)) > [23/Oct/2014:08:55:11 -0400] NSMMReplicationPlugin - CleanAllRUV Task: > Not all replicas caught up, retrying in 10 seconds > [23/Oct/2014:08:55:23 -0400] NSMMReplicationPlugin - CleanAllRUV Task: > Replica maxcsn (5447f56b000200180000) is not caught up with deleted > replica's maxcsn(5447f861000000180000) > [23/Oct/2014:08:55:23 -0400] NSMMReplicationPlugin - CleanAllRUV Task: > Replica not caught up (agmt="cn=meToiparepbackup.our.personal.domain" > (iparepbackup:389)) > [23/Oct/2014:08:55:23 -0400] NSMMReplicationPlugin - CleanAllRUV Task: > Not all replicas caught up, retrying in 20 seconds > > I then abort the task since the retrying went up to 14400 seconds. Mark, do you know what is going on here? > > Would this be a simple re-initialization from the master on the host > "iparepbackup"? > > Thanks, > John DeSantis > > 2014-10-22 16:03 GMT-04:00 John Desantis : >> Rob and Rich, >> >>> ipa-replica-manage del should have cleaned things up. You can clear out >>> old RUVs with ipa-replica-manage too via list-ruv and clean-ruv. You use >>> list-ruv to get the id# to clean and clean-ruv to do the actual cleaning. >> I remember having previously tried this task, but it had failed on >> older RUV's which were not even active (the KDC was under some strain >> so ipa queries were timing out). However, I ran it again and have >> been able to delete all but 1 (it's still running) RUV referencing the >> previous replica. >> >> I'll report back once the tasks finishes or fails. >> >> Thanks, >> John DeSantis >> >> >> 2014-10-22 15:49 GMT-04:00 Rob Crittenden : >>> Rich Megginson wrote: >>>> On 10/22/2014 12:55 PM, John Desantis wrote: >>>>> Richard, >>>>> >>>>>> You should remove the unused ruv elements. I'm not sure why they >>>>>> were not >>>>>> cleaned. You may have to use cleanallruv manually. >>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv >>>>>> >>>>>> >>>>>> note - use the cleanallruv procedure, not cleanruv. >>>>> I'll try that, thanks for the guidance. >>>>> >>>>>> What is the real problem you have? Did replication stop working? Are >>>>>> you >>>>>> getting error messages? >>>>> I cannot get the host to be a replica. Each time I run >>>>> `ipa-replica-install >>>>> replica-info-host-in-question.our.personal.domain.gpg' it fails. I >>>>> had assumed it was due to the fact that the host was already a >>>>> replica, but had to be taken offline due to a hard disk failing. The >>>>> machine was re-provisioned after the new hard drive was installed. >>>> Ok. I don't know if we have a documented procedure for that case. I >>>> assumed that if you first ran ipa-replica-manage del, then >>>> ipa-replica-prepare, then ipa-replica-install, that would take care of >>>> that. >>> ipa-replica-manage del should have cleaned things up. You can clear out >>> old RUVs with ipa-replica-manage too via list-ruv and clean-ruv. You use >>> list-ruv to get the id# to clean and clean-ruv to do the actual cleaning. >>> >>>>> When I enabled extra debugging during the installation process, the >>>>> initial error was that the dirsrv instance couldn't be started. I >>>>> checked into this and found that there were missing files in >>>>> /etc/dirsrv/slapd-BLAH directory. I was then able to start dirsrv >>>>> after copying some schema files from another replica. The install did >>>>> move forward but then failed with Apache and its IPA configuration. >>>>> >>>>> I performed several uninstalls and re-installs, and at one point I got >>>>> error code 3 from ipa-replica-install, which is why I was thinking >>>>> that the old RUV's and tombstones were to blame. >>>> It could be. I'm really not sure what the problem is at this point. >>> I think we'd need to see ipareplica-install.log to know for sure. It >>> could be the sort of thing where it fails early but doesn't kill the >>> install, so the last error is a red herring. >>> >>> rob >>> >>>>> Thanks, >>>>> John DeSantis >>>>> >>>>> >>>>> 2014-10-22 12:51 GMT-04:00 Rich Megginson : >>>>>> On 10/22/2014 10:31 AM, John Desantis wrote: >>>>>>> Richard, >>>>>>> >>>>>>> You helped me before in #freeipa, so I appreciate the assistance again. >>>>>>> >>>>>>>> What version of 389 are you using? >>>>>>>> rpm -q 389-ds-base >>>>>>> 389-ds-base-1.2.11.15-34.el6_5 >>>>>>> >>>>>>> Thanks, >>>>>>> John DeSantis >>>>>>> >>>>>>> 2014-10-22 12:09 GMT-04:00 Rich Megginson : >>>>>>>> On 10/22/2014 09:42 AM, John Desantis wrote: >>>>>>>>> Hello all, >>>>>>>>> >>>>>>>>> First and foremost, a big "thank you!" to the FreeIPA developers >>>>>>>>> for a >>>>>>>>> great product! >>>>>>>>> >>>>>>>>> Now, to the point! >>>>>>>>> >>>>>>>>> We're trying to re-provision a previous replica using the standard >>>>>>>>> documentation via the Red Hat site: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Setting_up_IPA_Replicas.html >>>>>>>>> >>>>>>>>> >>>>>>>>> However, we're running into errors during the import process. The >>>>>>>>> errors are varied and fail at random steps; there was an issue with >>>>>>>>> NTP or HTTP or LDAP, etc. This did not happen when we promoted a >>>>>>>>> separate node to become a replica. >>>>>>>>> >>>>>>>>> We had previously removed the replica via `ipa-replica-manage del` >>>>>>>>> and >>>>>>>>> ensured that no trace of it being a replica existed: removed DNS >>>>>>>>> records and verified that the host enrollment was not present. I did >>>>>>>>> not use the "--force" and "--cleanup" options. >>>>>>>> What version of 389 are you using? >>>>>>>> rpm -q 389-ds-base >>>>>> You should remove the unused ruv elements. I'm not sure why they >>>>>> were not >>>>>> cleaned. You may have to use cleanallruv manually. >>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv >>>>>> >>>>>> >>>>>> note - use the cleanallruv procedure, not cleanruv. >>>>>> >>>>>>>>> When I check RUV's against the host in question, there are >>>>>>>>> several. I >>>>>>>>> also queried the tombstones against the host and found two entries >>>>>>>>> which have valid hex time stamps; coincidentally, out of the 9 >>>>>>>>> tombstone entries, 2 have "nsds50ruv" time stamps. I'll paste >>>>>>>>> sanitized output below: >>>>>>>>> >>>>>>>>> # ldapsaerch -x -W -LLL -D "cn=directory manager" -b >>>>>>>>> "dc=our,dc=personal,dc=domain" '(objectclass=nsTombstone)' >>>>>>>>> Enter LDAP Password: >>>>>>>>> dn: >>>>>>>>> >>>>>>>>> nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=our,dc=personal,dc=domain >>>>>>>>> >>>>>>>>> objectClass: top >>>>>>>>> objectClass: nsTombstone >>>>>>>>> objectClass: extensibleobject >>>>>>>>> nsds50ruv: {replicageneration} 50ef13ae000000040000 >>>>>>>>> nsds50ruv: {replica 4 ldap://master.our.personal.domain:389} >>>>>>>>> 5164d147000000040000 5447bda 8000100040000 >>>>>>>>> nsds50ruv: {replica 22 ldap://separatenode.our.personal.domain:389} >>>>>>>>> 54107f9f000000160000 54436b 25000000160000 >>>>>>>>> nsds50ruv: {replica 21 ldap://iparepbackup.our.personal.domain:389} >>>>>>>>> 51b734de000000150000 51b7 34ef000200150000 >>>>>>>>> nsds50ruv: {replica 19 >>>>>>>>> ldap://host-in-question.our.personal.domain:389} 510d56c9000100130000 >>>>>>>>> 510d82 be000200130000 >>>>>>>>> nsds50ruv: {replica 18 >>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>> nsds50ruv: {replica 17 >>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>> nsds50ruv: {replica 16 >>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>> nsds50ruv: {replica 15 >>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>> nsds50ruv: {replica 14 >>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>> nsds50ruv: {replica 13 >>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>> nsds50ruv: {replica 12 >>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>> nsds50ruv: {replica 23 >>>>>>>>> ldap://host-in-question.our.personal.domain:389} 54187702000200170000 >>>>>>>>> 541878 9a000000170000 >>>>>>>>> dc: our >>>>>>>>> nsruvReplicaLastModified: {replica 4 >>>>>>>>> ldap://master.our.personal.domain:389} 5447bce8 >>>>>>>>> nsruvReplicaLastModified: {replica 22 >>>>>>>>> ldap://separatenode.our.personal.domain:389} 54436a5e >>>>>>>>> nsruvReplicaLastModified: {replica 21 >>>>>>>>> ldap://iparepbackup.our.personal.domain:389} 00000000 >>>>>>>>> nsruvReplicaLastModified: {replica 19 >>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>> nsruvReplicaLastModified: {replica 18 >>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>> nsruvReplicaLastModified: {replica 17 >>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>> nsruvReplicaLastModified: {replica 16 >>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>> nsruvReplicaLastModified: {replica 15 >>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>> nsruvReplicaLastModified: {replica 14 >>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>> nsruvReplicaLastModified: {replica 13 >>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>> nsruvReplicaLastModified: {replica 12 >>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>> nsruvReplicaLastModified: {replica 23 >>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>> >>>>>>>>> dn: >>>>>>>>> >>>>>>>>> nsuniqueid=c08a2803-5b5a11e2-a527ce8b-8fa47d35,cn=host-in-question.our.personal.domain,cn=maste >>>>>>>>> >>>>>>>>> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >>>>>>>>> objectClass: top >>>>>>>>> objectClass: nsContainer >>>>>>>>> objectClass: nsTombstone >>>>>>>>> cn: host-in-question.our.personal.domain >>>>>>>>> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >>>>>>>>> >>>>>>>>> dn: >>>>>>>>> >>>>>>>>> nsuniqueid=664c4383-6d6311e2-8db6e946-de27dd8d,cn=host-in-question.our.personal.domain,cn=maste >>>>>>>>> >>>>>>>>> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >>>>>>>>> objectClass: top >>>>>>>>> objectClass: nsContainer >>>>>>>>> objectClass: nsTombstone >>>>>>>>> cn: host-in-question.our.personal.domain >>>>>>>>> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >>>>>>>>> >>>>>>>>> As you can see, the "host-in-question" has many RUV's and of which >>>>>>>>> two >>>>>>>>> appear to be "active" and two entries which I believe (pardon my >>>>>>>>> ignorance) possibly correlate with the "active" entries of the >>>>>>>>> "host-in-question". >>>>>>>>> >>>>>>>>> Do these two tombstone entries need to be deleted with ldapdelete >>>>>>>>> before we can re-provision "host-in-question" and add it back as a >>>>>>>>> replica? >>>>>> No, you cannot delete tombstones manually. They will be cleaned up >>>>>> at some >>>>>> point by the dirsrv tombstone reap thread, and they should not be >>>>>> interfering with anything. >>>>>> >>>>>> What is the real problem you have? Did replication stop working? Are >>>>>> you >>>>>> getting error messages? >>>>>> >>>>>>>>> Thank you, >>>>>>>>> John DeSantis >>>>>>>>> >>>>>>>> -- >>>>>>>> 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 From abokovoy at redhat.com Thu Oct 23 13:41:55 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 23 Oct 2014 16:41:55 +0300 Subject: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1. In-Reply-To: <544902F5.7050908@mail.ru> References: <54480E4B.2000207@cenic.org> <5448A9C7.9020506@mail.ru> <5448D695.9020405@mail.ru> <544902F5.7050908@mail.ru> Message-ID: <20141023134155.GH5446@redhat.com> On Thu, 23 Oct 2014, Orkhan Gasimov wrote: >And another interesting behaviour. > >Say a user "netuser" is a member of a user group "netstaff", >and a host "bsd.example.com" is a member of a host group "nethosts". >We then create an HBAC rule "netstaff_to_nethosts": > >Who: User Groups -> netstaff -- Accessing: Host Groups -> nethosts -- >Via Service: Specified Services and Groups -> sshd Here you are allowing only sshd service for use. > >And we create a SUDO rule "test": > >Who: Specified Users and Groups -> netuser -- Access this host: >bsd.example.com -- Run Commands: Any Command > >Expected result is this: user "netuser" should be able to SSH to host >"bsd.example.com" and successfully issue the command "sudo shutdown -r >now". > >What happens instead: user "netuser" is able to SSH to host >"bsd.example.com", but issuing the command "sudo shutdown -r now" >produces this output (password is entered correctly): > >$ shutdown -r now >Password: >Ying Tong Iddle I Po >Password: >Do you think like you type? >Password: >Have you considered trying to match wits with a rutabaga? > >This is funny, and you can continue trying sudo and getting funny >outputs; but the only way for the command to work properly is to >change the HBAC rule: > >Who: User Groups -> netstaff -- Accessing: Host Groups -> nethosts -- >Via Service: Specified Services and Groups -> ANY SERVICE > >Is this the correct behavior? I don't remember anything like this in >FreeIPA 3.3. Yes. The behaviour did not change since may be FreeIPA 2.0. sudo does authenticate and authorize user first via PAM stack and then applies own ruleset. So HBAC rules get applied here and since you don't have allow_all rule that would allow any user to access any service on any host, you get denial. Instead of using only sshd service in HBAC rule, make a service group and add both sshd and sudo there. Alternatively you can add multiple HBAC rules, one for sshd, one for sudo. -- / Alexander Bokovoy From leszek.mis at gmail.com Thu Oct 23 13:47:31 2014 From: leszek.mis at gmail.com (crony) Date: Thu, 23 Oct 2014 15:47:31 +0200 Subject: [Freeipa-users] IPA+AD (transitive trust) - s2n exop request failed Message-ID: Hi All, I've found another problem with my setup: What could be the reason of such errors on FreeIPA client side: /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:49:23 2014) [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:03 2014) [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:04 2014) [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:06 2014) [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:06 2014) [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:07 2014) [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:07 2014) [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:08 2014) [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:08 2014) [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:17 2014) [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:52:05 2014) [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:52:08 2014) [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:52:18 2014) [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:57:12 2014) [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:57:15 2014) [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:58:29 2014) [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:58:34 2014) [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 10:02:10 2014) [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 10:02:13 2014) [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. IPA 3.3.3 + RHEL7 and IPA clients: RHEL 6.4 and RHEL 6.6 - the same situation. /lm -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Thu Oct 23 13:59:22 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 23 Oct 2014 15:59:22 +0200 Subject: [Freeipa-users] IPA+AD (transitive trust) - s2n exop request failed In-Reply-To: References: Message-ID: <20141023135922.GD2826@localhost.localdomain> On Thu, Oct 23, 2014 at 03:47:31PM +0200, crony wrote: > Hi All, > I've found another problem with my setup: > > What could be the reason of such errors on FreeIPA client side: > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:49:23 2014) > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > exop request failed. > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:03 2014) > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > exop request failed. > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:04 2014) > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > exop request failed. > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:06 2014) > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > exop request failed. > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:06 2014) > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > exop request failed. > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:07 2014) > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > exop request failed. > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:07 2014) > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > exop request failed. > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:08 2014) > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > exop request failed. > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:08 2014) > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > exop request failed. > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:17 2014) > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > exop request failed. > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:52:05 2014) > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > exop request failed. > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:52:08 2014) > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > exop request failed. > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:52:18 2014) > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > exop request failed. > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:57:12 2014) > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > exop request failed. > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:57:15 2014) > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > exop request failed. > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:58:29 2014) > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > exop request failed. > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:58:34 2014) > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > exop request failed. > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 10:02:10 2014) > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > exop request failed. > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 10:02:13 2014) > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > exop request failed. This typically indicates that the user or group lookup failed in the server side. Maybe this is related to the segfaults you are seeing on the server side. bye, Sumit > > IPA 3.3.3 + RHEL7 and IPA clients: RHEL 6.4 and RHEL 6.6 - the same > situation. > > /lm > -- > 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 From abokovoy at redhat.com Thu Oct 23 14:01:59 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 23 Oct 2014 17:01:59 +0300 Subject: [Freeipa-users] IPA+AD (transitive trust) - s2n exop request failed In-Reply-To: References: Message-ID: <20141023140159.GI5446@redhat.com> On Thu, 23 Oct 2014, crony wrote: >Hi All, >I've found another problem with my setup: > >What could be the reason of such errors on FreeIPA client side: You need to check sssd logs on IPA master side. >IPA 3.3.3 + RHEL7 and IPA clients: RHEL 6.4 and RHEL 6.6 - the same >situation. There were some bug fixes in SSSD in RHEL7 which are released upstream in 1.12.x but not yet available through RHEL 7 channels. If you have RHEL 7 subscription, feel free to raise a case with the support. The same applies to the another email you've sent. -- / Alexander Bokovoy From leszek.mis at gmail.com Thu Oct 23 14:01:55 2014 From: leszek.mis at gmail.com (crony) Date: Thu, 23 Oct 2014 16:01:55 +0200 Subject: [Freeipa-users] IPA+AD (transitive trust) - s2n exop request failed In-Reply-To: <20141023135922.GD2826@localhost.localdomain> References: <20141023135922.GD2826@localhost.localdomain> Message-ID: Probable yes. 2014-10-23 15:59 GMT+02:00 Sumit Bose : > On Thu, Oct 23, 2014 at 03:47:31PM +0200, crony wrote: > > Hi All, > > I've found another problem with my setup: > > > > What could be the reason of such errors on FreeIPA client side: > > > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:49:23 2014) > > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > > exop request failed. > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:03 2014) > > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > > exop request failed. > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:04 2014) > > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > > exop request failed. > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:06 2014) > > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > > exop request failed. > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:06 2014) > > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > > exop request failed. > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:07 2014) > > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > > exop request failed. > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:07 2014) > > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > > exop request failed. > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:08 2014) > > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > > exop request failed. > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:08 2014) > > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > > exop request failed. > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:17 2014) > > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > > exop request failed. > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:52:05 2014) > > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > > exop request failed. > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:52:08 2014) > > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > > exop request failed. > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:52:18 2014) > > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > > exop request failed. > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:57:12 2014) > > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > > exop request failed. > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:57:15 2014) > > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > > exop request failed. > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:58:29 2014) > > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > > exop request failed. > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:58:34 2014) > > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > > exop request failed. > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 10:02:10 2014) > > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > > exop request failed. > > /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 10:02:13 2014) > > [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n > > exop request failed. > > This typically indicates that the user or group lookup failed in the > server side. Maybe this is related to the segfaults you are seeing on > the server side. > > bye, > Sumit > > > > > IPA 3.3.3 + RHEL7 and IPA clients: RHEL 6.4 and RHEL 6.6 - the same > > situation. > > > > /lm > > > -- > > 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 > > -- Pozdrawiam Leszek Mi? www: http://cronylab.pl www: http://emerge.pl Nothing is secure, paranoia is your friend. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Oct 23 14:05:29 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 23 Oct 2014 17:05:29 +0300 Subject: [Freeipa-users] IPA 3.3.3 in transitive trust and random group assignment In-Reply-To: References: Message-ID: <20141023140529.GJ5446@redhat.com> On Thu, 23 Oct 2014, crony wrote: >Hi List, >On IPA server I added one external group for AD group. > >When I log in to IPA client I can see that group: > >976800007(trustlinuxgroup_from_ad2posix) > > but also I see few different groups came directly from Active Directory >like 127310615(trustlinuxgroup at acme.example.com) or 127200513(domain >users at acme.example.com): > >Afer clearing the cache, the group assignment looks different, few more or >less groups showed by id command. > >Do you know the reason? I have no idea what to do with this. Prior to SSSD 1.12 full group membership was only retrieved during actual authentication step. With 1.12.2, I think, we have means to pick up most of the groups before authentication as well, barring those that are not valid outside of the domain or forest's use (domain local groups). -- / Alexander Bokovoy From lslebodn at redhat.com Thu Oct 23 14:10:47 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 23 Oct 2014 16:10:47 +0200 Subject: [Freeipa-users] FreeIPA 3.3.3 and sssd segfault In-Reply-To: References: <20141023114507.GE28314@mail.corp.redhat.com> Message-ID: <20141023141045.GA7028@mail.corp.redhat.com> On (23/10/14 14:44), crony wrote: >Already sent directly to your email. > Thank you for coredump. It is a known bug (https://fedorahosted.org/sssd/ticket/2391) Bug is fixed in sssd upstream sh$ git tag --contains 895f045dd4aad7f5857826cc1496cfa048a790dd sssd-1_11_7 sh$ git tag --contains 82347f452febe3cbffc36b0a3308ffb462515442 sssd-1_12_1 sssd-1_12_2 If you want I can prepare you test package for epel7 in COPR, which will be equivalent to sssd in fedora 20 (sssd-1.11.7-2.fc20) LS From leszek.mis at gmail.com Thu Oct 23 14:31:44 2014 From: leszek.mis at gmail.com (crony) Date: Thu, 23 Oct 2014 16:31:44 +0200 Subject: [Freeipa-users] FreeIPA 3.3.3 and sssd segfault In-Reply-To: <20141023141045.GA7028@mail.corp.redhat.com> References: <20141023114507.GE28314@mail.corp.redhat.com> <20141023141045.GA7028@mail.corp.redhat.com> Message-ID: yes, sure, it would be great to see if it works in upstream version. thank you 2014-10-23 16:10 GMT+02:00 Lukas Slebodnik : > On (23/10/14 14:44), crony wrote: > >Already sent directly to your email. > > > Thank you for coredump. > It is a known bug (https://fedorahosted.org/sssd/ticket/2391) > > Bug is fixed in sssd upstream > > sh$ git tag --contains 895f045dd4aad7f5857826cc1496cfa048a790dd > sssd-1_11_7 > > sh$ git tag --contains > 82347f452febe3cbffc36b0a3308ffb462515442 > sssd-1_12_1 > sssd-1_12_2 > > If you want I can prepare you test package for epel7 in COPR, which will > be equivalent to sssd in fedora 20 (sssd-1.11.7-2.fc20) > > LS > -- Pozdrawiam Leszek Mi? www: http://cronylab.pl www: http://emerge.pl Nothing is secure, paranoia is your friend. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Thu Oct 23 15:09:27 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 23 Oct 2014 17:09:27 +0200 Subject: [Freeipa-users] FreeIPA 3.3.3 and sssd segfault In-Reply-To: References: <20141023114507.GE28314@mail.corp.redhat.com> <20141023141045.GA7028@mail.corp.redhat.com> Message-ID: <20141023150927.GB7028@mail.corp.redhat.com> On (23/10/14 16:31), crony wrote: >yes, sure, it would be great to see if it works in upstream version. >thank you > Here you are https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-11/ LS From pvoborni at redhat.com Thu Oct 23 15:22:27 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 23 Oct 2014 17:22:27 +0200 Subject: [Freeipa-users] Announcing FreeIPA 4.0.4 Message-ID: <54491D33.3030207@redhat.com> The FreeIPA team would like to announce FreeIPA v4.0.4 bugfix release! It can be downloaded from http://www.freeipa.org/page/Downloads. Builds for Fedora 21 are available in the official COPR repository [https://copr.fedoraproject.org/coprs/mkosek/freeipa-4.0/]. == Highlights in 4.0.4 == === Enhancements === * Packages can be now built and installed on RHEL/CentOS 7.0 * ipa-replica-prepare now waits for the replica DNS record to be available to fix race conditions in automated test environments * Port 8443 is now checked before server installation to prevent failures in configuring PKI which uses the port === Bug fixes === * Certmonger CAs are now set with correct path to ipa-submit which caused problems with new certificate submission * Directory Server again returns basic RootDSE attributes by default - namingContexts, supportedControl, supportedExtension, supportedLDAPVersion, supportedSASLMechanisms, vendorName, vendorVersion * "IPA OTP Last Token" plugin is now enabled also on upgraded FreeIPA servers before 4.0.0 * Better error message is provided if cert-request command fails for certificates with SAN * PKI|CA certificate renewal script (ca_renewal_master) triggered by certmonger could fail * sudorule-add-runasuser command now works with external users * "IPA" CA is now properly selected for Web Service and Directory Service certificates == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-ldap-updater --upgrade # ipa-upgradeconfig Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks, not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 3.3.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.0.3 == === Alexander Bokovoy (1) === * Default to use TLSv1.0 and TLSv1.1 on the IPA server side === David Kupka (5) === * Fix example usage in ipa man page. * Check that port 8443 is available when installing PKI. * Set IPA CA for freeipa certificates. * Stop dogtag when updating its configuration in ipa-upgradeconfig. * Fix typo causing certmonger is provided with wrong path to ipa-submit. === Gabe (1) === * Missing requires on python-dns in spec file === Jan Cholasta (9) === * Fix certmonger code causing the ca_renewal_master update plugin to fail * Allow RPM upgrade from ipa-* packages * Include ipaplatform in client-only build * Include the ipa command in client-only build * Remove misleading authorization error message in cert-request with --add * Split off generic Red Hat-like platform code from Fedora platform code * Add RHEL platform module * Support building RPMs for RHEL/CentOS 7.0 * Do not check if port 8443 is available in step 2 of external CA install === Ludwig Krispenz (1) === * Ignore irrelevant subtrees in schema compat plugin === Martin Basti (2) === * dnszone-remove-permission should raise error * Fix ipactl service ordering === Martin Kosek (2) === * Sudorule RunAsUser should work with external groups * Remove changetype attribute from update plugin === Nathaniel McCallum (1) === * Configure IPA OTP Last Token plugin on upgrade === Petr Viktorin (4) === * test_permission_plugin: Check legacy permissions * ipa-replica-prepare: Wait for the DNS entry to be resolvable * test_forced_client_reenrollment: Don't check for host certificates * sudo integration test: Remove the local user test === Petr Vobornik (4) === * webui-ci: case-insensitive record check * dns: fix privileges' memberof during dns install * build: increase java stack size for all arches * Become IPA 4.0.4 === Sumit Bose (1) === * ipa-kdb: fix unit tests === Tomas Babej (1) === * Set the default attributes for RootDSE -- Petr Vobornik From unitaip at gmail.com Thu Oct 23 12:19:54 2014 From: unitaip at gmail.com (=?UTF-8?B?0KHQsNC/0LXQs9C40L0g0JLQsNC70LXRgNC40Lk=?=) Date: Thu, 23 Oct 2014 16:19:54 +0400 Subject: [Freeipa-users] Synchronization Agreements between FreeIPA and AD Message-ID: Hello! I tryed to configure synchronization between FreeIPA and Windows AD 2012. In the thirst time accounts from AD synchronization properly but next schedule after 5 min is not work and in error log I see the following errors: # tail -f /var/log/dirsrv/slapd-TEST-CSBI-ITS-RU/errors [23/Oct/2014:15:51:34 +0300] NSMMReplicationPlugin - agmt="cn= meTocsbi-it-dc01.csbigroup.ru" (csbi-it-dc01:389): Replica has no update vector. It has never been initialized. [23/Oct/2014:15:51:37 +0300] NSMMReplicationPlugin - agmt="cn= meTocsbi-it-dc01.csbigroup.ru" (csbi-it-dc01:389): Replica has no update vector. It has never been initialized. [23/Oct/2014:15:51:40 +0300] NSMMReplicationPlugin - agmt="cn= meTocsbi-it-dc01.csbigroup.ru" (csbi-it-dc01:389): Replica has no update vector. It has never been initialized. Thirst synchronization out Added CA certificate /etc/openldap/certs/CSBIGROUP-CA.crt to certificate database for ipa.test-csbi-its.ru ipa: INFO: AD Suffix is: DC=csbigroup,DC=ru The user for the Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=test-csbi-its,dc=ru Windows PassSync entry exists, not resetting password ipa: INFO: Added new sync agreement, waiting for it to become ready . . . ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica acquired successfully: Incremental update started: start: 0: end: 0 ipa: INFO: Agreement is ready, starting replication . . . Starting replication, please wait until this has completed. Update in progress, 13 seconds elapsed [ipa.test-csbi-its.ru] reports: Update failed! Status: [-1 Total update abortedLDAP error: Can't contact LDAP server] Failed to start replication FreeIPA server version 3.3.3 OS version Centos 7 AD Domain 2012 Can you help me to resolve this problem? Best regards, Valeriy -------------- next part -------------- An HTML attachment was scrubbed... URL: From ctr2sprt at gmail.com Thu Oct 23 15:40:57 2014 From: ctr2sprt at gmail.com (Eric McCoy) Date: Thu, 23 Oct 2014 11:40:57 -0400 Subject: [Freeipa-users] Recovering from messed-up certs Message-ID: Hi all, I somehow destroyed my primary IPA server's Server-Cert in /etc/httpd/alias. I don't understand how or why it happened, all I know is that I went to restart Apache and it was gone. Apache won't start, of course, because the cert is missing. I can't issue a new cert on the primary because Apache is down. I tried using the secondary, but it fails saying that it can't connect to the web server on the primary (it's the same error message I get when I try to issue a cert from the primary). I can't figure out how to tell ipa-getcert et al. to talk to the secondary and not the primary. I'm not using DNS for service discovery, so I'm not sure how the various tools figure out where things are. This is all on CentOS 6.5 with IPA 3.0.0-37. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leszek.mis at gmail.com Thu Oct 23 16:12:03 2014 From: leszek.mis at gmail.com (crony) Date: Thu, 23 Oct 2014 18:12:03 +0200 Subject: [Freeipa-users] FreeIPA 3.3.3 and sssd segfault In-Reply-To: <20141023150927.GB7028@mail.corp.redhat.com> References: <20141023114507.GE28314@mail.corp.redhat.com> <20141023141045.GA7028@mail.corp.redhat.com> <20141023150927.GB7028@mail.corp.redhat.com> Message-ID: Thank you! Error: Package: sssd-client-1.11.7-2.el7.centos.x86_64 (lslebodn-sssd-1-11) Requires: libc.so.6(GLIBC_2.14)(64bit) Error: Package: python-sssdconfig-1.11.7-2.el7.centos.noarch (lslebodn-sssd-1-11) Requires: python(abi) = 2.7 Installed: python-2.6.6-52.el6.x86_64 (@updates) python(abi) = 2.6 Available: python-2.6.6-51.el6.x86_64 (base) python(abi) = 2.6 Should I change the default python from RHEL7 for dependencies? It could be destructive for my system ;-) 2014-10-23 17:09 GMT+02:00 Lukas Slebodnik : > On (23/10/14 16:31), crony wrote: > >yes, sure, it would be great to see if it works in upstream version. > >thank you > > > Here you are > https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-11/ > > LS > -- Pozdrawiam Leszek Mi? www: http://cronylab.pl www: http://emerge.pl Nothing is secure, paranoia is your friend. -------------- next part -------------- An HTML attachment was scrubbed... URL: From orkhan-azeri at mail.ru Thu Oct 23 16:13:53 2014 From: orkhan-azeri at mail.ru (=?UTF-8?B?0J7RgNGF0LDQvSDQmtCw0YHRg9C80L7Qsg==?=) Date: Thu, 23 Oct 2014 20:13:53 +0400 Subject: [Freeipa-users] =?utf-8?q?A_crazy_idea_maybe=2C_migration_to_Free?= =?utf-8?b?LUlQQSA0LjEu?= In-Reply-To: <20141023134155.GH5446@redhat.com> References: <54480E4B.2000207@cenic.org> <544902F5.7050908@mail.ru> <20141023134155.GH5446@redhat.com> Message-ID: <1414080833.731158339@f47.i.mail.ru> Alright then, thanks for info! Tomorrow is the deadline for my researches on FreeIPA. Then I have to start deploying a centralized management solution in our production environment. Please help me to make a final decision on which version of FreeIPA to choose - 3.3 or 4.1? I'd like to have all the benefits of the latest version, but all our production servers are FreeBSD. With all information sources at my disposal right now I tend to choose FreeIPA 3.3. The cause is that otherwise I can't use host groups with sudo commands - the cron script proposed at FreeBSD forums works with old way of storing host group information in the LDAP directory of FreeIPA. Is there any workaround for this? (P.S. Here's what I'm talking about: >" The tricky part was getting? sudo ?to work with host groups. FreeIPA keeps host groups in netgroups, and FreeBSD's support for netgroups is limited. One solution would have been to enable NIS services on the FreeIPA server so that we could use proper netgroups on FreeBSD clients. We didn't like that solution, so instead we wrote a script that pulls all netgroup data from FreeIPA and stores it in? /etc/netgroup . We run the script every hour via ?cron . " > >The script looks for host groups in 'cn=hostgroups,cn=accounts,dc=', and that works with FreeIPA 3.3. But in FreeIPA v4 host groups get in 'cn=ng,cn=compat,dc='. So the script needs modification. But I don't know how to modify the script, simply changing the string passed to the ldapsearch command doesn't work.) Thu, 23 Oct 2014 16:41:55 +0300 ?? Alexander Bokovoy : >On Thu, 23 Oct 2014, Orkhan Gasimov wrote: >>And another interesting behaviour. >> >>Say a user "netuser" is a member of a user group "netstaff", >>and a host "bsd.example.com" is a member of a host group "nethosts". >>We then create an HBAC rule "netstaff_to_nethosts": >> >>Who: User Groups -> netstaff -- Accessing: Host Groups -> nethosts -- >>Via Service: Specified Services and Groups -> sshd >Here you are allowing only sshd service for use. > >> >>And we create a SUDO rule "test": >> >>Who: Specified Users and Groups -> netuser -- Access this host: >>bsd.example.com -- Run Commands: Any Command >> >>Expected result is this: user "netuser" should be able to SSH to host >>"bsd.example.com" and successfully issue the command "sudo shutdown -r >>now". >> >>What happens instead: user "netuser" is able to SSH to host >>"bsd.example.com", but issuing the command "sudo shutdown -r now" >>produces this output (password is entered correctly): >> >>$ shutdown -r now >>Password: >>Ying Tong Iddle I Po >>Password: >>Do you think like you type? >>Password: >>Have you considered trying to match wits with a rutabaga? >> >>This is funny, and you can continue trying sudo and getting funny >>outputs; but the only way for the command to work properly is to >>change the HBAC rule: >> >>Who: User Groups -> netstaff -- Accessing: Host Groups -> nethosts -- >>Via Service: Specified Services and Groups -> ANY SERVICE >> >>Is this the correct behavior? I don't remember anything like this in >>FreeIPA 3.3. >Yes. The behaviour did not change since may be FreeIPA 2.0. > >sudo does authenticate and authorize user first via PAM stack and then applies own >ruleset. So HBAC rules get applied here and since you don't have >allow_all rule that would allow any user to access any service on any >host, you get denial. > >Instead of using only sshd service in HBAC rule, make a service group >and add both sshd and sudo there. > >Alternatively you can add multiple HBAC rules, one for sshd, one for >sudo. > > >-- >/ Alexander Bokovoy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Oct 23 16:26:16 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 23 Oct 2014 12:26:16 -0400 Subject: [Freeipa-users] Synchronization Agreements between FreeIPA and AD In-Reply-To: References: Message-ID: <54492C28.3080302@redhat.com> On 10/23/2014 08:19 AM, ??????? ??????? wrote: > Hello! > > I tryed to configure synchronization between FreeIPA and Windows AD > 2012. In the thirst time accounts from AD synchronization properly but > next schedule after 5 min is not work and in error log I see the > following errors: > > # tail -f /var/log/dirsrv/slapd-TEST-CSBI-ITS-RU/errors > [23/Oct/2014:15:51:34 +0300] NSMMReplicationPlugin - > agmt="cn=meTocsbi-it-dc01.csbigroup.ru > " (csbi-it-dc01:389): Replica > has no update vector. It has never been initialized. > [23/Oct/2014:15:51:37 +0300] NSMMReplicationPlugin - > agmt="cn=meTocsbi-it-dc01.csbigroup.ru > " (csbi-it-dc01:389): Replica > has no update vector. It has never been initialized. > [23/Oct/2014:15:51:40 +0300] NSMMReplicationPlugin - > agmt="cn=meTocsbi-it-dc01.csbigroup.ru > " (csbi-it-dc01:389): Replica > has no update vector. It has never been initialized. > > Thirst synchronization out > > Added CA certificate /etc/openldap/certs/CSBIGROUP-CA.crt to > certificate database for ipa.test-csbi-its.ru > > ipa: INFO: AD Suffix is: DC=csbigroup,DC=ru > The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=test-csbi-its,dc=ru > Windows PassSync entry exists, not resetting password > ipa: INFO: Added new sync agreement, waiting for it to become ready . . . > ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica > acquired successfully: Incremental update started: start: 0: end: 0 > ipa: INFO: Agreement is ready, starting replication . . . > Starting replication, please wait until this has completed. > Update in progress, 13 seconds elapsed > [ipa.test-csbi-its.ru ] reports: Update > failed! Status: [-1 Total update abortedLDAP error: Can't contact LDAP > server] Can you connect from this replica to AD using ldapsearch? > > Failed to start replication > > > > FreeIPA server version 3.3.3 > OS version Centos 7 > AD Domain 2012 > > Can you help me to resolve this problem? > > Best regards, Valeriy > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Thu Oct 23 16:30:16 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 23 Oct 2014 18:30:16 +0200 Subject: [Freeipa-users] FreeIPA 3.3.3 and sssd segfault In-Reply-To: References: <20141023114507.GE28314@mail.corp.redhat.com> <20141023141045.GA7028@mail.corp.redhat.com> <20141023150927.GB7028@mail.corp.redhat.com> Message-ID: <20141023163015.GC7028@mail.corp.redhat.com> On (23/10/14 18:12), crony wrote: >Thank you! > I prepared repo for epel6, epel7 and fedora 19 >Error: Package: sssd-client-1.11.7-2.el7.centos.x86_64 (lslebodn-sssd-1-11) > Requires: libc.so.6(GLIBC_2.14)(64bit) >Error: Package: python-sssdconfig-1.11.7-2.el7.centos.noarch ^^^^ you want to install package from epel7 >(lslebodn-sssd-1-11) > Requires: python(abi) = 2.7 > Installed: python-2.6.6-52.el6.x86_64 (@updates) ^^^ and machine is rhel6 (centos6) > python(abi) = 2.6 > Available: python-2.6.6-51.el6.x86_64 (base) > python(abi) = 2.6 > >Should I change the default python from RHEL7 for dependencies? It could be >destructive for my system ;-) Are you sure you are using RHEL7 and not RHEL6? LS From abokovoy at redhat.com Thu Oct 23 16:40:19 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 23 Oct 2014 19:40:19 +0300 Subject: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1. In-Reply-To: <1414080833.731158339@f47.i.mail.ru> References: <54480E4B.2000207@cenic.org> <544902F5.7050908@mail.ru> <20141023134155.GH5446@redhat.com> <1414080833.731158339@f47.i.mail.ru> Message-ID: <20141023164019.GK5446@redhat.com> On Thu, 23 Oct 2014, ????? ??????? wrote: > >Alright then, thanks for info! >Tomorrow is the deadline for my researches on FreeIPA. >Then I have to start deploying a centralized management solution in our production environment. >Please help me to make a final decision on which version of FreeIPA to choose - 3.3 or 4.1? >I'd like to have all the benefits of the latest version, but all our production servers are FreeBSD. >With all information sources at my disposal right now I tend to choose FreeIPA 3.3. >The cause is that otherwise I can't use host groups with sudo commands - >the cron script proposed at FreeBSD forums works with old way of storing host group information in the LDAP directory of FreeIPA. >Is there any workaround for this? (P.S. Here's what I'm talking about: >>" The tricky part was getting? sudo ?to work with host groups. FreeIPA >>keeps host groups in netgroups, and FreeBSD's support for netgroups is >>limited. One solution would have been to enable NIS services on the >>FreeIPA server so that we could use proper netgroups on FreeBSD >>clients. We didn't like that solution, so instead we wrote a script >>that pulls all netgroup data from FreeIPA and stores it in? >>/etc/netgroup . We run the script every hour via ?cron . " >> >>The script looks for host groups in >>'cn=hostgroups,cn=accounts,dc=', and that works with FreeIPA >>3.3. But in FreeIPA v4 host groups get in >>'cn=ng,cn=compat,dc='. So the script needs modification. But I >>don't know how to modify the script, simply changing the string passed >>to the ldapsearch command doesn't work.) I think you completely missed the way FreeIPA works. :) Host groups are always in cn=hostgroups,cn=accounts,$SUFFIX, no changes were done. What you see in cn=ng,cn=compat,$SUFFIX are net groups for compatibility with older applications which expect old LDAP schema. The tree in cn=compat,$SUFFIX is provided through schema compatibility plugin and was also provided this way for quite a long time. What I think you are stumbling upon is the fact that starting with FreeIPA 4.0 we are providing more fine-grained access control to the data in LDAP tree. For example: $ ipa permission-find --subtree=cn=hostgroups,cn=accounts,dc=ipacloud,dc=test --right=read --------------------- 2 permissions matched --------------------- Permission name: System: Read Hostgroup Membership Granted rights: read, compare, search Effective attributes: member, memberhost, memberof, memberuser Default attributes: member, memberof, memberuser, memberhost Bind rule type: all Subtree: cn=hostgroups,cn=accounts,dc=ipacloud,dc=test Type: hostgroup Permission name: System: Read Hostgroups Granted rights: read, compare, search Effective attributes: businesscategory, cn, createtimestamp, description, entryusn, ipauniqueid, modifytimestamp, o, objectclass, ou, owner, seealso Default attributes: cn, businesscategory, objectclass, description, o, ipauniqueid, owner, ou, seealso Bind rule type: all Subtree: cn=hostgroups,cn=accounts,dc=ipacloud,dc=test Type: hostgroup ---------------------------- Number of entries returned 2 ---------------------------- As you can see, both permissions require bind rule type 'all' which means 'all authenticated users'. On contrast, in schema compat tree you'll get the whole tree anonymously $ ipa permission-find --target=cn=ng,cn=compat,dc=ipacloud,dc=test --right=read -------------------- 1 permission matched -------------------- Permission name: System: Read Netgroup Compat Tree Granted rights: read, compare, search Effective attributes: cn, createtimestamp, entryusn, membernisnetgroup, modifytimestamp, nisnetgrouptriple, objectclass Default attributes: objectclass, nisnetgrouptriple, membernisnetgroup, cn Bind rule type: anonymous Subtree: dc=ipacloud,dc=test Target DN: cn=ng,cn=compat,dc=ipacloud,dc=test ---------------------------- Number of entries returned 1 ---------------------------- This means that your script should work as before, only that it needs to authenticate before connecting. As you run it as root, you can use host keytab, try adding something like this: old_krb5_ccache=${KRB5_CCACHE} KRB5_CCACHE=/tmp/_hostgroups_access.ccache.$$ export KRB5_CCACHE kinit -k -t /etc/krb5.keytab host/`hostname` # perform actual search ldapsearch -Y GSSAPI ..... # end of script kdestroy KRB5_CCACHE=${old_krb5_ccache} export KRB5_CCACHE note that ldapsearch -Y GSSAPI will use Kerberos authentication when talking to IPA LDAP server and use host/`hostname` principal for that. This should be enough for allowing access to the host groups. -- / Alexander Bokovoy From rcritten at redhat.com Thu Oct 23 16:53:53 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 23 Oct 2014 12:53:53 -0400 Subject: [Freeipa-users] Recovering from messed-up certs In-Reply-To: References: Message-ID: <544932A1.8030909@redhat.com> Eric McCoy wrote: > Hi all, > > I somehow destroyed my primary IPA server's Server-Cert in > /etc/httpd/alias. I don't understand how or why it happened, all I know > is that I went to restart Apache and it was gone. Apache won't start, > of course, because the cert is missing. I can't issue a new cert on the > primary because Apache is down. I tried using the secondary, but it > fails saying that it can't connect to the web server on the primary > (it's the same error message I get when I try to issue a cert from the > primary). I can't figure out how to tell ipa-getcert et al. to talk to > the secondary and not the primary. I'm not using DNS for service > discovery, so I'm not sure how the various tools figure out where things > are. > > This is all on CentOS 6.5 with IPA 3.0.0-37. > > What certs do you have in the database? # certutil -L -d /etc/httpd/alias rob From rmeggins at redhat.com Thu Oct 23 17:04:21 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 23 Oct 2014 11:04:21 -0600 Subject: [Freeipa-users] Synchronization Agreements between FreeIPA and AD In-Reply-To: <54492C28.3080302@redhat.com> References: <54492C28.3080302@redhat.com> Message-ID: <54493515.1070604@redhat.com> On 10/23/2014 10:26 AM, Dmitri Pal wrote: > On 10/23/2014 08:19 AM, ??????? ??????? wrote: >> Hello! >> >> I tryed to configure synchronization between FreeIPA and Windows AD >> 2012. In the thirst time accounts from AD synchronization properly >> but next schedule after 5 min is not work and in error log I see the >> following errors: >> >> # tail -f /var/log/dirsrv/slapd-TEST-CSBI-ITS-RU/errors >> [23/Oct/2014:15:51:34 +0300] NSMMReplicationPlugin - >> agmt="cn=meTocsbi-it-dc01.csbigroup.ru >> " (csbi-it-dc01:389): Replica >> has no update vector. It has never been initialized. >> [23/Oct/2014:15:51:37 +0300] NSMMReplicationPlugin - >> agmt="cn=meTocsbi-it-dc01.csbigroup.ru >> " (csbi-it-dc01:389): Replica >> has no update vector. It has never been initialized. >> [23/Oct/2014:15:51:40 +0300] NSMMReplicationPlugin - >> agmt="cn=meTocsbi-it-dc01.csbigroup.ru >> " (csbi-it-dc01:389): Replica >> has no update vector. It has never been initialized. >> >> Thirst synchronization out >> >> Added CA certificate /etc/openldap/certs/CSBIGROUP-CA.crt to >> certificate database for ipa.test-csbi-its.ru >> >> ipa: INFO: AD Suffix is: DC=csbigroup,DC=ru >> The user for the Windows PassSync service is >> uid=passsync,cn=sysaccounts,cn=etc,dc=test-csbi-its,dc=ru >> Windows PassSync entry exists, not resetting password >> ipa: INFO: Added new sync agreement, waiting for it to become ready . . . >> ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica >> acquired successfully: Incremental update started: start: 0: end: 0 >> ipa: INFO: Agreement is ready, starting replication . . . >> Starting replication, please wait until this has completed. >> Update in progress, 13 seconds elapsed >> [ipa.test-csbi-its.ru ] reports: Update >> failed! Status: [-1 Total update abortedLDAP error: Can't contact >> LDAP server] > > Can you connect from this replica to AD using ldapsearch? specifically $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-YOUR-DOMAIN ldapsearch -xLLL -ZZ -h fqdn.of.windows.machine -D "cn=administrator,cn=users,dc=csbigroup,dc=ru" -w "windows admin password" -s base -b "cn=users,dc=csbigroup,dc=ru" > >> >> Failed to start replication >> >> >> >> FreeIPA server version 3.3.3 >> OS version Centos 7 >> AD Domain 2012 >> >> Can you help me to resolve this problem? >> >> Best regards, Valeriy >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From orkhan-azeri at mail.ru Thu Oct 23 17:10:52 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Thu, 23 Oct 2014 22:10:52 +0500 Subject: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1. In-Reply-To: <20141023164019.GK5446@redhat.com> References: <54480E4B.2000207@cenic.org> <544902F5.7050908@mail.ru> <20141023134155.GH5446@redhat.com> <1414080833.731158339@f47.i.mail.ru> <20141023164019.GK5446@redhat.com> Message-ID: <45543293-80de-4f23-bdf2-65b047e11d80@email.bluemailapp.com> Very interesting! You're right, I used simple? "ldapsearch -x" command on the client when browsing the LDAP database. With IPA 3.3 it returned a whole lot of info about hostgroups, but with IPA 4.1 - only a single string 'cn=ng,cn=compat,$SUFFIX'. That's why current script didn't work. Tomorrow at work I'll try your advice, and if there's no another problem between the chair and the keyboard, I'll definitely stick with FreeIPA 4.1! ?????????? ?? Blue Mail ?? 21:40, 23.10.2014, ? 21:40, Alexander Bokovoy ???????:?>On Thu, 23 Oct 2014, ????? ??????? wrote: >> >>Alright then, thanks for info! >>Tomorrow is the deadline for my researches on FreeIPA. >>Then I have to start deploying a centralized management solution in >our production environment. >>Please help me to make a final decision on which version of FreeIPA to >choose - 3.3 or 4.1? >>I'd like to have all the benefits of the latest version, but all our >production servers are FreeBSD. >>With all information sources at my disposal right now I tend to choose >FreeIPA 3.3. >>The cause is that otherwise I can't use host groups with sudo commands >- >>the cron script proposed at FreeBSD forums works with old way of >storing host group information in the LDAP directory of FreeIPA. >>Is there any workaround for this? (P.S. Here's what I'm talking about: >>>" The tricky part was getting? sudo ?to work with host groups. >FreeIPA >>>keeps host groups in netgroups, and FreeBSD's support for netgroups >is >>>limited. One solution would have been to enable NIS services on the >>>FreeIPA server so that we could use proper netgroups on FreeBSD >>>clients. We didn't like that solution, so instead we wrote a script >>>that pulls all netgroup data from FreeIPA and stores it in? >>>/etc/netgroup . We run the script every hour via ?cron . " >>> >>>The script looks for host groups in >>>'cn=hostgroups,cn=accounts,dc=', and that works with FreeIPA >>>3.3. But in FreeIPA v4 host groups get in >>>'cn=ng,cn=compat,dc='. So the script needs modification. But >I >>>don't know how to modify the script, simply changing the string >passed >>>to the ldapsearch command doesn't work.) >I think you completely missed the way FreeIPA works. :) > >Host groups are always in cn=hostgroups,cn=accounts,$SUFFIX, no changes >were done. > >What you see in cn=ng,cn=compat,$SUFFIX are net groups for >compatibility >with older applications which expect old LDAP schema. The tree in >cn=compat,$SUFFIX is provided through schema compatibility plugin and >was also provided this way for quite a long time. > >What I think you are stumbling upon is the fact that starting with >FreeIPA 4.0 we are providing more fine-grained access control to the >data in LDAP tree. > >For example: >$ ipa permission-find >--subtree=cn=hostgroups,cn=accounts,dc=ipacloud,dc=test --right=read >--------------------- >2 permissions matched >--------------------- > Permission name: System: Read Hostgroup Membership > Granted rights: read, compare, search > Effective attributes: member, memberhost, memberof, memberuser > Default attributes: member, memberof, memberuser, memberhost > Bind rule type: all > Subtree: cn=hostgroups,cn=accounts,dc=ipacloud,dc=test > Type: hostgroup > > Permission name: System: Read Hostgroups > Granted rights: read, compare, search > Effective attributes: businesscategory, cn, createtimestamp, >description, entryusn, ipauniqueid, modifytimestamp, o, objectclass, >ou, >owner, seealso > Default attributes: cn, businesscategory, objectclass, description, o, >ipauniqueid, owner, ou, seealso > Bind rule type: all > Subtree: cn=hostgroups,cn=accounts,dc=ipacloud,dc=test > Type: hostgroup >---------------------------- >Number of entries returned 2 >---------------------------- > >As you can see, both permissions require bind rule type 'all' which >means 'all authenticated users'. > >On contrast, in schema compat tree you'll get the whole tree >anonymously > >$ ipa permission-find --target=cn=ng,cn=compat,dc=ipacloud,dc=test >--right=read >-------------------- >1 permission matched >-------------------- > Permission name: System: Read Netgroup Compat Tree > Granted rights: read, compare, search >Effective attributes: cn, createtimestamp, entryusn, membernisnetgroup, >modifytimestamp, nisnetgrouptriple, objectclass >Default attributes: objectclass, nisnetgrouptriple, membernisnetgroup, >cn > Bind rule type: anonymous > Subtree: dc=ipacloud,dc=test > Target DN: cn=ng,cn=compat,dc=ipacloud,dc=test >---------------------------- >Number of entries returned 1 >---------------------------- > >This means that your script should work as before, only that it needs >to >authenticate before connecting. As you run it as root, you can use host >keytab, try adding something like this: > >old_krb5_ccache=${KRB5_CCACHE} >KRB5_CCACHE=/tmp/_hostgroups_access.ccache.$$ >export KRB5_CCACHE >kinit -k -t /etc/krb5.keytab host/`hostname` ># perform actual search >ldapsearch -Y GSSAPI ..... > ># end of script >kdestroy >KRB5_CCACHE=${old_krb5_ccache} >export KRB5_CCACHE > >note that ldapsearch -Y GSSAPI will use Kerberos authentication when >talking to IPA LDAP server and use host/`hostname` principal for that. >This should be enough for allowing access to the host groups. > >-- >/ Alexander Bokovoy -------------- next part -------------- An HTML attachment was scrubbed... URL: From leszek.mis at gmail.com Thu Oct 23 17:29:46 2014 From: leszek.mis at gmail.com (crony) Date: Thu, 23 Oct 2014 19:29:46 +0200 Subject: [Freeipa-users] FreeIPA 3.3.3 and sssd segfault In-Reply-To: <20141023163015.GC7028@mail.corp.redhat.com> References: <20141023114507.GE28314@mail.corp.redhat.com> <20141023141045.GA7028@mail.corp.redhat.com> <20141023150927.GB7028@mail.corp.redhat.com> <20141023163015.GC7028@mail.corp.redhat.com> Message-ID: Oh, sorry Lukas, now its my mistake + tiredness.. I was testing on the wrong machine.Thank you. /lm 2014-10-23 18:30 GMT+02:00 Lukas Slebodnik : > On (23/10/14 18:12), crony wrote: > >Thank you! > > > I prepared repo for epel6, epel7 and fedora 19 > > >Error: Package: sssd-client-1.11.7-2.el7.centos.x86_64 > (lslebodn-sssd-1-11) > > Requires: libc.so.6(GLIBC_2.14)(64bit) > >Error: Package: python-sssdconfig-1.11.7-2.el7.centos.noarch > ^^^^ > you want to install package from epel7 > > >(lslebodn-sssd-1-11) > > Requires: python(abi) = 2.7 > > Installed: python-2.6.6-52.el6.x86_64 (@updates) > ^^^ > and machine is rhel6 (centos6) > > > python(abi) = 2.6 > > Available: python-2.6.6-51.el6.x86_64 (base) > > python(abi) = 2.6 > > > >Should I change the default python from RHEL7 for dependencies? It could > be > >destructive for my system ;-) > Are you sure you are using RHEL7 and not RHEL6? > > LS > -- Pozdrawiam Leszek Mi? www: http://cronylab.pl www: http://emerge.pl Nothing is secure, paranoia is your friend. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ctr2sprt at gmail.com Thu Oct 23 18:03:07 2014 From: ctr2sprt at gmail.com (Eric McCoy) Date: Thu, 23 Oct 2014 14:03:07 -0400 Subject: [Freeipa-users] Recovering from messed-up certs In-Reply-To: <544932A1.8030909@redhat.com> References: <544932A1.8030909@redhat.com> Message-ID: Some nicknames changed to protect the innocent. The puppetmaster/hostname cert is nominally unrelated, though its creation was contemporaneous with the disappearance of server-cert so I can't entirely rule it out. Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI puppetmaster/hostname u,u,u REALMNAME IPA CA CT,C,C ipaCert u,u,u Signing-Cert u,u,u On Thu, Oct 23, 2014 at 12:53 PM, Rob Crittenden wrote: > Eric McCoy wrote: > > Hi all, > > > > I somehow destroyed my primary IPA server's Server-Cert in > > /etc/httpd/alias. I don't understand how or why it happened, all I know > > is that I went to restart Apache and it was gone. Apache won't start, > > of course, because the cert is missing. I can't issue a new cert on the > > primary because Apache is down. I tried using the secondary, but it > > fails saying that it can't connect to the web server on the primary > > (it's the same error message I get when I try to issue a cert from the > > primary). I can't figure out how to tell ipa-getcert et al. to talk to > > the secondary and not the primary. I'm not using DNS for service > > discovery, so I'm not sure how the various tools figure out where things > > are. > > > > This is all on CentOS 6.5 with IPA 3.0.0-37. > > > > > > What certs do you have in the database? > > # certutil -L -d /etc/httpd/alias > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Oct 23 20:05:35 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 23 Oct 2014 16:05:35 -0400 Subject: [Freeipa-users] Recovering from messed-up certs In-Reply-To: References: <544932A1.8030909@redhat.com> Message-ID: <54495F8F.1030504@redhat.com> Eric McCoy wrote: > Some nicknames changed to protect the innocent. The > puppetmaster/hostname cert is nominally unrelated, though its creation > was contemporaneous with the disappearance of server-cert so I can't > entirely rule it out. > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > puppetmaster/hostname u,u,u > REALMNAME IPA CA CT,C,C > ipaCert u,u,u > Signing-Cert u,u,u Ok, this is good. If we have ipaCert we can get a cert directly from the CA like we do during installation. The attached python script should fix things up for you. Save it, modify it and replace subjectbase with what matches your environment. You can get the base from an existing cert with: # certutil -L -d /etc/dirsrv/slapd-REALM -n Server-Cert |grep Subject Unless you changed it during installation it should be O= Then just run the script: # python newcert.py Initializing API Setting up NSS databases Untracking existing Apache Server-Cert Issuing new cert Tracking Server-Cert # service httpd start The only thing this script doesn't do is put this updated certificate in the service record's LDAP entry. rob > > > On Thu, Oct 23, 2014 at 12:53 PM, Rob Crittenden > wrote: > > Eric McCoy wrote: > > Hi all, > > > > I somehow destroyed my primary IPA server's Server-Cert in > > /etc/httpd/alias. I don't understand how or why it happened, all > I know > > is that I went to restart Apache and it was gone. Apache won't start, > > of course, because the cert is missing. I can't issue a new cert > on the > > primary because Apache is down. I tried using the secondary, but it > > fails saying that it can't connect to the web server on the primary > > (it's the same error message I get when I try to issue a cert from the > > primary). I can't figure out how to tell ipa-getcert et al. to > talk to > > the secondary and not the primary. I'm not using DNS for service > > discovery, so I'm not sure how the various tools figure out where > things > > are. > > > > This is all on CentOS 6.5 with IPA 3.0.0-37. > > > > > > What certs do you have in the database? > > # certutil -L -d /etc/httpd/alias > > rob > > -------------- next part -------------- A non-text attachment was scrubbed... Name: newcert.py Type: text/x-python Size: 769 bytes Desc: not available URL: From mlasevich at gmail.com Fri Oct 24 00:15:15 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Thu, 23 Oct 2014 17:15:15 -0700 Subject: [Freeipa-users] Inconsistent group memberships in sssd Message-ID: FreeIPA 4.0.3 server with SSSD 1.9.2 on CentOS6 Seems that group membership is completely inconsistent Running "id" in shell as my user on: * ipa server - I am a member of 2 groups * Server that just came up and joined - 1 group * Server that has been up for some time - 5 groups Via UI: Member of 7 groups directly and 1 indirect Gets weirder - I added a line to sudoers file (not ipa sudo support, can't get that to work) allowing certain group I am a member of. If I run sudo as the user - i get rejected as not being in sudoers, however if I run check as root: sudo -l -U username I see that I should be allowed. More wierdness, If I do "getent group " - it shows me as a member - but I do not recall having this much trouble with same sssd and 3.0 server :-( Any thoughts? -M -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlasevich at gmail.com Fri Oct 24 00:19:38 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Thu, 23 Oct 2014 17:19:38 -0700 Subject: [Freeipa-users] Inconsistent group memberships in sssd In-Reply-To: References: Message-ID: Small update, it appears that once I run "getent group " - my user shows up in the group . Odd. (and yes, I have ran "sss_cache -UG" many a time) -M On Thu, Oct 23, 2014 at 5:15 PM, Michael Lasevich wrote: > FreeIPA 4.0.3 server with SSSD 1.9.2 on CentOS6 > > Seems that group membership is completely inconsistent > > Running "id" in shell as my user on: > * ipa server - I am a member of 2 groups > * Server that just came up and joined - 1 group > * Server that has been up for some time - 5 groups > > Via UI: Member of 7 groups directly and 1 indirect > > Gets weirder - I added a line to sudoers file (not ipa sudo support, can't > get that to work) allowing certain group I am a member of. If I run sudo as > the user - i get rejected as not being in sudoers, however if I run check > as root: > > sudo -l -U username > > I see that I should be allowed. > > More wierdness, If I do "getent group " - it shows me as a > member - but > I do not recall having this much trouble with same sssd and 3.0 server :-( > > Any thoughts? > > -M > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Fri Oct 24 00:36:15 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 24 Oct 2014 10:36:15 +1000 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <1414059167.879585640@f414.i.mail.ru> References: <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> <20141023075832.GA28314@mail.corp.redhat.com> <1414059167.879585640@f414.i.mail.ru> Message-ID: <20141024003615.GH21514@dhcp-40-8.bne.redhat.com> On Thu, Oct 23, 2014 at 02:12:47PM +0400, ????? ??????? wrote: > +1. > And even if talking about installation of the necessary software and not about the configuration, then why this? > > " The commands to enable the custom repository and install the required packages on a FreeBSD host appear below. > Note that these are? Bourne ?shell commands; this script will not work in the FreeBSD default shell? csh . " > > After having baked ONE SET OF DEFAULTS into a custom package (to make our lives easier), you leave readers to mess with ANOTHER SET OF DEFAULTS, i.e. to change?FreeBSD's shells? > It is only for that one script (because csh heredocs are weird). There is no need whatsoever for a chsh; just that one script needs to be executed in /bin/sh. I will clarify this in the post. > Aren't there some discrepancies??It may be simple / useful / interesting to change shells, but why not make a self-sufficient article? > Please update your article to provide a full picture of what a user should do to install all necessary software, and also which parts should be installed from your repo, and which parts should be installed from ports (+ the correct order). > You've already done a lot of work, but with this refinement your help will be even more valuable. > I'm not asking for myself personally (I've already accomplished all necessary tasks) - just IMHO everyone writing?instructions, tutorials and HowTos for the *nix world should stick to the rule: articles should be self-sufficient. > I.e. if they rely on techniques not detailed in them,?they should at least include links to other WORKING articles to ensure that a reader will be able to COMPLETE a task. > Thanks for your contribution, Fraser. > > > > Thu, 23 Oct 2014 09:58:33 +0200 ?? Lukas Slebodnik : > >On (23/10/14 11:27), Outback Dingo wrote: > >>On Thu, Oct 23, 2014 at 11:20 AM, Fraser Tweedale < ftweedal at redhat.com > > >>wrote: > >> > >>> On Wed, Oct 22, 2014 at 03:23:56PM +0200, Lukas Slebodnik wrote: > >>> > On (22/10/14 17:10), Fraser Tweedale wrote: > >>> > >Further to my earlier email, I have written a blog post about all > >>> > >these matters, with a particular focus on the custom package repo. > >>> > > > >>> > >I will update it tomorrow with a bit more about the package > >>> > >"flavours" topic. For now, all the details for enabling and using > >>> > >the custom repo are in the post. Check it out and let me know if > >>> > >you spot any issues. > >>> > > > >>> > > > >>> http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/ > >>> > > > >>> > The disadvantage of this approach is that users need to rely on updating > >>> > of non standard repo. https://frase.id.au/pkg/${ABI}_FreeIPA > >>> > > >>> > In my opinion, it's better to write howto (script) which will configure > >>> all > >>> > necessary ports/files and portmaster will take care of updating ports. > >>> > https://www.freebsd.org/doc/handbook/ports-using.html#portmaster > >>> > > >>> > LS > >>> > >>> Each has its advantages and disadvantages; people can choose what > >>> works for them. Hopefully - not too far in the future - people > >>> won't have to choose, when binary package "flavours" are > >>> implemented. When that happens, a small effort will be needed to > >>> define the FreeIPA flavour and ensure it gets included in the > >>> official package repos. > >>> > >Fraser you missed one main point of this thread. The most problematic was > >to *configure* all files and not install sssd. I don't want to say that > >installing is super easy, but configuration is much more complicated. > > > >> > >>Actually I would be inclined to assist with a ports build, so it could be > >>done correctly from the ports tree > >>and work towards having it adopted into mainline. > >> > >+1 > > > >LS > > > >-- > >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 > From ftweedal at redhat.com Fri Oct 24 00:42:03 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 24 Oct 2014 10:42:03 +1000 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141023075832.GA28314@mail.corp.redhat.com> References: <20141020080128.GA14974@mail.corp.redhat.com> <5444DE8A.4000304@mail.ru> <20141021183116.GG31312@mail.corp.redhat.com> <20141022020628.GH5346@dhcp-40-8.bne.redhat.com> <54472ED7.1000800@mail.ru> <20141022071055.GK5346@dhcp-40-8.bne.redhat.com> <20141022132355.GA4312@mail.corp.redhat.com> <20141023002040.GM5346@dhcp-40-8.bne.redhat.com> <20141023075832.GA28314@mail.corp.redhat.com> Message-ID: <20141024004203.GI21514@dhcp-40-8.bne.redhat.com> On Thu, Oct 23, 2014 at 09:58:33AM +0200, Lukas Slebodnik wrote: > On (23/10/14 11:27), Outback Dingo wrote: > >On Thu, Oct 23, 2014 at 11:20 AM, Fraser Tweedale > >wrote: > > > >> On Wed, Oct 22, 2014 at 03:23:56PM +0200, Lukas Slebodnik wrote: > >> > On (22/10/14 17:10), Fraser Tweedale wrote: > >> > >Further to my earlier email, I have written a blog post about all > >> > >these matters, with a particular focus on the custom package repo. > >> > > > >> > >I will update it tomorrow with a bit more about the package > >> > >"flavours" topic. For now, all the details for enabling and using > >> > >the custom repo are in the post. Check it out and let me know if > >> > >you spot any issues. > >> > > > >> > > > >> http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/ > >> > > > >> > The disadvantage of this approach is that users need to rely on updating > >> > of non standard repo. https://frase.id.au/pkg/${ABI}_FreeIPA > >> > > >> > In my opinion, it's better to write howto (script) which will configure > >> all > >> > necessary ports/files and portmaster will take care of updating ports. > >> > https://www.freebsd.org/doc/handbook/ports-using.html#portmaster > >> > > >> > LS > >> > >> Each has its advantages and disadvantages; people can choose what > >> works for them. Hopefully - not too far in the future - people > >> won't have to choose, when binary package "flavours" are > >> implemented. When that happens, a small effort will be needed to > >> define the FreeIPA flavour and ensure it gets included in the > >> official package repos. > >> > Fraser you missed one main point of this thread. The most problematic was > to *configure* all files and not install sssd. I don't want to say that > installing is super easy, but configuration is much more complicated. > I haven't missed that point at all. In the post I am up front about the difficulty and room for error in configuring all the services, and in the conclusion I talk about the scope for further work with a port of ipa-client-install. I will clarify the post to try and make it clearer that it focuses on the installation aspect of the setup and leaves other aspects for another day. Thanks for your feedback, Fraser > > > >Actually I would be inclined to assist with a ports build, so it could be > >done correctly from the ports tree > >and work towards having it adopted into mainline. > > > +1 > > LS From dprostran at monexa.com Fri Oct 24 02:36:58 2014 From: dprostran at monexa.com (Dragan Prostran) Date: Thu, 23 Oct 2014 19:36:58 -0700 Subject: [Freeipa-users] Third party SSL certificate renewal Message-ID: Hello, This is my first time posting to this list, so if I've made a faux pas or mistake, please do correct me. Can anyone please point me to the correct method to renewing 3rd party SSL certificates used by FreeIPA 3.0? I suspect I've not done this correctly. Here is what has worked correctly so far: 1. FreeIPA is installed and configured to work correctly. It uses 3rd party SSL certificates. I have access to the CSR, the certificate, the private key, and the new CA bundle. 2. I have successfully followed these instructions to update the SSL certificates used by Apache to serve the FreeIPA web interface: http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP. Of note is that there are 2 IPA servers, and the procedure has been followed on both. 3. Upon visiting the FreeIPA web interface, I can see that the certificate is valid, and expires in the future. Login to FreeIPA and modifying (for example) an LDAP password, work correctly. 4. 3rd party services that take advantage of LDAP work correctly. I can login and authenticate via LDAP. Here is what does not work correctly: 1. A distinct, 3rd party webservice that takes advantage of LDAP *via SSL* no longer is able to authenticate. Prior to certificate update mentioned, this did work correctly. I must admit I'm unfamiliar with LDAP (via SSL), and so instead of troubleshooting that service, I had a closer look at the FreeIPA instance. 2. When connected to the FreeIPA instance, and issuing 'ipa user-status username', the following error is returned: ipa: ERROR: cert validation failed for "CN=CERT_CN_REDACTED,OU=Domain Control Validated" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) ipa: ERROR: cert validation failed for "CN=CERT_CN_REDACTED,OU=Domain Control Validated" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) ipa: ERROR: cannot connect to Gettext('any of the configured servers', domain='ipa', localedir=None): https://IPA1_FQDN_REDACTED/ipa/xml, https://IPA2_FQDN_REDACTED/ipa/xml Note that, CERT_CN_REDACTED is the *.domain.tld cert that has been renewed. Of note is that, prior to the certificate update noted above, this did work correctly, and would return the status of the user. Further, when issuing 'ipa service restart' on the IPA instance, the following is returned: # service ipa restart Restarting Directory Service Shutting down dirsrv: DIRSRV_REDACTED... [ OK ] Starting dirsrv: DIRSRV_REDACTED...[21/Oct/2014:19:07:22 -0700] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert CERT_CN_REDACTED - GoDaddy.com, Inc. of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8172 - Peer's certificate issuer has been marked as not trusted by the user.) [ OK ] Restarting KDC Service Stopping Kerberos 5 KDC: [ OK ] Starting Kerberos 5 KDC: [ OK ] Restarting KPASSWD Service Stopping Kerberos 5 Admin Server: [ OK ] Starting Kerberos 5 Admin Server: [ OK ] Restarting MEMCACHE Service Stopping ipa_memcached: [ OK ] Starting ipa_memcached: [ OK ] Restarting HTTP Service Stopping httpd: [ OK ] Starting httpd: [ OK ] # Can anyone instruct me as to what may be misconfigured? I assume this is the root cause of LDAP via SSL not working correctly, but I'm not quite sure how to verify that. It is of note to say that the CA bundle (a chain of public keys leading to a root, 3rd party CA) issued with the new certificate is different from the previous certificate bundle. I know this as I have records of the original certificate, key, bundle, and CSR. The CA bundle issued with this new certificate is *different* from the CA bundle used with the original certificate. As I have not provided, or otherwise used, this new CA bundle when renewing the certificates in FreeIPA, I suspect this is the root cause of the error, and so I ask for help here. --- Dragan Prostran From orkhan-azeri at mail.ru Fri Oct 24 02:42:31 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Fri, 24 Oct 2014 07:42:31 +0500 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: <20141024003615.GH21514@dhcp-40-8.bne.redhat.com> References: <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> <20141023075832.GA28314@mail.corp.redhat.com> <1414059167.879585640@f414.i.mail.ru> <20141024003615.GH21514@dhcp-40-8.bne.redhat.com> Message-ID: You could ease everything by creating 2 files: FreeIPA.conf and FreeIPA.pem, uploading them to Web and sharing links to them. FreeBSD users could the use the "fetch" command to download and use your files. ?????????? ?? Blue Mail ?? 5:36, 24.10.2014, ? 5:36, Fraser Tweedale ???????:?>On Thu, Oct 23, 2014 at 02:12:47PM +0400, ????? ??????? wrote: >> +1. >> And even if talking about installation of the necessary software and >not about the configuration, then why this? >> >> " The commands to enable the custom repository and install the >required packages on a FreeBSD host appear below. >> Note that these are? Bourne ?shell commands; this script will not >work in the FreeBSD default shell? csh . " >> >> After having baked ONE SET OF DEFAULTS into a custom package (to make >our lives easier), you leave readers to mess with ANOTHER SET OF >DEFAULTS, i.e. to change?FreeBSD's shells? >> >It is only for that one script (because csh heredocs are weird). >There is no need whatsoever for a chsh; just that one script needs >to be executed in /bin/sh. I will clarify this in the post. > >> Aren't there some discrepancies??It may be simple / useful / >interesting to change shells, but why not make a self-sufficient >article? >> Please update your article to provide a full picture of what a user >should do to install all necessary software, and also which parts >should be installed from your repo, and which parts should be installed >from ports (+ the correct order). >> You've already done a lot of work, but with this refinement your help >will be even more valuable. >> I'm not asking for myself personally (I've already accomplished all >necessary tasks) - just IMHO everyone writing?instructions, tutorials >and HowTos for the *nix world should stick to the rule: articles should >be self-sufficient. >> I.e. if they rely on techniques not detailed in them,?they should at >least include links to other WORKING articles to ensure that a reader >will be able to COMPLETE a task. >> Thanks for your contribution, Fraser. >> >> >> >> Thu, 23 Oct 2014 09:58:33 +0200 ?? Lukas Slebodnik >: >> >On (23/10/14 11:27), Outback Dingo wrote: >> >>On Thu, Oct 23, 2014 at 11:20 AM, Fraser Tweedale < >ftweedal at redhat.com > >> >>wrote: >> >> >> >>> On Wed, Oct 22, 2014 at 03:23:56PM +0200, Lukas Slebodnik wrote: >> >>> > On (22/10/14 17:10), Fraser Tweedale wrote: >> >>> > >Further to my earlier email, I have written a blog post about >all >> >>> > >these matters, with a particular focus on the custom package >repo. >> >>> > > >> >>> > >I will update it tomorrow with a bit more about the package >> >>> > >"flavours" topic. For now, all the details for enabling and >using >> >>> > >the custom repo are in the post. Check it out and let me know >if >> >>> > >you spot any issues. >> >>> > > >> >>> > > >> >>> >http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/ >> >>> > > >> >>> > The disadvantage of this approach is that users need to rely on >updating >> >>> > of non standard repo. https://frase.id.au/pkg/${ABI}_FreeIPA >> >>> > >> >>> > In my opinion, it's better to write howto (script) which will >configure >> >>> all >> >>> > necessary ports/files and portmaster will take care of updating >ports. >> >>> > >https://www.freebsd.org/doc/handbook/ports-using.html#portmaster >> >>> > >> >>> > LS >> >>> >> >>> Each has its advantages and disadvantages; people can choose what >> >>> works for them. Hopefully - not too far in the future - people >> >>> won't have to choose, when binary package "flavours" are >> >>> implemented. When that happens, a small effort will be needed to >> >>> define the FreeIPA flavour and ensure it gets included in the >> >>> official package repos. >> >>> >> >Fraser you missed one main point of this thread. The most >problematic was >> >to *configure* all files and not install sssd. I don't want to say >that >> >installing is super easy, but configuration is much more >complicated. >> > >> >> >> >>Actually I would be inclined to assist with a ports build, so it >could be >> >>done correctly from the ports tree >> >>and work towards having it adopted into mainline. >> >> >> >+1 >> > >> >LS >> > >> >-- >> >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 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Fri Oct 24 03:01:48 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 24 Oct 2014 13:01:48 +1000 Subject: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server In-Reply-To: References: <5c9a5fa2-7b0f-42bd-94f6-103823f29951@email.bluemailapp.com> <20141023075832.GA28314@mail.corp.redhat.com> <1414059167.879585640@f414.i.mail.ru> <20141024003615.GH21514@dhcp-40-8.bne.redhat.com> Message-ID: <20141024030148.GK21514@dhcp-40-8.bne.redhat.com> On Fri, Oct 24, 2014 at 07:42:31AM +0500, Orkhan Gasimov wrote: > You could ease everything by creating 2 files: FreeIPA.conf and > FreeIPA.pem, uploading them to Web and sharing links to them. > FreeBSD users could the use the "fetch" command to download and > use your files. > I turned it into a shell script instead, with the appropriate #!/bin/sh so it doesn't matter what shell they invoke it from. Regards, Fraser > ?????????? ?? Blue Mail > > > > ?? 5:36, 24.10.2014, ? 5:36, Fraser Tweedale ???????:?>On Thu, Oct 23, 2014 at 02:12:47PM +0400, ????? ??????? wrote: > >> +1. > >> And even if talking about installation of the necessary software and > >not about the configuration, then why this? > >> > >> " The commands to enable the custom repository and install the > >required packages on a FreeBSD host appear below. > >> Note that these are? Bourne ?shell commands; this script will not > >work in the FreeBSD default shell? csh . " > >> > >> After having baked ONE SET OF DEFAULTS into a custom package (to make > >our lives easier), you leave readers to mess with ANOTHER SET OF > >DEFAULTS, i.e. to change?FreeBSD's shells? > >> > >It is only for that one script (because csh heredocs are weird). > >There is no need whatsoever for a chsh; just that one script needs > >to be executed in /bin/sh. I will clarify this in the post. > > > >> Aren't there some discrepancies??It may be simple / useful / > >interesting to change shells, but why not make a self-sufficient > >article? > >> Please update your article to provide a full picture of what a user > >should do to install all necessary software, and also which parts > >should be installed from your repo, and which parts should be installed > >from ports (+ the correct order). > >> You've already done a lot of work, but with this refinement your help > >will be even more valuable. > >> I'm not asking for myself personally (I've already accomplished all > >necessary tasks) - just IMHO everyone writing?instructions, tutorials > >and HowTos for the *nix world should stick to the rule: articles should > >be self-sufficient. > >> I.e. if they rely on techniques not detailed in them,?they should at > >least include links to other WORKING articles to ensure that a reader > >will be able to COMPLETE a task. > >> Thanks for your contribution, Fraser. > >> > >> > >> > >> Thu, 23 Oct 2014 09:58:33 +0200 ?? Lukas Slebodnik > >: > >> >On (23/10/14 11:27), Outback Dingo wrote: > >> >>On Thu, Oct 23, 2014 at 11:20 AM, Fraser Tweedale < > >ftweedal at redhat.com > > >> >>wrote: > >> >> > >> >>> On Wed, Oct 22, 2014 at 03:23:56PM +0200, Lukas Slebodnik wrote: > >> >>> > On (22/10/14 17:10), Fraser Tweedale wrote: > >> >>> > >Further to my earlier email, I have written a blog post about > >all > >> >>> > >these matters, with a particular focus on the custom package > >repo. > >> >>> > > > >> >>> > >I will update it tomorrow with a bit more about the package > >> >>> > >"flavours" topic. For now, all the details for enabling and > >using > >> >>> > >the custom repo are in the post. Check it out and let me know > >if > >> >>> > >you spot any issues. > >> >>> > > > >> >>> > > > >> >>> > >http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/ > >> >>> > > > >> >>> > The disadvantage of this approach is that users need to rely on > >updating > >> >>> > of non standard repo. https://frase.id.au/pkg/${ABI}_FreeIPA > >> >>> > > >> >>> > In my opinion, it's better to write howto (script) which will > >configure > >> >>> all > >> >>> > necessary ports/files and portmaster will take care of updating > >ports. > >> >>> > > >https://www.freebsd.org/doc/handbook/ports-using.html#portmaster > >> >>> > > >> >>> > LS > >> >>> > >> >>> Each has its advantages and disadvantages; people can choose what > >> >>> works for them. Hopefully - not too far in the future - people > >> >>> won't have to choose, when binary package "flavours" are > >> >>> implemented. When that happens, a small effort will be needed to > >> >>> define the FreeIPA flavour and ensure it gets included in the > >> >>> official package repos. > >> >>> > >> >Fraser you missed one main point of this thread. The most > >problematic was > >> >to *configure* all files and not install sssd. I don't want to say > >that > >> >installing is super easy, but configuration is much more > >complicated. > >> > > >> >> > >> >>Actually I would be inclined to assist with a ports build, so it > >could be > >> >>done correctly from the ports tree > >> >>and work towards having it adopted into mainline. > >> >> > >> >+1 > >> > > >> >LS > >> > > >> >-- > >> >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 > >> From mlasevich at gmail.com Fri Oct 24 03:17:30 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Thu, 23 Oct 2014 20:17:30 -0700 Subject: [Freeipa-users] Errors upgrading 4.0.1 to 4.1 Message-ID: While upgrading from 4.0.1. to 4.1 on fedora 20 got following on one of the two boxes: Upgrade failed with attribute "allowWeakCipher" not allowed IPA upgrade failed. Unexpected error DuplicateEntry: This entry already exists It seems the ipa no longer starts up after this. The replica server seems to have had same error,but it runs just fine. >From digging around, it appears that there are a number of GSS errors in dirsrv and bind fails with something like: named-pkcs11[2212]: ObjectStore.cpp(74): Failed to open token e919db16-6329-406c-6ae4-120ad68508c4 named-pkcs11[2212]: sha1.c:92: fatal error: named-pkcs11[2212]: RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, isc_boolean_true, isc_boolean_false, isc_boolean_false, ((void *)0), 0) == 0) failed Any help would be appreciated -M -------------- next part -------------- An HTML attachment was scrubbed... URL: From orkhan-azeri at mail.ru Fri Oct 24 06:57:05 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Fri, 24 Oct 2014 11:57:05 +0500 Subject: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1. In-Reply-To: <20141023164019.GK5446@redhat.com> References: <54480E4B.2000207@cenic.org> <544902F5.7050908@mail.ru> <20141023134155.GH5446@redhat.com> <1414080833.731158339@f47.i.mail.ru> <20141023164019.GK5446@redhat.com> Message-ID: <5449F841.7010705@mail.ru> Awesome, it worked! Just one final question: how to make that script search not only in ipa1.example.com's LDAP database, but also in ipa2.example.com's LDAP in case ipa1 is inaccessible? It's vital for a production environment! I tried copying the whole section of code from " ldapsearch ..." to "... done" and putting it after a new instance of " if [ ! -s "$tmpf" ]; then ", but it didn't work (I'm not a programmer...). My current cron script is like this: https://cloud.mail.ru/public/fdf2e60c5df8%2Fsudo.sh Programmers, please take a glance at the file - logically it shouldn't be difficult to make necessary modifications, but I don't know how... 23-Oct-14 21:40, Alexander Bokovoy ?????: > try adding something like this: > > old_krb5_ccache=${KRB5_CCACHE} > KRB5_CCACHE=/tmp/_hostgroups_access.ccache.$$ > export KRB5_CCACHE > kinit -k -t /etc/krb5.keytab host/`hostname` > # perform actual search > ldapsearch -Y GSSAPI ..... > > # end of script > kdestroy > KRB5_CCACHE=${old_krb5_ccache} > export KRB5_CCACHE -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Oct 24 07:43:21 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 24 Oct 2014 10:43:21 +0300 Subject: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1. In-Reply-To: <5449F841.7010705@mail.ru> References: <54480E4B.2000207@cenic.org> <544902F5.7050908@mail.ru> <20141023134155.GH5446@redhat.com> <1414080833.731158339@f47.i.mail.ru> <20141023164019.GK5446@redhat.com> <5449F841.7010705@mail.ru> Message-ID: <20141024074321.GM5446@redhat.com> On Fri, 24 Oct 2014, Orkhan Gasimov wrote: >Awesome, it worked! > >Just one final question: how to make that script search not only in >ipa1.example.com's LDAP database, but also in ipa2.example.com's LDAP >in case ipa1 is inaccessible? It's vital for a production environment! There are two things here: - ldapsearch should use DNS SRV records to discover servers - ldapsearch call should rotate over all servers in case of an error First is achieved with -H option if you don't specify a host but rather use DN: dc=example,dc=com, encoded in a way of RFC 2396: dc%3Dexample%2Cdc%3Dcom where %3D is escape sequence for '=' and %2C is escape sequence for ',' ldapsearch -H ldap://dc%3Dexample%2Cdc%3Dcom would request ldapsearch to first go and resolve DNS SRV record _ldap._tcp.example.com and then connect to the list of servers returned. All tools from OpenLDAP client side use this technique and rotate over list of servers. You can specify multiple servers yourself too as -H "ldap://ipa1.example.com ldap://ipa2.example.com ldap://ipa3.example.com" but using DNS SRV records is more reliable because you don't need to change your script when you decommission the servers. > >I tried copying the whole section of code from " ldapsearch ..." to >"... done" >and putting it after a new instance of " if [ ! -s "$tmpf" ]; then ", >but it didn't work (I'm not a programmer...). > >My current cron script is like this: >https://cloud.mail.ru/public/fdf2e60c5df8%2Fsudo.sh > >Programmers, please take a glance at the file - logically it shouldn't >be difficult to make necessary modifications, >but I don't know how... > > >23-Oct-14 21:40, Alexander Bokovoy ?????: >>try adding something like this: >> >>old_krb5_ccache=${KRB5_CCACHE} >>KRB5_CCACHE=/tmp/_hostgroups_access.ccache.$$ >>export KRB5_CCACHE >>kinit -k -t /etc/krb5.keytab host/`hostname` >># perform actual search >>ldapsearch -Y GSSAPI ..... >> >># end of script >>kdestroy >>KRB5_CCACHE=${old_krb5_ccache} >>export KRB5_CCACHE > -- / Alexander Bokovoy From mkosek at redhat.com Fri Oct 24 07:44:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 24 Oct 2014 09:44:00 +0200 Subject: [Freeipa-users] Errors upgrading 4.0.1 to 4.1 In-Reply-To: References: Message-ID: <544A0340.8050702@redhat.com> On 10/24/2014 05:17 AM, Michael Lasevich wrote: > While upgrading from 4.0.1. to 4.1 on fedora 20 got following on one of the two > boxes: > > Upgrade failed with attribute "allowWeakCipher" not allowed > IPA upgrade failed. > Unexpected error > DuplicateEntry: This entry already exists > > > It seems the ipa no longer starts up after this. The replica server seems to > have had same error,but it runs just fine. > > From digging around, it appears that there are a number of GSS errors in > dirsrv and bind fails with something like: > > named-pkcs11[2212]: ObjectStore.cpp(74): Failed to open token > e919db16-6329-406c-6ae4-120ad68508c4 > named-pkcs11[2212]: sha1.c:92: fatal error: > named-pkcs11[2212]: RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, > isc_boolean_true, isc_boolean_false, isc_boolean_false, ((void *)0), 0) == 0) > failed > > Any help would be appreciated > > > -M What Directory Server version do you use? This is an attribute introduced in 389-ds-base 1.3.3+ which should be included in the FreeIPA Copr (DS 1.3.3 is native to F21+). CCing Ludwig to advise further. Thanks, Martin From jhrozek at redhat.com Fri Oct 24 07:51:41 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 24 Oct 2014 09:51:41 +0200 Subject: [Freeipa-users] Inconsistent group memberships in sssd In-Reply-To: References: Message-ID: <20141024075141.GA17667@hendrix.redhat.com> On Thu, Oct 23, 2014 at 05:19:38PM -0700, Michael Lasevich wrote: > Small update, it appears that once I run "getent group " - my > user shows up in the group . Odd. > > (and yes, I have ran "sss_cache -UG" many a time) > > -M One particular change in IPA 4.x that might be giving old clients headache is the new permission system. Only clean installs or replicas of 6.6 (or newer) servers are guaranteed to work with old clients. How was your IPA 4.0.3 server installed? What is the 389-ds-base version you're running? Any chance you can try a newer SSSD on your CentOS6 client? I have a COPR repo with the latest 1.11 branch here: http://copr-fe.cloud.fedoraproject.org/coprs/jhrozek/SSSD-1.11-RHEL6/ From mlasevich at gmail.com Fri Oct 24 08:31:03 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Fri, 24 Oct 2014 01:31:03 -0700 Subject: [Freeipa-users] Inconsistent group memberships in sssd In-Reply-To: <20141024075141.GA17667@hendrix.redhat.com> References: <20141024075141.GA17667@hendrix.redhat.com> Message-ID: It was a clean install of 4.0.1(not 4.0.3, I was wrong). I have upgraded to 4.1 and have not yet seen the problem recur - though I have not tested it much yet. On Oct 24, 2014 12:53 AM, "Jakub Hrozek" wrote: > On Thu, Oct 23, 2014 at 05:19:38PM -0700, Michael Lasevich wrote: > > Small update, it appears that once I run "getent group " - my > > user shows up in the group . Odd. > > > > (and yes, I have ran "sss_cache -UG" many a time) > > > > -M > > One particular change in IPA 4.x that might be giving old clients > headache is the new permission system. Only clean installs or replicas > of 6.6 (or newer) servers are guaranteed to work with old clients. > > How was your IPA 4.0.3 server installed? What is the 389-ds-base version > you're running? > > Any chance you can try a newer SSSD on your CentOS6 client? I have a > COPR repo with the latest 1.11 branch here: > http://copr-fe.cloud.fedoraproject.org/coprs/jhrozek/SSSD-1.11-RHEL6/ > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From orkhan-azeri at mail.ru Fri Oct 24 09:24:40 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Fri, 24 Oct 2014 14:24:40 +0500 Subject: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1. In-Reply-To: <20141024074321.GM5446@redhat.com> References: <54480E4B.2000207@cenic.org> <544902F5.7050908@mail.ru> <20141023134155.GH5446@redhat.com> <1414080833.731158339@f47.i.mail.ru> <20141023164019.GK5446@redhat.com> <5449F841.7010705@mail.ru> <20141024074321.GM5446@redhat.com> Message-ID: <544A1AD8.9080406@mail.ru> Thanks, this option worked in that script! 24-Oct-14 12:43, Alexander Bokovoy ?????: > You can specify multiple servers yourself too as > > -H "ldap://ipa1.example.com ldap://ipa2.example.com > ldap://ipa3.example.com" From orkhan-azeri at mail.ru Fri Oct 24 12:27:39 2014 From: orkhan-azeri at mail.ru (=?UTF-8?B?0J7RgNGF0LDQvSDQmtCw0YHRg9C80L7Qsg==?=) Date: Fri, 24 Oct 2014 16:27:39 +0400 Subject: [Freeipa-users] =?utf-8?q?Radius_schema_addition_to_default_user_?= =?utf-8?q?objectclasses_in_FreeIPA_4=2E1?= Message-ID: <1414153659.837745408@f356.i.mail.ru> New task:?I want to add an additional schema (radius schema) to default user object classes. I prepared the ldif-file for the schema:? https://cloud.mail.ru/public/40edc9a6c9bb%2Fradiusschema.ldif ?, then followed instructions in? https://www.redhat.com/archives/freeipa-users/2014-February/msg00050.html ? At step #2 of the instructions, ldapmodify command was run; as I'm?using FreeIPA 4.1?in a multi-master replication scenario with 2 servers, the command was run?on both servers and produced this output on both: ? ?modifying entry "cn=schema" Then I switched to GUI and added "radiusprofile" objectclass. After hitting the "Update" button?I got the message:? "IPA Error 4001: NotFound objectclass radiusprofile not found" Restarting ipactl didn't help. Command "ldapsearch -Y GSSAPI | grep schema" gives no output besides informational SASL messages. There is a "MUST cn" part in the objectclass definition in the ldif-file, but even after removing it the situation doesn't change. Please help me to understand where is the problem, and is it generally possible to use radius.schema with FreeIPA? The original schema was taken from:? http://open.rhx.it/phamm/schema/radius.schema ? Thanks in advance! -- ????? ??????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Fri Oct 24 13:12:08 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 24 Oct 2014 15:12:08 +0200 Subject: [Freeipa-users] Third party SSL certificate renewal In-Reply-To: References: Message-ID: <544A5028.70100@redhat.com> Hi, Dne 24.10.2014 v 04:36 Dragan Prostran napsal(a): > Hello, > > This is my first time posting to this list, so if I've made a faux pas > or mistake, please do correct me. > > Can anyone please point me to the correct method to renewing 3rd party > SSL certificates used by FreeIPA 3.0? I suspect I've not done this > correctly. > > Here is what has worked correctly so far: > 1. FreeIPA is installed and configured to work correctly. It uses 3rd > party SSL certificates. I have access to the CSR, the certificate, the > private key, and the new CA bundle. > 2. I have successfully followed these instructions to update the SSL > certificates used by Apache to serve the FreeIPA web interface: > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP. > Of note is that there are 2 IPA servers, and the procedure has been > followed on both. > 3. Upon visiting the FreeIPA web interface, I can see that the > certificate is valid, and expires in the future. Login to FreeIPA and > modifying (for example) an LDAP password, work correctly. > 4. 3rd party services that take advantage of LDAP work correctly. I > can login and authenticate via LDAP. > > Here is what does not work correctly: > 1. A distinct, 3rd party webservice that takes advantage of LDAP *via > SSL* no longer is able to authenticate. Prior to certificate update > mentioned, this did work correctly. I must admit I'm unfamiliar with > LDAP (via SSL), and so instead of troubleshooting that service, I had > a closer look at the FreeIPA instance. The 3rd party webservice needs to trust the CA certificate of the LDAP server certificate in order for this to work. > 2. When connected to the FreeIPA instance, and issuing 'ipa > user-status username', the following error is returned: > > ipa: ERROR: cert validation failed for "CN=CERT_CN_REDACTED,OU=Domain > Control Validated" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate > issuer has been marked as not trusted by the user.) > ipa: ERROR: cert validation failed for "CN=CERT_CN_REDACTED,OU=Domain > Control Validated" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate > issuer has been marked as not trusted by the user.) > ipa: ERROR: cannot connect to Gettext('any of the configured servers', > domain='ipa', localedir=None): https://IPA1_FQDN_REDACTED/ipa/xml, > https://IPA2_FQDN_REDACTED/ipa/xml > > Note that, CERT_CN_REDACTED is the *.domain.tld cert that has been > renewed. Of note is that, prior to the certificate update noted above, > this did work correctly, and would return the status of the user. This means that the CA certificate of the HTTP server certificate is missing from the NSS database at /etc/pki/nssdb. > > Further, when issuing 'ipa service restart' on the IPA instance, the > following is returned: > > # service ipa restart > Restarting Directory Service > Shutting down dirsrv: > DIRSRV_REDACTED... [ OK ] > Starting dirsrv: > DIRSRV_REDACTED...[21/Oct/2014:19:07:22 -0700] - SSL alert: > CERT_VerifyCertificateNow: verify certificate failed for cert > CERT_CN_REDACTED - GoDaddy.com, Inc. of family > cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8172 > - Peer's certificate issuer has been marked as not trusted by the > user.) > [ OK ] > Restarting KDC Service > Stopping Kerberos 5 KDC: [ OK ] > Starting Kerberos 5 KDC: [ OK ] > Restarting KPASSWD Service > Stopping Kerberos 5 Admin Server: [ OK ] > Starting Kerberos 5 Admin Server: [ OK ] > Restarting MEMCACHE Service > Stopping ipa_memcached: [ OK ] > Starting ipa_memcached: [ OK ] > Restarting HTTP Service > Stopping httpd: [ OK ] > Starting httpd: [ OK ] > # This means that the CA certificate of the LDAP server certificate is missing from the NSS database at /etc/dirsrv/slapd-DIRSRV_REDACTED. > > Can anyone instruct me as to what may be misconfigured? I assume this > is the root cause of LDAP via SSL not working correctly, but I'm not > quite sure how to verify that. > It is of note to say that the CA bundle (a chain of public keys > leading to a root, 3rd party CA) issued with the new certificate is > different from the previous certificate bundle. I know this as I have > records of the original certificate, key, bundle, and CSR. The CA > bundle issued with this new certificate is *different* from the CA > bundle used with the original certificate. As I have not provided, or > otherwise used, this new CA bundle when renewing the certificates in > FreeIPA, I suspect this is the root cause of the error, and so I ask > for help here. You are right this is the root cause. To fix IPA, you need to import the CA certificate to NSS databases at /etc/dirsrv/slapd-DIRSRV_REDACTED, /etc/httpd/alias and /etc/pki/nssdb, copy it to /etc/ipa/ca.crt and /usr/share/ipa/html/ca.crt and update cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com in LDAP with it. > > --- > Dragan Prostran > Honza -- Jan Cholasta From dprostran at monexa.com Fri Oct 24 18:31:09 2014 From: dprostran at monexa.com (Dragan Prostran) Date: Fri, 24 Oct 2014 11:31:09 -0700 Subject: [Freeipa-users] Third party SSL certificate renewal In-Reply-To: <544A5028.70100@redhat.com> References: <544A5028.70100@redhat.com> Message-ID: Hi Jan, I'm grateful for your help. I've researched how to follow your recommendations above, but I'm not having a lot of luck. According to old posts in this mailing list, https://www.redhat.com/archives/freeipa-users/2013-May/msg00199.html, the command ipa-server-certinstall is the way to go. That said, I found an issue you've filed to allow for this, and it was implemented in FreeIPA 3.3: https://fedorahosted.org/freeipa/ticket/3641 Unfortunately, this system is running FreeIPA 3.0: # rpm -qa | grep -P "ipa[_-]" ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-client-3.0.0-26.el6_4.4.x86_64 ipa-admintools-3.0.0-26.el6_4.4.x86_64 libipa_hbac-1.9.2-82.10.el6_4.x86_64 libipa_hbac-python-1.9.2-82.10.el6_4.x86_64 ipa-python-3.0.0-26.el6_4.4.x86_64 ipa-server-3.0.0-26.el6_4.4.x86_64 # I've found these instructions: http://www.freeipa.org/page/Howto/CA_Certificate_Renewal. I've read those instructions, and I believe I may have a misconception about this process. The procedure calls to: # cp /root/ipa.crt /usr/share/ipa/html/ca.crt # cp /root/ipa.crt /etc/ipa/ca.crt Can you clear up what /root/ipa.crt ought to contain? I assume it ought to contain *only* the root CA certificate which is the *first* key in the bundle provided by the 3rd party Certificate Authority. Is that correct? The files /etc/ip/ca.crt already exists, but it is a single certificate. The file I have, issued alongside with the certificate by GoDaddy, is a CA bundle. It contains 3 public keys in sequence in a single file. Could you please be more detailed as to how to accomplish this: "you need to import the CA certificate to NSS databases at /etc/dirsrv/slapd-DIRSRV_REDACTED, /etc/httpd/alias and /etc/pki/nssdb, copy it to /etc/ipa/ca.crt and /usr/share/ipa/html/ca.crt and update cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com in LDAP with it." I certainly hope these are not inappropriate questions: I'd just like to ensure this is done correctly. Thank you. --- Dragan Prostran On Fri, Oct 24, 2014 at 6:12 AM, Jan Cholasta wrote: > Hi, > > Dne 24.10.2014 v 04:36 Dragan Prostran napsal(a): > >> Hello, >> >> This is my first time posting to this list, so if I've made a faux pas >> or mistake, please do correct me. >> >> Can anyone please point me to the correct method to renewing 3rd party >> SSL certificates used by FreeIPA 3.0? I suspect I've not done this >> correctly. >> >> Here is what has worked correctly so far: >> 1. FreeIPA is installed and configured to work correctly. It uses 3rd >> party SSL certificates. I have access to the CSR, the certificate, the >> private key, and the new CA bundle. >> 2. I have successfully followed these instructions to update the SSL >> certificates used by Apache to serve the FreeIPA web interface: >> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP. >> Of note is that there are 2 IPA servers, and the procedure has been >> followed on both. >> 3. Upon visiting the FreeIPA web interface, I can see that the >> certificate is valid, and expires in the future. Login to FreeIPA and >> modifying (for example) an LDAP password, work correctly. >> 4. 3rd party services that take advantage of LDAP work correctly. I >> can login and authenticate via LDAP. >> >> Here is what does not work correctly: >> 1. A distinct, 3rd party webservice that takes advantage of LDAP *via >> SSL* no longer is able to authenticate. Prior to certificate update >> mentioned, this did work correctly. I must admit I'm unfamiliar with >> LDAP (via SSL), and so instead of troubleshooting that service, I had >> a closer look at the FreeIPA instance. > > > The 3rd party webservice needs to trust the CA certificate of the LDAP > server certificate in order for this to work. > >> 2. When connected to the FreeIPA instance, and issuing 'ipa >> user-status username', the following error is returned: >> >> ipa: ERROR: cert validation failed for "CN=CERT_CN_REDACTED,OU=Domain >> Control Validated" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate >> issuer has been marked as not trusted by the user.) >> ipa: ERROR: cert validation failed for "CN=CERT_CN_REDACTED,OU=Domain >> Control Validated" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate >> issuer has been marked as not trusted by the user.) >> ipa: ERROR: cannot connect to Gettext('any of the configured servers', >> domain='ipa', localedir=None): https://IPA1_FQDN_REDACTED/ipa/xml, >> https://IPA2_FQDN_REDACTED/ipa/xml >> >> Note that, CERT_CN_REDACTED is the *.domain.tld cert that has been >> renewed. Of note is that, prior to the certificate update noted above, >> this did work correctly, and would return the status of the user. > > > This means that the CA certificate of the HTTP server certificate is missing > from the NSS database at /etc/pki/nssdb. > > >> >> Further, when issuing 'ipa service restart' on the IPA instance, the >> following is returned: >> >> # service ipa restart >> Restarting Directory Service >> Shutting down dirsrv: >> DIRSRV_REDACTED... [ OK ] >> Starting dirsrv: >> DIRSRV_REDACTED...[21/Oct/2014:19:07:22 -0700] - SSL alert: >> CERT_VerifyCertificateNow: verify certificate failed for cert >> CERT_CN_REDACTED - GoDaddy.com, Inc. of family >> cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8172 >> - Peer's certificate issuer has been marked as not trusted by the >> user.) >> [ OK ] >> Restarting KDC Service >> Stopping Kerberos 5 KDC: [ OK ] >> Starting Kerberos 5 KDC: [ OK ] >> Restarting KPASSWD Service >> Stopping Kerberos 5 Admin Server: [ OK ] >> Starting Kerberos 5 Admin Server: [ OK ] >> Restarting MEMCACHE Service >> Stopping ipa_memcached: [ OK ] >> Starting ipa_memcached: [ OK ] >> Restarting HTTP Service >> Stopping httpd: [ OK ] >> Starting httpd: [ OK ] >> # > > > This means that the CA certificate of the LDAP server certificate is missing > from the NSS database at /etc/dirsrv/slapd-DIRSRV_REDACTED. > >> >> Can anyone instruct me as to what may be misconfigured? I assume this >> is the root cause of LDAP via SSL not working correctly, but I'm not >> quite sure how to verify that. >> It is of note to say that the CA bundle (a chain of public keys >> leading to a root, 3rd party CA) issued with the new certificate is >> different from the previous certificate bundle. I know this as I have >> records of the original certificate, key, bundle, and CSR. The CA >> bundle issued with this new certificate is *different* from the CA >> bundle used with the original certificate. As I have not provided, or >> otherwise used, this new CA bundle when renewing the certificates in >> FreeIPA, I suspect this is the root cause of the error, and so I ask >> for help here. > > > You are right this is the root cause. To fix IPA, you need to import the CA > certificate to NSS databases at /etc/dirsrv/slapd-DIRSRV_REDACTED, > /etc/httpd/alias and /etc/pki/nssdb, copy it to /etc/ipa/ca.crt and > /usr/share/ipa/html/ca.crt and update > cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com in LDAP with it. > >> >> --- >> Dragan Prostran >> > > Honza > > -- > Jan Cholasta -- Dragan Prostran System Administrator Monexa Services Inc. From rmeggins at redhat.com Fri Oct 24 19:38:04 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 24 Oct 2014 13:38:04 -0600 Subject: [Freeipa-users] Radius schema addition to default user objectclasses in FreeIPA 4.1 In-Reply-To: <1414153659.837745408@f356.i.mail.ru> References: <1414153659.837745408@f356.i.mail.ru> Message-ID: <544AAA9C.3060007@redhat.com> On 10/24/2014 06:27 AM, ????? ??????? wrote: > New task: I want to add an additional schema (radius schema) to > default user object classes. > > I prepared the ldif-file for the schema: > https://cloud.mail.ru/public/40edc9a6c9bb%2Fradiusschema.ldif , > then followed instructions in > https://www.redhat.com/archives/freeipa-users/2014-February/msg00050.html > At step #2 of the instructions, ldapmodify command was run; > as I'm using FreeIPA 4.1 in a multi-master replication scenario with 2 > servers, > the command was run on both servers and produced this output on both: > > modifying entry "cn=schema" > > Then I switched to GUI and added "radiusprofile" objectclass. After > hitting the "Update" button I got the message: > > "IPA Error 4001: NotFound > > objectclass radiusprofile not found" > > Restarting ipactl didn't help. > Command "ldapsearch -Y GSSAPI | grep schema" gives no output besides > informational SASL messages. Are you trying to list the schema over LDAP? Where did you get the above instructions? They are wrong. Use ldapsearch -o ldif-wrap=no -Y GSSAPI -s base -b "cn=schema" attributeTypes objectClasses If you are using an older version of ldapsearch that doesn't support ldif-wrap, see http://richmegginson.livejournal.com/18726.html > There is a "MUST cn" part in the objectclass definition in the > ldif-file, but even after removing it the situation doesn't change. > Please help me to understand where is the problem, and is it generally > possible to use radius.schema with FreeIPA? > The original schema was taken from: > http://open.rhx.it/phamm/schema/radius.schema > Thanks in advance! > > -- > ????? ??????? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From CWhite at skytouchtechnology.com Fri Oct 24 23:01:48 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Fri, 24 Oct 2014 23:01:48 +0000 Subject: [Freeipa-users] multi-master replication Message-ID: I would have thought that changes go from replica to master and not just master to replica. Is there something I have to do to make the changes bi-directional? Craig White System Administrator O 623-201-8179 M 602-377-9752 [cid:image001.png at 01CF86FE.42D51630] SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7660 bytes Desc: image001.png URL: From CWhite at skytouchtechnology.com Fri Oct 24 23:15:22 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Fri, 24 Oct 2014 23:15:22 +0000 Subject: [Freeipa-users] multi-master replication In-Reply-To: References: Message-ID: From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Craig White Sent: Friday, October 24, 2014 4:02 PM To: freeipa-users at redhat.com Subject: [Freeipa-users] multi-master replication I would have thought that changes go from replica to master and not just master to replica. Is there something I have to do to make the changes bi-directional? Replying to my own post... Logs are my friend ;-) [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.domain.local " (ipa001:389): Replication bind with GSSAPI auth resumed [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.domain.local " (ipa001:389): Warning: unable to replicate schema: rc=2 [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.domain.local " (ipa001:389): Failed to send update operation to consumer (uniqueid e018060f-5bb011e4-81078979-dc802980, CSN 544aa346000000030000): Can't contact LDAP server. Will retry later. [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.domain.local " (ipa001:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.domain.local" (ipa001:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) And on the master, I see a bunch of... sasl_io_recv failed to decode packet for connection 4113 but dirsrv is running on both machines and firewalls aren't in the way because I managed to set up the initial replication from master to replica without a problem and the firewall rules are the same for both machines. # rpm -qa | grep ipa ipa-admintools-3.0.0-42.el6.x86_64 libipa_hbac-python-1.11.6-30.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-client-3.0.0-42.el6.x86_64 ipa-server-selinux-3.0.0-42.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-pki-ca-theme-9.0.3-7.el6.noarch sssd-ipa-1.11.6-30.el6.x86_64 ipa-python-3.0.0-42.el6.x86_64 ipa-server-3.0.0-42.el6.x86_64 libipa_hbac-1.11.6-30.el6.x86_64 RHEL 6.5 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Sat Oct 25 14:40:34 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Sat, 25 Oct 2014 16:40:34 +0200 Subject: [Freeipa-users] dns stops working after upgrade Message-ID: Hello all, I'm running freeipa 3.3.0 on fedora 20 x86_65 and it is set up as my main dns server. I've tried the upgrade to 4.1 using the copr repositorie. I performed the following steps: 1 apply latest fedora updates 2 shutdown system 3 create a snapshot from the freeipa vm as a backup (which is why I'm back at 3.3) 4 added the copr repo to my repositories 5 issue 'yum update' and grab a coffee 6 see the update complete and start to check if everything still works. all authentication seems to work fine, however all my local dns enties no longer work. all internet dns queries work fine, just not my own entries. they are all still there. so I shutdown my freeipa vm and reverted the snapshot, everything is back up and running again with 3.3.0 I've digged through my logs but see no errors whatsoever. Did I miss something that needs to be done when doing an upgrade ? Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From genadipost at gmail.com Sat Oct 25 21:02:26 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Sat, 25 Oct 2014 23:02:26 +0200 Subject: [Freeipa-users] Using Selective authentication on AD->IPA trust. In-Reply-To: <20141019215325.GK5446@redhat.com> References: <20141019215325.GK5446@redhat.com> Message-ID: > > We need to get host/ipa.master and HTTP/ipa.master principals to get >> > authenticated read only access to AD DC and LDAP servers. The problem > with granting this access in 'Selective authentication' case will > prevent the trust from working. > > Only the IPA servers are accessing AD DC? Or all the hosts (Clients) are also preforming query's on GC's LDAP, as you described in this older mail exchange : https://www.redhat.com/archives/freeipa-users/2014-January/msg00181.html *"IPA needs to be able to look up users and groups in AD. To do so, it uses Kerberos authentication against AD's Global Catalog services with own credentials (per each IPA host). We are using cross-realm Kerberos trust here, AD DC trusts cross-realm TGT issued by IPA KDC and vice versa, so IPA hosts can bind as their own identity (host/...) to AD."* If the first case is true, then read only permission can be granted to IPA server's *only *(?), . If the second is true, there is no escape but to convince (somehow) the AD IT guys. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Sat Oct 25 21:45:26 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 26 Oct 2014 00:45:26 +0300 Subject: [Freeipa-users] Using Selective authentication on AD->IPA trust. In-Reply-To: References: <20141019215325.GK5446@redhat.com> Message-ID: <20141025214526.GV5446@redhat.com> On Sat, 25 Oct 2014, Genadi Postrilko wrote: >> >> We need to get host/ipa.master and HTTP/ipa.master principals to get >>> >> authenticated read only access to AD DC and LDAP servers. The problem >> with granting this access in 'Selective authentication' case will >> prevent the trust from working. >> >> >Only the IPA servers are accessing AD DC? Or all the hosts (Clients) are >also preforming query's on GC's LDAP, as >you described in this older mail exchange : > >https://www.redhat.com/archives/freeipa-users/2014-January/msg00181.html > >*"IPA needs to be able to look up users and groups in AD. To do so, it >uses Kerberos authentication against AD's Global Catalog services with >own credentials (per each IPA host). We are using cross-realm >Kerberos trust here, AD DC trusts cross-realm TGT issued by IPA KDC and >vice versa, so IPA hosts can bind as their own identity (host/...) to >AD."* > > >If the first case is true, then read only permission can be granted to >IPA server's *only *(?), . IPA masters. SSSD on IPA clients talk to IPA masters via LDAP protocol using a special control. A plugin in LDAP server then talks to SSSD on the IPA master to request identity information and SSSD on the IPA master talks to the AD LDAP/GC services. I don't see what this changes, though. As I described before, authenticated access to AD LDAP/GC services is what is required to access them and unless more rights are given, access is read-only by default, you do not need to grant anything. Since Active Directory UI cannot resolve IPA domain's SIDs to names, it cannot be used to elevate the access rights. Neither it can reduce the rights of IPA principals beyond read-only access unless the objects in question would be made available only to members of certain AD groups of which IPA principals wouldn't be privy. The latter is rather limiting and unlikely situation for a typical Active Directory deployment which will likely break quite a lot of Windows applications anyway. Note also that AD DC only considers 'right' those principals which have MS PAC records within their tickets, containing SIDs this principal is representing (and the membership of the principal in question in other groups). IPA only gives out MS PAC record to host/, HTTP/, and cifs/ principals on the hosts where ipa-adtrust-install was run, in addition to normal IPA users. Thus, none of IPA clients' host/ principal can be used to directly authenticate against AD DC. -- / Alexander Bokovoy From dpal at redhat.com Sun Oct 26 00:17:41 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 25 Oct 2014 20:17:41 -0400 Subject: [Freeipa-users] multi-master replication In-Reply-To: References: Message-ID: <544C3DA5.6010009@redhat.com> On 10/24/2014 07:15 PM, Craig White wrote: > > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Craig White > *Sent:* Friday, October 24, 2014 4:02 PM > *To:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] multi-master replication > > I would have thought that changes go from replica to master and not > just master to replica. > > Is there something I have to do to make the changes bi-directional? > > Replying to my own post... > > Logs are my friend ;-) > > [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.domain.local " (ipa001:389): Replication bind with > GSSAPI auth resumed > > [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.domain.local " (ipa001:389): Warning: unable to > replicate schema: rc=2 > > [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.domain.local " (ipa001:389): Failed to send update > operation to consumer (uniqueid e018060f-5bb011e4-81078979-dc802980, > CSN 544aa346000000030000): Can't contact LDAP server. Will retry later. > > [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.domain.local " (ipa001:389): Consumer failed to > replay change (uniqueid (null), CSN (null)): Can't contact LDAP > server(-1). Will retry later. > These NULLs look suspicious. I hope DS gurus will have more for you on Monday. > [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.domain.local" (ipa001:389): Warning: unable to > send endReplication extended operation (Can't contact LDAP server) > > And on the master, I see a bunch of... > > sasl_io_recv failed to decode packet for connection 4113 > > but dirsrv is running on both machines and firewalls aren't in the way > because I managed to set up the initial replication from master to > replica without a problem and the firewall rules are the same for both > machines. > > # rpm -qa | grep ipa > > ipa-admintools-3.0.0-42.el6.x86_64 > > libipa_hbac-python-1.11.6-30.el6.x86_64 > > python-iniparse-0.3.1-2.1.el6.noarch > > ipa-client-3.0.0-42.el6.x86_64 > > ipa-server-selinux-3.0.0-42.el6.x86_64 > > ipa-pki-common-theme-9.0.3-7.el6.noarch > > ipa-pki-ca-theme-9.0.3-7.el6.noarch > > sssd-ipa-1.11.6-30.el6.x86_64 > > ipa-python-3.0.0-42.el6.x86_64 > > ipa-server-3.0.0-42.el6.x86_64 > > libipa_hbac-1.11.6-30.el6.x86_64 > > RHEL 6.5 > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.obaterspok at gmail.com Sun Oct 26 10:39:30 2014 From: john.obaterspok at gmail.com (John Obaterspok) Date: Sun, 26 Oct 2014 11:39:30 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: Message-ID: Hello Rob, Did systemd report any failed services? (systemctl --failed) -- john 2014-10-25 16:40 GMT+02:00 Rob Verduijn : > Hello all, > > I'm running freeipa 3.3.0 on fedora 20 x86_65 and it is set up as my main > dns server. > > I've tried the upgrade to 4.1 using the copr repositorie. > > I performed the following steps: > > 1 apply latest fedora updates > 2 shutdown system > 3 create a snapshot from the freeipa vm as a backup (which is why I'm back > at 3.3) > 4 added the copr repo to my repositories > 5 issue 'yum update' and grab a coffee > 6 see the update complete and start to check if everything still works. > all authentication seems to work fine, however all my local dns enties no > longer work. > all internet dns queries work fine, just not my own entries. > they are all still there. > > so I shutdown my freeipa vm and reverted the snapshot, everything is back > up and running again with 3.3.0 > > I've digged through my logs but see no errors whatsoever. > > Did I miss something that needs to be done when doing an upgrade ? > > Rob > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Sun Oct 26 15:24:02 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Sun, 26 Oct 2014 16:24:02 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: Message-ID: hmmmm.... after some more digging (monitoring the upgrade more closely.) I saw that the upgrade kept waiting for the ca to start, which it did not do. and after 5 minutes the upgrade gave up with the following errors in the ipaupgrade log : at 85% it says : 2014-10-26T15:04:35Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-XXXX-XXXX.socket conn= 2014-10-26T15:04:35Z DEBUG Starting external process 2014-10-26T15:04:35Z DEBUG args='/usr/bin/certutil' '-d' '/etc/httpd/alias' '-L' 2014-10-26T15:04:35Z DEBUG Process finished, return code=0 2014-10-26T15:04:35Z DEBUG stdout= Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Signing-Cert u,u,u XXXX.XXXX IPA CA CT,C,C ipaCert u,u,u Server-Cert u,u,u 2014-10-26T15:04:35Z DEBUG stderr= 2014-10-26T15:04:35Z DEBUG Starting external process 2014-10-26T15:04:35Z DEBUG args='/usr/bin/certutil' '-d' '/etc/httpd/alias' '-L' '-n' 'TJAKO.THUIS IPA CA' '-a' 2014-10-26T15:04:35Z DEBUG Process finished, return code=0 2014-10-26T15:04:35Z DEBUG stdout=-----BEGIN CERTIFICATE----- < certificate-removed > -----END CERTIFICATE----- 2014-10-26T15:04:35Z DEBUG stderr= 2014-10-26T15:04:36Z ERROR Upgrade failed with cannot connect to 'ldapi://%2fvar%2frun%2fslapd-XXXX-XXXX.socket': 2014-10-26T15:04:36Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 152, in __upgrade self.modified = (ld.update(self.files, ordered=True) or File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 874, in update updates = api.Backend.updateclient.update(POST_UPDATE, self.dm_password, self.ldapi, self.live_run) File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py", line 131, in update ld.update_from_dict(updates) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 889, in update_from_dict self._run_updates(updates) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 799, in _run_updates self._update_record(update) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 661, in _update_record e = self._get_entry(new_entry.dn) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 544, in _get_entry return self.conn.get_entries(dn, scope, searchfilter, sattrs) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1421, in get_entries base_dn=base_dn, scope=scope, filter=filter, attrs_list=attrs_list) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1527, in find_entries break File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1206, in error_handler error=info) NetworkError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-XXXX-XXXX.socket': and in the end it says : 2014-10-26T14:46:13Z DEBUG The CA status is: check interrupted 2014-10-26T14:46:13Z DEBUG Waiting for CA to start... 2014-10-26T14:46:14Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 646, in run_script return_value = main_function() File "/usr/sbin/ipa-upgradeconfig", line 1457, in main ca.restart(dogtag.configured_constants().PKI_INSTANCE_NAME) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 282, in restart self.service.restart(instance_name, capture_output=capture_output, wait=wait) File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 209, in restart self.wait_until_running() File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 197, in wait_until_running raise RuntimeError('CA did not start in %ss' % timeout) 2014-10-26T14:46:14Z DEBUG The ipa-upgradeconfig command failed, exception: RuntimeError: CA did not start in 300.0s I guess its something with the update for the ca certificate server that failed. Any clues on how to proceed ? Rob 2014-10-26 11:39 GMT+01:00 John Obaterspok : > Hello Rob, > > Did systemd report any failed services? (systemctl --failed) > > > -- john > > 2014-10-25 16:40 GMT+02:00 Rob Verduijn : > >> Hello all, >> >> I'm running freeipa 3.3.0 on fedora 20 x86_65 and it is set up as my main >> dns server. >> >> I've tried the upgrade to 4.1 using the copr repositorie. >> >> I performed the following steps: >> >> 1 apply latest fedora updates >> 2 shutdown system >> 3 create a snapshot from the freeipa vm as a backup (which is why I'm >> back at 3.3) >> 4 added the copr repo to my repositories >> 5 issue 'yum update' and grab a coffee >> 6 see the update complete and start to check if everything still works. >> all authentication seems to work fine, however all my local dns enties no >> longer work. >> all internet dns queries work fine, just not my own entries. >> they are all still there. >> >> so I shutdown my freeipa vm and reverted the snapshot, everything is back >> up and running again with 3.3.0 >> >> I've digged through my logs but see no errors whatsoever. >> >> Did I miss something that needs to be done when doing an upgrade ? >> >> Rob >> >> -- >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjaalton at ubuntu.com Sun Oct 26 18:29:09 2014 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Sun, 26 Oct 2014 20:29:09 +0200 Subject: [Freeipa-users] FreeIPA 4.0.4 now in Debian unstable! Message-ID: <544D3D75.9010804@ubuntu.com> Hi! Sooo.. as a followup to last weeks announcement about Dogtag 10.2 getting in Debian, today marks the day that FreeIPA finally made it to the distro! And unless release critical bugs are found it'll migrate to the testing branch after spending 10 days on unstable, just in time before the freeze of the next release. The past week was spent on fixing the remaining issues around client & server install. Thanks to everyone on #freeipa-devel that helped me on times of despair :) It'll take some time to wrap the distro patches into something that upstream could accept with a straight face.. In the meantime, feel free to kick the tires by installing 'freeipa-server' or 'freeipa-client' and report bugs if you find any! The packages will also get in the next Ubuntu release, and I'll backport them to 14.04 later this year. ps. special thanks to Benjamin Drung who joined the ranks of pkg-freeipa-devel earlier this year, reviewed all the new packages with attention to detail, sponsored them for me before I got upload rights, and most importantly stuck around all this time :) -- t From purpleidea at gmail.com Sun Oct 26 18:53:16 2014 From: purpleidea at gmail.com (James) Date: Sun, 26 Oct 2014 14:53:16 -0400 Subject: [Freeipa-users] FreeIPA 4.0.4 now in Debian unstable! In-Reply-To: <544D3D75.9010804@ubuntu.com> References: <544D3D75.9010804@ubuntu.com> Message-ID: On Sun, Oct 26, 2014 at 2:29 PM, Timo Aaltonen wrote: > > Hi! > > Sooo.. as a followup to last weeks announcement about Dogtag 10.2 > getting in Debian, today marks the day that FreeIPA finally made it to > the distro! And unless release critical bugs are found it'll migrate to > the testing branch after spending 10 days on unstable, just in time > before the freeze of the next release. > > The past week was spent on fixing the remaining issues around client & > server install. Thanks to everyone on #freeipa-devel that helped me on > times of despair :) > > It'll take some time to wrap the distro patches into something that > upstream could accept with a straight face.. In the meantime, feel free > to kick the tires by installing 'freeipa-server' or 'freeipa-client' and > report bugs if you find any! > > The packages will also get in the next Ubuntu release, and I'll backport > them to 14.04 later this year. > > > ps. special thanks to Benjamin Drung who joined the ranks of > pkg-freeipa-devel earlier this year, reviewed all the new packages with > attention to detail, sponsored them for me before I got upload rights, > and most importantly stuck around all this time :) > > > -- > t > > -- Awesome news! If someone is willing to test, I'm willing to write the patches to puppet-ipa [1] so that it works on Debian. Let me know. Cheers, James [1] https://github.com/purpleidea/puppet-ipa From rcritten at redhat.com Sun Oct 26 20:38:10 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Sun, 26 Oct 2014 16:38:10 -0400 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: Message-ID: <544D5BB2.5090003@redhat.com> Rob Verduijn wrote: > hmmmm.... > > after some more digging (monitoring the upgrade more closely.) > I saw that the upgrade kept waiting for the ca to start, which it did > not do. > and after 5 minutes the upgrade gave up with the following errors in the > ipaupgrade log : > > at 85% it says : > 2014-10-26T15:04:35Z DEBUG retrieving schema for SchemaCache > url=ldapi://%2fvar%2frun%2fslapd-XXXX-XXXX.socket > conn= > 2014-10-26T15:04:35Z DEBUG Starting external process > 2014-10-26T15:04:35Z DEBUG args='/usr/bin/certutil' '-d' > '/etc/httpd/alias' '-L' > 2014-10-26T15:04:35Z DEBUG Process finished, return code=0 > 2014-10-26T15:04:35Z DEBUG stdout= > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > Signing-Cert u,u,u > XXXX.XXXX IPA CA CT,C,C > ipaCert u,u,u > Server-Cert u,u,u > > 2014-10-26T15:04:35Z DEBUG stderr= > 2014-10-26T15:04:35Z DEBUG Starting external process > 2014-10-26T15:04:35Z DEBUG args='/usr/bin/certutil' '-d' > '/etc/httpd/alias' '-L' '-n' 'TJAKO.THUIS IPA CA' '-a' > 2014-10-26T15:04:35Z DEBUG Process finished, return code=0 > 2014-10-26T15:04:35Z DEBUG stdout=-----BEGIN CERTIFICATE----- > < certificate-removed > > -----END CERTIFICATE----- > 2014-10-26T15:04:35Z DEBUG stderr= > 2014-10-26T15:04:36Z ERROR Upgrade failed with cannot connect to > 'ldapi://%2fvar%2frun%2fslapd-XXXX-XXXX.socket':\ This has nothing to do with the CA, the LDAP server didn't come up. I'd start with those logs or look earlier in ipaupgrade.log The CA requires 389-ds to be running so if it isn't up, then it will fail to start too. rob From john.obaterspok at gmail.com Sun Oct 26 20:39:08 2014 From: john.obaterspok at gmail.com (John Obaterspok) Date: Sun, 26 Oct 2014 21:39:08 +0100 Subject: [Freeipa-users] F20 Problem upgrading to 4.1 Message-ID: Hi, I enabled mkosek-freeipa repo for F20 and updated freeipa-server from 3.3.5 to 4.1. The yum update reported just a single error: Could not load host key: /etc/ssh/ssh_host_dsa_key After reboot I had 3 services that failed to start: ipa, kadmin, named-pkcs11 Doing "strace -f named-pkcs11 -u named -f -g" I can see: "/var/lib/softhsm/tokens/" => -1 EACCES (Permission denied) initializing DST: PKCS#11 initialization failed exiting (due to fatal error) For kadmin the error is due to not being able to connect to sldap I noticed that softhsm2-util --show-slots reported "ERROR: Could not initialize the library." But that seemed to be because krb5-libs/openssl wasn't part of the update. After that I could show the default slot and then I manually called following (as root): "/usr/bin/softhsm2-util --init-token --slot 0 --label ipaDNSSEC --pin XXXXXXXX --so-pin XXXXXXXX" But the problems won't go away. Any clues? -- john -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Oct 27 11:19:56 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 27 Oct 2014 12:19:56 +0100 Subject: [Freeipa-users] F20 Problem upgrading to 4.1 In-Reply-To: References: Message-ID: <544E2A5C.50209@redhat.com> On 26/10/14 21:39, John Obaterspok wrote: > Hi, > > I enabled mkosek-freeipa repo for F20 and updated freeipa-server from > 3.3.5 to 4.1. The yum update reported just a single error: > > Could not load host key: /etc/ssh/ssh_host_dsa_key > > After reboot I had 3 services that failed to start: > ipa, kadmin, named-pkcs11 > > Doing "strace -f named-pkcs11 -u named -f -g" I can see: > "/var/lib/softhsm/tokens/" => -1 EACCES (Permission denied) > initializing DST: PKCS#11 initialization failed > exiting (due to fatal error) > > > For kadmin the error is due to not being able to connect to sldap > > I noticed that softhsm2-util --show-slots reported "ERROR: Could not > initialize the library." But that seemed to be because wasn't part > of the update. After that I could show the default slot and then I > manually called following (as root): > > "/usr/bin/softhsm2-util --init-token --slot 0 --label ipaDNSSEC --pin > XXXXXXXX --so-pin XXXXXXXX" > > But the problems won't go away. Any clues? > > -- john > > > > Hello, 1) can you share your /var/log/ipaupgrade.log ? 2) your issue with softhsm can be caused by missing enviroment variable IPA internally uses SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf please try SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf softhsm2-util --show-slots, and let me know if it works same with named-pkcs11, 3) can you share journalctl -u named-pkcs11 output? 4) I'm not aware of that we need, krb5-libs/openssl, I was getting this error if tokens directory doesnt exists, but IPA uses own configuration (see 2) not default. Martin^2 -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From Duncan.Innes at virginmoney.com Mon Oct 27 12:13:46 2014 From: Duncan.Innes at virginmoney.com (Innes, Duncan) Date: Mon, 27 Oct 2014 12:13:46 -0000 Subject: [Freeipa-users] Test connectivity before joining domain Message-ID: <56343345B145C043AE990701E3D193950478E1E5@EXVS2.nrplc.localnet> Hi, Have been using `ping` to test connectivity from our clients to the various IPA servers around the WAN before running an ldapsearch to pull some details about the client from the LDAP database. Several new VLAN's have now come online that do not permit ping traffic to be transmitted outside the VLAN, so clients on these LAN's think they can't see any of my IPA servers and then fail the domain join during the kickstart phase. Wondering if there's a consensus on how to check connectivity to IPA servers on the network? Something that I can use during the kickstart post-install phase. Current effort is: wget --timeout=1 --tries=1 --no-check-certificate https://ipaserver1.example.com and then test $? for result. But this only tests ports 80/443 - which authentication clients wont necessarily have access on. Can I reliably test the other FreeIPA ports? 389, 636, 88, 464? These are the ports that clients have to be allowed access to the IPA servers. Cheers Duncan This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Oct 27 13:14:53 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 27 Oct 2014 14:14:53 +0100 Subject: [Freeipa-users] Inconsistent group memberships in sssd In-Reply-To: <20141024075141.GA17667@hendrix.redhat.com> References: <20141024075141.GA17667@hendrix.redhat.com> Message-ID: <20141027131453.GJ9019@hendrix.redhat.com> On Fri, Oct 24, 2014 at 09:51:41AM +0200, Jakub Hrozek wrote: > On Thu, Oct 23, 2014 at 05:19:38PM -0700, Michael Lasevich wrote: > > Small update, it appears that once I run "getent group " - my > > user shows up in the group . Odd. > > > > (and yes, I have ran "sss_cache -UG" many a time) > > > > -M > > One particular change in IPA 4.x that might be giving old clients > headache is the new permission system. Only clean installs or replicas > of 6.6 (or newer) servers are guaranteed to work with old clients. > > How was your IPA 4.0.3 server installed? What is the 389-ds-base version > you're running? > > Any chance you can try a newer SSSD on your CentOS6 client? I have a > COPR repo with the latest 1.11 branch here: > http://copr-fe.cloud.fedoraproject.org/coprs/jhrozek/SSSD-1.11-RHEL6/ I should have been clearer in my previous response. We /do not/ require old clients to be upgraded in order to work with a newer server. We care about backwards compatibility. However, some changes in the new permissions system require an existing RHEL-6 IPA 3.x server that should be replicated onto a IPA 4.x server is first upgraded to RHEL-6.6, especially the 389-ds component. Clean installs of new servers are fine. Sorry for the confustion. From rmeggins at redhat.com Mon Oct 27 13:30:39 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 27 Oct 2014 07:30:39 -0600 Subject: [Freeipa-users] Test connectivity before joining domain In-Reply-To: <56343345B145C043AE990701E3D193950478E1E5@EXVS2.nrplc.localnet> References: <56343345B145C043AE990701E3D193950478E1E5@EXVS2.nrplc.localnet> Message-ID: <544E48FF.40009@redhat.com> On 10/27/2014 06:13 AM, Innes, Duncan wrote: > Hi, > Have been using `ping` to test connectivity from our clients to the > various IPA servers around the WAN before running an ldapsearch to > pull some details about the client from the LDAP database. > Several new VLAN's have now come online that do not permit ping > traffic to be transmitted outside the VLAN, so clients on these LAN's > think they can't see any of my IPA servers and then fail the domain > join during the kickstart phase. > Wondering if there's a consensus on how to check connectivity to IPA > servers on the network? Something that I can use during the kickstart > post-install phase. > Current effort is: > wget --timeout=1 --tries=1 --no-check-certificate > https://ipaserver1.example.com > and then test $? for result. But this only tests ports 80/443 - which > authentication clients wont necessarily have access on. Can I > reliably test the other FreeIPA ports? 389, 636, 389: ldapsearch -xLLL -h ipaserver1.example.com -p 389 -s base -b "" 636: LDAPTLS_REQCERT=never ldapsearch -xLLL -H ldaps://ipaserver1.example.com -s base -b "" > 88, 464? These are the ports that clients have to be allowed access > to the IPA servers. > Cheers > Duncan > > This message has been checked for viruses and spam by the Virgin Money > email scanning system powered by Messagelabs. > > This e-mail is intended to be confidential to the recipient. If you > receive a copy in error, please inform the sender and then delete this > message. > > Virgin Money plc - Registered in England and Wales (Company no. > 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon > Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential > Regulation Authority and regulated by the Financial Conduct Authority > and the Prudential Regulation Authority. > > The following companies also trade as Virgin Money. They are both > authorised and regulated by the Financial Conduct Authority, are > registered in England and Wales and have their registered office at > Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money > Personal Financial Service Limited (Company no. 3072766) and Virgin > Money Unit Trust Managers Limited (Company no. 3000482). > > For further details of Virgin Money group companies please visit our > website at virginmoney.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Oct 27 13:41:57 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 27 Oct 2014 07:41:57 -0600 Subject: [Freeipa-users] multi-master replication In-Reply-To: <544C3DA5.6010009@redhat.com> References: <544C3DA5.6010009@redhat.com> Message-ID: <544E4BA5.8020602@redhat.com> On 10/25/2014 06:17 PM, Dmitri Pal wrote: > On 10/24/2014 07:15 PM, Craig White wrote: >> >> *From:*freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Craig White >> *Sent:* Friday, October 24, 2014 4:02 PM >> *To:* freeipa-users at redhat.com >> *Subject:* [Freeipa-users] multi-master replication >> >> I would have thought that changes go from replica to master and not >> just master to replica. >> >> Is there something I have to do to make the changes bi-directional? >> >> Replying to my own post? >> >> Logs are my friend ;-) >> >> [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - >> agmt="cn=meToipa001.domain.local " (ipa001:389): Replication bind >> with GSSAPI auth resumed >> >> [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - >> agmt="cn=meToipa001.domain.local " (ipa001:389): Warning: unable to >> replicate schema: rc=2 >> >> [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - >> agmt="cn=meToipa001.domain.local " (ipa001:389): Failed to send >> update operation to consumer (uniqueid >> e018060f-5bb011e4-81078979-dc802980, CSN 544aa346000000030000): Can't >> contact LDAP server. Will retry later. >> >> [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - >> agmt="cn=meToipa001.domain.local " (ipa001:389): Consumer failed to >> replay change (uniqueid (null), CSN (null)): Can't contact LDAP >> server(-1). Will retry later. >> > > These NULLs look suspicious. > I hope DS gurus will have more for you on Monday. 1) Yes, replication is fully bi-directional. 2) What are the exact versions of dirsrv? rpm -q 389-ds-base on supplier and consumer. 3) Can you reproduce the problem using the replication log level on both the supplier and consumer? http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting > >> [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - >> agmt="cn=meToipa001.domain.local" (ipa001:389): Warning: unable to >> send endReplication extended operation (Can't contact LDAP server) >> >> And on the master, I see a bunch of? >> >> sasl_io_recv failed to decode packet for connection 4113 >> >> but dirsrv is running on both machines and firewalls aren?t in the >> way because I managed to set up the initial replication from master >> to replica without a problem and the firewall rules are the same for >> both machines. >> >> # rpm -qa | grep ipa >> >> ipa-admintools-3.0.0-42.el6.x86_64 >> >> libipa_hbac-python-1.11.6-30.el6.x86_64 >> >> python-iniparse-0.3.1-2.1.el6.noarch >> >> ipa-client-3.0.0-42.el6.x86_64 >> >> ipa-server-selinux-3.0.0-42.el6.x86_64 >> >> ipa-pki-common-theme-9.0.3-7.el6.noarch >> >> ipa-pki-ca-theme-9.0.3-7.el6.noarch >> >> sssd-ipa-1.11.6-30.el6.x86_64 >> >> ipa-python-3.0.0-42.el6.x86_64 >> >> ipa-server-3.0.0-42.el6.x86_64 >> >> libipa_hbac-1.11.6-30.el6.x86_64 >> >> RHEL 6.5 >> >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Oct 27 13:45:11 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 27 Oct 2014 09:45:11 -0400 Subject: [Freeipa-users] Test connectivity before joining domain In-Reply-To: <56343345B145C043AE990701E3D193950478E1E5@EXVS2.nrplc.localnet> References: <56343345B145C043AE990701E3D193950478E1E5@EXVS2.nrplc.localnet> Message-ID: <20141027094511.5efc2ecf@willson.usersys.redhat.com> On Mon, 27 Oct 2014 12:13:46 -0000 "Innes, Duncan" wrote: > Hi, > > Have been using `ping` to test connectivity from our clients to the > various IPA servers around the WAN before running an ldapsearch to > pull some details about the client from the LDAP database. > > Several new VLAN's have now come online that do not permit ping > traffic to be transmitted outside the VLAN, so clients on these LAN's > think they can't see any of my IPA servers and then fail the domain > join during the kickstart phase. > > Wondering if there's a consensus on how to check connectivity to IPA > servers on the network? Something that I can use during the kickstart > post-install phase. > > Current effort is: > > wget --timeout=1 --tries=1 --no-check-certificate > https://ipaserver1.example.com > > and then test $? for result. But this only tests ports 80/443 - which > authentication clients wont necessarily have access on. Can I > reliably test the other FreeIPA ports? 389, 636, 88, 464? These are > the ports that clients have to be allowed access to the IPA servers. Duncan, if you know python you can look into the ipa-replica-install tool, as it does a full check of accessibility. You do not need all those tests (as you do not need connection back from the server for example). But you can take inspiration there to see how we test each service. Simo. -- Simo Sorce * Red Hat, Inc * New York From trevor.t.kates at dom.com Mon Oct 27 14:07:42 2014 From: trevor.t.kates at dom.com (Trevor T Kates (Services - 6)) Date: Mon, 27 Oct 2014 14:07:42 +0000 Subject: [Freeipa-users] Question About Properly Configuring DNS Message-ID: Hi, all: I have four servers (two in one location, two in another) running IPA 3.0 set to replicate like so: Location A Server 1 - - - - - - - - Location B Server 1 | | | | | | | | Location A Server 2 - - - - - - - - Location B Server 2 Each server has DNS configured; however, I think I have configured something inappropriately with respect to authoritative records. I have eight zones configured and ipa dnszone-show for any one of them has Location B Server 1's name as authoritative. In each of the eight zones, I have added NS records for the other three servers. On all of the servers except Location B Server 1, /var/log/messages will show: client x.xxx.x.xxx#14366: received notify for zone 'x.xxx.x.in-addr.arpa': not authoritative This occurs for most, but not all, zones. Along with this: LDAP query timed out. Try to adjust "timeout" parameter update_record (psearch) failed, dn 'idnsname=xxx,idnsname=x.xxx.xx.in-addr.arpa.,cn=dns,dc=example,dc=com' change type 0x0. Records can be outdated, run `rndc reload`: not found I feel like I've misconfigured a few things along the way and I'd love some help. Along with that if anyone has recommendations on things I should read to help me better understand what I should be doing with DNS, I'd appreciate it. Thanks, Trevor T. Kates CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. From rob.verduijn at gmail.com Mon Oct 27 14:52:56 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Mon, 27 Oct 2014 15:52:56 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <544D5BB2.5090003@redhat.com> References: <544D5BB2.5090003@redhat.com> Message-ID: Ok after some more digging : I found some warnings (see below) Is any of these the cause for the error ? Rob 2014-10-27T13:56:13Z INFO Updating existing entry: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config 2014-10-27T13:56:13Z WARNING remove: 'sudoRunAsGroup=%deref("ipaSudoRunAs","cn")' not in schema-compat-entry-attribute 2014-10-27T13:56:13Z WARNING remove: '(targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || krbPrincipalName || krbCanonicalName || krbUPEnabled || krbTicketPolicyReference || krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || krbPwdHistory || krbLastPwdChange || krbPrincipalAliases || krbExtraData || krbLastSuccessfulAuth || krbLastFailedAuth || krbLoginFailedCount || ipaUniqueId || memberOf || serverHostName || enrolledBy || ipaNTHash")(version 3.0; acl "Admin can manage any entry"; allow (all) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,dc=XXXXX,dc=XXXXX";)' not in aci 2014-10-27T13:56:13Z WARNING remove: '(targetattr = "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory")(version 3.0; acl "Admins can write passwords"; allow (add,delete,write) groupdn="ldap:///cn=admins,cn=groups,cn=accounts,dc=XXXXX,dc=XXXXX";)' not in aci 2014-10-27T13:56:13Z INFO Updating existing entry: cn=ipa-winsync,cn=plugins,cn=config 2014-10-27T13:56:13Z WARNING remove: 'uidNumber 999' not in ipaWinSyncUserAttr 2014-10-27T13:56:13Z WARNING remove: 'gidNumber 999' not in ipaWinSyncUserAttr 2014-10-27T13:56:14Z INFO Updating existing entry: cn=referential integrity postoperation,cn=plugins,cn=config 2014-10-27T13:56:14Z WARNING remove: 'ipatokenradiusconfiglink' not in nsslapd-pluginArg18 2014-10-27T13:56:27Z INFO Updating existing entry: dc=XXXXX,dc=XXXXX 2014-10-27T13:56:27Z WARNING remove: '(target = "ldap:///idnsname=*,cn=dns,dc=XXXXX,dc=XXXXX")(version 3.0;acl "Add DNS entries";allow (add) groupdn = "ldap:///cn=add dns entries,cn=permissions,cn=pbac,dc=XXXXX,dc=XXXXX";)' not in aci 014-10-27T13:56:13Z INFO Updating existing entry: cn=Kerberos Principal Name,cn=IPA MODRDN,cn=plugins,cn=config 2014-10-27T13:56:13Z DEBUG remove: '60' from nsslapd-pluginPrecedence, current value [] 2014-10-27T13:56:13Z WARNING remove: '60' not in nsslapd-pluginPrecedence 2014-10-27T13:56:13Z INFO Updating existing entry: dc=XXXXX,dc=XXXXX 2014-10-27T13:56:27Z WARNING remove: '(target = "ldap:///idnsname=*,cn=dns,dc=XXXXX,dc=XXXXX")(version 3.0;acl "Add DNS entries";allow (add) groupdn = "ldap:///cn=add dns entries,cn=permissions,cn=pbac,dc=XXXXX,dc=XXXXX";)' not in aci 2014-10-27T13:56:27Z WARNING remove: '(target = "ldap:///idnsname=*,cn=dns,dc=XXXXX,dc=XXXXX")(version 3.0;acl "Remove DNS entries";allow (delete) groupdn = "ldap:///cn=remove dns entries,cn=permissions,cn=pbac,dc=XXXXX,dc=XXXXX";)' not in aci 2014-10-27T13:56:27Z WARNING remove: '(targetattr = "idnsname || cn || idnsallowdynupdate || dnsttl || dnsclass || arecord || aaaarecord || a6record || nsrecord || cnamerecord || ptrrecord || srvrecord || txtrecord || mxrecord || mdrecord || hinforecord || minforecord || afsdbrecord || sigrecord || keyrecord || locrecord || nxtrecord || naptrrecord || kxrecord || certrecord || dnamerecord || dsrecord || sshfprecord || rrsigrecord || nsecrecord || idnsname || idnszoneactive || idnssoamname || idnssoarname || idnssoaserial || idnssoarefresh || idnssoaretry || idnssoaexpire || idnssoaminimum || idnsupdatepolicy")(target = "ldap:///idnsname=*,cn=dns,dc=XXXXX,dc=XXXXX")(version 3.0;acl "Update DNS entries";allow (write) groupdn = "ldap:///cn=update dns entries,cn=permissions,cn=pbac,dc=XXXXX,dc=XXXXX";)' not in ac 2014-10-27T13:56:27Z WARNING remove: '(target = "ldap:///ipatokenuniqueid=*,cn=otp,dc=XXXXX,dc=XXXXX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl "Users can create and delete tokens"; allow (add, delete) userattr = "ipatokenOwner#SELFDN";)' not in aci 2014-10-27T13:56:27Z WARNING remove: '(targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = "ipatokenOTPkey || ipatokenOTPalgorithm || ipatokenOTPdigits || ipatokenHOTPcounter")(version 3.0; acl "Users can add HOTP token secrets"; allow (write, search) userattr = "ipatokenOwner#USERDN";)' not in aci 2014-10-27T13:56:28Z INFO Updating existing entry: cn=ipaConfig,cn=etc,dc=XXXXX,dc=XXXXX 2014-10-27T13:56:28Z WARNING remove: 'AllowLMhash' not in ipaConfigString and then we get to the traceback: 2014-10-27T13:56:34Z ERROR Upgrade failed with cannot connect to 'ldapi://%2fvar%2frun%2fslapd-XXXXX-XXXXX.socket': 2014-10-27T13:56:34Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 152, in __upgrade self.modified = (ld.update(self.files, ordered=True) or File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 874, in update updates = api.Backend.updateclient.update(POST_UPDATE, self.dm_password, self.ldapi, self.live_run) File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py", line 131, in update ld.update_from_dict(updates) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 889, in update_from_dict self._run_updates(updates) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 799, in _run_updates self._update_record(update) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 661, in _update_record e = self._get_entry(new_entry.dn) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 544, in _get_entry return self.conn.get_entries(dn, scope, searchfilter, sattrs) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1421, in get_entries base_dn=base_dn, scope=scope, filter=filter, attrs_list=attrs_list) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1527, in find_entries break File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1206, in error_handler error=info) NetworkError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-XXXXX-XXXXX.socket': 2014-10-26 21:38 GMT+01:00 Rob Crittenden : > Rob Verduijn wrote: > > hmmmm.... > > > > after some more digging (monitoring the upgrade more closely.) > > I saw that the upgrade kept waiting for the ca to start, which it did > > not do. > > and after 5 minutes the upgrade gave up with the following errors in the > > ipaupgrade log : > > > > at 85% it says : > > 2014-10-26T15:04:35Z DEBUG retrieving schema for SchemaCache > > url=ldapi://%2fvar%2frun%2fslapd-XXXX-XXXX.socket > > conn= > > 2014-10-26T15:04:35Z DEBUG Starting external process > > 2014-10-26T15:04:35Z DEBUG args='/usr/bin/certutil' '-d' > > '/etc/httpd/alias' '-L' > > 2014-10-26T15:04:35Z DEBUG Process finished, return code=0 > > 2014-10-26T15:04:35Z DEBUG stdout= > > Certificate Nickname Trust > > Attributes > > > > SSL,S/MIME,JAR/XPI > > > > Signing-Cert u,u,u > > XXXX.XXXX IPA CA CT,C,C > > ipaCert u,u,u > > Server-Cert u,u,u > > > > 2014-10-26T15:04:35Z DEBUG stderr= > > 2014-10-26T15:04:35Z DEBUG Starting external process > > 2014-10-26T15:04:35Z DEBUG args='/usr/bin/certutil' '-d' > > '/etc/httpd/alias' '-L' '-n' 'TJAKO.THUIS IPA CA' '-a' > > 2014-10-26T15:04:35Z DEBUG Process finished, return code=0 > > 2014-10-26T15:04:35Z DEBUG stdout=-----BEGIN CERTIFICATE----- > > < certificate-removed > > > -----END CERTIFICATE----- > > 2014-10-26T15:04:35Z DEBUG stderr= > > 2014-10-26T15:04:36Z ERROR Upgrade failed with cannot connect to > > 'ldapi://%2fvar%2frun%2fslapd-XXXX-XXXX.socket':\ > > This has nothing to do with the CA, the LDAP server didn't come up. I'd > start with those logs or look earlier in ipaupgrade.log > > The CA requires 389-ds to be running so if it isn't up, then it will > fail to start too. > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From CWhite at skytouchtechnology.com Mon Oct 27 16:12:54 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Mon, 27 Oct 2014 16:12:54 +0000 Subject: [Freeipa-users] multi-master replication In-Reply-To: <544E4BA5.8020602@redhat.com> References: <544C3DA5.6010009@redhat.com> <544E4BA5.8020602@redhat.com> Message-ID: <5b424b09f0a74ee0822b49ce2e886694@BLUPR08MB488.namprd08.prod.outlook.com> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson Sent: Monday, October 27, 2014 6:42 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] multi-master replication On 10/25/2014 06:17 PM, Dmitri Pal wrote: On 10/24/2014 07:15 PM, Craig White wrote: From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Craig White Sent: Friday, October 24, 2014 4:02 PM To: freeipa-users at redhat.com Subject: [Freeipa-users] multi-master replication I would have thought that changes go from replica to master and not just master to replica. Is there something I have to do to make the changes bi-directional? Replying to my own post... Logs are my friend ;-) [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.domain.local " (ipa001:389): Replication bind with GSSAPI auth resumed [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.domain.local " (ipa001:389): Warning: unable to replicate schema: rc=2 [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.domain.local " (ipa001:389): Failed to send update operation to consumer (uniqueid e018060f-5bb011e4-81078979-dc802980, CSN 544aa346000000030000): Can't contact LDAP server. Will retry later. [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.domain.local " (ipa001:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. These NULLs look suspicious. I hope DS gurus will have more for you on Monday. 1) Yes, replication is fully bi-directional. 2) What are the exact versions of dirsrv? rpm -q 389-ds-base on supplier and consumer. 3) Can you reproduce the problem using the replication log level on both the supplier and consumer? http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting ---- 1) I sort of expected it to be - that's what had me worried when it didn't work as expected. 2) ]# rpm -qa | grep 389 389-ds-base-1.2.11.15-47.el6.x86_64 389-ds-base-libs-1.2.11.15-47.el6.x86_64 3) Upped the log levels - hopefully this is a reasonable representative from ipa002 (the replica) [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - conn=4 op=229791 repl="dc=stt,dc=local": Acquired replica [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - conn=4 op=229791 repl="dc=stt,dc=local": StartNSDS90ReplicationRequest: response=0 rc=0 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - conn=4 op=229791 Relinquishing consumer connection extension [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 544e6b02000000040000 into pending list [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - Purged state information from entry krbprincipalname=ldap/ipa002.FQDN at FQDN,cn=services,cn=accounts,dc=stt,dc=local up to CSN 5445307e000000040000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object f32b80 for database /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object f32b80 for database /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - ruv_update_ruv: successfully committed csn 544e6b02000000040000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Disconnected from the consumer [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Warning: unable to replicate schema: rc=2 [27/Oct/2014:15:55:47 +0000] - csngen_adjust_time: gen state before 544e6b040001:1414425347:0:1 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFile: found DB object f32b80 for database /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 [27/Oct/2014:15:55:47 +0000] - _cl5PositionCursorForReplay (agmt="cn=meToipa001.FQDN" (ipa001:389)): Consumer RUV: [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replicageneration} 544aa332000000040000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 4 ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e6b02000000040000 00000000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 3 ldap://ipa002.FQDN:389} 544aa339000000030000 544aa33f000400030000 00000000 [27/Oct/2014:15:55:47 +0000] - _cl5PositionCursorForReplay (agmt="cn=meToipa001.FQDN" (ipa001:389)): Supplier RUV: [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replicageneration} 544aa332000000040000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 3 ldap://ipa002.FQDN:389} 544aa339000000030000 544e6aa4000300030000 544e6aa3 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 4 ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e6b02000000040000 544e6b03 [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - clcache_get_buffer: found thread private buffer cache 7fe85000ea50 [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - clcache_get_buffer: _pool is f89af0 _pool->pl_busy_lists is 7fe8500197d0 _pool->pl_busy_lists->bl_buffers is 7fe85000ea50 [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - session start: anchorcsn=544aa33f000400030000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog program - agmt="cn=meToipa001.FQDN" (ipa001:389): CSN 544aa33f000400030000 found, position set for replay [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - load=1 rec=1 csn=544aa346000000030000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): replay_update: Sending add operation (dn="cn=KDC,cn=ipa002.FQDN,cn=masters,cn=ipa,cn=etc,dc=stt,dc=local" csn=544aa346000000030000) [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): replay_update: Consumer could not replay operation with csn 544aa346000000030000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Failed to send update operation to consumer (uniqueid e018060f-5bb011e4-81078979-dc802980, CSN 544aa346000000030000): Can't contact LDAP server. Will retry later. [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain starting [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Connection disconnected by another thread [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain: read result for message_id 0 [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain: result 3, -1, 2, 0, (null) [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain: got op result 205 should finish 1 [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain exiting [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - session end: state=0 load=1 sent=1 skipped=0 skipped_new_rid=0 skipped_csn_gt_cons_maxcsn=0 skipped_up_to_date=0 skipped_csn_gt_ruv=0 skipped_csn_covered=0 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): State: sending_updates -> start_backoff [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): State: start_backoff -> start_backoff [27/Oct/2014:15:55:49 +0000] NSMMReplicationPlugin - conn=4 op=229793 Acquired consumer connection extension [27/Oct/2014:15:55:49 +0000] NSMMReplicationPlugin - conn=4 op=229793 repl="dc=stt,dc=local": Released replica held by locking_purl=conn=4 id=229791 [27/Oct/2014:15:55:49 +0000] NSMMReplicationPlugin - conn=4 op=229793 Relinquishing consumer connection extension [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): State: start_backoff -> backoff [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Trying non-secure slapi_ldap_init_ext [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): binddn = , passwd = [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Replication bind with GSSAPI auth resumed [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): No linger to cancel on the connection [27/Oct/2014:15:55:51 +0000] - _csngen_adjust_local_time: gen state before 544e6b040001:1414425347:0:1 [27/Oct/2014:15:55:51 +0000] - _csngen_adjust_local_time: gen state after 544e6b080000:1414425351:0:1 [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Replica was successfully acquired. [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): State: backoff -> sending_updates [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - conn=4 op=229794 Acquired consumer connection extension [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - conn=4 op=229794 repl="dc=stt,dc=local": Begin incremental protocol [27/Oct/2014:15:55:51 +0000] - csngen_adjust_time: gen state before 544e6b080001:1414425351:0:1 [27/Oct/2014:15:55:51 +0000] - csngen_adjust_time: gen state after 544e6b080001:1414425351:0:1 This is the log from ipa002 (which was the replica) and I am confused by the error logged, 'Can't contact LDAP server' because it surely can... ]# telnet 172.29.31.100 389 Trying 172.29.31.100... Connected to 172.29.31.100. Escape character is '^]'. ^] telnet> quit Connection closed. This is a new setup (setup master on Thursday, imported users from OpenLDAP and then setup replica on Friday). Had a few issues that I didn't understand which may or may not be relevant. First, after I made some changes to SSSD to allow for sudo and hopefully HBAC, it seemed like the directory server crashed and I had to restart it. Seemed like the same thing happened at the same time when I likewise configured the replica. Also, when I was trying to setup the replica, I had to resort to -skip-conncheck as it (presume Kerberos) not only asked for the password for admin@$DOMAIN but also the password for admin at ipa001.$DOMAIN for which I had never specifically setup any password and no password already used in Kerberos worked. Thanks Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Oct 27 16:25:35 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 27 Oct 2014 10:25:35 -0600 Subject: [Freeipa-users] multi-master replication In-Reply-To: <5b424b09f0a74ee0822b49ce2e886694@BLUPR08MB488.namprd08.prod.outlook.com> References: <544C3DA5.6010009@redhat.com> <544E4BA5.8020602@redhat.com> <5b424b09f0a74ee0822b49ce2e886694@BLUPR08MB488.namprd08.prod.outlook.com> Message-ID: <544E71FF.1040701@redhat.com> On 10/27/2014 10:12 AM, Craig White wrote: > > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Rich Megginson > *Sent:* Monday, October 27, 2014 6:42 AM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] multi-master replication > > On 10/25/2014 06:17 PM, Dmitri Pal wrote: > > On 10/24/2014 07:15 PM, Craig White wrote: > > *From:*freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Craig > White > *Sent:* Friday, October 24, 2014 4:02 PM > *To:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] multi-master replication > > I would have thought that changes go from replica to master > and not just master to replica. > > Is there something I have to do to make the changes > bi-directional? > > Replying to my own post? > > Logs are my friend ;-) > > [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.domain.local " (ipa001:389): Replication > bind with GSSAPI auth resumed > > [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.domain.local " (ipa001:389): Warning: > unable to replicate schema: rc=2 > > [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.domain.local " (ipa001:389): Failed to > send update operation to consumer (uniqueid > e018060f-5bb011e4-81078979-dc802980, CSN > 544aa346000000030000): Can't contact LDAP server. Will retry > later. > > [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.domain.local " (ipa001:389): Consumer > failed to replay change (uniqueid (null), CSN (null)): Can't > contact LDAP server(-1). Will retry later. > > > These NULLs look suspicious. > I hope DS gurus will have more for you on Monday. > > > 1) Yes, replication is fully bi-directional. > 2) What are the exact versions of dirsrv? rpm -q 389-ds-base on > supplier and consumer. > 3) Can you reproduce the problem using the replication log level on > both the supplier and consumer? > http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting > ---- > > 1)I sort of expected it to be ? that?s what had me worried when it > didn?t work as expected. > > 2)]# rpm -qa | grep 389 > > 389-ds-base-1.2.11.15-47.el6.x86_64 > > 389-ds-base-libs-1.2.11.15-47.el6.x86_64 > > 3)Upped the log levels ? hopefully this is a reasonable representative > from ipa002 (the replica) > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - conn=4 op=229791 > repl="dc=stt,dc=local": Acquired replica > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - conn=4 op=229791 > repl="dc=stt,dc=local": StartNSDS90ReplicationRequest: response=0 rc=0 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - conn=4 op=229791 > Relinquishing consumer connection extension > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > ruv_add_csn_inprogress: successfully inserted csn 544e6b02000000040000 > into pending list > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - Purged state > information from entry > krbprincipalname=ldap/ipa002.FQDN at FQDN,cn=services,cn=accounts,dc=stt,dc=local > up to CSN 5445307e000000040000 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog program > - _cl5GetDBFileByReplicaName: found DB object f32b80 for database > /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog program > - _cl5GetDBFileByReplicaName: found DB object f32b80 for database > /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - ruv_update_ruv: > successfully committed csn 544e6b02000000040000 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Disconnected from the consumer > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Warning: unable to replicate > schema: rc=2 > > [27/Oct/2014:15:55:47 +0000] - csngen_adjust_time: gen state before > 544e6b040001:1414425347:0:1 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog program > - _cl5GetDBFile: found DB object f32b80 for database > /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 > > [27/Oct/2014:15:55:47 +0000] - _cl5PositionCursorForReplay > (agmt="cn=meToipa001.FQDN" (ipa001:389)): Consumer RUV: > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): {replicageneration} > 544aa332000000040000 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 4 > ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e6b02000000040000 00000000 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 3 > ldap://ipa002.FQDN:389} 544aa339000000030000 544aa33f000400030000 00000000 > > [27/Oct/2014:15:55:47 +0000] - _cl5PositionCursorForReplay > (agmt="cn=meToipa001.FQDN" (ipa001:389)): Supplier RUV: > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): {replicageneration} > 544aa332000000040000 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 3 > ldap://ipa002.FQDN:389} 544aa339000000030000 544e6aa4000300030000 544e6aa3 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 4 > ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e6b02000000040000 544e6b03 > > [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - > clcache_get_buffer: found thread private buffer cache 7fe85000ea50 > > [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - > clcache_get_buffer: _pool is f89af0 _pool->pl_busy_lists is > 7fe8500197d0 _pool->pl_busy_lists->bl_buffers is 7fe85000ea50 > > [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - > session start: anchorcsn=544aa33f000400030000 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog program > - agmt="cn=meToipa001.FQDN" (ipa001:389): CSN 544aa33f000400030000 > found, position set for replay > > [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - > load=1 rec=1 csn=544aa346000000030000 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): replay_update: Sending add > operation > (dn="cn=KDC,cn=ipa002.FQDN,cn=masters,cn=ipa,cn=etc,dc=stt,dc=local" > csn=544aa346000000030000) > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): replay_update: Consumer could > not replay operation with csn 544aa346000000030000 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Failed to send update > operation to consumer (uniqueid e018060f-5bb011e4-81078979-dc802980, > CSN 544aa346000000030000): Can't contact LDAP server. Will retry later. > > [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain starting > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Connection disconnected by > another thread > > [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain: read > result for message_id 0 > > [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain: result 3, > -1, 2, 0, (null) > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Consumer failed to replay > change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). > Will retry later. > > [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain: got op > result 205 should finish 1 > > [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain exiting > > [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - > session end: state=0 load=1 sent=1 skipped=0 skipped_new_rid=0 > skipped_csn_gt_cons_maxcsn=0 skipped_up_to_date=0 skipped_csn_gt_ruv=0 > skipped_csn_covered=0 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Warning: unable to send > endReplication extended operation (Can't contact LDAP server) > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): State: sending_updates -> > start_backoff > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): State: start_backoff -> > start_backoff > > [27/Oct/2014:15:55:49 +0000] NSMMReplicationPlugin - conn=4 op=229793 > Acquired consumer connection extension > > [27/Oct/2014:15:55:49 +0000] NSMMReplicationPlugin - conn=4 op=229793 > repl="dc=stt,dc=local": Released replica held by locking_purl=conn=4 > id=229791 > > [27/Oct/2014:15:55:49 +0000] NSMMReplicationPlugin - conn=4 op=229793 > Relinquishing consumer connection extension > > [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): State: start_backoff -> backoff > > [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Trying non-secure > slapi_ldap_init_ext > > [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): binddn = , passwd = > > [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Replication bind with GSSAPI > auth resumed > > [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): No linger to cancel on the > connection > > [27/Oct/2014:15:55:51 +0000] - _csngen_adjust_local_time: gen state > before 544e6b040001:1414425347:0:1 > > [27/Oct/2014:15:55:51 +0000] - _csngen_adjust_local_time: gen state > after 544e6b080000:1414425351:0:1 > > [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Replica was successfully acquired. > > [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): State: backoff -> sending_updates > > [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - conn=4 op=229794 > Acquired consumer connection extension > > [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - conn=4 op=229794 > repl="dc=stt,dc=local": Begin incremental protocol > > [27/Oct/2014:15:55:51 +0000] - csngen_adjust_time: gen state before > 544e6b080001:1414425351:0:1 > > [27/Oct/2014:15:55:51 +0000] - csngen_adjust_time: gen state after > 544e6b080001:1414425351:0:1 > > This is the log from ipa002 (which was the replica) and I am confused > by the error logged, ?Can?t contact LDAP server? because it surely can? > > ]# telnet 172.29.31.100 389 > > Trying 172.29.31.100... > > Connected to 172.29.31.100. > > Escape character is '^]'. > > ^] > > telnet> quit > > Connection closed. > Replication uses Kerberos/GSSAPI and also possibly startTLS (I can't remember if ipa uses startTLS for an additional layer of encryption, or just uses Kerberos/GSSAPI for encryption). These might also cause the directory server to report connection failures even if the tcp layer connections are working. Can you provided excerpts from the 172.29.31.100 directory server access logs from around the time of the connection failures reported above? > This is a new setup (setup master on Thursday, imported users from > OpenLDAP and then setup replica on Friday). Had a few issues that I > didn?t understand which may or may not be relevant. First, after I > made some changes to SSSD to allow for sudo and hopefully HBAC, it > seemed like the directory server crashed and I had to restart it. > Crashed? If you can reproduce this problem, see http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes If there is a crash, we need to see the stack trace. > Seemed like the same thing happened at the same time when I likewise > configured the replica. > Again, see above. > Also, when I was trying to setup the replica, I had to resort to > ?skip-conncheck as it (presume Kerberos) not only asked for the > password for admin@$DOMAIN but also the password for > admin at ipa001.$DOMAIN for which I had > never specifically setup any password and no password already used in > Kerberos worked. > Hmm - maybe one of the ipa guys knows what the problem is here. > Thanks > > Craig > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Oct 27 16:30:05 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 27 Oct 2014 12:30:05 -0400 Subject: [Freeipa-users] Question About Properly Configuring DNS In-Reply-To: References: Message-ID: <20141027123005.1ba14cf4@willson.usersys.redhat.com> On Mon, 27 Oct 2014 14:07:42 +0000 "Trevor T Kates (Services - 6)" wrote: > Hi, all: > > I have four servers (two in one location, two in another) running IPA > 3.0 set to replicate like so: > > Location A Server 1 - - - - - - - - Location B Server 1 > | | > | | > | | > | | > Location A Server 2 - - - - - - - - Location B Server 2 > > Each server has DNS configured; however, I think I have configured > something inappropriately with respect to authoritative records. > > I have eight zones configured and ipa dnszone-show for any one of > them has Location B Server 1's name as authoritative. In each of the > eight zones, I have added NS records for the other three servers. On > all of the servers except Location B Server 1, /var/log/messages will > show: > > client x.xxx.x.xxx#14366: received notify for zone > 'x.xxx.x.in-addr.arpa': not authoritative > > This occurs for most, but not all, zones. Along with this: > > LDAP query timed out. Try to adjust "timeout" parameter > update_record (psearch) failed, dn > 'idnsname=xxx,idnsname=x.xxx.xx.in-addr.arpa.,cn=dns,dc=example,dc=com' > change type 0x0. Records can be outdated, run `rndc reload`: not found > > I feel like I've misconfigured a few things along the way and I'd > love some help. Along with that if anyone has recommendations on > things I should read to help me better understand what I should be > doing with DNS, I'd appreciate it. Uhmm sounds like a bug in reloading the info in the bind ldap plugin. Can you restart named on one of the other servers and tell if the warning goes away and/or if the client returns that server as authoritative after the bounce ? Simo. -- Simo Sorce * Red Hat, Inc * New York From Duncan.Innes at virginmoney.com Mon Oct 27 16:58:52 2014 From: Duncan.Innes at virginmoney.com (Innes, Duncan) Date: Mon, 27 Oct 2014 16:58:52 -0000 Subject: [Freeipa-users] Test connectivity before joining domain In-Reply-To: <20141027094511.5efc2ecf@willson.usersys.redhat.com> References: <56343345B145C043AE990701E3D193950478E1E5@EXVS2.nrplc.localnet> <20141027094511.5efc2ecf@willson.usersys.redhat.com> Message-ID: <56343345B145C043AE990701E3D193950478E1EA@EXVS2.nrplc.localnet> Thanks for all the suggestions guys. I was already working on an ldapsearch, so in the end I've gone with: /usr/bin/ldapsearch -h ipaserver.example.com -x -LLL -o nettimeout=2 -b "fqdn=client.example.com,cn=computers,cn=accounts,dc=example,dc=com" localityName Reason being that we demand an object is pre-created in IdM/FreeIPA before the install takes place. We then use localityName to describe roughly where in our maze of VLAN's the client actually sits. I know I could search for something more generic to provide a response, but it seems to make sense to check that the data we expect for a client is actually in LDAP already. There's a list of 8 IPA servers to check, so the timeout ensures we don't waste time waiting around for responses that just aren't going to come. Working well for now. Cheers Duncan -----Original Message----- From: Simo Sorce [mailto:simo at redhat.com] Sent: 27 October 2014 13:45 To: Innes, Duncan Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Test connectivity before joining domain On Mon, 27 Oct 2014 12:13:46 -0000 "Innes, Duncan" wrote: > Hi, > > Have been using `ping` to test connectivity from our clients to the > various IPA servers around the WAN before running an ldapsearch to > pull some details about the client from the LDAP database. > > Several new VLAN's have now come online that do not permit ping > traffic to be transmitted outside the VLAN, so clients on these LAN's > think they can't see any of my IPA servers and then fail the domain > join during the kickstart phase. > > Wondering if there's a consensus on how to check connectivity to IPA > servers on the network? Something that I can use during the kickstart > post-install phase. > > Current effort is: > > wget --timeout=1 --tries=1 --no-check-certificate > https://ipaserver1.example.com > > and then test $? for result. But this only tests ports 80/443 - which > authentication clients wont necessarily have access on. Can I > reliably test the other FreeIPA ports? 389, 636, 88, 464? These are > the ports that clients have to be allowed access to the IPA servers. Duncan, if you know python you can look into the ipa-replica-install tool, as it does a full check of accessibility. You do not need all those tests (as you do not need connection back from the server for example). But you can take inspiration there to see how we test each service. Simo. -- Simo Sorce * Red Hat, Inc * New York This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com From CWhite at skytouchtechnology.com Mon Oct 27 17:16:39 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Mon, 27 Oct 2014 17:16:39 +0000 Subject: [Freeipa-users] multi-master replication In-Reply-To: <544E71FF.1040701@redhat.com> References: <544C3DA5.6010009@redhat.com> <544E4BA5.8020602@redhat.com> <5b424b09f0a74ee0822b49ce2e886694@BLUPR08MB488.namprd08.prod.outlook.com> <544E71FF.1040701@redhat.com> Message-ID: From: Rich Megginson [mailto:rmeggins at redhat.com] Sent: Monday, October 27, 2014 9:26 AM To: Craig White; freeipa-users at redhat.com Subject: Re: [Freeipa-users] multi-master replication On 10/27/2014 10:12 AM, Craig White wrote: From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson Sent: Monday, October 27, 2014 6:42 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] multi-master replication On 10/25/2014 06:17 PM, Dmitri Pal wrote: On 10/24/2014 07:15 PM, Craig White wrote: From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Craig White Sent: Friday, October 24, 2014 4:02 PM To: freeipa-users at redhat.com Subject: [Freeipa-users] multi-master replication I would have thought that changes go from replica to master and not just master to replica. Is there something I have to do to make the changes bi-directional? Replying to my own post... Logs are my friend ;-) [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.domain.local " (ipa001:389): Replication bind with GSSAPI auth resumed [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.domain.local " (ipa001:389): Warning: unable to replicate schema: rc=2 [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.domain.local " (ipa001:389): Failed to send update operation to consumer (uniqueid e018060f-5bb011e4-81078979-dc802980, CSN 544aa346000000030000): Can't contact LDAP server. Will retry later. [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.domain.local " (ipa001:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. These NULLs look suspicious. I hope DS gurus will have more for you on Monday. 1) Yes, replication is fully bi-directional. 2) What are the exact versions of dirsrv? rpm -q 389-ds-base on supplier and consumer. 3) Can you reproduce the problem using the replication log level on both the supplier and consumer? http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting ---- 1) I sort of expected it to be - that's what had me worried when it didn't work as expected. 2) ]# rpm -qa | grep 389 389-ds-base-1.2.11.15-47.el6.x86_64 389-ds-base-libs-1.2.11.15-47.el6.x86_64 3) Upped the log levels - hopefully this is a reasonable representative from ipa002 (the replica) [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - conn=4 op=229791 repl="dc=stt,dc=local": Acquired replica [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - conn=4 op=229791 repl="dc=stt,dc=local": StartNSDS90ReplicationRequest: response=0 rc=0 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - conn=4 op=229791 Relinquishing consumer connection extension [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 544e6b02000000040000 into pending list [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - Purged state information from entry krbprincipalname=ldap/ipa002.FQDN at FQDN,cn=services,cn=accounts,dc=stt,dc=local up to CSN 5445307e000000040000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object f32b80 for database /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object f32b80 for database /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - ruv_update_ruv: successfully committed csn 544e6b02000000040000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Disconnected from the consumer [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Warning: unable to replicate schema: rc=2 [27/Oct/2014:15:55:47 +0000] - csngen_adjust_time: gen state before 544e6b040001:1414425347:0:1 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFile: found DB object f32b80 for database /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 [27/Oct/2014:15:55:47 +0000] - _cl5PositionCursorForReplay (agmt="cn=meToipa001.FQDN" (ipa001:389)): Consumer RUV: [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replicageneration} 544aa332000000040000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 4 ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e6b02000000040000 00000000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 3 ldap://ipa002.FQDN:389} 544aa339000000030000 544aa33f000400030000 00000000 [27/Oct/2014:15:55:47 +0000] - _cl5PositionCursorForReplay (agmt="cn=meToipa001.FQDN" (ipa001:389)): Supplier RUV: [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replicageneration} 544aa332000000040000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 3 ldap://ipa002.FQDN:389} 544aa339000000030000 544e6aa4000300030000 544e6aa3 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 4 ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e6b02000000040000 544e6b03 [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - clcache_get_buffer: found thread private buffer cache 7fe85000ea50 [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - clcache_get_buffer: _pool is f89af0 _pool->pl_busy_lists is 7fe8500197d0 _pool->pl_busy_lists->bl_buffers is 7fe85000ea50 [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - session start: anchorcsn=544aa33f000400030000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog program - agmt="cn=meToipa001.FQDN" (ipa001:389): CSN 544aa33f000400030000 found, position set for replay [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - load=1 rec=1 csn=544aa346000000030000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): replay_update: Sending add operation (dn="cn=KDC,cn=ipa002.FQDN,cn=masters,cn=ipa,cn=etc,dc=stt,dc=local" csn=544aa346000000030000) [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): replay_update: Consumer could not replay operation with csn 544aa346000000030000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Failed to send update operation to consumer (uniqueid e018060f-5bb011e4-81078979-dc802980, CSN 544aa346000000030000): Can't contact LDAP server. Will retry later. [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain starting [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Connection disconnected by another thread [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain: read result for message_id 0 [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain: result 3, -1, 2, 0, (null) [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain: got op result 205 should finish 1 [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain exiting [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - session end: state=0 load=1 sent=1 skipped=0 skipped_new_rid=0 skipped_csn_gt_cons_maxcsn=0 skipped_up_to_date=0 skipped_csn_gt_ruv=0 skipped_csn_covered=0 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): State: sending_updates -> start_backoff [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): State: start_backoff -> start_backoff [27/Oct/2014:15:55:49 +0000] NSMMReplicationPlugin - conn=4 op=229793 Acquired consumer connection extension [27/Oct/2014:15:55:49 +0000] NSMMReplicationPlugin - conn=4 op=229793 repl="dc=stt,dc=local": Released replica held by locking_purl=conn=4 id=229791 [27/Oct/2014:15:55:49 +0000] NSMMReplicationPlugin - conn=4 op=229793 Relinquishing consumer connection extension [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): State: start_backoff -> backoff [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Trying non-secure slapi_ldap_init_ext [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): binddn = , passwd = [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Replication bind with GSSAPI auth resumed [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): No linger to cancel on the connection [27/Oct/2014:15:55:51 +0000] - _csngen_adjust_local_time: gen state before 544e6b040001:1414425347:0:1 [27/Oct/2014:15:55:51 +0000] - _csngen_adjust_local_time: gen state after 544e6b080000:1414425351:0:1 [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Replica was successfully acquired. [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): State: backoff -> sending_updates [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - conn=4 op=229794 Acquired consumer connection extension [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - conn=4 op=229794 repl="dc=stt,dc=local": Begin incremental protocol [27/Oct/2014:15:55:51 +0000] - csngen_adjust_time: gen state before 544e6b080001:1414425351:0:1 [27/Oct/2014:15:55:51 +0000] - csngen_adjust_time: gen state after 544e6b080001:1414425351:0:1 This is the log from ipa002 (which was the replica) and I am confused by the error logged, 'Can't contact LDAP server' because it surely can... ]# telnet 172.29.31.100 389 Trying 172.29.31.100... Connected to 172.29.31.100. Escape character is '^]'. ^] telnet> quit Connection closed. Replication uses Kerberos/GSSAPI and also possibly startTLS (I can't remember if ipa uses startTLS for an additional layer of encryption, or just uses Kerberos/GSSAPI for encryption). These might also cause the directory server to report connection failures even if the tcp layer connections are working. Can you provided excerpts from the 172.29.31.100 directory server access logs from around the time of the connection failures reported above? This is a new setup (setup master on Thursday, imported users from OpenLDAP and then setup replica on Friday). Had a few issues that I didn't understand which may or may not be relevant. First, after I made some changes to SSSD to allow for sudo and hopefully HBAC, it seemed like the directory server crashed and I had to restart it. Crashed? If you can reproduce this problem, see http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes If there is a crash, we need to see the stack trace. Seemed like the same thing happened at the same time when I likewise configured the replica. Again, see above. Also, when I was trying to setup the replica, I had to resort to -skip-conncheck as it (presume Kerberos) not only asked for the password for admin@$DOMAIN but also the password for admin at ipa001.$DOMAIN for which I had never specifically setup any password and no password already used in Kerberos worked. Hmm - maybe one of the ipa guys knows what the problem is here. ---- I'll have to look through the logs to see if there's anything useful for the LDAP / dirsrv crashing when first setup & configuring SSSD/pam but I know that the logging would have been default/terse at that time. Logs on the master from that same time shown on the replica above show only... [24/Oct/2014:23:08:15 +0000] - sasl_io_recv failed to decode packet for connection 4037 [24/Oct/2014:23:08:20 +0000] - sasl_io_recv failed to decode packet for connection 4038 And this hopefully should help identify the problem - verbose logging on Replica [27/Oct/2014:17:07:06 +0000] - _csngen_adjust_local_time: gen state after 544e7bbb0000:1414429626:0:1 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Replica was successfully acquired. [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): State: backoff -> sending_updates [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - conn=4 op=233926 Acquired consumer connection extension [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - conn=4 op=233926 repl="dc=stt,dc=local": Begin incremental protocol [27/Oct/2014:17:07:06 +0000] - csngen_adjust_time: gen state before 544e7bbb0001:1414429626:0:1 [27/Oct/2014:17:07:06 +0000] - csngen_adjust_time: gen state after 544e7bbb0001:1414429626:0:1 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - conn=4 op=233926 repl="dc=stt,dc=local": Acquired replica [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - conn=4 op=233926 repl="dc=stt,dc=local": StartNSDS90ReplicationRequest: response=0 rc=0 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - conn=4 op=233926 Relinquishing consumer connection extension [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 544e7bb9000000040000 into pending list [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - Purged state information from entry krbprincipalname=ldap/ipa002.FQDN at FQDN,cn=services,cn=accounts,dc=stt,dc=local up to CSN 54454135000000040000 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object f32b80 for database /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object f32b80 for database /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - ruv_update_ruv: successfully committed csn 544e7bb9000000040000 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Disconnected from the consumer [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Warning: unable to replicate schema: rc=2 [27/Oct/2014:17:07:06 +0000] - csngen_adjust_time: gen state before 544e7bbb0001:1414429626:0:1 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFile: found DB object f32b80 for database /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 [27/Oct/2014:17:07:06 +0000] - _cl5PositionCursorForReplay (agmt="cn=meToipa001.FQDN" (ipa001:389)): Consumer RUV: [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replicageneration} 544aa332000000040000 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 4 ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e7bb9000000040000 00000000 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 3 ldap://ipa002.FQDN:389} 544aa339000000030000 544aa33f000400030000 00000000 [27/Oct/2014:17:07:06 +0000] - _cl5PositionCursorForReplay (agmt="cn=meToipa001.FQDN" (ipa001:389)): Supplier RUV: [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replicageneration} 544aa332000000040000 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 3 ldap://ipa002.FQDN:389} 544aa339000000030000 544e7a1c000200030000 544e7a1b [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 4 ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e7bb9000000040000 544e7bba [27/Oct/2014:17:07:06 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - clcache_get_buffer: found thread private buffer cache 7fe85000ea50 [27/Oct/2014:17:07:06 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - clcache_get_buffer: _pool is f89af0 _pool->pl_busy_lists is 7fe8500197d0 _pool->pl_busy_lists->bl_buffers is 7fe85000ea50 [27/Oct/2014:17:07:06 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - session start: anchorcsn=544aa33f000400030000 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - changelog program - agmt="cn=meToipa001.FQDN" (ipa001:389): CSN 544aa33f000400030000 found, position set for replay [27/Oct/2014:17:07:06 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - load=1 rec=1 csn=544aa346000000030000 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): replay_update: Sending add operation (dn="cn=KDC,cn=ipa002.FQDN,cn=masters,cn=ipa,cn=etc,dc=stt,dc=local" csn=544aa346000000030000) [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): replay_update: Consumer could not replay operation with csn 544aa346000000030000 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Failed to send update operation to consumer (uniqueid e018060f-5bb011e4-81078979-dc802980, CSN 544aa346000000030000): Can't contact LDAP server. Will retry later. [27/Oct/2014:17:07:06 +0000] - repl5_inc_result_threadmain starting [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Connection disconnected by another thread [27/Oct/2014:17:07:06 +0000] - repl5_inc_result_threadmain: read result for message_id 0 [27/Oct/2014:17:07:06 +0000] - repl5_inc_result_threadmain: result 3, -1, 2, 0, (null) [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. [27/Oct/2014:17:07:06 +0000] - repl5_inc_result_threadmain: got op result 205 should finish 1 [27/Oct/2014:17:07:06 +0000] - repl5_inc_result_threadmain exiting [27/Oct/2014:17:07:06 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - session end: state=0 load=1 sent=1 skipped=0 skipped_new_rid=0 skipped_csn_gt_cons_maxcsn=0 skipped_up_to_date=0 skipped_csn_gt_ruv=0 skipped_csn_covered=0 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) And Simultaneous verbose logging on Master [27/Oct/2014:17:06:06 +0000] - repl5_inc_result_threadmain exiting [27/Oct/2014:17:06:06 +0000] agmt="cn=meToipa002.FQDN" (ipa002:389) - session end: state=5 load=1 sent=1 skipped=0 skipped_new_rid=0 skipped_csn_gt_cons_m axcsn=0 skipped_up_to_date=0 skipped_csn_gt_ruv=0 skipped_csn_covered=0 [27/Oct/2014:17:06:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): Successfully released consumer [27/Oct/2014:17:06:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): Beginning linger on the connection [27/Oct/2014:17:06:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): State: sending_updates -> wait_for_changes [27/Oct/2014:17:06:08 +0000] - _csngen_adjust_local_time: gen state before 544e7b820002:1414429564:2:4 [27/Oct/2014:17:06:08 +0000] - _csngen_adjust_local_time: gen state after 544e7b840000:1414429568:0:4 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 544e7b84000000040000 into pending list [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - Purged state information from entry krbprincipalname=ldap/ipa002.FQDN at FQDN,cn=services,cn=acco unts,dc=stt,dc=local up to CSN 54454100000000040000 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - conn=69255 op=5 Acquired consumer connection extension [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - conn=69255 op=5 repl="dc=stt,dc=local": Begin incremental protocol [27/Oct/2014:17:06:08 +0000] - csngen_adjust_time: gen state before 544e7b840001:1414429568:0:4 [27/Oct/2014:17:06:08 +0000] - csngen_adjust_time: gen state after 544e7b860001:1414429568:2:4 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - conn=69255 op=5 repl="dc=stt,dc=local": Acquired replica [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - conn=69255 op=5 repl="dc=stt,dc=local": StartNSDS90ReplicationRequest: response=0 rc=0 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - conn=69255 op=5 Relinquishing consumer connection extension [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 7fb95801fbf0 for database /var/lib/dirsrv/slapd-STT-LOCA L/cldb/d7273483-5bb011e4-8073dfa6-7d9cbbef_544aa332000000040000.db4 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 7fb95801fbf0 for database /var/lib/dirsrv/slapd-STT-LOCA L/cldb/d7273483-5bb011e4-8073dfa6-7d9cbbef_544aa332000000040000.db4 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - ruv_update_ruv: successfully committed csn 544e7b84000000040000 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): State: wait_for_changes -> wait_for_changes [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): State: wait_for_changes -> ready_to_acquire_replica [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): Cancelling linger on the connection [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): Replica was successfully acquired. [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): State: ready_to_acquire_replica -> sending_updates [27/Oct/2014:17:06:08 +0000] - csngen_adjust_time: gen state before 544e7b860002:1414429568:2:4 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFile: found DB object 7fb95801fbf0 for database /var/lib/dirsrv/slapd-STT-LOCAL/cldb/d7273483-5bb011e4-8073dfa6-7d9cbbef_544aa332000000040000.db4 [27/Oct/2014:17:06:08 +0000] - _cl5PositionCursorForReplay (agmt="cn=meToipa002.FQDN" (ipa002:389)): Consumer RUV: [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): {replicageneration} 544aa332000000040000 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): {replica 3 ldap://ipa002.FQDN:389} 544aa339000000030000 544e7a1c000200030000 00000000 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): {replica 4 ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e7b80000000040000 00000000 [27/Oct/2014:17:06:08 +0000] - _cl5PositionCursorForReplay (agmt="cn=meToipa002.FQDN" (ipa002:389)): Supplier RUV: [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): {replicageneration} 544aa332000000040000 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): {replica 4 ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e7b84000000040000 544e7b80 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): {replica 3 ldap://ipa002.FQDN:389} 544aa339000000030000 544aa33f000400030000 544aa33e [27/Oct/2014:17:06:08 +0000] agmt="cn=meToipa002.FQDN" (ipa002:389) - clcache_get_buffer: found thread private buffer cache 135d780 [27/Oct/2014:17:06:08 +0000] agmt="cn=meToipa002.FQDN" (ipa002:389) - clcache_get_buffer: _pool is 11eaca0 _pool->pl_busy_lists is 1239060 _pool->pl_busy_lists->bl_buffers is 135d780 [27/Oct/2014:17:06:08 +0000] agmt="cn=meToipa002.FQDN" (ipa002:389) - session start: anchorcsn=544e7b80000000040000 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - changelog program - agmt="cn=meToipa002.FQDN" (ipa002:389): CSN 544e7b80000000040000 found, position set for replay [27/Oct/2014:17:06:08 +0000] agmt="cn=meToipa002.FQDN" (ipa002:389) - load=1 rec=1 csn=544e7b84000000040000 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): replay_update: Sending modify operation (dn="krbprincipalname=ldap/ipa002.FQDN at FQDN,cn=services,cn=accounts,dc=stt,dc=local" csn=544e7b84000000040000) [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): replay_update: Consumer successfully sent operation with csn 544e7b84000000040000 [27/Oct/2014:17:06:08 +0000] agmt="cn=meToipa002.FQDN" (ipa002:389) - clcache_load_buffer: rc=-30988 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): No more updates to send (cl5GetNextOperationToReplay) [27/Oct/2014:17:06:08 +0000] - repl5_inc_waitfor_async_results: 0 195864 [27/Oct/2014:17:06:08 +0000] - repl5_inc_result_threadmain starting [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: result 3, 0, 0, 195864, (null) [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - sasl_io_recv failed to decode packet for connection 69255 [27/Oct/2014:17:06:09 +0000] NSMMReplicationPlugin - conn=0 op=-1 repl="dc=stt,dc=local": Released replica held by locking_purl=conn=69255 id=5 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_waitfor_async_results: 195864 195864 -------------- next part -------------- An HTML attachment was scrubbed... URL: From CWhite at skytouchtechnology.com Mon Oct 27 17:41:44 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Mon, 27 Oct 2014 17:41:44 +0000 Subject: [Freeipa-users] multi-master replication In-Reply-To: References: <544C3DA5.6010009@redhat.com> <544E4BA5.8020602@redhat.com> <5b424b09f0a74ee0822b49ce2e886694@BLUPR08MB488.namprd08.prod.outlook.com> <544E71FF.1040701@redhat.com> Message-ID: <8ff07afa639047f3970f0f0621bd655a@BLUPR08MB488.namprd08.prod.outlook.com> Maybe fixed - seems to be replicating now... https://bugzilla.redhat.com/show_bug.cgi?id=953653 Why don't they incorporate that into the released RHEL version? From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Craig White Sent: Monday, October 27, 2014 10:17 AM To: Rich Megginson; freeipa-users at redhat.com Subject: Re: [Freeipa-users] multi-master replication From: Rich Megginson [mailto:rmeggins at redhat.com] Sent: Monday, October 27, 2014 9:26 AM To: Craig White; freeipa-users at redhat.com Subject: Re: [Freeipa-users] multi-master replication On 10/27/2014 10:12 AM, Craig White wrote: From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson Sent: Monday, October 27, 2014 6:42 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] multi-master replication On 10/25/2014 06:17 PM, Dmitri Pal wrote: On 10/24/2014 07:15 PM, Craig White wrote: From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Craig White Sent: Friday, October 24, 2014 4:02 PM To: freeipa-users at redhat.com Subject: [Freeipa-users] multi-master replication I would have thought that changes go from replica to master and not just master to replica. Is there something I have to do to make the changes bi-directional? Replying to my own post... Logs are my friend ;-) [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.domain.local " (ipa001:389): Replication bind with GSSAPI auth resumed [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.domain.local " (ipa001:389): Warning: unable to replicate schema: rc=2 [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.domain.local " (ipa001:389): Failed to send update operation to consumer (uniqueid e018060f-5bb011e4-81078979-dc802980, CSN 544aa346000000030000): Can't contact LDAP server. Will retry later. [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.domain.local " (ipa001:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. These NULLs look suspicious. I hope DS gurus will have more for you on Monday. 1) Yes, replication is fully bi-directional. 2) What are the exact versions of dirsrv? rpm -q 389-ds-base on supplier and consumer. 3) Can you reproduce the problem using the replication log level on both the supplier and consumer? http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting ---- 1) I sort of expected it to be - that's what had me worried when it didn't work as expected. 2) ]# rpm -qa | grep 389 389-ds-base-1.2.11.15-47.el6.x86_64 389-ds-base-libs-1.2.11.15-47.el6.x86_64 3) Upped the log levels - hopefully this is a reasonable representative from ipa002 (the replica) [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - conn=4 op=229791 repl="dc=stt,dc=local": Acquired replica [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - conn=4 op=229791 repl="dc=stt,dc=local": StartNSDS90ReplicationRequest: response=0 rc=0 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - conn=4 op=229791 Relinquishing consumer connection extension [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 544e6b02000000040000 into pending list [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - Purged state information from entry krbprincipalname=ldap/ipa002.FQDN at FQDN,cn=services,cn=accounts,dc=stt,dc=local up to CSN 5445307e000000040000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object f32b80 for database /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object f32b80 for database /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - ruv_update_ruv: successfully committed csn 544e6b02000000040000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Disconnected from the consumer [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Warning: unable to replicate schema: rc=2 [27/Oct/2014:15:55:47 +0000] - csngen_adjust_time: gen state before 544e6b040001:1414425347:0:1 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFile: found DB object f32b80 for database /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 [27/Oct/2014:15:55:47 +0000] - _cl5PositionCursorForReplay (agmt="cn=meToipa001.FQDN" (ipa001:389)): Consumer RUV: [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replicageneration} 544aa332000000040000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 4 ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e6b02000000040000 00000000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 3 ldap://ipa002.FQDN:389} 544aa339000000030000 544aa33f000400030000 00000000 [27/Oct/2014:15:55:47 +0000] - _cl5PositionCursorForReplay (agmt="cn=meToipa001.FQDN" (ipa001:389)): Supplier RUV: [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replicageneration} 544aa332000000040000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 3 ldap://ipa002.FQDN:389} 544aa339000000030000 544e6aa4000300030000 544e6aa3 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 4 ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e6b02000000040000 544e6b03 [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - clcache_get_buffer: found thread private buffer cache 7fe85000ea50 [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - clcache_get_buffer: _pool is f89af0 _pool->pl_busy_lists is 7fe8500197d0 _pool->pl_busy_lists->bl_buffers is 7fe85000ea50 [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - session start: anchorcsn=544aa33f000400030000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog program - agmt="cn=meToipa001.FQDN" (ipa001:389): CSN 544aa33f000400030000 found, position set for replay [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - load=1 rec=1 csn=544aa346000000030000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): replay_update: Sending add operation (dn="cn=KDC,cn=ipa002.FQDN,cn=masters,cn=ipa,cn=etc,dc=stt,dc=local" csn=544aa346000000030000) [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): replay_update: Consumer could not replay operation with csn 544aa346000000030000 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Failed to send update operation to consumer (uniqueid e018060f-5bb011e4-81078979-dc802980, CSN 544aa346000000030000): Can't contact LDAP server. Will retry later. [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain starting [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Connection disconnected by another thread [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain: read result for message_id 0 [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain: result 3, -1, 2, 0, (null) [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain: got op result 205 should finish 1 [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain exiting [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - session end: state=0 load=1 sent=1 skipped=0 skipped_new_rid=0 skipped_csn_gt_cons_maxcsn=0 skipped_up_to_date=0 skipped_csn_gt_ruv=0 skipped_csn_covered=0 [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): State: sending_updates -> start_backoff [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): State: start_backoff -> start_backoff [27/Oct/2014:15:55:49 +0000] NSMMReplicationPlugin - conn=4 op=229793 Acquired consumer connection extension [27/Oct/2014:15:55:49 +0000] NSMMReplicationPlugin - conn=4 op=229793 repl="dc=stt,dc=local": Released replica held by locking_purl=conn=4 id=229791 [27/Oct/2014:15:55:49 +0000] NSMMReplicationPlugin - conn=4 op=229793 Relinquishing consumer connection extension [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): State: start_backoff -> backoff [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Trying non-secure slapi_ldap_init_ext [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): binddn = , passwd = [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Replication bind with GSSAPI auth resumed [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): No linger to cancel on the connection [27/Oct/2014:15:55:51 +0000] - _csngen_adjust_local_time: gen state before 544e6b040001:1414425347:0:1 [27/Oct/2014:15:55:51 +0000] - _csngen_adjust_local_time: gen state after 544e6b080000:1414425351:0:1 [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Replica was successfully acquired. [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): State: backoff -> sending_updates [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - conn=4 op=229794 Acquired consumer connection extension [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - conn=4 op=229794 repl="dc=stt,dc=local": Begin incremental protocol [27/Oct/2014:15:55:51 +0000] - csngen_adjust_time: gen state before 544e6b080001:1414425351:0:1 [27/Oct/2014:15:55:51 +0000] - csngen_adjust_time: gen state after 544e6b080001:1414425351:0:1 This is the log from ipa002 (which was the replica) and I am confused by the error logged, 'Can't contact LDAP server' because it surely can... ]# telnet 172.29.31.100 389 Trying 172.29.31.100... Connected to 172.29.31.100. Escape character is '^]'. ^] telnet> quit Connection closed. Replication uses Kerberos/GSSAPI and also possibly startTLS (I can't remember if ipa uses startTLS for an additional layer of encryption, or just uses Kerberos/GSSAPI for encryption). These might also cause the directory server to report connection failures even if the tcp layer connections are working. Can you provided excerpts from the 172.29.31.100 directory server access logs from around the time of the connection failures reported above? This is a new setup (setup master on Thursday, imported users from OpenLDAP and then setup replica on Friday). Had a few issues that I didn't understand which may or may not be relevant. First, after I made some changes to SSSD to allow for sudo and hopefully HBAC, it seemed like the directory server crashed and I had to restart it. Crashed? If you can reproduce this problem, see http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes If there is a crash, we need to see the stack trace. Seemed like the same thing happened at the same time when I likewise configured the replica. Again, see above. Also, when I was trying to setup the replica, I had to resort to -skip-conncheck as it (presume Kerberos) not only asked for the password for admin@$DOMAIN but also the password for admin at ipa001.$DOMAIN for which I had never specifically setup any password and no password already used in Kerberos worked. Hmm - maybe one of the ipa guys knows what the problem is here. ---- I'll have to look through the logs to see if there's anything useful for the LDAP / dirsrv crashing when first setup & configuring SSSD/pam but I know that the logging would have been default/terse at that time. Logs on the master from that same time shown on the replica above show only... [24/Oct/2014:23:08:15 +0000] - sasl_io_recv failed to decode packet for connection 4037 [24/Oct/2014:23:08:20 +0000] - sasl_io_recv failed to decode packet for connection 4038 And this hopefully should help identify the problem - verbose logging on Replica [27/Oct/2014:17:07:06 +0000] - _csngen_adjust_local_time: gen state after 544e7bbb0000:1414429626:0:1 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Replica was successfully acquired. [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): State: backoff -> sending_updates [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - conn=4 op=233926 Acquired consumer connection extension [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - conn=4 op=233926 repl="dc=stt,dc=local": Begin incremental protocol [27/Oct/2014:17:07:06 +0000] - csngen_adjust_time: gen state before 544e7bbb0001:1414429626:0:1 [27/Oct/2014:17:07:06 +0000] - csngen_adjust_time: gen state after 544e7bbb0001:1414429626:0:1 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - conn=4 op=233926 repl="dc=stt,dc=local": Acquired replica [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - conn=4 op=233926 repl="dc=stt,dc=local": StartNSDS90ReplicationRequest: response=0 rc=0 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - conn=4 op=233926 Relinquishing consumer connection extension [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 544e7bb9000000040000 into pending list [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - Purged state information from entry krbprincipalname=ldap/ipa002.FQDN at FQDN,cn=services,cn=accounts,dc=stt,dc=local up to CSN 54454135000000040000 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object f32b80 for database /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object f32b80 for database /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - ruv_update_ruv: successfully committed csn 544e7bb9000000040000 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Disconnected from the consumer [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Warning: unable to replicate schema: rc=2 [27/Oct/2014:17:07:06 +0000] - csngen_adjust_time: gen state before 544e7bbb0001:1414429626:0:1 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFile: found DB object f32b80 for database /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 [27/Oct/2014:17:07:06 +0000] - _cl5PositionCursorForReplay (agmt="cn=meToipa001.FQDN" (ipa001:389)): Consumer RUV: [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replicageneration} 544aa332000000040000 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 4 ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e7bb9000000040000 00000000 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 3 ldap://ipa002.FQDN:389} 544aa339000000030000 544aa33f000400030000 00000000 [27/Oct/2014:17:07:06 +0000] - _cl5PositionCursorForReplay (agmt="cn=meToipa001.FQDN" (ipa001:389)): Supplier RUV: [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replicageneration} 544aa332000000040000 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 3 ldap://ipa002.FQDN:389} 544aa339000000030000 544e7a1c000200030000 544e7a1b [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 4 ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e7bb9000000040000 544e7bba [27/Oct/2014:17:07:06 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - clcache_get_buffer: found thread private buffer cache 7fe85000ea50 [27/Oct/2014:17:07:06 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - clcache_get_buffer: _pool is f89af0 _pool->pl_busy_lists is 7fe8500197d0 _pool->pl_busy_lists->bl_buffers is 7fe85000ea50 [27/Oct/2014:17:07:06 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - session start: anchorcsn=544aa33f000400030000 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - changelog program - agmt="cn=meToipa001.FQDN" (ipa001:389): CSN 544aa33f000400030000 found, position set for replay [27/Oct/2014:17:07:06 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - load=1 rec=1 csn=544aa346000000030000 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): replay_update: Sending add operation (dn="cn=KDC,cn=ipa002.FQDN,cn=masters,cn=ipa,cn=etc,dc=stt,dc=local" csn=544aa346000000030000) [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): replay_update: Consumer could not replay operation with csn 544aa346000000030000 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Failed to send update operation to consumer (uniqueid e018060f-5bb011e4-81078979-dc802980, CSN 544aa346000000030000): Can't contact LDAP server. Will retry later. [27/Oct/2014:17:07:06 +0000] - repl5_inc_result_threadmain starting [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Connection disconnected by another thread [27/Oct/2014:17:07:06 +0000] - repl5_inc_result_threadmain: read result for message_id 0 [27/Oct/2014:17:07:06 +0000] - repl5_inc_result_threadmain: result 3, -1, 2, 0, (null) [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. [27/Oct/2014:17:07:06 +0000] - repl5_inc_result_threadmain: got op result 205 should finish 1 [27/Oct/2014:17:07:06 +0000] - repl5_inc_result_threadmain exiting [27/Oct/2014:17:07:06 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - session end: state=0 load=1 sent=1 skipped=0 skipped_new_rid=0 skipped_csn_gt_cons_maxcsn=0 skipped_up_to_date=0 skipped_csn_gt_ruv=0 skipped_csn_covered=0 [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa001.FQDN" (ipa001:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) And Simultaneous verbose logging on Master [27/Oct/2014:17:06:06 +0000] - repl5_inc_result_threadmain exiting [27/Oct/2014:17:06:06 +0000] agmt="cn=meToipa002.FQDN" (ipa002:389) - session end: state=5 load=1 sent=1 skipped=0 skipped_new_rid=0 skipped_csn_gt_cons_m axcsn=0 skipped_up_to_date=0 skipped_csn_gt_ruv=0 skipped_csn_covered=0 [27/Oct/2014:17:06:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): Successfully released consumer [27/Oct/2014:17:06:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): Beginning linger on the connection [27/Oct/2014:17:06:06 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): State: sending_updates -> wait_for_changes [27/Oct/2014:17:06:08 +0000] - _csngen_adjust_local_time: gen state before 544e7b820002:1414429564:2:4 [27/Oct/2014:17:06:08 +0000] - _csngen_adjust_local_time: gen state after 544e7b840000:1414429568:0:4 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 544e7b84000000040000 into pending list [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - Purged state information from entry krbprincipalname=ldap/ipa002.FQDN at FQDN,cn=services,cn=acco unts,dc=stt,dc=local up to CSN 54454100000000040000 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - conn=69255 op=5 Acquired consumer connection extension [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - conn=69255 op=5 repl="dc=stt,dc=local": Begin incremental protocol [27/Oct/2014:17:06:08 +0000] - csngen_adjust_time: gen state before 544e7b840001:1414429568:0:4 [27/Oct/2014:17:06:08 +0000] - csngen_adjust_time: gen state after 544e7b860001:1414429568:2:4 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - conn=69255 op=5 repl="dc=stt,dc=local": Acquired replica [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - conn=69255 op=5 repl="dc=stt,dc=local": StartNSDS90ReplicationRequest: response=0 rc=0 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - conn=69255 op=5 Relinquishing consumer connection extension [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 7fb95801fbf0 for database /var/lib/dirsrv/slapd-STT-LOCA L/cldb/d7273483-5bb011e4-8073dfa6-7d9cbbef_544aa332000000040000.db4 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 7fb95801fbf0 for database /var/lib/dirsrv/slapd-STT-LOCA L/cldb/d7273483-5bb011e4-8073dfa6-7d9cbbef_544aa332000000040000.db4 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - ruv_update_ruv: successfully committed csn 544e7b84000000040000 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): State: wait_for_changes -> wait_for_changes [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): State: wait_for_changes -> ready_to_acquire_replica [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): Cancelling linger on the connection [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): Replica was successfully acquired. [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): State: ready_to_acquire_replica -> sending_updates [27/Oct/2014:17:06:08 +0000] - csngen_adjust_time: gen state before 544e7b860002:1414429568:2:4 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFile: found DB object 7fb95801fbf0 for database /var/lib/dirsrv/slapd-STT-LOCAL/cldb/d7273483-5bb011e4-8073dfa6-7d9cbbef_544aa332000000040000.db4 [27/Oct/2014:17:06:08 +0000] - _cl5PositionCursorForReplay (agmt="cn=meToipa002.FQDN" (ipa002:389)): Consumer RUV: [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): {replicageneration} 544aa332000000040000 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): {replica 3 ldap://ipa002.FQDN:389} 544aa339000000030000 544e7a1c000200030000 00000000 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): {replica 4 ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e7b80000000040000 00000000 [27/Oct/2014:17:06:08 +0000] - _cl5PositionCursorForReplay (agmt="cn=meToipa002.FQDN" (ipa002:389)): Supplier RUV: [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): {replicageneration} 544aa332000000040000 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): {replica 4 ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e7b84000000040000 544e7b80 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): {replica 3 ldap://ipa002.FQDN:389} 544aa339000000030000 544aa33f000400030000 544aa33e [27/Oct/2014:17:06:08 +0000] agmt="cn=meToipa002.FQDN" (ipa002:389) - clcache_get_buffer: found thread private buffer cache 135d780 [27/Oct/2014:17:06:08 +0000] agmt="cn=meToipa002.FQDN" (ipa002:389) - clcache_get_buffer: _pool is 11eaca0 _pool->pl_busy_lists is 1239060 _pool->pl_busy_lists->bl_buffers is 135d780 [27/Oct/2014:17:06:08 +0000] agmt="cn=meToipa002.FQDN" (ipa002:389) - session start: anchorcsn=544e7b80000000040000 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - changelog program - agmt="cn=meToipa002.FQDN" (ipa002:389): CSN 544e7b80000000040000 found, position set for replay [27/Oct/2014:17:06:08 +0000] agmt="cn=meToipa002.FQDN" (ipa002:389) - load=1 rec=1 csn=544e7b84000000040000 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): replay_update: Sending modify operation (dn="krbprincipalname=ldap/ipa002.FQDN at FQDN,cn=services,cn=accounts,dc=stt,dc=local" csn=544e7b84000000040000) [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): replay_update: Consumer successfully sent operation with csn 544e7b84000000040000 [27/Oct/2014:17:06:08 +0000] agmt="cn=meToipa002.FQDN" (ipa002:389) - clcache_load_buffer: rc=-30988 [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.FQDN" (ipa002:389): No more updates to send (cl5GetNextOperationToReplay) [27/Oct/2014:17:06:08 +0000] - repl5_inc_waitfor_async_results: 0 195864 [27/Oct/2014:17:06:08 +0000] - repl5_inc_result_threadmain starting [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: result 3, 0, 0, 195864, (null) [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - sasl_io_recv failed to decode packet for connection 69255 [27/Oct/2014:17:06:09 +0000] NSMMReplicationPlugin - conn=0 op=-1 repl="dc=stt,dc=local": Released replica held by locking_purl=conn=69255 id=5 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read result for message_id 195864 [27/Oct/2014:17:06:09 +0000] - repl5_inc_waitfor_async_results: 195864 195864 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trevor.t.kates at dom.com Mon Oct 27 17:50:13 2014 From: trevor.t.kates at dom.com (Trevor T Kates (Services - 6)) Date: Mon, 27 Oct 2014 17:50:13 +0000 Subject: [Freeipa-users] Question About Properly Configuring DNS In-Reply-To: <20141027123005.1ba14cf4@willson.usersys.redhat.com> References: <20141027123005.1ba14cf4@willson.usersys.redhat.com> Message-ID: > -----Original Message----- > From: Simo Sorce [mailto:simo at redhat.com] > Sent: Monday, October 27, 2014 12:30 PM > To: Trevor T Kates (Services - 6) > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Question About Properly Configuring DNS > > On Mon, 27 Oct 2014 14:07:42 +0000 > "Trevor T Kates (Services - 6)" wrote: > > > Hi, all: > > > > I have four servers (two in one location, two in another) running IPA > > 3.0 set to replicate like so: > > > > Location A Server 1 - - - - - - - - Location B Server 1 > > | | > > | | > > | | > > | | > > Location A Server 2 - - - - - - - - Location B Server 2 > > > > Each server has DNS configured; however, I think I have configured > > something inappropriately with respect to authoritative records. > > > > I have eight zones configured and ipa dnszone-show for any one of > > them has Location B Server 1's name as authoritative. In each of the > > eight zones, I have added NS records for the other three servers. On > > all of the servers except Location B Server 1, /var/log/messages will > > show: > > > > client x.xxx.x.xxx#14366: received notify for zone > > 'x.xxx.x.in-addr.arpa': not authoritative > > > > This occurs for most, but not all, zones. Along with this: > > > > LDAP query timed out. Try to adjust "timeout" parameter > > update_record (psearch) failed, dn > > 'idnsname=xxx,idnsname=x.xxx.xx.in-addr.arpa.,cn=dns,dc=example,dc=com' > > change type 0x0. Records can be outdated, run `rndc reload`: not found > > > > I feel like I've misconfigured a few things along the way and I'd > > love some help. Along with that if anyone has recommendations on > > things I should read to help me better understand what I should be > > doing with DNS, I'd appreciate it. > > Uhmm sounds like a bug in reloading the info in the bind ldap plugin. > > Can you restart named on one of the other servers and tell if the > warning goes away and/or if the client returns that server as > authoritative after the bounce ? > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York Upon restarting named, 'not authoritative' is not present for any of the zones and dig on clients shows all of the servers as authoritative. The restart of named did not always go cleanly, however. Sometimes, the same timeout issue as before would present itself. Should I not worry about those? Thanks for your help! Trevor T. Kates CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. From john.obaterspok at gmail.com Mon Oct 27 17:53:33 2014 From: john.obaterspok at gmail.com (John Obaterspok) Date: Mon, 27 Oct 2014 18:53:33 +0100 Subject: [Freeipa-users] F20 Problem upgrading to 4.1 In-Reply-To: <544E2A5C.50209@redhat.com> References: <544E2A5C.50209@redhat.com> Message-ID: 2014-10-27 12:19 GMT+01:00 Martin Basti : > On 26/10/14 21:39, John Obaterspok wrote: > > Hi, > > I enabled mkosek-freeipa repo for F20 and updated freeipa-server from > 3.3.5 to 4.1. The yum update reported just a single error: > > Could not load host key: /etc/ssh/ssh_host_dsa_key > > After reboot I had 3 services that failed to start: > ipa, kadmin, named-pkcs11 > > Doing "strace -f named-pkcs11 -u named -f -g" I can see: > "/var/lib/softhsm/tokens/" => -1 EACCES (Permission denied) > initializing DST: PKCS#11 initialization failed > exiting (due to fatal error) > > > For kadmin the error is due to not being able to connect to sldap > > I noticed that softhsm2-util --show-slots reported "ERROR: Could not > initialize the library." But that seemed to be because wasn't part of the > update. After that I could show the default slot and then I manually called > following (as root): > > "/usr/bin/softhsm2-util --init-token --slot 0 --label ipaDNSSEC --pin > XXXXXXXX --so-pin XXXXXXXX" > > But the problems won't go away. Any clues? > > -- john > > > > > Hello, > > 1) > can you share your /var/log/ipaupgrade.log ? > Unfortunatly I removed the original ipaupgrade.log file when I did I retry to install freeipa-server. The current ipaupgrade.log has two errors: First) 2014-10-26T12:45:15Z DEBUG Live 1, updated 1 2014-10-26T12:45:15Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: {'desc': 'Operations error'} 2014-10-26T12:45:15Z ERROR Update failed: Operations error: 2014-10-26T12:45:15Z INFO Updating existing entry: cn=MemberOf Plugin,cn=plugins,cn=config 2014-10-26T12:45:15Z DEBUG --------------------------------------------- Second) It complains about not being able to start named-pkcs11 service. > 2) > your issue with softhsm can be caused by missing enviroment variable > IPA internally uses > > SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf > please try SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf softhsm2-util > --show-slots, and let me know if it works > > same with named-pkcs11, > > The filestamps for softhsm_pin & tokens match the time I did the original update # ll /var/lib/ipa/dnssec/ -rwxrwx---. 1 ods named 30 Oct 26 10:35 softhsm_pin drwxrws---. 2 ods named 4.0K Oct 26 10:35 tokens # ll /var/lib/ipa/dnssec/tokens/ total 0 # SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf softhsm2-util --show-slots Available slots: Slot 0 Slot info: Description: SoftHSM slot 0 Manufacturer ID: SoftHSM project Hardware version: 2.0 Firmware version: 2.0 Token present: yes Token info: Manufacturer ID: SoftHSM project Model: SoftHSM v2 Hardware version: 2.0 Firmware version: 2.0 Serial number: Initialized: no User PIN init.: no Label: 3) > can you share journalctl -u named-pkcs11 output? > 10:35:48 systemd[1]: named-pkcs11.service: control process exited, code=exited status=1 10:35:48 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native PKCS#11. 10:35:48 systemd[1]: Unit named-pkcs11.service entered failed state. 10:35:48 systemd[1]: Stopped Berkeley Internet Name Domain (DNS) with native PKCS#11. -- Reboot -- 10:58:05 named-pkcs11[1496]: initializing DST: no PKCS#11 provider 10:58:05 named-pkcs11[1496]: exiting (due to fatal error) 10:58:05 systemd[1]: named-pkcs11.service: control process exited, code=exited status=1 10:58:05 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native PKCS#11. 10:58:05 systemd[1]: Unit named-pkcs11.service entered failed state. 10:58:05 systemd[1]: Stopped Berkeley Internet Name Domain (DNS) with native PKCS#11. ... After some fiddeling a restart says this: 19:26:21 named-pkcs11[8807]: sha1.c:92: fatal error: 19:26:21 named-pkcs11[8807]: RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, isc_boolean_true, isc_boolean_false, isc_bo 19:26:21 named-pkcs11[8807]: exiting (due to fatal error in library) 19:26:21 systemd[1]: named-pkcs11.service: control process exited, code=exited status=1 19:26:21 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native PKCS#11. 19:26:21 systemd[1]: Unit named-pkcs11.service entered failed state. 4) > I'm not aware of that we need, krb5-libs/openssl, I was getting this error > if tokens directory doesnt exists, but IPA uses own configuration (see 2) > not default. > ok -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Oct 27 18:05:51 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 27 Oct 2014 19:05:51 +0100 Subject: [Freeipa-users] F20 Problem upgrading to 4.1 In-Reply-To: References: <544E2A5C.50209@redhat.com> Message-ID: <544E897F.4050801@redhat.com> On 27/10/14 18:53, John Obaterspok wrote: > > > 2014-10-27 12:19 GMT+01:00 Martin Basti >: > > On 26/10/14 21:39, John Obaterspok wrote: >> Hi, >> >> I enabled mkosek-freeipa repo for F20 and updated freeipa-server >> from 3.3.5 to 4.1. The yum update reported just a single error: >> >> Could not load host key: /etc/ssh/ssh_host_dsa_key >> >> After reboot I had 3 services that failed to start: >> ipa, kadmin, named-pkcs11 >> >> Doing "strace -f named-pkcs11 -u named -f -g" I can see: >> "/var/lib/softhsm/tokens/" => -1 EACCES (Permission denied) >> initializing DST: PKCS#11 initialization failed >> exiting (due to fatal error) >> >> >> For kadmin the error is due to not being able to connect to sldap >> >> I noticed that softhsm2-util --show-slots reported "ERROR: Could >> not initialize the library." But that seemed to be because >> wasn't part of the update. After that I could show the default >> slot and then I manually called following (as root): >> >> "/usr/bin/softhsm2-util --init-token --slot 0 --label ipaDNSSEC >> --pin XXXXXXXX --so-pin XXXXXXXX" >> >> But the problems won't go away. Any clues? >> >> -- john >> >> >> >> > Hello, > > 1) > can you share your /var/log/ipaupgrade.log ? > > > Unfortunatly I removed the original ipaupgrade.log file when I did I > retry to install freeipa-server. The current ipaupgrade.log has two > errors: > First) > > 2014-10-26T12:45:15Z DEBUG Live 1, updated 1 > 2014-10-26T12:45:15Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: > {'desc': 'Operations error'} > 2014-10-26T12:45:15Z ERROR Update failed: Operations error: > 2014-10-26T12:45:15Z INFO Updating existing entry: cn=MemberOf > Plugin,cn=plugins,cn=config > 2014-10-26T12:45:15Z DEBUG --------------------------------------------- Are there some information about entry which is updated above? > > Second) It complains about not being able to start named-pkcs11 service. > > 2) > your issue with softhsm can be caused by missing enviroment variable > IPA internally uses > > SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf > please try SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf > softhsm2-util --show-slots, and let me know if it works > > same with named-pkcs11, > > > The filestamps for softhsm_pin & tokens match the time I did the > original update > > # ll /var/lib/ipa/dnssec/ > -rwxrwx---. 1 ods named 30 Oct 26 10:35 softhsm_pin > drwxrws---. 2 ods named 4.0K Oct 26 10:35 tokens > > # ll /var/lib/ipa/dnssec/tokens/ > total 0 > > # SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf softhsm2-util --show-slots > Available slots: > Slot 0 > Slot info: > Description: SoftHSM slot 0 > Manufacturer ID: SoftHSM project > Hardware version: 2.0 > Firmware version: 2.0 > Token present: yes > Token info: > Manufacturer ID: SoftHSM project > Model: SoftHSM v2 > Hardware version: 2.0 > Firmware version: 2.0 > Serial number: > Initialized: no > User PIN init.: no > Label: Slot was not initialized by IPA > > 3) > can you share journalctl -u named-pkcs11 output? > > > 10:35:48 systemd[1]: named-pkcs11.service: control process exited, > code=exited status=1 > 10:35:48 systemd[1]: Failed to start Berkeley Internet Name Domain > (DNS) with native PKCS#11. > 10:35:48 systemd[1]: Unit named-pkcs11.service entered failed state. > 10:35:48 systemd[1]: Stopped Berkeley Internet Name Domain (DNS) with > native PKCS#11. > -- Reboot -- > 10:58:05 named-pkcs11[1496]: initializing DST: no PKCS#11 provider > 10:58:05 named-pkcs11[1496]: exiting (due to fatal error) > 10:58:05 systemd[1]: named-pkcs11.service: control process exited, > code=exited status=1 > 10:58:05 systemd[1]: Failed to start Berkeley Internet Name Domain > (DNS) with native PKCS#11. > 10:58:05 systemd[1]: Unit named-pkcs11.service entered failed state. > 10:58:05 systemd[1]: Stopped Berkeley Internet Name Domain (DNS) with > native PKCS#11. > > ... After some fiddeling a restart says this: > > 19:26:21 named-pkcs11[8807]: sha1.c:92: fatal error: > 19:26:21 named-pkcs11[8807]: RUNTIME_CHECK(pk11_get_session(ctx, > OP_DIGEST, isc_boolean_true, isc_boolean_false, isc_bo > 19:26:21 named-pkcs11[8807]: exiting (due to fatal error in library) > 19:26:21 systemd[1]: named-pkcs11.service: control process exited, > code=exited status=1 > 19:26:21 systemd[1]: Failed to start Berkeley Internet Name Domain > (DNS) with native PKCS#11. > 19:26:21 systemd[1]: Unit named-pkcs11.service entered failed state. > > 4) > I'm not aware of that we need, krb5-libs/openssl, I was getting > this error if tokens directory doesnt exists, but IPA uses own > configuration (see 2) not default. > > > ok I took a deeper look, and I found there some packaging errors with softhsm. You was right with missing dependency. Please install softhsm-devel package, remove /var/lib/ipa/dnssec/tokens directory, then reinstall DNS, ipa-dns-install (requires running directory server) Or if you have snapshot, install softhsm-devel before upgrading ipa HTH Martin^2 -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Oct 27 18:15:09 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 27 Oct 2014 14:15:09 -0400 Subject: [Freeipa-users] Question About Properly Configuring DNS In-Reply-To: References: <20141027123005.1ba14cf4@willson.usersys.redhat.com> Message-ID: <20141027141509.416baa61@willson.usersys.redhat.com> On Mon, 27 Oct 2014 17:50:13 +0000 "Trevor T Kates (Services - 6)" wrote: > > -----Original Message----- > > From: Simo Sorce [mailto:simo at redhat.com] > > Sent: Monday, October 27, 2014 12:30 PM > > To: Trevor T Kates (Services - 6) > > Cc: freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] Question About Properly Configuring DNS > > > > On Mon, 27 Oct 2014 14:07:42 +0000 > > "Trevor T Kates (Services - 6)" wrote: > > > > > Hi, all: > > > > > > I have four servers (two in one location, two in another) running > > > IPA 3.0 set to replicate like so: > > > > > > Location A Server 1 - - - - - - - - Location B Server 1 > > > | | > > > | | > > > | | > > > | | > > > Location A Server 2 - - - - - - - - Location B Server 2 > > > > > > Each server has DNS configured; however, I think I have configured > > > something inappropriately with respect to authoritative records. > > > > > > I have eight zones configured and ipa dnszone-show for any one of > > > them has Location B Server 1's name as authoritative. In each of > > > the eight zones, I have added NS records for the other three > > > servers. On all of the servers except Location B Server > > > 1, /var/log/messages will show: > > > > > > client x.xxx.x.xxx#14366: received notify for zone > > > 'x.xxx.x.in-addr.arpa': not authoritative > > > > > > This occurs for most, but not all, zones. Along with this: > > > > > > LDAP query timed out. Try to adjust "timeout" parameter > > > update_record (psearch) failed, dn > > > 'idnsname=xxx,idnsname=x.xxx.xx.in-addr.arpa.,cn=dns,dc=example,dc=com' > > > change type 0x0. Records can be outdated, run `rndc reload`: not > > > found > > > > > > I feel like I've misconfigured a few things along the way and I'd > > > love some help. Along with that if anyone has recommendations on > > > things I should read to help me better understand what I should be > > > doing with DNS, I'd appreciate it. > > > > Uhmm sounds like a bug in reloading the info in the bind ldap > > plugin. > > > > Can you restart named on one of the other servers and tell if the > > warning goes away and/or if the client returns that server as > > authoritative after the bounce ? > > > > Simo. > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > Upon restarting named, 'not authoritative' is not present for any of > the zones and dig on clients shows all of the servers as > authoritative. The restart of named did not always go cleanly, > however. Sometimes, the same timeout issue as before would present > itself. Should I not worry about those? Ok would you be able to opne a bug (bugzilla or trac, either is fine) for the 2 issues ? One seem to be that changing the NS record is not causing a proper change in authoritative status. The second should be about the timeout error you are seeing. Thank you, Simo. > Thanks for your help! > > Trevor T. Kates > > > CONFIDENTIALITY NOTICE: This electronic message contains information > which may be legally confidential and or privileged and does not in > any case represent a firm ENERGY COMMODITY bid or offer relating > thereto which binds the sender without an additional express written > confirmation to that effect. The information is intended solely for > the individual or entity named above and access by anyone else is > unauthorized. If you are not the intended recipient, any disclosure, > copying, distribution, or use of the contents of this information is > prohibited and may be unlawful. If you have received this electronic > transmission in error, please reply immediately to the sender that > you have received the message in error, and delete it. Thank you. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Mon Oct 27 18:22:25 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 27 Oct 2014 14:22:25 -0400 Subject: [Freeipa-users] multi-master replication In-Reply-To: <8ff07afa639047f3970f0f0621bd655a@BLUPR08MB488.namprd08.prod.outlook.com> References: <544C3DA5.6010009@redhat.com> <544E4BA5.8020602@redhat.com> <5b424b09f0a74ee0822b49ce2e886694@BLUPR08MB488.namprd08.prod.outlook.com> <544E71FF.1040701@redhat.com> <8ff07afa639047f3970f0f0621bd655a@BLUPR08MB488.namprd08.prod.outlook.com> Message-ID: <544E8D61.6050205@redhat.com> On 10/27/2014 01:41 PM, Craig White wrote: > > Maybe fixed -- seems to be replicating now... > > https://bugzilla.redhat.com/show_bug.cgi?id=953653 > > Why don't they incorporate that into the released RHEL version? > I think we did. Into 7.0. > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Craig White > *Sent:* Monday, October 27, 2014 10:17 AM > *To:* Rich Megginson; freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] multi-master replication > > *From:*Rich Megginson [mailto:rmeggins at redhat.com] > *Sent:* Monday, October 27, 2014 9:26 AM > *To:* Craig White; freeipa-users at redhat.com > > *Subject:* Re: [Freeipa-users] multi-master replication > > On 10/27/2014 10:12 AM, Craig White wrote: > > *From:*freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Rich > Megginson > *Sent:* Monday, October 27, 2014 6:42 AM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] multi-master replication > > On 10/25/2014 06:17 PM, Dmitri Pal wrote: > > On 10/24/2014 07:15 PM, Craig White wrote: > > *From:*freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of > *Craig White > *Sent:* Friday, October 24, 2014 4:02 PM > *To:* freeipa-users at redhat.com > > *Subject:* [Freeipa-users] multi-master replication > > I would have thought that changes go from replica to > master and not just master to replica. > > Is there something I have to do to make the changes > bi-directional? > > Replying to my own post... > > Logs are my friend ;-) > > [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.domain.local " (ipa001:389): > Replication bind with GSSAPI auth resumed > > [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.domain.local " (ipa001:389): Warning: > unable to replicate schema: rc=2 > > [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.domain.local " (ipa001:389): Failed to > send update operation to consumer (uniqueid > e018060f-5bb011e4-81078979-dc802980, CSN > 544aa346000000030000): Can't contact LDAP server. Will > retry later. > > [24/Oct/2014:23:08:17 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.domain.local " (ipa001:389): Consumer > failed to replay change (uniqueid (null), CSN (null)): > Can't contact LDAP server(-1). Will retry later. > > > These NULLs look suspicious. > I hope DS gurus will have more for you on Monday. > > > 1) Yes, replication is fully bi-directional. > 2) What are the exact versions of dirsrv? rpm -q 389-ds-base on > supplier and consumer. > 3) Can you reproduce the problem using the replication log level > on both the supplier and consumer? > http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting > ---- > > 1)I sort of expected it to be -- that's what had me worried when > it didn't work as expected. > > 2)]# rpm -qa | grep 389 > > 389-ds-base-1.2.11.15-47.el6.x86_64 > > 389-ds-base-libs-1.2.11.15-47.el6.x86_64 > > 3)Upped the log levels -- hopefully this is a reasonable > representative from ipa002 (the replica) > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - conn=4 > op=229791 repl="dc=stt,dc=local": Acquired replica > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - conn=4 > op=229791 repl="dc=stt,dc=local": StartNSDS90ReplicationRequest: > response=0 rc=0 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - conn=4 > op=229791 Relinquishing consumer connection extension > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > ruv_add_csn_inprogress: successfully inserted csn > 544e6b02000000040000 into pending list > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - Purged state > information from entry > krbprincipalname=ldap/ipa002.FQDN at FQDN,cn=services,cn=accounts,dc=stt,dc=local > > up to CSN 5445307e000000040000 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog > program - _cl5GetDBFileByReplicaName: found DB object f32b80 for > database > /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog > program - _cl5GetDBFileByReplicaName: found DB object f32b80 for > database > /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > ruv_update_ruv: successfully committed csn 544e6b02000000040000 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Disconnected from the consumer > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Warning: unable to > replicate schema: rc=2 > > [27/Oct/2014:15:55:47 +0000] - csngen_adjust_time: gen state > before 544e6b040001:1414425347:0:1 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog > program - _cl5GetDBFile: found DB object f32b80 for database > /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 > > [27/Oct/2014:15:55:47 +0000] - _cl5PositionCursorForReplay > (agmt="cn=meToipa001.FQDN" (ipa001:389)): Consumer RUV: > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): {replicageneration} > 544aa332000000040000 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 4 > ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e6b02000000040000 > 00000000 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 3 > ldap://ipa002.FQDN:389} 544aa339000000030000 544aa33f000400030000 > 00000000 > > [27/Oct/2014:15:55:47 +0000] - _cl5PositionCursorForReplay > (agmt="cn=meToipa001.FQDN" (ipa001:389)): Supplier RUV: > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): {replicageneration} > 544aa332000000040000 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 3 > ldap://ipa002.FQDN:389} 544aa339000000030000 544e6aa4000300030000 > 544e6aa3 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 4 > ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e6b02000000040000 > 544e6b03 > > [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" > (ipa001:389) - clcache_get_buffer: found thread private buffer > cache 7fe85000ea50 > > [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" > (ipa001:389) - clcache_get_buffer: _pool is f89af0 > _pool->pl_busy_lists is 7fe8500197d0 > _pool->pl_busy_lists->bl_buffers is 7fe85000ea50 > > [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" > (ipa001:389) - session start: anchorcsn=544aa33f000400030000 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - changelog > program - agmt="cn=meToipa001.FQDN" (ipa001:389): CSN > 544aa33f000400030000 found, position set for replay > > [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" > (ipa001:389) - load=1 rec=1 csn=544aa346000000030000 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): replay_update: Sending add > operation > (dn="cn=KDC,cn=ipa002.FQDN,cn=masters,cn=ipa,cn=etc,dc=stt,dc=local" > csn=544aa346000000030000) > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): replay_update: Consumer > could not replay operation with csn 544aa346000000030000 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Failed to send update > operation to consumer (uniqueid > e018060f-5bb011e4-81078979-dc802980, CSN 544aa346000000030000): > Can't contact LDAP server. Will retry later. > > [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain starting > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Connection disconnected by > another thread > > [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain: read > result for message_id 0 > > [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain: result > 3, -1, 2, 0, (null) > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Consumer failed to replay > change (uniqueid (null), CSN (null)): Can't contact LDAP > server(-1). Will retry later. > > [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain: got op > result 205 should finish 1 > > [27/Oct/2014:15:55:47 +0000] - repl5_inc_result_threadmain exiting > > [27/Oct/2014:15:55:47 +0000] agmt="cn=meToipa001.FQDN" > (ipa001:389) - session end: state=0 load=1 sent=1 skipped=0 > skipped_new_rid=0 skipped_csn_gt_cons_maxcsn=0 > skipped_up_to_date=0 skipped_csn_gt_ruv=0 skipped_csn_covered=0 > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Warning: unable to send > endReplication extended operation (Can't contact LDAP server) > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): State: sending_updates -> > start_backoff > > [27/Oct/2014:15:55:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): State: start_backoff -> > start_backoff > > [27/Oct/2014:15:55:49 +0000] NSMMReplicationPlugin - conn=4 > op=229793 Acquired consumer connection extension > > [27/Oct/2014:15:55:49 +0000] NSMMReplicationPlugin - conn=4 > op=229793 repl="dc=stt,dc=local": Released replica held by > locking_purl=conn=4 id=229791 > > [27/Oct/2014:15:55:49 +0000] NSMMReplicationPlugin - conn=4 > op=229793 Relinquishing consumer connection extension > > [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): State: start_backoff -> > backoff > > [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Trying non-secure > slapi_ldap_init_ext > > [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): binddn = , passwd = > > [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Replication bind with > GSSAPI auth resumed > > [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): No linger to cancel on the > connection > > [27/Oct/2014:15:55:51 +0000] - _csngen_adjust_local_time: gen > state before 544e6b040001:1414425347:0:1 > > [27/Oct/2014:15:55:51 +0000] - _csngen_adjust_local_time: gen > state after 544e6b080000:1414425351:0:1 > > [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Replica was successfully > acquired. > > [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): State: backoff -> > sending_updates > > [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - conn=4 > op=229794 Acquired consumer connection extension > > [27/Oct/2014:15:55:51 +0000] NSMMReplicationPlugin - conn=4 > op=229794 repl="dc=stt,dc=local": Begin incremental protocol > > [27/Oct/2014:15:55:51 +0000] - csngen_adjust_time: gen state > before 544e6b080001:1414425351:0:1 > > [27/Oct/2014:15:55:51 +0000] - csngen_adjust_time: gen state after > 544e6b080001:1414425351:0:1 > > This is the log from ipa002 (which was the replica) and I am > confused by the error logged, 'Can't contact LDAP server' because > it surely can... > > ]# telnet 172.29.31.100 389 > > Trying 172.29.31.100... > > Connected to 172.29.31.100. > > Escape character is '^]'. > > ^] > > telnet> quit > > Connection closed. > > > Replication uses Kerberos/GSSAPI and also possibly startTLS (I can't > remember if ipa uses startTLS for an additional layer of encryption, > or just uses Kerberos/GSSAPI for encryption). These might also cause > the directory server to report connection failures even if the tcp > layer connections are working. > > Can you provided excerpts from the 172.29.31.100 directory server > access logs from around the time of the connection failures reported > above? > > This is a new setup (setup master on Thursday, imported users from > OpenLDAP and then setup replica on Friday). Had a few issues that I > didn't understand which may or may not be relevant. First, after I > made some changes to SSSD to allow for sudo and hopefully HBAC, it > seemed like the directory server crashed and I had to restart it. > > > Crashed? If you can reproduce this problem, see > http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes > If there is a crash, we need to see the stack trace. > > Seemed like the same thing happened at the same time when I likewise > configured the replica. > > > Again, see above. > > Also, when I was trying to setup the replica, I had to resort to > --skip-conncheck as it (presume Kerberos) not only asked for the > password for admin@$DOMAIN but also the password for > admin at ipa001.$DOMAIN for which I had > never specifically setup any password and no password already used in > Kerberos worked. > > > Hmm - maybe one of the ipa guys knows what the problem is here. > > ---- > > I'll have to look through the logs to see if there's anything useful > for the LDAP / dirsrv crashing when first setup & configuring SSSD/pam > but I know that the logging would have been default/terse at that time. > > Logs on the master from that same time shown on the replica above show > only... > > [24/Oct/2014:23:08:15 +0000] - sasl_io_recv failed to decode packet > for connection 4037 > > [24/Oct/2014:23:08:20 +0000] - sasl_io_recv failed to decode packet > for connection 4038 > > And this hopefully should help identify the problem -- verbose logging > on Replica > > [27/Oct/2014:17:07:06 +0000] - _csngen_adjust_local_time: gen state > after 544e7bbb0000:1414429626:0:1 > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Replica was successfully acquired. > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): State: backoff -> sending_updates > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - conn=4 op=233926 > Acquired consumer connection extension > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - conn=4 op=233926 > repl="dc=stt,dc=local": Begin incremental protocol > > [27/Oct/2014:17:07:06 +0000] - csngen_adjust_time: gen state before > 544e7bbb0001:1414429626:0:1 > > [27/Oct/2014:17:07:06 +0000] - csngen_adjust_time: gen state after > 544e7bbb0001:1414429626:0:1 > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - conn=4 op=233926 > repl="dc=stt,dc=local": Acquired replica > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - conn=4 op=233926 > repl="dc=stt,dc=local": StartNSDS90ReplicationRequest: response=0 rc=0 > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - conn=4 op=233926 > Relinquishing consumer connection extension > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - > ruv_add_csn_inprogress: successfully inserted csn 544e7bb9000000040000 > into pending list > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - Purged state > information from entry > krbprincipalname=ldap/ipa002.FQDN at FQDN,cn=services,cn=accounts,dc=stt,dc=local > > up to CSN 54454135000000040000 > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - changelog program > - _cl5GetDBFileByReplicaName: found DB object f32b80 for database > /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - changelog program > - _cl5GetDBFileByReplicaName: found DB object f32b80 for database > /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - ruv_update_ruv: > successfully committed csn 544e7bb9000000040000 > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Disconnected from the consumer > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Warning: unable to replicate > schema: rc=2 > > [27/Oct/2014:17:07:06 +0000] - csngen_adjust_time: gen state before > 544e7bbb0001:1414429626:0:1 > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - changelog program > - _cl5GetDBFile: found DB object f32b80 for database > /var/lib/dirsrv/slapd-STT-LOCAL/cldb/dababc08-5bb011e4-81078979-dc802980_544aa332000000040000.db4 > > [27/Oct/2014:17:07:06 +0000] - _cl5PositionCursorForReplay > (agmt="cn=meToipa001.FQDN" (ipa001:389)): Consumer RUV: > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): {replicageneration} > 544aa332000000040000 > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 4 > ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e7bb9000000040000 00000000 > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 3 > ldap://ipa002.FQDN:389} 544aa339000000030000 544aa33f000400030000 00000000 > > [27/Oct/2014:17:07:06 +0000] - _cl5PositionCursorForReplay > (agmt="cn=meToipa001.FQDN" (ipa001:389)): Supplier RUV: > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): {replicageneration} > 544aa332000000040000 > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 3 > ldap://ipa002.FQDN:389} 544aa339000000030000 544e7a1c000200030000 544e7a1b > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): {replica 4 > ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e7bb9000000040000 544e7bba > > [27/Oct/2014:17:07:06 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - > clcache_get_buffer: found thread private buffer cache 7fe85000ea50 > > [27/Oct/2014:17:07:06 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - > clcache_get_buffer: _pool is f89af0 _pool->pl_busy_lists is > 7fe8500197d0 _pool->pl_busy_lists->bl_buffers is 7fe85000ea50 > > [27/Oct/2014:17:07:06 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - > session start: anchorcsn=544aa33f000400030000 > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - changelog program > - agmt="cn=meToipa001.FQDN" (ipa001:389): CSN 544aa33f000400030000 > found, position set for replay > > [27/Oct/2014:17:07:06 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - > load=1 rec=1 csn=544aa346000000030000 > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): replay_update: Sending add > operation > (dn="cn=KDC,cn=ipa002.FQDN,cn=masters,cn=ipa,cn=etc,dc=stt,dc=local" > csn=544aa346000000030000) > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): replay_update: Consumer could > not replay operation with csn 544aa346000000030000 > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Failed to send update > operation to consumer (uniqueid e018060f-5bb011e4-81078979-dc802980, > CSN 544aa346000000030000): Can't contact LDAP server. Will retry later. > > [27/Oct/2014:17:07:06 +0000] - repl5_inc_result_threadmain starting > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Connection disconnected by > another thread > > [27/Oct/2014:17:07:06 +0000] - repl5_inc_result_threadmain: read > result for message_id 0 > > [27/Oct/2014:17:07:06 +0000] - repl5_inc_result_threadmain: result 3, > -1, 2, 0, (null) > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Consumer failed to replay > change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). > Will retry later. > > [27/Oct/2014:17:07:06 +0000] - repl5_inc_result_threadmain: got op > result 205 should finish 1 > > [27/Oct/2014:17:07:06 +0000] - repl5_inc_result_threadmain exiting > > [27/Oct/2014:17:07:06 +0000] agmt="cn=meToipa001.FQDN" (ipa001:389) - > session end: state=0 load=1 sent=1 skipped=0 skipped_new_rid=0 > skipped_csn_gt_cons_maxcsn=0 skipped_up_to_date=0 skipped_csn_gt_ruv=0 > skipped_csn_covered=0 > > [27/Oct/2014:17:07:06 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa001.FQDN" (ipa001:389): Warning: unable to send > endReplication extended operation (Can't contact LDAP server) > > And Simultaneous verbose logging on Master > > [27/Oct/2014:17:06:06 +0000] - repl5_inc_result_threadmain exiting > > [27/Oct/2014:17:06:06 +0000] agmt="cn=meToipa002.FQDN" (ipa002:389) - > session end: state=5 load=1 sent=1 skipped=0 skipped_new_rid=0 > skipped_csn_gt_cons_m > > axcsn=0 skipped_up_to_date=0 skipped_csn_gt_ruv=0 skipped_csn_covered=0 > > [27/Oct/2014:17:06:06 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.FQDN" (ipa002:389): Successfully released consumer > > [27/Oct/2014:17:06:06 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.FQDN" (ipa002:389): Beginning linger on the connection > > [27/Oct/2014:17:06:06 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.FQDN" (ipa002:389): State: sending_updates -> > wait_for_changes > > [27/Oct/2014:17:06:08 +0000] - _csngen_adjust_local_time: gen state > before 544e7b820002:1414429564:2:4 > > [27/Oct/2014:17:06:08 +0000] - _csngen_adjust_local_time: gen state > after 544e7b840000:1414429568:0:4 > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - > ruv_add_csn_inprogress: successfully inserted csn 544e7b84000000040000 > into pending list > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - Purged state > information from entry > krbprincipalname=ldap/ipa002.FQDN at FQDN,cn=services,cn=acco > > > unts,dc=stt,dc=local up to CSN 54454100000000040000 > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - conn=69255 op=5 > Acquired consumer connection extension > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - conn=69255 op=5 > repl="dc=stt,dc=local": Begin incremental protocol > > [27/Oct/2014:17:06:08 +0000] - csngen_adjust_time: gen state before > 544e7b840001:1414429568:0:4 > > [27/Oct/2014:17:06:08 +0000] - csngen_adjust_time: gen state after > 544e7b860001:1414429568:2:4 > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - conn=69255 op=5 > repl="dc=stt,dc=local": Acquired replica > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - conn=69255 op=5 > repl="dc=stt,dc=local": StartNSDS90ReplicationRequest: response=0 rc=0 > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - conn=69255 op=5 > Relinquishing consumer connection extension > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - changelog program > - _cl5GetDBFileByReplicaName: found DB object 7fb95801fbf0 for > database /var/lib/dirsrv/slapd-STT-LOCA > > L/cldb/d7273483-5bb011e4-8073dfa6-7d9cbbef_544aa332000000040000.db4 > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - changelog program > - _cl5GetDBFileByReplicaName: found DB object 7fb95801fbf0 for > database /var/lib/dirsrv/slapd-STT-LOCA > > L/cldb/d7273483-5bb011e4-8073dfa6-7d9cbbef_544aa332000000040000.db4 > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - ruv_update_ruv: > successfully committed csn 544e7b84000000040000 > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.FQDN" (ipa002:389): State: wait_for_changes -> > wait_for_changes > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.FQDN" (ipa002:389): State: wait_for_changes -> > ready_to_acquire_replica > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.FQDN" (ipa002:389): Cancelling linger on the > connection > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.FQDN" (ipa002:389): Replica was successfully acquired. > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.FQDN" (ipa002:389): State: > ready_to_acquire_replica -> sending_updates > > [27/Oct/2014:17:06:08 +0000] - csngen_adjust_time: gen state before > 544e7b860002:1414429568:2:4 > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - changelog program > - _cl5GetDBFile: found DB object 7fb95801fbf0 for database > /var/lib/dirsrv/slapd-STT-LOCAL/cldb/d7273483-5bb011e4-8073dfa6-7d9cbbef_544aa332000000040000.db4 > > [27/Oct/2014:17:06:08 +0000] - _cl5PositionCursorForReplay > (agmt="cn=meToipa002.FQDN" (ipa002:389)): Consumer RUV: > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.FQDN" (ipa002:389): {replicageneration} > 544aa332000000040000 > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.FQDN" (ipa002:389): {replica 3 > ldap://ipa002.FQDN:389} 544aa339000000030000 544e7a1c000200030000 00000000 > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.FQDN" (ipa002:389): {replica 4 > ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e7b80000000040000 00000000 > > [27/Oct/2014:17:06:08 +0000] - _cl5PositionCursorForReplay > (agmt="cn=meToipa002.FQDN" (ipa002:389)): Supplier RUV: > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.FQDN" (ipa002:389): {replicageneration} > 544aa332000000040000 > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.FQDN" (ipa002:389): {replica 4 > ldap://ipa001.FQDN:389} 544aa3a1000000040000 544e7b84000000040000 544e7b80 > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.FQDN" (ipa002:389): {replica 3 > ldap://ipa002.FQDN:389} 544aa339000000030000 544aa33f000400030000 544aa33e > > [27/Oct/2014:17:06:08 +0000] agmt="cn=meToipa002.FQDN" (ipa002:389) - > clcache_get_buffer: found thread private buffer cache 135d780 > > [27/Oct/2014:17:06:08 +0000] agmt="cn=meToipa002.FQDN" (ipa002:389) - > clcache_get_buffer: _pool is 11eaca0 _pool->pl_busy_lists is 1239060 > _pool->pl_busy_lists->bl_buffers is 135d780 > > [27/Oct/2014:17:06:08 +0000] agmt="cn=meToipa002.FQDN" (ipa002:389) - > session start: anchorcsn=544e7b80000000040000 > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - changelog program > - agmt="cn=meToipa002.FQDN" (ipa002:389): CSN 544e7b80000000040000 > found, position set for replay > > [27/Oct/2014:17:06:08 +0000] agmt="cn=meToipa002.FQDN" (ipa002:389) - > load=1 rec=1 csn=544e7b84000000040000 > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.FQDN" (ipa002:389): replay_update: Sending modify > operation > (dn="krbprincipalname=ldap/ipa002.FQDN at FQDN,cn=services,cn=accounts,dc=stt,dc=local > " > csn=544e7b84000000040000) > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.FQDN" (ipa002:389): replay_update: Consumer > successfully sent operation with csn 544e7b84000000040000 > > [27/Oct/2014:17:06:08 +0000] agmt="cn=meToipa002.FQDN" (ipa002:389) - > clcache_load_buffer: rc=-30988 > > [27/Oct/2014:17:06:08 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.FQDN" (ipa002:389): No more updates to send > (cl5GetNextOperationToReplay) > > [27/Oct/2014:17:06:08 +0000] - repl5_inc_waitfor_async_results: 0 195864 > > [27/Oct/2014:17:06:08 +0000] - repl5_inc_result_threadmain starting > > [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read > result for message_id 195864 > > [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: result 3, > 0, 0, 195864, (null) > > [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read > result for message_id 195864 > > [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read > result for message_id 195864 > > [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read > result for message_id 195864 > > [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read > result for message_id 195864 > > [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read > result for message_id 195864 > > [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read > result for message_id 195864 > > [27/Oct/2014:17:06:09 +0000] - sasl_io_recv failed to decode packet > for connection 69255 > > [27/Oct/2014:17:06:09 +0000] NSMMReplicationPlugin - conn=0 op=-1 > repl="dc=stt,dc=local": Released replica held by > locking_purl=conn=69255 id=5 > > [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read > result for message_id 195864 > > [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read > result for message_id 195864 > > [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read > result for message_id 195864 > > [27/Oct/2014:17:06:09 +0000] - repl5_inc_result_threadmain: read > result for message_id 195864 > > [27/Oct/2014:17:06:09 +0000] - repl5_inc_waitfor_async_results: 195864 > 195864 > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From CWhite at skytouchtechnology.com Mon Oct 27 18:41:33 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Mon, 27 Oct 2014 18:41:33 +0000 Subject: [Freeipa-users] multi-master replication In-Reply-To: <544E8D61.6050205@redhat.com> References: <544C3DA5.6010009@redhat.com> <544E4BA5.8020602@redhat.com> <5b424b09f0a74ee0822b49ce2e886694@BLUPR08MB488.namprd08.prod.outlook.com> <544E71FF.1040701@redhat.com> <8ff07afa639047f3970f0f0621bd655a@BLUPR08MB488.namprd08.prod.outlook.com> <544E8D61.6050205@redhat.com> Message-ID: <15dbb99a45a64ad4bd168584e2a1baac@BLUPR08MB488.namprd08.prod.outlook.com> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Monday, October 27, 2014 11:22 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] multi-master replication On 10/27/2014 01:41 PM, Craig White wrote: Maybe fixed - seems to be replicating now... https://bugzilla.redhat.com/show_bug.cgi?id=953653 Why don't they incorporate that into the released RHEL version? I think we did. Into 7.0. ---- Great - but 7.0 isn't certified at Rackspace so I had no choice but to use 6.x and I would suspect that people are going to still be using 6.x for new installs for a while. But thanks - and keep up the great work. Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.obaterspok at gmail.com Mon Oct 27 18:57:09 2014 From: john.obaterspok at gmail.com (John Obaterspok) Date: Mon, 27 Oct 2014 19:57:09 +0100 Subject: [Freeipa-users] F20 Problem upgrading to 4.1 In-Reply-To: <544E897F.4050801@redhat.com> References: <544E2A5C.50209@redhat.com> <544E897F.4050801@redhat.com> Message-ID: Hello Martin, Still no go. I installed the softhsm-devel package (that only contains header files), removed the token directory, reinstalled the bind & bind-pkcs11, did ipa-dns-install that completed ok (I guess): To accept the default shown in brackets, press the Enter key. Existing BIND configuration detected, overwrite? [no]: yes Directory Manager password: # ipa-upgradeconfig [Verifying that root certificate is published] *Failed to backup CS.cfg: no magic attribute 'dogtag'* [Migrate CRL publish directory] CRL tree already moved [Verifying that CA proxy configuration is correct] [Verifying that KDC configuration is using ipa-kdb backend] [Fixing trust flags in /etc/httpd/alias] Trust flags already processed [Fix DS schema file syntax] Syntax already fixed [Removing RA cert from DS NSS database] RA cert already removed [Removing self-signed CA] [Checking for deprecated KDC configuration files] [Checking for deprecated backups of Samba configuration files] [Setting up Firefox extension] [Add missing CA DNS records] IPA CA DNS records already processed [Removing deprecated DNS configuration options] [Ensuring minimal number of connections] [Enabling serial autoincrement in DNS] [Updating GSSAPI configuration in DNS] [Updating pid-file configuration in DNS] [Masking named] Changes to named.conf have been made, restart named *Failed to restart named: Command ''/bin/systemctl' 'restart' 'named-pkcs11.service'' returned non-zero exit status 1* [Verifying that CA service certificate profile is updated] [Update certmonger certificate renewal configuration to version 2] [Enable PKIX certificate path discovery and validation] PKIX already enabled The ipa-upgradeconfig command was successful # systemctl restart named-pkcs11 && journalctl -xn 19:38:54 named-pkcs11[838]: ObjectStore.cpp(59): Failed to enumerate object store in /var/lib/ipa/dnssec/tokens 19:38:54 named-pkcs11[838]: SoftHSM.cpp(437): Could not load the object store 19:38:54 named-pkcs11[838]: initializing DST: PKCS#11 initialization failed 19:38:54 named-pkcs11[838]: exiting (due to fatal error) 19:38:54 systemd[1]: named-pkcs11.service: control process exited, code=exited status=1 19:38:54 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native PKCS#11. It seems the problem is now there are no tokens: # ll /var/lib/ipa/dnssec/ total 4.0K -rwxrwx---. 1 ods named 30 Oct 26 10:35 softhsm_pin Any ideas? -- john 2014-10-27 19:05 GMT+01:00 Martin Basti : > On 27/10/14 18:53, John Obaterspok wrote: > > > > 2014-10-27 12:19 GMT+01:00 Martin Basti : > >> On 26/10/14 21:39, John Obaterspok wrote: >> >> Hi, >> >> I enabled mkosek-freeipa repo for F20 and updated freeipa-server from >> 3.3.5 to 4.1. The yum update reported just a single error: >> >> Could not load host key: /etc/ssh/ssh_host_dsa_key >> >> After reboot I had 3 services that failed to start: >> ipa, kadmin, named-pkcs11 >> >> Doing "strace -f named-pkcs11 -u named -f -g" I can see: >> "/var/lib/softhsm/tokens/" => -1 EACCES (Permission denied) >> initializing DST: PKCS#11 initialization failed >> exiting (due to fatal error) >> >> >> For kadmin the error is due to not being able to connect to sldap >> >> I noticed that softhsm2-util --show-slots reported "ERROR: Could not >> initialize the library." But that seemed to be because wasn't part of the >> update. After that I could show the default slot and then I manually called >> following (as root): >> >> "/usr/bin/softhsm2-util --init-token --slot 0 --label ipaDNSSEC --pin >> XXXXXXXX --so-pin XXXXXXXX" >> >> But the problems won't go away. Any clues? >> >> -- john >> >> >> >> >> Hello, >> >> 1) >> can you share your /var/log/ipaupgrade.log ? >> > > Unfortunatly I removed the original ipaupgrade.log file when I did I > retry to install freeipa-server. The current ipaupgrade.log has two errors: > First) > > 2014-10-26T12:45:15Z DEBUG Live 1, updated 1 > 2014-10-26T12:45:15Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: {'desc': > 'Operations error'} > 2014-10-26T12:45:15Z ERROR Update failed: Operations error: > 2014-10-26T12:45:15Z INFO Updating existing entry: cn=MemberOf > Plugin,cn=plugins,cn=config > 2014-10-26T12:45:15Z DEBUG --------------------------------------------- > > Are there some information about entry which is updated above? > > > Second) It complains about not being able to start named-pkcs11 service. > > > >> 2) >> your issue with softhsm can be caused by missing enviroment variable >> IPA internally uses >> >> SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf >> please try SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf softhsm2-util >> --show-slots, and let me know if it works >> >> same with named-pkcs11, >> >> > The filestamps for softhsm_pin & tokens match the time I did the > original update > > # ll /var/lib/ipa/dnssec/ > -rwxrwx---. 1 ods named 30 Oct 26 10:35 softhsm_pin > drwxrws---. 2 ods named 4.0K Oct 26 10:35 tokens > > # ll /var/lib/ipa/dnssec/tokens/ > total 0 > > # SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf softhsm2-util --show-slots > Available slots: > Slot 0 > Slot info: > Description: SoftHSM slot 0 > Manufacturer ID: SoftHSM project > Hardware version: 2.0 > Firmware version: 2.0 > Token present: yes > Token info: > Manufacturer ID: SoftHSM project > Model: SoftHSM v2 > Hardware version: 2.0 > Firmware version: 2.0 > Serial number: > Initialized: no > User PIN init.: no > Label: > > Slot was not initialized by IPA > > > 3) >> can you share journalctl -u named-pkcs11 output? >> > > 10:35:48 systemd[1]: named-pkcs11.service: control process exited, > code=exited status=1 > 10:35:48 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) > with native PKCS#11. > 10:35:48 systemd[1]: Unit named-pkcs11.service entered failed state. > 10:35:48 systemd[1]: Stopped Berkeley Internet Name Domain (DNS) with > native PKCS#11. > -- Reboot -- > 10:58:05 named-pkcs11[1496]: initializing DST: no PKCS#11 provider > 10:58:05 named-pkcs11[1496]: exiting (due to fatal error) > 10:58:05 systemd[1]: named-pkcs11.service: control process exited, > code=exited status=1 > 10:58:05 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) > with native PKCS#11. > 10:58:05 systemd[1]: Unit named-pkcs11.service entered failed state. > 10:58:05 systemd[1]: Stopped Berkeley Internet Name Domain (DNS) with > native PKCS#11. > > ... After some fiddeling a restart says this: > > 19:26:21 named-pkcs11[8807]: sha1.c:92: fatal error: > 19:26:21 named-pkcs11[8807]: RUNTIME_CHECK(pk11_get_session(ctx, > OP_DIGEST, isc_boolean_true, isc_boolean_false, isc_bo > 19:26:21 named-pkcs11[8807]: exiting (due to fatal error in library) > 19:26:21 systemd[1]: named-pkcs11.service: control process exited, > code=exited status=1 > 19:26:21 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) > with native PKCS#11. > 19:26:21 systemd[1]: Unit named-pkcs11.service entered failed state. > > 4) >> I'm not aware of that we need, krb5-libs/openssl, I was getting this >> error if tokens directory doesnt exists, but IPA uses own configuration >> (see 2) not default. >> > > ok > > > I took a deeper look, and I found there some packaging errors with softhsm. > You was right with missing dependency. > > Please install softhsm-devel package, remove /var/lib/ipa/dnssec/tokens > directory, then reinstall DNS, ipa-dns-install (requires running directory > server) > > Or if you have snapshot, install softhsm-devel before upgrading ipa > > HTH > Martin^2 > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Oct 27 19:09:24 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 27 Oct 2014 20:09:24 +0100 Subject: [Freeipa-users] F20 Problem upgrading to 4.1 In-Reply-To: References: <544E2A5C.50209@redhat.com> <544E897F.4050801@redhat.com> Message-ID: <544E9864.9060804@redhat.com> On 27/10/14 19:57, John Obaterspok wrote: > Hello Martin, > > Still no go. > > I installed the softhsm-devel package (that only contains header > files), removed the token directory, reinstalled the bind & > bind-pkcs11, did ipa-dns-install that completed ok (I guess): > > To accept the default shown in brackets, press the Enter key. > > Existing BIND configuration detected, overwrite? [no]: yes > Directory Manager password: > > # ipa-upgradeconfig > [Verifying that root certificate is published] > *Failed to backup CS.cfg: no magic attribute 'dogtag'* > [Migrate CRL publish directory] > CRL tree already moved > [Verifying that CA proxy configuration is correct] > [Verifying that KDC configuration is using ipa-kdb backend] > [Fixing trust flags in /etc/httpd/alias] > Trust flags already processed > [Fix DS schema file syntax] > Syntax already fixed > [Removing RA cert from DS NSS database] > RA cert already removed > [Removing self-signed CA] > [Checking for deprecated KDC configuration files] > [Checking for deprecated backups of Samba configuration files] > [Setting up Firefox extension] > [Add missing CA DNS records] > IPA CA DNS records already processed > [Removing deprecated DNS configuration options] > [Ensuring minimal number of connections] > [Enabling serial autoincrement in DNS] > [Updating GSSAPI configuration in DNS] > [Updating pid-file configuration in DNS] > [Masking named] > Changes to named.conf have been made, restart named > *Failed to restart named: Command ''/bin/systemctl' 'restart' > 'named-pkcs11.service'' returned non-zero exit status 1* > [Verifying that CA service certificate profile is updated] > [Update certmonger certificate renewal configuration to version 2] > [Enable PKIX certificate path discovery and validation] > PKIX already enabled > The ipa-upgradeconfig command was successful > > > # systemctl restart named-pkcs11 && journalctl -xn > 19:38:54 named-pkcs11[838]: ObjectStore.cpp(59): Failed to enumerate > object store in /var/lib/ipa/dnssec/tokens > 19:38:54 named-pkcs11[838]: SoftHSM.cpp(437): Could not load the > object store > 19:38:54 named-pkcs11[838]: initializing DST: PKCS#11 initialization > failed > 19:38:54 named-pkcs11[838]: exiting (due to fatal error) > 19:38:54 systemd[1]: named-pkcs11.service: control process exited, > code=exited status=1 > 19:38:54 systemd[1]: Failed to start Berkeley Internet Name Domain > (DNS) with native PKCS#11. > > > It seems the problem is now there are no tokens: > # ll /var/lib/ipa/dnssec/ > total 4.0K > -rwxrwx---. 1 ods named 30 Oct 26 10:35 softhsm_pin This is interesting, ipa-dns-install should detect missing directory and create new one. Could you send me tail of /var/log/ipaserver-install.log, where DNS debug lines are? Martin^2 > > Any ideas? > > -- john > > 2014-10-27 19:05 GMT+01:00 Martin Basti >: > > On 27/10/14 18:53, John Obaterspok wrote: >> >> >> 2014-10-27 12:19 GMT+01:00 Martin Basti > >: >> >> On 26/10/14 21:39, John Obaterspok wrote: >>> Hi, >>> >>> I enabled mkosek-freeipa repo for F20 and updated >>> freeipa-server from 3.3.5 to 4.1. The yum update reported >>> just a single error: >>> >>> Could not load host key: /etc/ssh/ssh_host_dsa_key >>> >>> After reboot I had 3 services that failed to start: >>> ipa, kadmin, named-pkcs11 >>> >>> Doing "strace -f named-pkcs11 -u named -f -g" I can see: >>> "/var/lib/softhsm/tokens/" => -1 EACCES (Permission denied) >>> initializing DST: PKCS#11 initialization failed >>> exiting (due to fatal error) >>> >>> >>> For kadmin the error is due to not being able to connect to >>> sldap >>> >>> I noticed that softhsm2-util --show-slots reported "ERROR: >>> Could not initialize the library." But that seemed to be >>> because wasn't part of the update. After that I could show >>> the default slot and then I manually called following (as root): >>> >>> "/usr/bin/softhsm2-util --init-token --slot 0 --label >>> ipaDNSSEC --pin XXXXXXXX --so-pin XXXXXXXX" >>> >>> But the problems won't go away. Any clues? >>> >>> -- john >>> >>> >>> >>> >> Hello, >> >> 1) >> can you share your /var/log/ipaupgrade.log ? >> >> >> Unfortunatly I removed the original ipaupgrade.log file when I >> did I retry to install freeipa-server. The current ipaupgrade.log >> has two errors: >> First) >> >> 2014-10-26T12:45:15Z DEBUG Live 1, updated 1 >> 2014-10-26T12:45:15Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: >> {'desc': 'Operations error'} >> 2014-10-26T12:45:15Z ERROR Update failed: Operations error: >> 2014-10-26T12:45:15Z INFO Updating existing entry: cn=MemberOf >> Plugin,cn=plugins,cn=config >> 2014-10-26T12:45:15Z DEBUG >> --------------------------------------------- > Are there some information about entry which is updated above? > >> >> Second) It complains about not being able to start named-pkcs11 >> service. >> >> 2) >> your issue with softhsm can be caused by missing enviroment >> variable >> IPA internally uses >> >> SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf >> please try SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf >> softhsm2-util --show-slots, and let me know if it works >> >> same with named-pkcs11, >> >> >> The filestamps for softhsm_pin & tokens match the time I did the >> original update >> >> # ll /var/lib/ipa/dnssec/ >> -rwxrwx---. 1 ods named 30 Oct 26 10:35 softhsm_pin >> drwxrws---. 2 ods named 4.0K Oct 26 10:35 tokens >> >> # ll /var/lib/ipa/dnssec/tokens/ >> total 0 >> >> # SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf softhsm2-util >> --show-slots >> Available slots: >> Slot 0 >> Slot info: >> Description: SoftHSM slot 0 >> Manufacturer ID: SoftHSM project >> Hardware version: 2.0 >> Firmware version: 2.0 >> Token present: yes >> Token info: >> Manufacturer ID: SoftHSM project >> Model: SoftHSM v2 >> Hardware version: 2.0 >> Firmware version: 2.0 >> Serial number: >> Initialized: no >> User PIN init.: no >> Label: > Slot was not initialized by IPA >> >> 3) >> can you share journalctl -u named-pkcs11 output? >> >> >> 10:35:48 systemd[1]: named-pkcs11.service: control process >> exited, code=exited status=1 >> 10:35:48 systemd[1]: Failed to start Berkeley Internet Name >> Domain (DNS) with native PKCS#11. >> 10:35:48 systemd[1]: Unit named-pkcs11.service entered failed state. >> 10:35:48 systemd[1]: Stopped Berkeley Internet Name Domain (DNS) >> with native PKCS#11. >> -- Reboot -- >> 10:58:05 named-pkcs11[1496]: initializing DST: no PKCS#11 provider >> 10:58:05 named-pkcs11[1496]: exiting (due to fatal error) >> 10:58:05 systemd[1]: named-pkcs11.service: control process >> exited, code=exited status=1 >> 10:58:05 systemd[1]: Failed to start Berkeley Internet Name >> Domain (DNS) with native PKCS#11. >> 10:58:05 systemd[1]: Unit named-pkcs11.service entered failed state. >> 10:58:05 systemd[1]: Stopped Berkeley Internet Name Domain (DNS) >> with native PKCS#11. >> >> ... After some fiddeling a restart says this: >> >> 19:26:21 named-pkcs11[8807]: sha1.c:92: fatal error: >> 19:26:21 named-pkcs11[8807]: RUNTIME_CHECK(pk11_get_session(ctx, >> OP_DIGEST, isc_boolean_true, isc_boolean_false, isc_bo >> 19:26:21 named-pkcs11[8807]: exiting (due to fatal error in library) >> 19:26:21 systemd[1]: named-pkcs11.service: control process >> exited, code=exited status=1 >> 19:26:21 systemd[1]: Failed to start Berkeley Internet Name >> Domain (DNS) with native PKCS#11. >> 19:26:21 systemd[1]: Unit named-pkcs11.service entered failed state. >> >> 4) >> I'm not aware of that we need, krb5-libs/openssl, I was >> getting this error if tokens directory doesnt exists, but IPA >> uses own configuration (see 2) not default. >> >> >> ok > > I took a deeper look, and I found there some packaging errors with > softhsm. > You was right with missing dependency. > > Please install softhsm-devel package, remove > /var/lib/ipa/dnssec/tokens directory, then reinstall DNS, > ipa-dns-install (requires running directory server) > > Or if you have snapshot, install softhsm-devel before upgrading ipa > > HTH > Martin^2 > > -- > Martin Basti > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.obaterspok at gmail.com Mon Oct 27 19:34:53 2014 From: john.obaterspok at gmail.com (John Obaterspok) Date: Mon, 27 Oct 2014 20:34:53 +0100 Subject: [Freeipa-users] F20 Problem upgrading to 4.1 In-Reply-To: <544E9864.9060804@redhat.com> References: <544E2A5C.50209@redhat.com> <544E897F.4050801@redhat.com> <544E9864.9060804@redhat.com> Message-ID: hmm... Could not connect to the Directory Server So I started it with start-dirsrv since "systemctl start ipa" failed. Then it was a breeze, ipa-dns-install worked fine. # systemctl --failed 0 loaded units listed. I haven't verified that it works, but I feel confident :) -- john 2014-10-27 20:09 GMT+01:00 Martin Basti : > On 27/10/14 19:57, John Obaterspok wrote: > > Hello Martin, > > Still no go. > > I installed the softhsm-devel package (that only contains header files), > removed the token directory, reinstalled the bind & bind-pkcs11, did > ipa-dns-install that completed ok (I guess): > > To accept the default shown in brackets, press the Enter key. > > Existing BIND configuration detected, overwrite? [no]: yes > Directory Manager password: > > # ipa-upgradeconfig > [Verifying that root certificate is published] > *Failed to backup CS.cfg: no magic attribute 'dogtag'* > [Migrate CRL publish directory] > CRL tree already moved > [Verifying that CA proxy configuration is correct] > [Verifying that KDC configuration is using ipa-kdb backend] > [Fixing trust flags in /etc/httpd/alias] > Trust flags already processed > [Fix DS schema file syntax] > Syntax already fixed > [Removing RA cert from DS NSS database] > RA cert already removed > [Removing self-signed CA] > [Checking for deprecated KDC configuration files] > [Checking for deprecated backups of Samba configuration files] > [Setting up Firefox extension] > [Add missing CA DNS records] > IPA CA DNS records already processed > [Removing deprecated DNS configuration options] > [Ensuring minimal number of connections] > [Enabling serial autoincrement in DNS] > [Updating GSSAPI configuration in DNS] > [Updating pid-file configuration in DNS] > [Masking named] > Changes to named.conf have been made, restart named > *Failed to restart named: Command ''/bin/systemctl' 'restart' > 'named-pkcs11.service'' returned non-zero exit status 1* > [Verifying that CA service certificate profile is updated] > [Update certmonger certificate renewal configuration to version 2] > [Enable PKIX certificate path discovery and validation] > PKIX already enabled > The ipa-upgradeconfig command was successful > > > # systemctl restart named-pkcs11 && journalctl -xn > 19:38:54 named-pkcs11[838]: ObjectStore.cpp(59): Failed to enumerate > object store in /var/lib/ipa/dnssec/tokens > 19:38:54 named-pkcs11[838]: SoftHSM.cpp(437): Could not load the object > store > 19:38:54 named-pkcs11[838]: initializing DST: PKCS#11 initialization failed > 19:38:54 named-pkcs11[838]: exiting (due to fatal error) > 19:38:54 systemd[1]: named-pkcs11.service: control process exited, > code=exited status=1 > 19:38:54 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) > with native PKCS#11. > > > It seems the problem is now there are no tokens: > # ll /var/lib/ipa/dnssec/ > total 4.0K > -rwxrwx---. 1 ods named 30 Oct 26 10:35 softhsm_pin > > > This is interesting, ipa-dns-install should detect missing directory and > create new one. > Could you send me tail of /var/log/ipaserver-install.log, where DNS debug > lines are? > > Martin^2 > > > Any ideas? > > -- john > > 2014-10-27 19:05 GMT+01:00 Martin Basti : > >> On 27/10/14 18:53, John Obaterspok wrote: >> >> >> >> 2014-10-27 12:19 GMT+01:00 Martin Basti : >> >>> On 26/10/14 21:39, John Obaterspok wrote: >>> >>> Hi, >>> >>> I enabled mkosek-freeipa repo for F20 and updated freeipa-server from >>> 3.3.5 to 4.1. The yum update reported just a single error: >>> >>> Could not load host key: /etc/ssh/ssh_host_dsa_key >>> >>> After reboot I had 3 services that failed to start: >>> ipa, kadmin, named-pkcs11 >>> >>> Doing "strace -f named-pkcs11 -u named -f -g" I can see: >>> "/var/lib/softhsm/tokens/" => -1 EACCES (Permission denied) >>> initializing DST: PKCS#11 initialization failed >>> exiting (due to fatal error) >>> >>> >>> For kadmin the error is due to not being able to connect to sldap >>> >>> I noticed that softhsm2-util --show-slots reported "ERROR: Could not >>> initialize the library." But that seemed to be because wasn't part of the >>> update. After that I could show the default slot and then I manually called >>> following (as root): >>> >>> "/usr/bin/softhsm2-util --init-token --slot 0 --label ipaDNSSEC --pin >>> XXXXXXXX --so-pin XXXXXXXX" >>> >>> But the problems won't go away. Any clues? >>> >>> -- john >>> >>> >>> >>> >>> Hello, >>> >>> 1) >>> can you share your /var/log/ipaupgrade.log ? >>> >> >> Unfortunatly I removed the original ipaupgrade.log file when I did I >> retry to install freeipa-server. The current ipaupgrade.log has two errors: >> First) >> >> 2014-10-26T12:45:15Z DEBUG Live 1, updated 1 >> 2014-10-26T12:45:15Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: >> {'desc': 'Operations error'} >> 2014-10-26T12:45:15Z ERROR Update failed: Operations error: >> 2014-10-26T12:45:15Z INFO Updating existing entry: cn=MemberOf >> Plugin,cn=plugins,cn=config >> 2014-10-26T12:45:15Z DEBUG --------------------------------------------- >> >> Are there some information about entry which is updated above? >> >> >> Second) It complains about not being able to start named-pkcs11 service. >> >> >> >>> 2) >>> your issue with softhsm can be caused by missing enviroment variable >>> IPA internally uses >>> >>> SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf >>> please try SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf softhsm2-util >>> --show-slots, and let me know if it works >>> >>> same with named-pkcs11, >>> >>> >> The filestamps for softhsm_pin & tokens match the time I did the >> original update >> >> # ll /var/lib/ipa/dnssec/ >> -rwxrwx---. 1 ods named 30 Oct 26 10:35 softhsm_pin >> drwxrws---. 2 ods named 4.0K Oct 26 10:35 tokens >> >> # ll /var/lib/ipa/dnssec/tokens/ >> total 0 >> >> # SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf softhsm2-util --show-slots >> Available slots: >> Slot 0 >> Slot info: >> Description: SoftHSM slot 0 >> Manufacturer ID: SoftHSM project >> Hardware version: 2.0 >> Firmware version: 2.0 >> Token present: yes >> Token info: >> Manufacturer ID: SoftHSM project >> Model: SoftHSM v2 >> Hardware version: 2.0 >> Firmware version: 2.0 >> Serial number: >> Initialized: no >> User PIN init.: no >> Label: >> >> Slot was not initialized by IPA >> >> >> 3) >>> can you share journalctl -u named-pkcs11 output? >>> >> >> 10:35:48 systemd[1]: named-pkcs11.service: control process exited, >> code=exited status=1 >> 10:35:48 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) >> with native PKCS#11. >> 10:35:48 systemd[1]: Unit named-pkcs11.service entered failed state. >> 10:35:48 systemd[1]: Stopped Berkeley Internet Name Domain (DNS) with >> native PKCS#11. >> -- Reboot -- >> 10:58:05 named-pkcs11[1496]: initializing DST: no PKCS#11 provider >> 10:58:05 named-pkcs11[1496]: exiting (due to fatal error) >> 10:58:05 systemd[1]: named-pkcs11.service: control process exited, >> code=exited status=1 >> 10:58:05 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) >> with native PKCS#11. >> 10:58:05 systemd[1]: Unit named-pkcs11.service entered failed state. >> 10:58:05 systemd[1]: Stopped Berkeley Internet Name Domain (DNS) with >> native PKCS#11. >> >> ... After some fiddeling a restart says this: >> >> 19:26:21 named-pkcs11[8807]: sha1.c:92: fatal error: >> 19:26:21 named-pkcs11[8807]: RUNTIME_CHECK(pk11_get_session(ctx, >> OP_DIGEST, isc_boolean_true, isc_boolean_false, isc_bo >> 19:26:21 named-pkcs11[8807]: exiting (due to fatal error in library) >> 19:26:21 systemd[1]: named-pkcs11.service: control process exited, >> code=exited status=1 >> 19:26:21 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) >> with native PKCS#11. >> 19:26:21 systemd[1]: Unit named-pkcs11.service entered failed state. >> >> 4) >>> I'm not aware of that we need, krb5-libs/openssl, I was getting this >>> error if tokens directory doesnt exists, but IPA uses own configuration >>> (see 2) not default. >>> >> >> ok >> >> >> I took a deeper look, and I found there some packaging errors with >> softhsm. >> You was right with missing dependency. >> >> Please install softhsm-devel package, remove /var/lib/ipa/dnssec/tokens >> directory, then reinstall DNS, ipa-dns-install (requires running directory >> server) >> >> Or if you have snapshot, install softhsm-devel before upgrading ipa >> >> HTH >> Martin^2 >> >> -- >> Martin Basti >> >> > > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Oct 27 19:40:51 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 27 Oct 2014 20:40:51 +0100 Subject: [Freeipa-users] F20 Problem upgrading to 4.1 In-Reply-To: References: <544E2A5C.50209@redhat.com> <544E897F.4050801@redhat.com> <544E9864.9060804@redhat.com> Message-ID: <544E9FC3.6020809@redhat.com> On 27/10/14 20:34, John Obaterspok wrote: > hmm... Could not connect to the Directory Server > > So I started it with start-dirsrv since "systemctl start ipa" failed. > Then it was a breeze, ipa-dns-install worked fine. > > # systemctl --failed > 0 loaded units listed. I'm lost, does IPA work or not? are all services running? (ipactl status) are tokens created in /var/lib/ipa/dnssec/tokens can you dig records from IPA DNS? Martin^2 > > I haven't verified that it works, but I feel confident :) > > -- john > > > 2014-10-27 20:09 GMT+01:00 Martin Basti >: > > On 27/10/14 19:57, John Obaterspok wrote: >> Hello Martin, >> >> Still no go. >> >> I installed the softhsm-devel package (that only contains header >> files), removed the token directory, reinstalled the bind & >> bind-pkcs11, did ipa-dns-install that completed ok (I guess): >> >> To accept the default shown in brackets, press the Enter key. >> >> Existing BIND configuration detected, overwrite? [no]: yes >> Directory Manager password: >> >> # ipa-upgradeconfig >> [Verifying that root certificate is published] >> *Failed to backup CS.cfg: no magic attribute 'dogtag'* >> [Migrate CRL publish directory] >> CRL tree already moved >> [Verifying that CA proxy configuration is correct] >> [Verifying that KDC configuration is using ipa-kdb backend] >> [Fixing trust flags in /etc/httpd/alias] >> Trust flags already processed >> [Fix DS schema file syntax] >> Syntax already fixed >> [Removing RA cert from DS NSS database] >> RA cert already removed >> [Removing self-signed CA] >> [Checking for deprecated KDC configuration files] >> [Checking for deprecated backups of Samba configuration files] >> [Setting up Firefox extension] >> [Add missing CA DNS records] >> IPA CA DNS records already processed >> [Removing deprecated DNS configuration options] >> [Ensuring minimal number of connections] >> [Enabling serial autoincrement in DNS] >> [Updating GSSAPI configuration in DNS] >> [Updating pid-file configuration in DNS] >> [Masking named] >> Changes to named.conf have been made, restart named >> *Failed to restart named: Command ''/bin/systemctl' 'restart' >> 'named-pkcs11.service'' returned non-zero exit status 1* >> [Verifying that CA service certificate profile is updated] >> [Update certmonger certificate renewal configuration to version 2] >> [Enable PKIX certificate path discovery and validation] >> PKIX already enabled >> The ipa-upgradeconfig command was successful >> >> >> # systemctl restart named-pkcs11 && journalctl -xn >> 19:38:54 named-pkcs11[838]: ObjectStore.cpp(59): Failed to >> enumerate object store in /var/lib/ipa/dnssec/tokens >> 19:38:54 named-pkcs11[838]: SoftHSM.cpp(437): Could not load the >> object store >> 19:38:54 named-pkcs11[838]: initializing DST: PKCS#11 >> initialization failed >> 19:38:54 named-pkcs11[838]: exiting (due to fatal error) >> 19:38:54 systemd[1]: named-pkcs11.service: control process >> exited, code=exited status=1 >> 19:38:54 systemd[1]: Failed to start Berkeley Internet Name >> Domain (DNS) with native PKCS#11. >> >> >> It seems the problem is now there are no tokens: >> # ll /var/lib/ipa/dnssec/ >> total 4.0K >> -rwxrwx---. 1 ods named 30 Oct 26 10:35 softhsm_pin > > This is interesting, ipa-dns-install should detect missing > directory and create new one. > Could you send me tail of /var/log/ipaserver-install.log, where > DNS debug lines are? > > Martin^2 > >> >> Any ideas? >> >> -- john >> >> 2014-10-27 19:05 GMT+01:00 Martin Basti > >: >> >> On 27/10/14 18:53, John Obaterspok wrote: >>> >>> >>> 2014-10-27 12:19 GMT+01:00 Martin Basti >> >: >>> >>> On 26/10/14 21:39, John Obaterspok wrote: >>>> Hi, >>>> >>>> I enabled mkosek-freeipa repo for F20 and updated >>>> freeipa-server from 3.3.5 to 4.1. The yum update >>>> reported just a single error: >>>> >>>> Could not load host key: /etc/ssh/ssh_host_dsa_key >>>> >>>> After reboot I had 3 services that failed to start: >>>> ipa, kadmin, named-pkcs11 >>>> >>>> Doing "strace -f named-pkcs11 -u named -f -g" I can see: >>>> "/var/lib/softhsm/tokens/" => -1 EACCES (Permission >>>> denied) >>>> initializing DST: PKCS#11 initialization failed >>>> exiting (due to fatal error) >>>> >>>> >>>> For kadmin the error is due to not being able to >>>> connect to sldap >>>> >>>> I noticed that softhsm2-util --show-slots reported >>>> "ERROR: Could not initialize the library." But that >>>> seemed to be because wasn't part of the update. After >>>> that I could show the default slot and then I manually >>>> called following (as root): >>>> >>>> "/usr/bin/softhsm2-util --init-token --slot 0 --label >>>> ipaDNSSEC --pin XXXXXXXX --so-pin XXXXXXXX" >>>> >>>> But the problems won't go away. Any clues? >>>> >>>> -- john >>>> >>>> >>>> >>>> >>> Hello, >>> >>> 1) >>> can you share your /var/log/ipaupgrade.log ? >>> >>> >>> Unfortunatly I removed the original ipaupgrade.log file when >>> I did I retry to install freeipa-server. The current >>> ipaupgrade.log has two errors: >>> First) >>> >>> 2014-10-26T12:45:15Z DEBUG Live 1, updated 1 >>> 2014-10-26T12:45:15Z DEBUG Unhandled LDAPError: >>> OPERATIONS_ERROR: {'desc': 'Operations error'} >>> 2014-10-26T12:45:15Z ERROR Update failed: Operations error: >>> 2014-10-26T12:45:15Z INFO Updating existing entry: >>> cn=MemberOf Plugin,cn=plugins,cn=config >>> 2014-10-26T12:45:15Z DEBUG >>> --------------------------------------------- >> Are there some information about entry which is updated above? >> >>> >>> Second) It complains about not being able to start >>> named-pkcs11 service. >>> >>> 2) >>> your issue with softhsm can be caused by missing >>> enviroment variable >>> IPA internally uses >>> >>> SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf >>> please try SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf >>> softhsm2-util --show-slots, and let me know if it works >>> >>> same with named-pkcs11, >>> >>> >>> The filestamps for softhsm_pin & tokens match the time I did >>> the original update >>> >>> # ll /var/lib/ipa/dnssec/ >>> -rwxrwx---. 1 ods named 30 Oct 26 10:35 softhsm_pin >>> drwxrws---. 2 ods named 4.0K Oct 26 10:35 tokens >>> >>> # ll /var/lib/ipa/dnssec/tokens/ >>> total 0 >>> >>> # SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf softhsm2-util >>> --show-slots >>> Available slots: >>> Slot 0 >>> Slot info: >>> Description: SoftHSM slot 0 >>> Manufacturer ID: SoftHSM project >>> Hardware version: 2.0 >>> Firmware version: 2.0 >>> Token present: yes >>> Token info: >>> Manufacturer ID: SoftHSM project >>> Model: SoftHSM v2 >>> Hardware version: 2.0 >>> Firmware version: 2.0 >>> Serial number: >>> Initialized: no >>> User PIN init.: no >>> Label: >> Slot was not initialized by IPA >>> >>> 3) >>> can you share journalctl -u named-pkcs11 output? >>> >>> >>> 10:35:48 systemd[1]: named-pkcs11.service: control process >>> exited, code=exited status=1 >>> 10:35:48 systemd[1]: Failed to start Berkeley Internet Name >>> Domain (DNS) with native PKCS#11. >>> 10:35:48 systemd[1]: Unit named-pkcs11.service entered >>> failed state. >>> 10:35:48 systemd[1]: Stopped Berkeley Internet Name Domain >>> (DNS) with native PKCS#11. >>> -- Reboot -- >>> 10:58:05 named-pkcs11[1496]: initializing DST: no PKCS#11 >>> provider >>> 10:58:05 named-pkcs11[1496]: exiting (due to fatal error) >>> 10:58:05 systemd[1]: named-pkcs11.service: control process >>> exited, code=exited status=1 >>> 10:58:05 systemd[1]: Failed to start Berkeley Internet Name >>> Domain (DNS) with native PKCS#11. >>> 10:58:05 systemd[1]: Unit named-pkcs11.service entered >>> failed state. >>> 10:58:05 systemd[1]: Stopped Berkeley Internet Name Domain >>> (DNS) with native PKCS#11. >>> >>> ... After some fiddeling a restart says this: >>> >>> 19:26:21 named-pkcs11[8807]: sha1.c:92: fatal error: >>> 19:26:21 named-pkcs11[8807]: >>> RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, >>> isc_boolean_true, isc_boolean_false, isc_bo >>> 19:26:21 named-pkcs11[8807]: exiting (due to fatal error in >>> library) >>> 19:26:21 systemd[1]: named-pkcs11.service: control process >>> exited, code=exited status=1 >>> 19:26:21 systemd[1]: Failed to start Berkeley Internet Name >>> Domain (DNS) with native PKCS#11. >>> 19:26:21 systemd[1]: Unit named-pkcs11.service entered >>> failed state. >>> >>> 4) >>> I'm not aware of that we need, krb5-libs/openssl, I was >>> getting this error if tokens directory doesnt exists, >>> but IPA uses own configuration (see 2) not default. >>> >>> >>> ok >> >> I took a deeper look, and I found there some packaging errors >> with softhsm. >> You was right with missing dependency. >> >> Please install softhsm-devel package, remove >> /var/lib/ipa/dnssec/tokens directory, then reinstall DNS, >> ipa-dns-install (requires running directory server) >> >> Or if you have snapshot, install softhsm-devel before >> upgrading ipa >> >> HTH >> Martin^2 >> >> -- >> Martin Basti >> >> > > > -- > Martin Basti > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.obaterspok at gmail.com Mon Oct 27 19:50:01 2014 From: john.obaterspok at gmail.com (John Obaterspok) Date: Mon, 27 Oct 2014 20:50:01 +0100 Subject: [Freeipa-users] F20 Problem upgrading to 4.1 In-Reply-To: <544E9FC3.6020809@redhat.com> References: <544E2A5C.50209@redhat.com> <544E897F.4050801@redhat.com> <544E9864.9060804@redhat.com> <544E9FC3.6020809@redhat.com> Message-ID: Hello Martin, It works perfectly again! note, I noticed in /var/log/ipaserver-install.log that ipa-dns-installed failed due to 389 wasn't started (failed to connect). Once it was started manually the ipa-dns-installed worked fine. Thanks a lot Martin, -- john 2014-10-27 20:40 GMT+01:00 Martin Basti : > On 27/10/14 20:34, John Obaterspok wrote: > > hmm... Could not connect to the Directory Server > > So I started it with start-dirsrv since "systemctl start ipa" failed. > Then it was a breeze, ipa-dns-install worked fine. > > # systemctl --failed > 0 loaded units listed. > > I'm lost, does IPA work or not? > are all services running? (ipactl status) > are tokens created in /var/lib/ipa/dnssec/tokens > can you dig records from IPA DNS? > > Martin^2 > > > I haven't verified that it works, but I feel confident :) > > -- john > > > 2014-10-27 20:09 GMT+01:00 Martin Basti : > >> On 27/10/14 19:57, John Obaterspok wrote: >> >> Hello Martin, >> >> Still no go. >> >> I installed the softhsm-devel package (that only contains header >> files), removed the token directory, reinstalled the bind & bind-pkcs11, >> did ipa-dns-install that completed ok (I guess): >> >> To accept the default shown in brackets, press the Enter key. >> >> Existing BIND configuration detected, overwrite? [no]: yes >> Directory Manager password: >> >> # ipa-upgradeconfig >> [Verifying that root certificate is published] >> *Failed to backup CS.cfg: no magic attribute 'dogtag'* >> [Migrate CRL publish directory] >> CRL tree already moved >> [Verifying that CA proxy configuration is correct] >> [Verifying that KDC configuration is using ipa-kdb backend] >> [Fixing trust flags in /etc/httpd/alias] >> Trust flags already processed >> [Fix DS schema file syntax] >> Syntax already fixed >> [Removing RA cert from DS NSS database] >> RA cert already removed >> [Removing self-signed CA] >> [Checking for deprecated KDC configuration files] >> [Checking for deprecated backups of Samba configuration files] >> [Setting up Firefox extension] >> [Add missing CA DNS records] >> IPA CA DNS records already processed >> [Removing deprecated DNS configuration options] >> [Ensuring minimal number of connections] >> [Enabling serial autoincrement in DNS] >> [Updating GSSAPI configuration in DNS] >> [Updating pid-file configuration in DNS] >> [Masking named] >> Changes to named.conf have been made, restart named >> *Failed to restart named: Command ''/bin/systemctl' 'restart' >> 'named-pkcs11.service'' returned non-zero exit status 1* >> [Verifying that CA service certificate profile is updated] >> [Update certmonger certificate renewal configuration to version 2] >> [Enable PKIX certificate path discovery and validation] >> PKIX already enabled >> The ipa-upgradeconfig command was successful >> >> >> # systemctl restart named-pkcs11 && journalctl -xn >> 19:38:54 named-pkcs11[838]: ObjectStore.cpp(59): Failed to enumerate >> object store in /var/lib/ipa/dnssec/tokens >> 19:38:54 named-pkcs11[838]: SoftHSM.cpp(437): Could not load the object >> store >> 19:38:54 named-pkcs11[838]: initializing DST: PKCS#11 initialization >> failed >> 19:38:54 named-pkcs11[838]: exiting (due to fatal error) >> 19:38:54 systemd[1]: named-pkcs11.service: control process exited, >> code=exited status=1 >> 19:38:54 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) >> with native PKCS#11. >> >> >> It seems the problem is now there are no tokens: >> # ll /var/lib/ipa/dnssec/ >> total 4.0K >> -rwxrwx---. 1 ods named 30 Oct 26 10:35 softhsm_pin >> >> >> This is interesting, ipa-dns-install should detect missing directory >> and create new one. >> Could you send me tail of /var/log/ipaserver-install.log, where DNS debug >> lines are? >> >> Martin^2 >> >> >> Any ideas? >> >> -- john >> >> 2014-10-27 19:05 GMT+01:00 Martin Basti : >> >>> On 27/10/14 18:53, John Obaterspok wrote: >>> >>> >>> >>> 2014-10-27 12:19 GMT+01:00 Martin Basti : >>> >>>> On 26/10/14 21:39, John Obaterspok wrote: >>>> >>>> Hi, >>>> >>>> I enabled mkosek-freeipa repo for F20 and updated freeipa-server from >>>> 3.3.5 to 4.1. The yum update reported just a single error: >>>> >>>> Could not load host key: /etc/ssh/ssh_host_dsa_key >>>> >>>> After reboot I had 3 services that failed to start: >>>> ipa, kadmin, named-pkcs11 >>>> >>>> Doing "strace -f named-pkcs11 -u named -f -g" I can see: >>>> "/var/lib/softhsm/tokens/" => -1 EACCES (Permission denied) >>>> initializing DST: PKCS#11 initialization failed >>>> exiting (due to fatal error) >>>> >>>> >>>> For kadmin the error is due to not being able to connect to sldap >>>> >>>> I noticed that softhsm2-util --show-slots reported "ERROR: Could not >>>> initialize the library." But that seemed to be because wasn't part of the >>>> update. After that I could show the default slot and then I manually called >>>> following (as root): >>>> >>>> "/usr/bin/softhsm2-util --init-token --slot 0 --label ipaDNSSEC --pin >>>> XXXXXXXX --so-pin XXXXXXXX" >>>> >>>> But the problems won't go away. Any clues? >>>> >>>> -- john >>>> >>>> >>>> >>>> >>>> Hello, >>>> >>>> 1) >>>> can you share your /var/log/ipaupgrade.log ? >>>> >>> >>> Unfortunatly I removed the original ipaupgrade.log file when I did I >>> retry to install freeipa-server. The current ipaupgrade.log has two errors: >>> First) >>> >>> 2014-10-26T12:45:15Z DEBUG Live 1, updated 1 >>> 2014-10-26T12:45:15Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: >>> {'desc': 'Operations error'} >>> 2014-10-26T12:45:15Z ERROR Update failed: Operations error: >>> 2014-10-26T12:45:15Z INFO Updating existing entry: cn=MemberOf >>> Plugin,cn=plugins,cn=config >>> 2014-10-26T12:45:15Z DEBUG --------------------------------------------- >>> >>> Are there some information about entry which is updated above? >>> >>> >>> Second) It complains about not being able to start named-pkcs11 >>> service. >>> >>> >>> >>>> 2) >>>> your issue with softhsm can be caused by missing enviroment variable >>>> IPA internally uses >>>> >>>> SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf >>>> please try SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf softhsm2-util >>>> --show-slots, and let me know if it works >>>> >>>> same with named-pkcs11, >>>> >>>> >>> The filestamps for softhsm_pin & tokens match the time I did the >>> original update >>> >>> # ll /var/lib/ipa/dnssec/ >>> -rwxrwx---. 1 ods named 30 Oct 26 10:35 softhsm_pin >>> drwxrws---. 2 ods named 4.0K Oct 26 10:35 tokens >>> >>> # ll /var/lib/ipa/dnssec/tokens/ >>> total 0 >>> >>> # SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf softhsm2-util >>> --show-slots >>> Available slots: >>> Slot 0 >>> Slot info: >>> Description: SoftHSM slot 0 >>> Manufacturer ID: SoftHSM project >>> Hardware version: 2.0 >>> Firmware version: 2.0 >>> Token present: yes >>> Token info: >>> Manufacturer ID: SoftHSM project >>> Model: SoftHSM v2 >>> Hardware version: 2.0 >>> Firmware version: 2.0 >>> Serial number: >>> Initialized: no >>> User PIN init.: no >>> Label: >>> >>> Slot was not initialized by IPA >>> >>> >>> 3) >>>> can you share journalctl -u named-pkcs11 output? >>>> >>> >>> 10:35:48 systemd[1]: named-pkcs11.service: control process exited, >>> code=exited status=1 >>> 10:35:48 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) >>> with native PKCS#11. >>> 10:35:48 systemd[1]: Unit named-pkcs11.service entered failed state. >>> 10:35:48 systemd[1]: Stopped Berkeley Internet Name Domain (DNS) with >>> native PKCS#11. >>> -- Reboot -- >>> 10:58:05 named-pkcs11[1496]: initializing DST: no PKCS#11 provider >>> 10:58:05 named-pkcs11[1496]: exiting (due to fatal error) >>> 10:58:05 systemd[1]: named-pkcs11.service: control process exited, >>> code=exited status=1 >>> 10:58:05 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) >>> with native PKCS#11. >>> 10:58:05 systemd[1]: Unit named-pkcs11.service entered failed state. >>> 10:58:05 systemd[1]: Stopped Berkeley Internet Name Domain (DNS) with >>> native PKCS#11. >>> >>> ... After some fiddeling a restart says this: >>> >>> 19:26:21 named-pkcs11[8807]: sha1.c:92: fatal error: >>> 19:26:21 named-pkcs11[8807]: RUNTIME_CHECK(pk11_get_session(ctx, >>> OP_DIGEST, isc_boolean_true, isc_boolean_false, isc_bo >>> 19:26:21 named-pkcs11[8807]: exiting (due to fatal error in library) >>> 19:26:21 systemd[1]: named-pkcs11.service: control process exited, >>> code=exited status=1 >>> 19:26:21 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) >>> with native PKCS#11. >>> 19:26:21 systemd[1]: Unit named-pkcs11.service entered failed state. >>> >>> 4) >>>> I'm not aware of that we need, krb5-libs/openssl, I was getting this >>>> error if tokens directory doesnt exists, but IPA uses own configuration >>>> (see 2) not default. >>>> >>> >>> ok >>> >>> >>> I took a deeper look, and I found there some packaging errors with >>> softhsm. >>> You was right with missing dependency. >>> >>> Please install softhsm-devel package, remove /var/lib/ipa/dnssec/tokens >>> directory, then reinstall DNS, ipa-dns-install (requires running directory >>> server) >>> >>> Or if you have snapshot, install softhsm-devel before upgrading ipa >>> >>> HTH >>> Martin^2 >>> >>> -- >>> Martin Basti >>> >>> >> >> >> -- >> Martin Basti >> >> > > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Oct 27 19:52:43 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 27 Oct 2014 20:52:43 +0100 Subject: [Freeipa-users] F20 Problem upgrading to 4.1 In-Reply-To: References: <544E2A5C.50209@redhat.com> <544E897F.4050801@redhat.com> <544E9864.9060804@redhat.com> <544E9FC3.6020809@redhat.com> Message-ID: <544EA28B.5050402@redhat.com> On 27/10/14 20:50, John Obaterspok wrote: > Hello Martin, > > It works perfectly again! > > note, I noticed in /var/log/ipaserver-install.log that > ipa-dns-installed failed due to 389 wasn't started (failed to > connect). Once it was started manually the ipa-dns-installed worked fine. > > Thanks a lot Martin, > > -- john > You are welcome :-) > > 2014-10-27 20:40 GMT+01:00 Martin Basti >: > > On 27/10/14 20:34, John Obaterspok wrote: >> hmm... Could not connect to the Directory Server >> >> So I started it with start-dirsrv since "systemctl start ipa" >> failed. Then it was a breeze, ipa-dns-install worked fine. >> >> # systemctl --failed >> 0 loaded units listed. > I'm lost, does IPA work or not? > are all services running? (ipactl status) > are tokens created in /var/lib/ipa/dnssec/tokens > can you dig records from IPA DNS? > > Martin^2 > >> >> I haven't verified that it works, but I feel confident :) >> >> -- john >> >> >> 2014-10-27 20:09 GMT+01:00 Martin Basti > >: >> >> On 27/10/14 19:57, John Obaterspok wrote: >>> Hello Martin, >>> >>> Still no go. >>> >>> I installed the softhsm-devel package (that only contains >>> header files), removed the token directory, reinstalled the >>> bind & bind-pkcs11, did ipa-dns-install that completed ok (I >>> guess): >>> >>> To accept the default shown in brackets, press the Enter key. >>> >>> Existing BIND configuration detected, overwrite? [no]: yes >>> Directory Manager password: >>> >>> # ipa-upgradeconfig >>> [Verifying that root certificate is published] >>> *Failed to backup CS.cfg: no magic attribute 'dogtag'* >>> [Migrate CRL publish directory] >>> CRL tree already moved >>> [Verifying that CA proxy configuration is correct] >>> [Verifying that KDC configuration is using ipa-kdb backend] >>> [Fixing trust flags in /etc/httpd/alias] >>> Trust flags already processed >>> [Fix DS schema file syntax] >>> Syntax already fixed >>> [Removing RA cert from DS NSS database] >>> RA cert already removed >>> [Removing self-signed CA] >>> [Checking for deprecated KDC configuration files] >>> [Checking for deprecated backups of Samba configuration files] >>> [Setting up Firefox extension] >>> [Add missing CA DNS records] >>> IPA CA DNS records already processed >>> [Removing deprecated DNS configuration options] >>> [Ensuring minimal number of connections] >>> [Enabling serial autoincrement in DNS] >>> [Updating GSSAPI configuration in DNS] >>> [Updating pid-file configuration in DNS] >>> [Masking named] >>> Changes to named.conf have been made, restart named >>> *Failed to restart named: Command ''/bin/systemctl' >>> 'restart' 'named-pkcs11.service'' returned non-zero exit >>> status 1* >>> [Verifying that CA service certificate profile is updated] >>> [Update certmonger certificate renewal configuration to >>> version 2] >>> [Enable PKIX certificate path discovery and validation] >>> PKIX already enabled >>> The ipa-upgradeconfig command was successful >>> >>> >>> # systemctl restart named-pkcs11 && journalctl -xn >>> 19:38:54 named-pkcs11[838]: ObjectStore.cpp(59): Failed to >>> enumerate object store in /var/lib/ipa/dnssec/tokens >>> 19:38:54 named-pkcs11[838]: SoftHSM.cpp(437): Could not load >>> the object store >>> 19:38:54 named-pkcs11[838]: initializing DST: PKCS#11 >>> initialization failed >>> 19:38:54 named-pkcs11[838]: exiting (due to fatal error) >>> 19:38:54 systemd[1]: named-pkcs11.service: control process >>> exited, code=exited status=1 >>> 19:38:54 systemd[1]: Failed to start Berkeley Internet Name >>> Domain (DNS) with native PKCS#11. >>> >>> >>> It seems the problem is now there are no tokens: >>> # ll /var/lib/ipa/dnssec/ >>> total 4.0K >>> -rwxrwx---. 1 ods named 30 Oct 26 10:35 softhsm_pin >> >> This is interesting, ipa-dns-install should detect missing >> directory and create new one. >> Could you send me tail of /var/log/ipaserver-install.log, >> where DNS debug lines are? >> >> Martin^2 >> >>> >>> Any ideas? >>> >>> -- john >>> >>> 2014-10-27 19:05 GMT+01:00 Martin Basti >> >: >>> >>> On 27/10/14 18:53, John Obaterspok wrote: >>>> >>>> >>>> 2014-10-27 12:19 GMT+01:00 Martin Basti >>>> >: >>>> >>>> On 26/10/14 21:39, John Obaterspok wrote: >>>>> Hi, >>>>> >>>>> I enabled mkosek-freeipa repo for F20 and updated >>>>> freeipa-server from 3.3.5 to 4.1. The yum update >>>>> reported just a single error: >>>>> >>>>> Could not load host key: /etc/ssh/ssh_host_dsa_key >>>>> >>>>> After reboot I had 3 services that failed to start: >>>>> ipa, kadmin, named-pkcs11 >>>>> >>>>> Doing "strace -f named-pkcs11 -u named -f -g" I >>>>> can see: >>>>> "/var/lib/softhsm/tokens/" => -1 EACCES >>>>> (Permission denied) >>>>> initializing DST: PKCS#11 initialization failed >>>>> exiting (due to fatal error) >>>>> >>>>> >>>>> For kadmin the error is due to not being able to >>>>> connect to sldap >>>>> >>>>> I noticed that softhsm2-util --show-slots reported >>>>> "ERROR: Could not initialize the library." But >>>>> that seemed to be because wasn't part of the >>>>> update. After that I could show the default slot >>>>> and then I manually called following (as root): >>>>> >>>>> "/usr/bin/softhsm2-util --init-token --slot 0 >>>>> --label ipaDNSSEC --pin XXXXXXXX --so-pin XXXXXXXX" >>>>> >>>>> But the problems won't go away. Any clues? >>>>> >>>>> -- john >>>>> >>>>> >>>>> >>>>> >>>> Hello, >>>> >>>> 1) >>>> can you share your /var/log/ipaupgrade.log ? >>>> >>>> >>>> Unfortunatly I removed the original ipaupgrade.log file >>>> when I did I retry to install freeipa-server. The >>>> current ipaupgrade.log has two errors: >>>> First) >>>> >>>> 2014-10-26T12:45:15Z DEBUG Live 1, updated 1 >>>> 2014-10-26T12:45:15Z DEBUG Unhandled LDAPError: >>>> OPERATIONS_ERROR: {'desc': 'Operations error'} >>>> 2014-10-26T12:45:15Z ERROR Update failed: Operations error: >>>> 2014-10-26T12:45:15Z INFO Updating existing entry: >>>> cn=MemberOf Plugin,cn=plugins,cn=config >>>> 2014-10-26T12:45:15Z DEBUG >>>> --------------------------------------------- >>> Are there some information about entry which is updated >>> above? >>> >>>> >>>> Second) It complains about not being able to start >>>> named-pkcs11 service. >>>> >>>> 2) >>>> your issue with softhsm can be caused by missing >>>> enviroment variable >>>> IPA internally uses >>>> >>>> SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf >>>> please try >>>> SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf >>>> softhsm2-util --show-slots, and let me know if it works >>>> >>>> same with named-pkcs11, >>>> >>>> >>>> The filestamps for softhsm_pin & tokens match the time >>>> I did the original update >>>> >>>> # ll /var/lib/ipa/dnssec/ >>>> -rwxrwx---. 1 ods named 30 Oct 26 10:35 softhsm_pin >>>> drwxrws---. 2 ods named 4.0K Oct 26 10:35 tokens >>>> >>>> # ll /var/lib/ipa/dnssec/tokens/ >>>> total 0 >>>> >>>> # SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf >>>> softhsm2-util --show-slots >>>> Available slots: >>>> Slot 0 >>>> Slot info: >>>> Description: SoftHSM slot 0 >>>> Manufacturer ID: SoftHSM project >>>> Hardware version: 2.0 >>>> Firmware version: 2.0 >>>> Token present: yes >>>> Token info: >>>> Manufacturer ID: SoftHSM project >>>> Model: SoftHSM v2 >>>> Hardware version: 2.0 >>>> Firmware version: 2.0 >>>> Serial number: >>>> Initialized: no >>>> User PIN init.: no >>>> Label: >>> Slot was not initialized by IPA >>>> >>>> 3) >>>> can you share journalctl -u named-pkcs11 output? >>>> >>>> >>>> 10:35:48 systemd[1]: named-pkcs11.service: control >>>> process exited, code=exited status=1 >>>> 10:35:48 systemd[1]: Failed to start Berkeley Internet >>>> Name Domain (DNS) with native PKCS#11. >>>> 10:35:48 systemd[1]: Unit named-pkcs11.service entered >>>> failed state. >>>> 10:35:48 systemd[1]: Stopped Berkeley Internet Name >>>> Domain (DNS) with native PKCS#11. >>>> -- Reboot -- >>>> 10:58:05 named-pkcs11[1496]: initializing DST: no >>>> PKCS#11 provider >>>> 10:58:05 named-pkcs11[1496]: exiting (due to fatal error) >>>> 10:58:05 systemd[1]: named-pkcs11.service: control >>>> process exited, code=exited status=1 >>>> 10:58:05 systemd[1]: Failed to start Berkeley Internet >>>> Name Domain (DNS) with native PKCS#11. >>>> 10:58:05 systemd[1]: Unit named-pkcs11.service entered >>>> failed state. >>>> 10:58:05 systemd[1]: Stopped Berkeley Internet Name >>>> Domain (DNS) with native PKCS#11. >>>> >>>> ... After some fiddeling a restart says this: >>>> >>>> 19:26:21 named-pkcs11[8807]: sha1.c:92: fatal error: >>>> 19:26:21 named-pkcs11[8807]: >>>> RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, >>>> isc_boolean_true, isc_boolean_false, isc_bo >>>> 19:26:21 named-pkcs11[8807]: exiting (due to fatal >>>> error in library) >>>> 19:26:21 systemd[1]: named-pkcs11.service: control >>>> process exited, code=exited status=1 >>>> 19:26:21 systemd[1]: Failed to start Berkeley Internet >>>> Name Domain (DNS) with native PKCS#11. >>>> 19:26:21 systemd[1]: Unit named-pkcs11.service entered >>>> failed state. >>>> >>>> 4) >>>> I'm not aware of that we need, krb5-libs/openssl, I >>>> was getting this error if tokens directory doesnt >>>> exists, but IPA uses own configuration (see 2) not >>>> default. >>>> >>>> >>>> ok >>> >>> I took a deeper look, and I found there some packaging >>> errors with softhsm. >>> You was right with missing dependency. >>> >>> Please install softhsm-devel package, remove >>> /var/lib/ipa/dnssec/tokens directory, then reinstall >>> DNS, ipa-dns-install (requires running directory server) >>> >>> Or if you have snapshot, install softhsm-devel before >>> upgrading ipa >>> >>> HTH >>> Martin^2 >>> >>> -- >>> Martin Basti >>> >>> >> >> >> -- >> Martin Basti >> >> > > > -- > Martin Basti > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Oct 27 20:38:30 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 27 Oct 2014 14:38:30 -0600 Subject: [Freeipa-users] multi-master replication In-Reply-To: <15dbb99a45a64ad4bd168584e2a1baac@BLUPR08MB488.namprd08.prod.outlook.com> References: <544C3DA5.6010009@redhat.com> <544E4BA5.8020602@redhat.com> <5b424b09f0a74ee0822b49ce2e886694@BLUPR08MB488.namprd08.prod.outlook.com> <544E71FF.1040701@redhat.com> <8ff07afa639047f3970f0f0621bd655a@BLUPR08MB488.namprd08.prod.outlook.com> <544E8D61.6050205@redhat.com> <15dbb99a45a64ad4bd168584e2a1baac@BLUPR08MB488.namprd08.prod.outlook.com> Message-ID: <544EAD46.8010301@redhat.com> On 10/27/2014 12:41 PM, Craig White wrote: > > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* Monday, October 27, 2014 11:22 AM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] multi-master replication > > On 10/27/2014 01:41 PM, Craig White wrote: > > Maybe fixed ? seems to be replicating now? > > https://bugzilla.redhat.com/show_bug.cgi?id=953653 > > Why don?t they incorporate that into the released RHEL version? > > > I think we did. Into 7.0. > What was the fix? In 389-ds-base we increased the default sasl buffer size from 2k to 64k. Did IPA in 7.0 increase the default sasl buffer size to 256k? What did you do to fix the problem? Did you increase the sasl buffer size to be > 64k? If you feel this should be fixed in RHEL 6.x, please file a bug against RHEL 6.x and/or open a support ticket. But if the problem is that the default sasl buffer size setting is too low, then the real problem is - what should the default size be? Maybe 256k won't be enough for all users? Should we make the default 500k? 1Mb? > ---- > > Great ? but 7.0 isn?t certified at Rackspace so I had no choice but to > use 6.x and I would suspect that people are going to still be using > 6.x for new installs for a while. > > But thanks ? and keep up the great work. > > Craig > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From CWhite at skytouchtechnology.com Mon Oct 27 20:56:40 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Mon, 27 Oct 2014 20:56:40 +0000 Subject: [Freeipa-users] adding 45 users to a group crashes dirsrv Message-ID: RHEL 6.5 - new install ipa-server-3.0.0-42.el6.x86_64 389-ds-base-1.2.11.15-47.el6.x86_64 Create a new group, click 'add users' and click the box on the top to select all 45 users, click the arrows to move all of the users over and click 'Add' on the bottom at which point it will lose connection to the LDAP server, throw up an error and dirsrv is dead and has to be restarted. Seems as though I can make it crash with as few as 4-6 users at a time. [27/Oct/2014:17:40:23 +0000] agmt="cn=meToipa002.stt.local" (ipa002:389) - session end: state=5 load=1 sent=3 skipped=0 skipped_new_rid=0 skipped_csn_gt_cons_maxcsn=0 skipped_up_to_date=0 skipped_csn_gt_ruv=0 skipped_csn_covered=0 [27/Oct/2014:17:40:23 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.stt.local" (ipa002:389): Successfully released consumer [27/Oct/2014:17:40:23 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.stt.local " (ipa002:389): Beginning linger on the connection [27/Oct/2014:17:40:23 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.stt.local " (ipa002:389): State: sending_updates -> wait_for_changes [27/Oct/2014:17:40:24 +0000] NSMMReplicationPlugin - conn=69789 op=6 Acquired consumer connection extension [27/Oct/2014:17:40:24 +0000] NSMMReplicationPlugin - conn=69789 op=6 repl="dc=stt-internal,dc=local": Released replica held by locking_purl=conn=69789 id=5 [27/Oct/2014:17:40:24 +0000] NSMMReplicationPlugin - conn=69789 op=6 Relinquishing consumer connection extension [27/Oct/2014:17:40:24 +0000] NSMMReplicationPlugin - conn=69789 op=7 Acquired consumer connection extension [27/Oct/2014:17:40:24 +0000] NSMMReplicationPlugin - conn=69789 op=7 repl="dc=stt-internal,dc=local": Begin incremental protocol [27/Oct/2014:17:40:24 +0000] - csngen_adjust_time: gen state before 544e83890005:1414431621:0:4 [27/Oct/2014:17:40:24 +0000] - _csngen_adjust_local_time: gen state before 544e83890005:1414431621:0:4 [27/Oct/2014:17:40:24 +0000] - _csngen_adjust_local_time: gen state after 544e838c0000:1414431624:0:4 [27/Oct/2014:17:40:24 +0000] - csngen_adjust_time: gen state after 544e838e0001:1414431624:2:4 [27/Oct/2014:17:40:24 +0000] NSMMReplicationPlugin - conn=69789 op=7 repl="dc=stt-internal,dc=local": Acquired replica [27/Oct/2014:17:40:24 +0000] NSMMReplicationPlugin - conn=69789 op=7 repl="dc=stt-internal,dc=local": StartNSDS90ReplicationRequest: response=0 rc=0 [27/Oct/2014:17:40:24 +0000] NSMMReplicationPlugin - conn=69789 op=7 Relinquishing consumer connection extension [27/Oct/2014:17:40:28 +0000] NSMMReplicationPlugin - changelog program - _cl5GetDBFile: found DB object 7fb95801fbf0 for database /var/lib/dirsrv/slapd-STT-INTERNAL-LOCAL/cldb/d7273483-5bb011e4-8073dfa6-7d9cbbef_544aa332000000040000.db4 [27/Oct/2014:17:40:28 +0000] NSMMReplicationPlugin - changelog program - cl5GetOperationCount: found DB object 7fb95801fbf0 [27/Oct/2014:17:40:30 +0000] NSMMReplicationPlugin - conn=69789 op=8 Acquired consumer connection extension [27/Oct/2014:17:40:30 +0000] NSMMReplicationPlugin - conn=69789 op=8 repl="dc=stt-internal,dc=local": Released replica held by locking_purl=conn=69789 id=7 [27/Oct/2014:17:40:30 +0000] NSMMReplicationPlugin - conn=69789 op=8 Relinquishing consumer connection extension [27/Oct/2014:17:41:24 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.stt" (ipa002:389): Linger timeout has expired on the connection [27/Oct/2014:17:41:24 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.stt" (ipa002:389): Disconnected from the consumer [27/Oct/2014:17:45:53 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.stt" (ipa002:389): Consumer failed to replay change (uniqueid 46305b1f-5ad711e4-89d1dfa6-7d9cbbef, CSN 544e84d7000200040000): Can't contact LDAP server(-1). Will retry later. [27/Oct/2014:17:45:55 +0000] NSMMReplicationPlugin - agmt="cn=meToipa002.stt" (ipa002:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) [27/Oct/2014:17:45:55 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [27/Oct/2014:17:45:55 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP server) [27/Oct/2014:17:45:59 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [27/Oct/2014:17:45:59 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP server) [27/Oct/2014:17:46:05 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [27/Oct/2014:17:46:05 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP server) [27/Oct/2014:17:46:17 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) Craig White System Administrator O 623-201-8179 M 602-377-9752 [cid:image001.png at 01CF86FE.42D51630] SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7660 bytes Desc: image001.png URL: From sipazzo at yahoo.com Mon Oct 27 21:00:13 2014 From: sipazzo at yahoo.com (sipazzo) Date: Mon, 27 Oct 2014 14:00:13 -0700 Subject: [Freeipa-users] Solaris 10 client configuration using profile In-Reply-To: <20141011175449.GG2328@redhat.com> Message-ID: <1414443613.71533.YahooMailBasic@web122501.mail.ne1.yahoo.com> okay so this is working with the secure profile, thank you all, but I am getting a ton of errors in my logs on the solaris clients like this: Oct 27 13:08:51 dc2.ipadomain.com ldap_cachemgr[15004]: [ID 545954 daemon.error] libsldap: makeConnection: failed to open connection to idm1.ipadomain.com Oct 27 13:08:51 dc2.ipadomain.com ldap_cachemgr[15004]: [ID 545954 daemon.error] libsldap: makeConnection: failed to open connection to idm2.ipadomain.com Oct 27 13:08:51 dc2.ipadomain.com ldap_cachemgr[15004]: [ID 687686 daemon.warning] libsldap: Falling back to anonymous, non-SSL mode for __ns_ldap_getRootDSE. openConnection: simple bind failed - Can't contact LDAP server Oct 27 13:08:51 dc2.ipadomain.com last message repeated 1 time Oct 27 13:08:51 dc2.ipadomain.com ldap_cachemgr[15004]: [ID 293258 daemon.warning] libsldap: Status: 81 Mesg: openConnection: simple bind failed - Can't contact LDAP server Oct 27 13:08:51 dc2.ipadomain.com ldap_cachemgr[15004]: [ID 545954 daemon.error] libsldap: makeConnection: failed to open connection to idm1-corp.ipadomain.com Oct 27 13:08:51 dc2-io.ipadomain.com ldap_cachemgr[15004]: [ID 687686 daemon.warning] libsldap: Falling back to anonymous, non-SSL mode for __ns_ldap_getRootDSE. openConnection: simple bind failed - Can't contact LDAP server I think this might be related to trying to use tls:simple for authentication so I went back over the steps for the cert set up and I am unable to generate or import the ca.pem cert into the nssdb database certutil -N -d /var/ldap certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format. certutil -A -n "ca-cert" -i /etc/ipa/ca.pem -a -t CT -d /var/ldap certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format. ldap_cachemgr is online and we can authenticate but errors are filling logs. ldaplist and ldapclient list look fine. When I try to use ssl with ldapsearch I get the followin: ldapsearch -D "uid=auth,cn=users,cn=accounts,dc=ipadomain,dc=com" -w secret -h idm2.ipadomain.com -b "dc=ipadomain,dc=com" -s sub -x -ZZ "(objectclass=*)" SSL initialization failed: error -8174 (security library: bad database.) This is solaris 10 client and redhat 6.5 servers running version 3.0.0-37. I am unsure of the next step to troubleshoot this issue. -------------------------------------------- On Sat, 10/11/14, Alexander Bokovoy wrote: Subject: Re: [Freeipa-users] Solaris 10 client configuration using profile To: "Rob Crittenden" Cc: "sipazzo" , "Freeipa-users at redhat.com" Date: Saturday, October 11, 2014, 10:54 AM On Sat, 11 Oct 2014, Rob Crittenden wrote: >sipazzo wrote: >> Thank you,I know where the profile is in the directory tree and how I would invoke it were it there...I don't know how to get it into the directory tree so that it is available to clients. I see posts giving examples of different profilesthat could be used but no post as to how to add it to the directory. Sorry if I am missing something obvious. >> >> >> -------------------------------------------- >> On Fri, 10/10/14, Rob Crittenden wrote: >> >>? Subject: Re: [Freeipa-users] Solaris 10 client configuration using profile >>? To: "sipazzo" , freeipa-users at redhat.com >>? Date: Friday, October 10, 2014, 4:53 PM >> >>? sipazzo wrote: >>? > >>? Hello, I am trying to set up a default profile for my >>? Solaris 10 IPA clients as recommended. I generated a profile >>? on a Solaris with the attributes I needed except I got an >>? "invalid parameter" error when specifying the >>? domainName attribute like this -a domainName=example.com >>? even though this parameter works when I use it in >>? ldapclient manual. More of an issue though is I have been >>? unable to find documentation on getting the profile >>? incorporated into the ipa server. How do I get this profile >>? on the ipa server and make it available to my Solaris >>? clients? Also, my understanding is the clients periodically >>? check this profile so they stay updated with the latest >>? configuration information. What generates this check? Is it >>? time based, a restart of a service or ?? >>? > >>? > Thank you for any >>? assistance. >>? > >> >>? It's been forever since I configured a >>? Solaris anything client but I can >>? tell you >>? where the profile gets stored: >>? cn=profilename,cn=default,ou=profile,$SUFFIX >> >>? IPA ships with a default >>? profile of: >> >>? dn: >>? cn=default,ou=profile,$SUFFIX >>? ObjectClass: >>? top >>? ObjectClass: DUAConfigProfile >>? defaultServerList: $FQDN >>? defaultSearchBase: $SUFFIX >>? authenticationMethod: none >>? searchTimeLimit: 15 >>? cn: >>? default >>? serviceSearchDescriptor: >>? passwd:cn=users,cn=accounts,$SUFFIX >>? serviceSearchDescriptor: >>? group:cn=groups,cn=compat,$SUFFIX >>? bindTimeLimit: 5 >>? objectClassMap: >>? shadow:shadowAccount=posixAccount >>? followReferrals:TRUE >> >>? The full schema can be found at >>? http://docs.oracle.com/cd/E23824_01/html/821-1455/schemas-17.html >> >>? So if your profile is named >>? foo you'd invoke it with something like: >> >>? # ldapclient init -a >>? profileName=foo ipa.example.com >> >>? rob >> >> > >Here is an example inspired by >https://bugzilla.redhat.com/show_bug.cgi?id=815515 > >$ ldapmodify -x -D 'cn=Directory Manager' -W >dn: cn=solaris_authssl_test,ou=profile,dc=example,dc=com >objectClass: top >objectClass: DUAConfigProfile >cn: solaris_authssl_test >authenticationMethod: tls:simple >bindTimeLimit: 5 >credentialLevel: proxy >defaultSearchBase: dc=example,dc=com >defaultSearchScope: one >defaultServerList: ipa01.example.com ipa02.example.com ipa03.example.com >followReferrals: TRUE >objectclassMap: shadow:shadowAccount=posixAccount >objectclassMap: printers:sunPrinter=printerService >preferredServerList: ipa01.example.com ipa02.example.com >profileTTL: 6000 >searchTimeLimit: 10 >serviceSearchDescriptor: passwd:cn=users,cn=accounts,dc=example,dc=com >serviceSearchDescriptor: group:cn=groups,cn=compat,dc=example,dc=com >serviceSearchDescriptor: netgroup:cn=ng,cn=compat,dc=example,dc=com >serviceSearchDescriptor: ethers:cn=computers,cn=accounts,dc=example,dc=com >serviceSearchDescriptor: automount:cn=default,cn=automount,dc=example,dc=com >serviceSearchDescriptor: >auto_master:automountMapName=auto.master,cn=defualt,cn=automount,dc=example,dc=com >serviceSearchDescriptor: aliases:ou=aliases,ou=test,dc=example,dc=com >serviceSearchDescriptor: printers:ou=printers,ou=test,dc=example,dc=com > >^D > >You may want to check out >https://bugzilla.redhat.com/show_bug.cgi?id=815533 as well. Should the profile be available anonymously? It is not in 4.x: $ ldapsearch -x -b ou=profile,dc=ipacloud,dc=test # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 $ kinit admin Password for admin at IPACLOUD.TEST: $ ldapsearch -Y GSSAPI -b ou=profile,dc=ipacloud,dc=test SASL/GSSAPI authentication started SASL username: admin at IPACLOUD.TEST SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # profile, ipacloud.test dn: ou=profile,dc=ipacloud,dc=test objectClass: top objectClass: organizationalUnit ou: profiles ou: profile # default, profile, ipacloud.test dn: cn=default,ou=profile,dc=ipacloud,dc=test defaultServerList: cc21.ipacloud.test defaultSearchBase: dc=ipacloud,dc=test objectClass: top objectClass: DUAConfigProfile serviceSearchDescriptor: passwd:cn=users,cn=accounts,dc=ipacloud,dc=test serviceSearchDescriptor: group:cn=groups,cn=compat,dc=ipacloud,dc=test searchTimeLimit: 15 followReferrals: TRUE objectclassMap: shadow:shadowAccount=posixAccount bindTimeLimit: 5 authenticationMethod: none cn: default # search result search: 4 result: 0 Success # numResponses: 3 # numEntries: 2 I think it should be available anonymously too, so we need to add a specialized ACI for that. -- / Alexander Bokovoy From CWhite at skytouchtechnology.com Mon Oct 27 21:03:08 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Mon, 27 Oct 2014 21:03:08 +0000 Subject: [Freeipa-users] multi-master replication In-Reply-To: <544EAD46.8010301@redhat.com> References: <544C3DA5.6010009@redhat.com> <544E4BA5.8020602@redhat.com> <5b424b09f0a74ee0822b49ce2e886694@BLUPR08MB488.namprd08.prod.outlook.com> <544E71FF.1040701@redhat.com> <8ff07afa639047f3970f0f0621bd655a@BLUPR08MB488.namprd08.prod.outlook.com> <544E8D61.6050205@redhat.com> <15dbb99a45a64ad4bd168584e2a1baac@BLUPR08MB488.namprd08.prod.outlook.com> <544EAD46.8010301@redhat.com> Message-ID: <993b173069964862ba2cb45b9b39e491@BLUPR08MB488.namprd08.prod.outlook.com> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson Sent: Monday, October 27, 2014 1:39 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] multi-master replication On 10/27/2014 12:41 PM, Craig White wrote: From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Monday, October 27, 2014 11:22 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] multi-master replication On 10/27/2014 01:41 PM, Craig White wrote: Maybe fixed - seems to be replicating now... https://bugzilla.redhat.com/show_bug.cgi?id=953653 Why don't they incorporate that into the released RHEL version? I think we did. Into 7.0. What was the fix? In 389-ds-base we increased the default sasl buffer size from 2k to 64k. Did IPA in 7.0 increase the default sasl buffer size to 256k? What did you do to fix the problem? Did you increase the sasl buffer size to be > 64k? If you feel this should be fixed in RHEL 6.x, please file a bug against RHEL 6.x and/or open a support ticket. But if the problem is that the default sasl buffer size setting is too low, then the real problem is - what should the default size be? Maybe 256k won't be enough for all users? Should we make the default 500k? 1Mb? ---- # cat buffer-size.ldif dn: cn=config changetype: modify replace: nsslapd-sasl-max-buffer-size nsslapd-sasl-max-buffer-size: 262144 it may not be enough but it was enough to allow the replica to send data back to the master which solved my immediate problem. I will file a bug against RHEL 6 when I get a chance to breath later this week. Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Oct 27 21:07:16 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 27 Oct 2014 17:07:16 -0400 Subject: [Freeipa-users] Solaris 10 client configuration using profile In-Reply-To: <1414443613.71533.YahooMailBasic@web122501.mail.ne1.yahoo.com> References: <1414443613.71533.YahooMailBasic@web122501.mail.ne1.yahoo.com> Message-ID: <544EB404.7040606@redhat.com> sipazzo wrote: > okay so this is working with the secure profile, thank you all, but I am getting a ton of errors in my logs on the solaris clients like this: > > Oct 27 13:08:51 dc2.ipadomain.com ldap_cachemgr[15004]: [ID 545954 daemon.error] libsldap: makeConnection: failed to open connection to idm1.ipadomain.com > Oct 27 13:08:51 dc2.ipadomain.com ldap_cachemgr[15004]: [ID 545954 daemon.error] libsldap: makeConnection: failed to open connection to idm2.ipadomain.com > Oct 27 13:08:51 dc2.ipadomain.com ldap_cachemgr[15004]: [ID 687686 daemon.warning] libsldap: Falling back to anonymous, non-SSL mode for __ns_ldap_getRootDSE. openConnection: simple bind failed - Can't contact LDAP server > Oct 27 13:08:51 dc2.ipadomain.com last message repeated 1 time > Oct 27 13:08:51 dc2.ipadomain.com ldap_cachemgr[15004]: [ID 293258 daemon.warning] libsldap: Status: 81 Mesg: openConnection: simple bind failed - Can't contact LDAP server > Oct 27 13:08:51 dc2.ipadomain.com ldap_cachemgr[15004]: [ID 545954 daemon.error] libsldap: makeConnection: failed to open connection to idm1-corp.ipadomain.com > Oct 27 13:08:51 dc2-io.ipadomain.com ldap_cachemgr[15004]: [ID 687686 daemon.warning] libsldap: Falling back to anonymous, non-SSL mode for __ns_ldap_getRootDSE. openConnection: simple bind failed - Can't contact LDAP server > > > I think this might be related to trying to use tls:simple for authentication so I went back over the steps for the cert set up and I am unable to generate or import the ca.pem cert into the nssdb database > > certutil -N -d /var/ldap > certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format. > > > certutil -A -n "ca-cert" -i /etc/ipa/ca.pem -a -t CT -d /var/ldap > certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format. Does the directory /var/ldap exist and can the current user write to it? rob From rmeggins at redhat.com Mon Oct 27 21:10:54 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 27 Oct 2014 15:10:54 -0600 Subject: [Freeipa-users] adding 45 users to a group crashes dirsrv In-Reply-To: References: Message-ID: <544EB4DE.8090100@redhat.com> On 10/27/2014 02:56 PM, Craig White wrote: > > RHEL 6.5 ? new install > > ipa-server-3.0.0-42.el6.x86_64 > > 389-ds-base-1.2.11.15-47.el6.x86_64 > > Create a new group, click ?add users? and click the box on the top to > select all 45 users, click the arrows to move all of the users over > and click ?Add? on the bottom at which point it will lose connection > to the LDAP server, throw up an error and dirsrv is dead and has to be > restarted. > > Seems as though I can make it crash with as few as 4-6 users at a time. > Please follow http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes so we can get a core file and a stack trace from the core. > [27/Oct/2014:17:40:23 +0000] agmt="cn=meToipa002.stt.local" > (ipa002:389) - session end: state=5 load=1 sent=3 skipped=0 > skipped_new_rid=0 skipped_csn_gt_cons_maxcsn=0 skipped_up_to_date=0 > skipped_csn_gt_ruv=0 skipped_csn_covered=0 > > [27/Oct/2014:17:40:23 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.stt.local" (ipa002:389): Successfully released > consumer > > [27/Oct/2014:17:40:23 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.stt.local " (ipa002:389): Beginning linger on the > connection > > [27/Oct/2014:17:40:23 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.stt.local " (ipa002:389): State: sending_updates > -> wait_for_changes > > [27/Oct/2014:17:40:24 +0000] NSMMReplicationPlugin - conn=69789 op=6 > Acquired consumer connection extension > > [27/Oct/2014:17:40:24 +0000] NSMMReplicationPlugin - conn=69789 op=6 > repl="dc=stt-internal,dc=local": Released replica held by > locking_purl=conn=69789 id=5 > > [27/Oct/2014:17:40:24 +0000] NSMMReplicationPlugin - conn=69789 op=6 > Relinquishing consumer connection extension > > [27/Oct/2014:17:40:24 +0000] NSMMReplicationPlugin - conn=69789 op=7 > Acquired consumer connection extension > > [27/Oct/2014:17:40:24 +0000] NSMMReplicationPlugin - conn=69789 op=7 > repl="dc=stt-internal,dc=local": Begin incremental protocol > > [27/Oct/2014:17:40:24 +0000] - csngen_adjust_time: gen state before > 544e83890005:1414431621:0:4 > > [27/Oct/2014:17:40:24 +0000] - _csngen_adjust_local_time: gen state > before 544e83890005:1414431621:0:4 > > [27/Oct/2014:17:40:24 +0000] - _csngen_adjust_local_time: gen state > after 544e838c0000:1414431624:0:4 > > [27/Oct/2014:17:40:24 +0000] - csngen_adjust_time: gen state after > 544e838e0001:1414431624:2:4 > > [27/Oct/2014:17:40:24 +0000] NSMMReplicationPlugin - conn=69789 op=7 > repl="dc=stt-internal,dc=local": Acquired replica > > [27/Oct/2014:17:40:24 +0000] NSMMReplicationPlugin - conn=69789 op=7 > repl="dc=stt-internal,dc=local": StartNSDS90ReplicationRequest: > response=0 rc=0 > > [27/Oct/2014:17:40:24 +0000] NSMMReplicationPlugin - conn=69789 op=7 > Relinquishing consumer connection extension > > [27/Oct/2014:17:40:28 +0000] NSMMReplicationPlugin - changelog program > - _cl5GetDBFile: found DB object 7fb95801fbf0 for database > /var/lib/dirsrv/slapd-STT-INTERNAL-LOCAL/cldb/d7273483-5bb011e4-8073dfa6-7d9cbbef_544aa332000000040000.db4 > > [27/Oct/2014:17:40:28 +0000] NSMMReplicationPlugin - changelog program > - cl5GetOperationCount: found DB object 7fb95801fbf0 > > [27/Oct/2014:17:40:30 +0000] NSMMReplicationPlugin - conn=69789 op=8 > Acquired consumer connection extension > > [27/Oct/2014:17:40:30 +0000] NSMMReplicationPlugin - conn=69789 op=8 > repl="dc=stt-internal,dc=local": Released replica held by > locking_purl=conn=69789 id=7 > > [27/Oct/2014:17:40:30 +0000] NSMMReplicationPlugin - conn=69789 op=8 > Relinquishing consumer connection extension > > [27/Oct/2014:17:41:24 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.stt" (ipa002:389): Linger timeout has expired on > the connection > > [27/Oct/2014:17:41:24 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.stt" (ipa002:389): Disconnected from the consumer > > [27/Oct/2014:17:45:53 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.stt" (ipa002:389): Consumer failed to replay > change (uniqueid 46305b1f-5ad711e4-89d1dfa6-7d9cbbef, CSN > 544e84d7000200040000): Can't contact LDAP server(-1). Will retry later. > > [27/Oct/2014:17:45:55 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa002.stt" (ipa002:389): Warning: unable to send > endReplication extended operation (Can't contact LDAP server) > > [27/Oct/2014:17:45:55 +0000] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint > is not connected) > > [27/Oct/2014:17:45:55 +0000] slapi_ldap_bind - Error: could not > perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't > contact LDAP server) > > [27/Oct/2014:17:45:59 +0000] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint > is not connected) > > [27/Oct/2014:17:45:59 +0000] slapi_ldap_bind - Error: could not > perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't > contact LDAP server) > > [27/Oct/2014:17:46:05 +0000] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint > is not connected) > > [27/Oct/2014:17:46:05 +0000] slapi_ldap_bind - Error: could not > perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't > contact LDAP server) > > [27/Oct/2014:17:46:17 +0000] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint > is not connected) > > Craig White > > System Administrator > > O623-201-8179 M602-377-9752 > > cid:image001.png at 01CF86FE.42D51630 > > SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 7660 bytes Desc: not available URL: From rob.verduijn at gmail.com Mon Oct 27 21:59:11 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Mon, 27 Oct 2014 22:59:11 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <544D5BB2.5090003@redhat.com> References: <544D5BB2.5090003@redhat.com> Message-ID: Hello, I'm rather at a loss here. Everything seems to be running ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING ipa_memcached Service: RUNNING httpd Service: RUNNING pki-tomcatd Service: RUNNING ipa-otpd Service: RUNNING ipa-dnskeysyncd Service: RUNNING ipa: INFO: The ipactl command was successful but the upgrade log is flooded with this error : 2014-10-27T21:52:10Z DEBUG Waiting for CA to start... 2014-10-27T21:52:11Z DEBUG request ' https://freeipa.x.x:443/ca/admin/ca/getStatus' 2014-10-27T21:52:11Z DEBUG request body '' 2014-10-27T21:52:11Z DEBUG The CA status is: check interrupted 2014-10-27T21:52:11Z DEBUG Waiting for CA to start... 2014-10-27T21:52:12Z DEBUG request ' https://freeipa.x.x:443/ca/admin/ca/getStatus' 2014-10-27T21:52:12Z DEBUG request body '' I've tried the url and it works fine. https://freeipa.x.x/ca/admin/ca/getStatus it gives the following xml: 1 CArunning10.2.0-3.fc20 After I run ipa-upgradeconfig it complains about a missing magic dog tag attribute ipa-upgradeconfig [Verifying that root certificate is published]Failed to backup CS.cfg: no magic attribute 'dogtag'[Migrate CRL publish directory]CRL tree already moved[Verifying that CA proxy configuration is correct][Verifying that KDC configuration is using ipa-kdb backend][Fixing trust flags in /etc/httpd/alias]Trust flags already processed[Fix DS schema file syntax]Syntax already fixed[Removing RA cert from DS NSS database]RA cert already removed[Removing self-signed CA][Checking for deprecated KDC configuration files][Checking for deprecated backups of Samba configuration files][Setting up Firefox extension][Add missing CA DNS records]IPA CA DNS records already processed[Removing deprecated DNS configuration options][Ensuring minimal number of connections][Enabling serial autoincrement in DNS][Updating GSSAPI configuration in DNS][Updating pid-file configuration in DNS][Masking named]Changes to named.conf have been made, restart named[Verifying that CA service certificate profile is updated][Update certmonger certificate renewal configuration to version 2][Enable PKIX certificate path discovery and validation]PKIX already enabledThe ipa-upgradeconfig command was successful But my local dns zone does no longer resolve :( reverting back to the 3.3 snapshot again :( Please help Rob 2014-10-26 21:38 GMT+01:00 Rob Crittenden : > Rob Verduijn wrote: > > hmmmm.... > > > > after some more digging (monitoring the upgrade more closely.) > > I saw that the upgrade kept waiting for the ca to start, which it did > > not do. > > and after 5 minutes the upgrade gave up with the following errors in the > > ipaupgrade log : > > > > at 85% it says : > > 2014-10-26T15:04:35Z DEBUG retrieving schema for SchemaCache > > url=ldapi://%2fvar%2frun%2fslapd-XXXX-XXXX.socket > > conn= > > 2014-10-26T15:04:35Z DEBUG Starting external process > > 2014-10-26T15:04:35Z DEBUG args='/usr/bin/certutil' '-d' > > '/etc/httpd/alias' '-L' > > 2014-10-26T15:04:35Z DEBUG Process finished, return code=0 > > 2014-10-26T15:04:35Z DEBUG stdout= > > Certificate Nickname Trust > > Attributes > > > > SSL,S/MIME,JAR/XPI > > > > Signing-Cert u,u,u > > XXXX.XXXX IPA CA CT,C,C > > ipaCert u,u,u > > Server-Cert u,u,u > > > > 2014-10-26T15:04:35Z DEBUG stderr= > > 2014-10-26T15:04:35Z DEBUG Starting external process > > 2014-10-26T15:04:35Z DEBUG args='/usr/bin/certutil' '-d' > > '/etc/httpd/alias' '-L' '-n' 'TJAKO.THUIS IPA CA' '-a' > > 2014-10-26T15:04:35Z DEBUG Process finished, return code=0 > > 2014-10-26T15:04:35Z DEBUG stdout=-----BEGIN CERTIFICATE----- > > < certificate-removed > > > -----END CERTIFICATE----- > > 2014-10-26T15:04:35Z DEBUG stderr= > > 2014-10-26T15:04:36Z ERROR Upgrade failed with cannot connect to > > 'ldapi://%2fvar%2frun%2fslapd-XXXX-XXXX.socket':\ > > This has nothing to do with the CA, the LDAP server didn't come up. I'd > start with those logs or look earlier in ipaupgrade.log > > The CA requires 389-ds to be running so if it isn't up, then it will > fail to start too. > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Mon Oct 27 22:05:20 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Mon, 27 Oct 2014 23:05:20 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: <544D5BB2.5090003@redhat.com> Message-ID: sorry for the xml formatting didn't realize it would mess up some mail clients The last bit of the message again ipa-upgradeconfig gives the following : [Verifying that root certificate is published] Failed to backup CS.cfg: no magic attribute 'dogtag' [Migrate CRL publish directory] CRL tree already moved [Verifying that CA proxy configuration is correct] [Verifying that KDC configuration is using ipa-kdb backend] [Fixing trust flags in /etc/httpd/alias] Trust flags already processed [Fix DS schema file syntax] Syntax already fixed [Removing RA cert from DS NSS database] RA cert already removed [Removing self-signed CA] [Checking for deprecated KDC configuration files] [Checking for deprecated backups of Samba configuration files] [Setting up Firefox extension] [Add missing CA DNS records] IPA CA DNS records already processed [Removing deprecated DNS configuration options] [Ensuring minimal number of connections] [Enabling serial autoincrement in DNS] [Updating GSSAPI configuration in DNS] [Updating pid-file configuration in DNS] [Masking named] Changes to named.conf have been made, restart named [Verifying that CA service certificate profile is updated] [Update certmonger certificate renewal configuration to version 2] [Enable PKIX certificate path discovery and validation] PKIX already enabled The ipa-upgradeconfig command was successful Any ideas ? I'm rather stuck now. Rob 2014-10-27 22:59 GMT+01:00 Rob Verduijn : > Hello, > > I'm rather at a loss here. > Everything seems to be running > ipactl status > Directory Service: RUNNING > krb5kdc Service: RUNNING > kadmin Service: RUNNING > named Service: RUNNING > ipa_memcached Service: RUNNING > httpd Service: RUNNING > pki-tomcatd Service: RUNNING > ipa-otpd Service: RUNNING > ipa-dnskeysyncd Service: RUNNING > ipa: INFO: The ipactl command was successful > > but the upgrade log is flooded with this error : > 2014-10-27T21:52:10Z DEBUG Waiting for CA to start... > 2014-10-27T21:52:11Z DEBUG request ' > https://freeipa.x.x:443/ca/admin/ca/getStatus' > 2014-10-27T21:52:11Z DEBUG request body '' > 2014-10-27T21:52:11Z DEBUG The CA status is: check interrupted > 2014-10-27T21:52:11Z DEBUG Waiting for CA to start... > 2014-10-27T21:52:12Z DEBUG request ' > https://freeipa.x.x:443/ca/admin/ca/getStatus' > 2014-10-27T21:52:12Z DEBUG request body '' > > I've tried the url and it works fine. > https://freeipa.x.x/ca/admin/ca/getStatus > it gives the following xml: > > 1CArunning10.2.0-3.fc20 > > > After I run ipa-upgradeconfig it complains about a missing magic dog tag > attribute > ipa-upgradeconfig [Verifying that root certificate is published]Failed to > backup CS.cfg: no magic attribute 'dogtag'[Migrate CRL publish directory]CRL > tree already moved[Verifying that CA proxy configuration is correct][Verifying > that KDC configuration is using ipa-kdb backend][Fixing trust flags in > /etc/httpd/alias]Trust flags already processed[Fix DS schema file syntax]Syntax > already fixed[Removing RA cert from DS NSS database]RA cert already > removed[Removing self-signed CA][Checking for deprecated KDC > configuration files][Checking for deprecated backups of Samba > configuration files][Setting up Firefox extension][Add missing CA DNS > records]IPA CA DNS records already processed[Removing deprecated DNS > configuration options][Ensuring minimal number of connections][Enabling > serial autoincrement in DNS][Updating GSSAPI configuration in DNS][Updating > pid-file configuration in DNS][Masking named]Changes to named.conf have > been made, restart named[Verifying that CA service certificate profile is > updated][Update certmonger certificate renewal configuration to version 2][Enable > PKIX certificate path discovery and validation]PKIX already enabledThe > ipa-upgradeconfig command was successful > > But my local dns zone does no longer resolve :( > > reverting back to the 3.3 snapshot again :( > > Please help > Rob > > 2014-10-26 21:38 GMT+01:00 Rob Crittenden : > >> Rob Verduijn wrote: >> > hmmmm.... >> > >> > after some more digging (monitoring the upgrade more closely.) >> > I saw that the upgrade kept waiting for the ca to start, which it did >> > not do. >> > and after 5 minutes the upgrade gave up with the following errors in the >> > ipaupgrade log : >> > >> > at 85% it says : >> > 2014-10-26T15:04:35Z DEBUG retrieving schema for SchemaCache >> > url=ldapi://%2fvar%2frun%2fslapd-XXXX-XXXX.socket >> > conn= >> > 2014-10-26T15:04:35Z DEBUG Starting external process >> > 2014-10-26T15:04:35Z DEBUG args='/usr/bin/certutil' '-d' >> > '/etc/httpd/alias' '-L' >> > 2014-10-26T15:04:35Z DEBUG Process finished, return code=0 >> > 2014-10-26T15:04:35Z DEBUG stdout= >> > Certificate Nickname Trust >> > Attributes >> > >> > SSL,S/MIME,JAR/XPI >> > >> > Signing-Cert u,u,u >> > XXXX.XXXX IPA CA CT,C,C >> > ipaCert u,u,u >> > Server-Cert u,u,u >> > >> > 2014-10-26T15:04:35Z DEBUG stderr= >> > 2014-10-26T15:04:35Z DEBUG Starting external process >> > 2014-10-26T15:04:35Z DEBUG args='/usr/bin/certutil' '-d' >> > '/etc/httpd/alias' '-L' '-n' 'TJAKO.THUIS IPA CA' '-a' >> > 2014-10-26T15:04:35Z DEBUG Process finished, return code=0 >> > 2014-10-26T15:04:35Z DEBUG stdout=-----BEGIN CERTIFICATE----- >> > < certificate-removed > >> > -----END CERTIFICATE----- >> > 2014-10-26T15:04:35Z DEBUG stderr= >> > 2014-10-26T15:04:36Z ERROR Upgrade failed with cannot connect to >> > 'ldapi://%2fvar%2frun%2fslapd-XXXX-XXXX.socket':\ >> >> This has nothing to do with the CA, the LDAP server didn't come up. I'd >> start with those logs or look earlier in ipaupgrade.log >> >> The CA requires 389-ds to be running so if it isn't up, then it will >> fail to start too. >> >> rob >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janellenicole80 at gmail.com Mon Oct 27 22:41:11 2014 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 27 Oct 2014 15:41:11 -0700 Subject: [Freeipa-users] ipa 4.1 on CentOS 7? Any luck? Message-ID: <544ECA07.9040909@gmail.com> Hi everyone.. Well, since the fun of getting 4.0.4 on CentOS 7 - and just removing the branch of 10.2 PKI - that was easy. But trying to get 4.1 installed - it complains about needing 10.2, so I am wondering if anyone has been successful in this endeavor?? Thanks ~J From rcritten at redhat.com Mon Oct 27 22:41:46 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 27 Oct 2014 18:41:46 -0400 Subject: [Freeipa-users] Solaris 10 client configuration using profile In-Reply-To: <1414446960.78911.YahooMailBasic@web122504.mail.ne1.yahoo.com> References: <1414446960.78911.YahooMailBasic@web122504.mail.ne1.yahoo.com> Message-ID: <544ECA2A.2000700@redhat.com> sipazzo wrote: > /var/ldap exists on both client and server and I was able to sudo to root and generate the *.db files without getting the legacy database error. I scp'd them to the hosts and restarted ldap_cachemgr but errors continued. I then re-initialized the client and am still getting same errors in log files and same error when running an ldapsearch using ssl > > > SSL initialization failed: error -8174 (security library: bad database.) > > The .db files all have 444 permissions This database is only needed on the client. I gather you created the NSS database on your Linux server and copied it over? I wonder if the database version isn't supported. What are the names of the db files in /var/ldap? Do you have a certutil on the Solaris machine to do this work? The Oracle docs suggest that cert8/key3 should be fine though. rob > > > -------------------------------------------- > On Mon, 10/27/14, Rob Crittenden wrote: > > Subject: Re: [Freeipa-users] Solaris 10 client configuration using profile > To: "sipazzo" , "Alexander Bokovoy" > Cc: "Freeipa-users at redhat.com" > Date: Monday, October 27, 2014, 2:07 PM > > sipazzo wrote: > > okay so this is working with the secure > profile, thank you all, but I am getting a ton of errors in > my logs on the solaris clients like this: > > > > Oct 27 13:08:51 > dc2.ipadomain.com ldap_cachemgr[15004]: [ID 545954 > daemon.error] libsldap: makeConnection: failed to open > connection to idm1.ipadomain.com > > Oct 27 > 13:08:51 dc2.ipadomain.com ldap_cachemgr[15004]: [ID 545954 > daemon.error] libsldap: makeConnection: failed to open > connection to idm2.ipadomain.com > > Oct 27 > 13:08:51 dc2.ipadomain.com ldap_cachemgr[15004]: [ID 687686 > daemon.warning] libsldap: Falling back to anonymous, non-SSL > mode for __ns_ldap_getRootDSE. openConnection: simple bind > failed - Can't contact LDAP server > > > Oct 27 13:08:51 dc2.ipadomain.com last message repeated 1 > time > > Oct 27 13:08:51 dc2.ipadomain.com > ldap_cachemgr[15004]: [ID 293258 daemon.warning] libsldap: > Status: 81 Mesg: openConnection: simple bind failed - > Can't contact LDAP server > > Oct 27 > 13:08:51 dc2.ipadomain.com ldap_cachemgr[15004]: [ID 545954 > daemon.error] libsldap: makeConnection: failed to open > connection to idm1-corp.ipadomain.com > > > Oct 27 13:08:51 dc2-io.ipadomain.com ldap_cachemgr[15004]: > [ID 687686 daemon.warning] libsldap: Falling back to > anonymous, non-SSL mode for __ns_ldap_getRootDSE. > openConnection: simple bind failed - Can't contact LDAP > server > > > > > > I think this might be related to trying to > use tls:simple for authentication so I went back over the > steps for the cert set up and I am unable to generate or > import the ca.pem cert into the nssdb database > > > > certutil -N -d > /var/ldap > > certutil: function failed: > SEC_ERROR_LEGACY_DATABASE: The certificate/key database is > in an old, unsupported format. > > > > > > certutil -A -n > "ca-cert" -i /etc/ipa/ca.pem -a -t CT -d > /var/ldap > > certutil: function failed: > SEC_ERROR_LEGACY_DATABASE: The certificate/key database is > in an old, unsupported format. > > Does the directory /var/ldap exist and can the > current user write to it? > > rob > > From CWhite at skytouchtechnology.com Mon Oct 27 22:43:13 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Mon, 27 Oct 2014 22:43:13 +0000 Subject: [Freeipa-users] adding 45 users to a group crashes dirsrv In-Reply-To: <544EB4DE.8090100@redhat.com> References: <544EB4DE.8090100@redhat.com> Message-ID: <0f8c206292d6430e932b9d6863348134@BLUPR08MB488.namprd08.prod.outlook.com> Craig White System Administrator O 623-201-8179 M 602-377-9752 [cid:image001.png at 01CF86FE.42D51630] SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson Sent: Monday, October 27, 2014 2:11 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] adding 45 users to a group crashes dirsrv On 10/27/2014 02:56 PM, Craig White wrote: RHEL 6.5 - new install ipa-server-3.0.0-42.el6.x86_64 389-ds-base-1.2.11.15-47.el6.x86_64 Create a new group, click 'add users' and click the box on the top to select all 45 users, click the arrows to move all of the users over and click 'Add' on the bottom at which point it will lose connection to the LDAP server, throw up an error and dirsrv is dead and has to be restarted. Seems as though I can make it crash with as few as 4-6 users at a time. Please follow http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes so we can get a core file and a stack trace from the core. ---- OK - increased logging to catch this but since then, I couldn't make it happen. It has happened at least 10 times already so I am sure that it will happen again but I can't waste any more time on it but logging is enabled when it does happen again. Thanks - Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7660 bytes Desc: image001.png URL: From rmeggins at redhat.com Mon Oct 27 22:54:17 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 27 Oct 2014 16:54:17 -0600 Subject: [Freeipa-users] adding 45 users to a group crashes dirsrv In-Reply-To: <0f8c206292d6430e932b9d6863348134@BLUPR08MB488.namprd08.prod.outlook.com> References: <544EB4DE.8090100@redhat.com> <0f8c206292d6430e932b9d6863348134@BLUPR08MB488.namprd08.prod.outlook.com> Message-ID: <544ECD19.3000900@redhat.com> On 10/27/2014 04:43 PM, Craig White wrote: > > Craig White > > System Administrator > > O623-201-8179 M602-377-9752 > > cid:image001.png at 01CF86FE.42D51630 > > SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 > > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Rich Megginson > *Sent:* Monday, October 27, 2014 2:11 PM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] adding 45 users to a group crashes dirsrv > > On 10/27/2014 02:56 PM, Craig White wrote: > > RHEL 6.5 ? new install > > ipa-server-3.0.0-42.el6.x86_64 > > 389-ds-base-1.2.11.15-47.el6.x86_64 > > Create a new group, click ?add users? and click the box on the top > to select all 45 users, click the arrows to move all of the users > over and click ?Add? on the bottom at which point it will lose > connection to the LDAP server, throw up an error and dirsrv is > dead and has to be restarted. > > Seems as though I can make it crash with as few as 4-6 users at a > time. > > > Please follow > http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes so we > can get a core file and a stack trace from the core. > > ---- > > OK ? increased logging to catch this but since then, I couldn?t make > it happen. It has happened at least 10 times already so I am sure that > it will happen again but I can?t waste any more time on it but logging > is enabled when it does happen again. > You don't need additional logging. In fact, you can reset the log level back to the default, as per the faq.html#Troubleshooting instructions. What I'm interested in is getting a core file and a stack trace, which is a different process than the logging level process. Please read and follow http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes > Thanks - Craig > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 7660 bytes Desc: not available URL: From CWhite at skytouchtechnology.com Mon Oct 27 23:38:14 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Mon, 27 Oct 2014 23:38:14 +0000 Subject: [Freeipa-users] getent passwd / group Message-ID: <4c0def2865e24b7182481c4a33837a75@BLUPR08MB488.namprd08.prod.outlook.com> RHEL 6.5 - new install ipa-server-3.0.0-42.el6.x86_64 389-ds-base-1.2.11.15-47.el6.x86_64 On the master, I get nothing [root at ipa001 log]# getent passwd admin [root at ipa001 log]# But it works on the replica as expected [root at ipa002nadev01 ~]# getent passwd admin admin:*:1140000000:1110000000:Administrator:/home/admin:/bin/bash I am used to using PADL / NSSWITCH with OpenLDAP and I am rather surprised that on both, 'getent passwd' and 'getent group' return only entries from local files but then again, I've never used sssd before. Partial from /etc/sssd/sssd.conf [domain/stt.local] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = stt.local id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ipa001nadev01.stt.local chpass_provider = ipa ipa_server = ipa001nadev01.stt.local ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = stt.local debug_level = 6 Shouldn't I be seeing both local files and IPA defined users with 'getent passwd' and IPA defined users with 'getent group' commands? What could cause 'getent passwd admin' not to work on the master server now when I know I tested it when I first set it up and it worked? I have done little more than import users and groups from OpenLDAP and configure HBAC, sudo stuff in the IPA web UI. Craig White System Administrator O 623-201-8179 M 602-377-9752 [cid:image001.png at 01CF86FE.42D51630] SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7660 bytes Desc: image001.png URL: From dpal at redhat.com Tue Oct 28 00:32:02 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 27 Oct 2014 20:32:02 -0400 Subject: [Freeipa-users] getent passwd / group In-Reply-To: <4c0def2865e24b7182481c4a33837a75@BLUPR08MB488.namprd08.prod.outlook.com> References: <4c0def2865e24b7182481c4a33837a75@BLUPR08MB488.namprd08.prod.outlook.com> Message-ID: <544EE402.4010108@redhat.com> On 10/27/2014 07:38 PM, Craig White wrote: > > RHEL 6.5 -- new install > > ipa-server-3.0.0-42.el6.x86_64 > > 389-ds-base-1.2.11.15-47.el6.x86_64 > > On the master, I get nothing > > [root at ipa001 log]# getent passwd admin > > [root at ipa001 log]# > > But it works on the replica as expected > > [root at ipa002nadev01 ~]# getent passwd admin > > admin:*:1140000000:1110000000:Administrator:/home/admin:/bin/bash > > I am used to using PADL / NSSWITCH with OpenLDAP and I am rather > surprised that on both, 'getent passwd' and 'getent group' return only > entries from local files but then again, I've never used sssd before. > > Partial from /etc/sssd/sssd.conf > > [domain/stt.local] > > cache_credentials = True > > krb5_store_password_if_offline = True > > ipa_domain = stt.local > > id_provider = ipa > > auth_provider = ipa > > access_provider = ipa > > ipa_hostname = ipa001nadev01.stt.local > > chpass_provider = ipa > > ipa_server = ipa001nadev01.stt.local > > ldap_tls_cacert = /etc/ipa/ca.crt > > [sssd] > > services = nss, sudo, pam, ssh > > config_file_version = 2 > > domains = stt.local > > debug_level = 6 > > Shouldn't I be seeing both local files and IPA defined users with > 'getent passwd' and IPA defined users with 'getent group' commands? > > What could cause 'getent passwd admin' not to work on the master > server now when I know I tested it when I first set it up and it > worked? I have done little more than import users and groups from > OpenLDAP and configure HBAC, sudo stuff in the IPA web UI. > Please check on master: 1. Installation logs. Client on the server is installed last and may be there is something that went wrong at this stage but the rest of the server is OK. 2. DNS. Can you resolve the host properly? 3. Firewall. Can you kinit admin or or do an ldap search? > Craig White > > System Administrator > > O623-201-8179 M602-377-9752 > > cid:image001.png at 01CF86FE.42D51630 > > SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 7660 bytes Desc: not available URL: From jhrozek at redhat.com Tue Oct 28 01:57:33 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 28 Oct 2014 02:57:33 +0100 Subject: [Freeipa-users] getent passwd / group In-Reply-To: <4c0def2865e24b7182481c4a33837a75@BLUPR08MB488.namprd08.prod.outlook.com> References: <4c0def2865e24b7182481c4a33837a75@BLUPR08MB488.namprd08.prod.outlook.com> Message-ID: <20141028015733.GR9019@hendrix.redhat.com> On Mon, Oct 27, 2014 at 11:38:14PM +0000, Craig White wrote: > RHEL 6.5 - new install > ipa-server-3.0.0-42.el6.x86_64 > 389-ds-base-1.2.11.15-47.el6.x86_64 > > On the master, I get nothing > > [root at ipa001 log]# getent passwd admin We need to debug this one. I suspect DNS.. > [root at ipa001 log]# > > But it works on the replica as expected > > [root at ipa002nadev01 ~]# getent passwd admin > admin:*:1140000000:1110000000:Administrator:/home/admin:/bin/bash > > I am used to using PADL / NSSWITCH with OpenLDAP and I am rather surprised that on both, 'getent passwd' and 'getent group' return only entries from local files but then again, I've never used sssd before. > > Partial from /etc/sssd/sssd.conf > [domain/stt.local] > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = stt.local > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = ipa001nadev01.stt.local > chpass_provider = ipa > ipa_server = ipa001nadev01.stt.local > ldap_tls_cacert = /etc/ipa/ca.crt > > [sssd] > services = nss, sudo, pam, ssh > config_file_version = 2 > domains = stt.local > debug_level = 6 Note - the debug_level directive belongs to the domain section. If present in the [sssd] section, only debugging for the main sssd process is enabled. > > Shouldn't I be seeing both local files and IPA defined users with 'getent passwd' and IPA defined users with 'getent group' commands? No, this is by design. See the description of the 'enumerate' parameter in sssd.conf, there is also an explanation on why enumeration is off by defualt. > > What could cause 'getent passwd admin' not to work on the master server now when I know I tested it when I first set it up and it worked? I have done little more than import users and groups from OpenLDAP and configure HBAC, sudo stuff in the IPA web UI. As Dmitri said.. From mlasevich at gmail.com Tue Oct 28 05:14:22 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Mon, 27 Oct 2014 22:14:22 -0700 Subject: [Freeipa-users] F20 Problem upgrading to 4.1 In-Reply-To: <544EA28B.5050402@redhat.com> References: <544E2A5C.50209@redhat.com> <544E897F.4050801@redhat.com> <544E9864.9060804@redhat.com> <544E9FC3.6020809@redhat.com> <544EA28B.5050402@redhat.com> Message-ID: <544F262E.1050400@gmail.com> Running into same thing, but running ipa-dnsinstall does not complete: ============================= Configuring DNS (named) [1/8]: generating rndc key file WARNING: Your system is running out of entropy, you may experience long delays [2/8]: setting up our own record [3/8]: adding NS record to the zones [4/8]: setting up CA record [5/8]: setting up kerberos principal [6/8]: setting up named.conf [7/8]: configuring named to start on boot [8/8]: changing resolv.conf to point to ourselves Done configuring DNS (named). Configuring DNS key synchronization service (ipa-dnskeysyncd) [1/6]: checking status [2/6]: setting up kerberos principal [3/6]: setting up SoftHSM [4/6]: adding DNSSEC containers [5/6]: creating replica keys [error] DuplicateEntry: This entry already exists Unexpected error - see /var/log/ipaserver-install.log for details: DuplicateEntry: This entry already exists ============================= Looking into the /var/log/ipaserver-install.log gets: ============================= 2014-10-28T05:01:24Z DEBUG Storing replica public key to LDAP, ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com 2014-10-28T05:01:24Z DEBUG flushing ldap://infra-dc-01.my.domain.com:389 from SchemaCache 2014-10-28T05:01:24Z DEBUG retrieving schema for SchemaCache url=ldap://infra-dc-01.my.domain.com:389 conn= 2014-10-28T05:01:24Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 382, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 372, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", line 340, in __setup_replica_keys ldap.add_entry(entry) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1169, in error_handler raise errors.DuplicateEntry() DuplicateEntry: This entry already exists 2014-10-28T05:01:24Z DEBUG [error] DuplicateEntry: This entry already exists 2014-10-28T05:01:24Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 646, in run_script return_value = main_function() File "/sbin/ipa-dns-install", line 218, in main dnskeysyncd.create_instance(api.env.host, api.env.realm) File "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", line 128, in create_instance self.start_creation() File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 382, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 372, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", line 340, in __setup_replica_keys ldap.add_entry(entry) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1169, in error_handler raise errors.DuplicateEntry() 2014-10-28T05:01:24Z DEBUG The ipa-dns-install command failed, exception: DuplicateEntry: This entry already exists -M On 10/27/14, 12:52 PM, Martin Basti wrote: > On 27/10/14 20:50, John Obaterspok wrote: >> Hello Martin, >> >> It works perfectly again! >> >> note, I noticed in /var/log/ipaserver-install.log that >> ipa-dns-installed failed due to 389 wasn't started (failed to >> connect). Once it was started manually the ipa-dns-installed worked fine. >> >> Thanks a lot Martin, >> >> -- john >> > You are welcome :-) > >> >> 2014-10-27 20:40 GMT+01:00 Martin Basti > >: >> >> On 27/10/14 20:34, John Obaterspok wrote: >>> hmm... Could not connect to the Directory Server >>> >>> So I started it with start-dirsrv since "systemctl start ipa" >>> failed. Then it was a breeze, ipa-dns-install worked fine. >>> >>> # systemctl --failed >>> 0 loaded units listed. >> I'm lost, does IPA work or not? >> are all services running? (ipactl status) >> are tokens created in /var/lib/ipa/dnssec/tokens >> can you dig records from IPA DNS? >> >> Martin^2 >> >>> >>> I haven't verified that it works, but I feel confident :) >>> >>> -- john >>> >>> >>> 2014-10-27 20:09 GMT+01:00 Martin Basti >> >: >>> >>> On 27/10/14 19:57, John Obaterspok wrote: >>>> Hello Martin, >>>> >>>> Still no go. >>>> >>>> I installed the softhsm-devel package (that only contains >>>> header files), removed the token directory, reinstalled the >>>> bind & bind-pkcs11, did ipa-dns-install that completed ok >>>> (I guess): >>>> >>>> To accept the default shown in brackets, press the Enter key. >>>> >>>> Existing BIND configuration detected, overwrite? [no]: yes >>>> Directory Manager password: >>>> >>>> # ipa-upgradeconfig >>>> [Verifying that root certificate is published] >>>> *Failed to backup CS.cfg: no magic attribute 'dogtag'* >>>> [Migrate CRL publish directory] >>>> CRL tree already moved >>>> [Verifying that CA proxy configuration is correct] >>>> [Verifying that KDC configuration is using ipa-kdb backend] >>>> [Fixing trust flags in /etc/httpd/alias] >>>> Trust flags already processed >>>> [Fix DS schema file syntax] >>>> Syntax already fixed >>>> [Removing RA cert from DS NSS database] >>>> RA cert already removed >>>> [Removing self-signed CA] >>>> [Checking for deprecated KDC configuration files] >>>> [Checking for deprecated backups of Samba configuration files] >>>> [Setting up Firefox extension] >>>> [Add missing CA DNS records] >>>> IPA CA DNS records already processed >>>> [Removing deprecated DNS configuration options] >>>> [Ensuring minimal number of connections] >>>> [Enabling serial autoincrement in DNS] >>>> [Updating GSSAPI configuration in DNS] >>>> [Updating pid-file configuration in DNS] >>>> [Masking named] >>>> Changes to named.conf have been made, restart named >>>> *Failed to restart named: Command ''/bin/systemctl' >>>> 'restart' 'named-pkcs11.service'' returned non-zero exit >>>> status 1* >>>> [Verifying that CA service certificate profile is updated] >>>> [Update certmonger certificate renewal configuration to >>>> version 2] >>>> [Enable PKIX certificate path discovery and validation] >>>> PKIX already enabled >>>> The ipa-upgradeconfig command was successful >>>> >>>> >>>> # systemctl restart named-pkcs11 && journalctl -xn >>>> 19:38:54 named-pkcs11[838]: ObjectStore.cpp(59): Failed to >>>> enumerate object store in /var/lib/ipa/dnssec/tokens >>>> 19:38:54 named-pkcs11[838]: SoftHSM.cpp(437): Could not >>>> load the object store >>>> 19:38:54 named-pkcs11[838]: initializing DST: PKCS#11 >>>> initialization failed >>>> 19:38:54 named-pkcs11[838]: exiting (due to fatal error) >>>> 19:38:54 systemd[1]: named-pkcs11.service: control process >>>> exited, code=exited status=1 >>>> 19:38:54 systemd[1]: Failed to start Berkeley Internet Name >>>> Domain (DNS) with native PKCS#11. >>>> >>>> >>>> It seems the problem is now there are no tokens: >>>> # ll /var/lib/ipa/dnssec/ >>>> total 4.0K >>>> -rwxrwx---. 1 ods named 30 Oct 26 10:35 softhsm_pin >>> >>> This is interesting, ipa-dns-install should detect missing >>> directory and create new one. >>> Could you send me tail of /var/log/ipaserver-install.log, >>> where DNS debug lines are? >>> >>> Martin^2 >>> >>>> >>>> Any ideas? >>>> >>>> -- john >>>> >>>> 2014-10-27 19:05 GMT+01:00 Martin Basti >>> >: >>>> >>>> On 27/10/14 18:53, John Obaterspok wrote: >>>>> >>>>> >>>>> 2014-10-27 12:19 GMT+01:00 Martin Basti >>>>> >: >>>>> >>>>> On 26/10/14 21:39, John Obaterspok wrote: >>>>>> Hi, >>>>>> >>>>>> I enabled mkosek-freeipa repo for F20 and updated >>>>>> freeipa-server from 3.3.5 to 4.1. The yum update >>>>>> reported just a single error: >>>>>> >>>>>> Could not load host key: /etc/ssh/ssh_host_dsa_key >>>>>> >>>>>> After reboot I had 3 services that failed to start: >>>>>> ipa, kadmin, named-pkcs11 >>>>>> >>>>>> Doing "strace -f named-pkcs11 -u named -f -g" I >>>>>> can see: >>>>>> "/var/lib/softhsm/tokens/" => -1 EACCES >>>>>> (Permission denied) >>>>>> initializing DST: PKCS#11 initialization failed >>>>>> exiting (due to fatal error) >>>>>> >>>>>> >>>>>> For kadmin the error is due to not being able to >>>>>> connect to sldap >>>>>> >>>>>> I noticed that softhsm2-util --show-slots >>>>>> reported "ERROR: Could not initialize the >>>>>> library." But that seemed to be because wasn't >>>>>> part of the update. After that I could show the >>>>>> default slot and then I manually called following >>>>>> (as root): >>>>>> >>>>>> "/usr/bin/softhsm2-util --init-token --slot 0 >>>>>> --label ipaDNSSEC --pin XXXXXXXX --so-pin XXXXXXXX" >>>>>> >>>>>> But the problems won't go away. Any clues? >>>>>> >>>>>> -- john >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Hello, >>>>> >>>>> 1) >>>>> can you share your /var/log/ipaupgrade.log ? >>>>> >>>>> >>>>> Unfortunatly I removed the original ipaupgrade.log >>>>> file when I did I retry to install freeipa-server. The >>>>> current ipaupgrade.log has two errors: >>>>> First) >>>>> >>>>> 2014-10-26T12:45:15Z DEBUG Live 1, updated 1 >>>>> 2014-10-26T12:45:15Z DEBUG Unhandled LDAPError: >>>>> OPERATIONS_ERROR: {'desc': 'Operations error'} >>>>> 2014-10-26T12:45:15Z ERROR Update failed: Operations >>>>> error: >>>>> 2014-10-26T12:45:15Z INFO Updating existing entry: >>>>> cn=MemberOf Plugin,cn=plugins,cn=config >>>>> 2014-10-26T12:45:15Z DEBUG >>>>> --------------------------------------------- >>>> Are there some information about entry which is updated >>>> above? >>>> >>>>> >>>>> Second) It complains about not being able to start >>>>> named-pkcs11 service. >>>>> >>>>> >>>>> >>>>> 2) >>>>> your issue with softhsm can be caused by missing >>>>> enviroment variable >>>>> IPA internally uses >>>>> >>>>> SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf >>>>> please try >>>>> SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf >>>>> softhsm2-util --show-slots, and let me know if it >>>>> works >>>>> >>>>> same with named-pkcs11, >>>>> >>>>> >>>>> The filestamps for softhsm_pin & tokens match the time >>>>> I did the original update >>>>> >>>>> # ll /var/lib/ipa/dnssec/ >>>>> -rwxrwx---. 1 ods named 30 Oct 26 10:35 softhsm_pin >>>>> drwxrws---. 2 ods named 4.0K Oct 26 10:35 tokens >>>>> >>>>> # ll /var/lib/ipa/dnssec/tokens/ >>>>> total 0 >>>>> >>>>> # SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf >>>>> softhsm2-util --show-slots >>>>> Available slots: >>>>> Slot 0 >>>>> Slot info: >>>>> Description: SoftHSM slot 0 >>>>> Manufacturer ID: SoftHSM project >>>>> Hardware version: 2.0 >>>>> Firmware version: 2.0 >>>>> Token present: yes >>>>> Token info: >>>>> Manufacturer ID: SoftHSM project >>>>> Model: SoftHSM v2 >>>>> Hardware version: 2.0 >>>>> Firmware version: 2.0 >>>>> Serial number: >>>>> Initialized: no >>>>> User PIN init.: no >>>>> Label: >>>> Slot was not initialized by IPA >>>>> >>>>> 3) >>>>> can you share journalctl -u named-pkcs11 output? >>>>> >>>>> >>>>> 10:35:48 systemd[1]: named-pkcs11.service: control >>>>> process exited, code=exited status=1 >>>>> 10:35:48 systemd[1]: Failed to start Berkeley Internet >>>>> Name Domain (DNS) with native PKCS#11. >>>>> 10:35:48 systemd[1]: Unit named-pkcs11.service entered >>>>> failed state. >>>>> 10:35:48 systemd[1]: Stopped Berkeley Internet Name >>>>> Domain (DNS) with native PKCS#11. >>>>> -- Reboot -- >>>>> 10:58:05 named-pkcs11[1496]: initializing DST: no >>>>> PKCS#11 provider >>>>> 10:58:05 named-pkcs11[1496]: exiting (due to fatal error) >>>>> 10:58:05 systemd[1]: named-pkcs11.service: control >>>>> process exited, code=exited status=1 >>>>> 10:58:05 systemd[1]: Failed to start Berkeley Internet >>>>> Name Domain (DNS) with native PKCS#11. >>>>> 10:58:05 systemd[1]: Unit named-pkcs11.service entered >>>>> failed state. >>>>> 10:58:05 systemd[1]: Stopped Berkeley Internet Name >>>>> Domain (DNS) with native PKCS#11. >>>>> >>>>> ... After some fiddeling a restart says this: >>>>> >>>>> 19:26:21 named-pkcs11[8807]: sha1.c:92: fatal error: >>>>> 19:26:21 named-pkcs11[8807]: >>>>> RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, >>>>> isc_boolean_true, isc_boolean_false, isc_bo >>>>> 19:26:21 named-pkcs11[8807]: exiting (due to fatal >>>>> error in library) >>>>> 19:26:21 systemd[1]: named-pkcs11.service: control >>>>> process exited, code=exited status=1 >>>>> 19:26:21 systemd[1]: Failed to start Berkeley Internet >>>>> Name Domain (DNS) with native PKCS#11. >>>>> 19:26:21 systemd[1]: Unit named-pkcs11.service entered >>>>> failed state. >>>>> >>>>> 4) >>>>> I'm not aware of that we need, krb5-libs/openssl, >>>>> I was getting this error if tokens directory >>>>> doesnt exists, but IPA uses own configuration (see >>>>> 2) not default. >>>>> >>>>> >>>>> ok >>>> >>>> I took a deeper look, and I found there some packaging >>>> errors with softhsm. >>>> You was right with missing dependency. >>>> >>>> Please install softhsm-devel package, remove >>>> /var/lib/ipa/dnssec/tokens directory, then reinstall >>>> DNS, ipa-dns-install (requires running directory server) >>>> >>>> Or if you have snapshot, install softhsm-devel before >>>> upgrading ipa >>>> >>>> HTH >>>> Martin^2 >>>> >>>> -- >>>> Martin Basti >>>> >>>> >>> >>> >>> -- >>> Martin Basti >>> >>> >> >> >> -- >> Martin Basti >> >> > > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Oct 28 10:21:48 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 28 Oct 2014 11:21:48 +0100 Subject: [Freeipa-users] F20 Problem upgrading to 4.1 In-Reply-To: <544F262E.1050400@gmail.com> References: <544E2A5C.50209@redhat.com> <544E897F.4050801@redhat.com> <544E9864.9060804@redhat.com> <544E9FC3.6020809@redhat.com> <544EA28B.5050402@redhat.com> <544F262E.1050400@gmail.com> Message-ID: <544F6E3C.3050000@redhat.com> On 28/10/14 06:14, Michael Lasevich wrote: > Running into same thing, but running ipa-dnsinstall does not complete: > > ============================= > Configuring DNS (named) > [1/8]: generating rndc key file > WARNING: Your system is running out of entropy, you may experience > long delays > [2/8]: setting up our own record > [3/8]: adding NS record to the zones > [4/8]: setting up CA record > [5/8]: setting up kerberos principal > [6/8]: setting up named.conf > [7/8]: configuring named to start on boot > [8/8]: changing resolv.conf to point to ourselves > Done configuring DNS (named). > Configuring DNS key synchronization service (ipa-dnskeysyncd) > [1/6]: checking status > [2/6]: setting up kerberos principal > [3/6]: setting up SoftHSM > [4/6]: adding DNSSEC containers > [5/6]: creating replica keys > [error] DuplicateEntry: This entry already exists > Unexpected error - see /var/log/ipaserver-install.log for details: > DuplicateEntry: This entry already exists > ============================= > > Looking into the /var/log/ipaserver-install.log gets: > ============================= > 2014-10-28T05:01:24Z DEBUG Storing replica public key to LDAP, > ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com > 2014-10-28T05:01:24Z DEBUG flushing > ldap://infra-dc-01.my.domain.com:389 from SchemaCache > 2014-10-28T05:01:24Z DEBUG retrieving schema for SchemaCache > url=ldap://infra-dc-01.my.domain.com:389 > conn= > 2014-10-28T05:01:24Z DEBUG Traceback (most recent call last): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > 382, in start_creation run_step(full_msg, method) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > 372, in run_step method() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", > line 340, in __setup_replica_keys ldap.add_entry(entry) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line > 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) > File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ > self.gen.throw(type, value, traceback) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line > 1169, in error_handler raise errors.DuplicateEntry() > DuplicateEntry: This entry already exists > > 2014-10-28T05:01:24Z DEBUG [error] DuplicateEntry: This entry > already exists > 2014-10-28T05:01:24Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 646, in run_script > return_value = main_function() > File "/sbin/ipa-dns-install", line 218, in main > dnskeysyncd.create_instance(api.env.host, api.env.realm) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", > line 128, in create_instance self.start_creation() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > 382, in start_creation run_step(full_msg, method) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > 372, in run_step method() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", > line 340, in __setup_replica_keys ldap.add_entry(entry) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line > 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) > File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ > self.gen.throw(type, value, traceback) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line > 1169, in error_handler raise errors.DuplicateEntry() > 2014-10-28T05:01:24Z DEBUG The ipa-dns-install command failed, > exception: DuplicateEntry: This entry already exists Hello Michael, can you send me which entries do you have in cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com, it looks like directory server doesn't generate uniqueID for keys. Do you have upgraded IPA or fresh installed? Martin^2 -- Martin Basti From ctr2sprt at gmail.com Tue Oct 28 11:43:46 2014 From: ctr2sprt at gmail.com (Eric McCoy) Date: Tue, 28 Oct 2014 07:43:46 -0400 Subject: [Freeipa-users] Recovering from messed-up certs In-Reply-To: <54495F8F.1030504@redhat.com> References: <544932A1.8030909@redhat.com> <54495F8F.1030504@redhat.com> Message-ID: Sorry it took me so long to try this and get back to you. I tried modifying that Python script and running it, and this is what I get: Initializing API Setting up NSS databases Untracking existing Apache Server-Cert Issuing new cert Tracking Server-Cert ipa: ERROR: certmonger failed starting to track certificate: Nickname "Server-Cert" doesn't exist in NSS database "/etc/httpd/alias" I checked and it's right. The output of certutil -L -d /etc/httpd/alias is... confusing, actually. So I got the above output. Then I realized my Kerberos ticket was expired and I ought to get a new one. When I did so, I retried the command and got the exact same output. However, this time certutil's output is different: # certutil -L -d /etc/httpd/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI puppetmaster/hostname u,u,u REALMNAME IPA CA CT,C,C ipaCert u,u,u Signing-Cert u,u,u puppetmaster/hostname u,u,u The puppetmaster/hostname entry is in there twice. The first attempt at newcert.py is still in my scroll buffer: the puppetmaster entry definitely only appears once until after this most recent run. I'm starting to wonder if my attempts to create that puppetmaster cert somehow screwed up the database. On Thu, Oct 23, 2014 at 4:05 PM, Rob Crittenden wrote: > Eric McCoy wrote: > > Some nicknames changed to protect the innocent. The > > puppetmaster/hostname cert is nominally unrelated, though its creation > > was contemporaneous with the disappearance of server-cert so I can't > > entirely rule it out. > > > > Certificate Nickname Trust > > Attributes > > > > SSL,S/MIME,JAR/XPI > > > > puppetmaster/hostname u,u,u > > REALMNAME IPA CA CT,C,C > > ipaCert u,u,u > > Signing-Cert u,u,u > > Ok, this is good. If we have ipaCert we can get a cert directly from the > CA like we do during installation. > > The attached python script should fix things up for you. > > Save it, modify it and replace subjectbase with what matches your > environment. You can get the base from an existing cert with: > > # certutil -L -d /etc/dirsrv/slapd-REALM -n Server-Cert |grep Subject > > Unless you changed it during installation it should be O= > > Then just run the script: > > # python newcert.py > Initializing API > Setting up NSS databases > Untracking existing Apache Server-Cert > Issuing new cert > Tracking Server-Cert > > # service httpd start > > The only thing this script doesn't do is put this updated certificate in > the service record's LDAP entry. > > rob > > > > > > > On Thu, Oct 23, 2014 at 12:53 PM, Rob Crittenden > > wrote: > > > > Eric McCoy wrote: > > > Hi all, > > > > > > I somehow destroyed my primary IPA server's Server-Cert in > > > /etc/httpd/alias. I don't understand how or why it happened, all > > I know > > > is that I went to restart Apache and it was gone. Apache won't > start, > > > of course, because the cert is missing. I can't issue a new cert > > on the > > > primary because Apache is down. I tried using the secondary, but > it > > > fails saying that it can't connect to the web server on the primary > > > (it's the same error message I get when I try to issue a cert from > the > > > primary). I can't figure out how to tell ipa-getcert et al. to > > talk to > > > the secondary and not the primary. I'm not using DNS for service > > > discovery, so I'm not sure how the various tools figure out where > > things > > > are. > > > > > > This is all on CentOS 6.5 with IPA 3.0.0-37. > > > > > > > > > > What certs do you have in the database? > > > > # certutil -L -d /etc/httpd/alias > > > > rob > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From orkhan-azeri at mail.ru Tue Oct 28 11:43:13 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Tue, 28 Oct 2014 15:43:13 +0400 Subject: [Freeipa-users] Radius schema addition to default user objectclasses in FreeIPA 4.1 In-Reply-To: <544AAA9C.3060007@redhat.com> References: <1414153659.837745408@f356.i.mail.ru> <544AAA9C.3060007@redhat.com> Message-ID: <544F8151.7030707@mail.ru> OK, thanks for info. First I used that command with " | grep radius" at the end prior to adding my radiusschema.ldif. It returned no data. Then I added my radiusschema.ldif using the command: # ldapmodify -ZZ -x -D "cn=Directory Manager" -W -H ldap://localhost -f /usr/share/radiusschema.ldif Then I issued the command you suggested again with " | grep radius|less" at the end. This time it retrned a lot of entries (apparently those that were in the radiusschema.ldif file). But when I tried to switch to GUI and add "radiusprofile" objectclass, I got the same message: "IPA Error 4001: NotFound objectclass radiusprofile not found" I know that radius schema taken from http://open.rhx.it/phamm/schema/radius.schema works, it was checked by me with OpenLDAP 2.4 and FreeRadius 2.2. What am I doing wrong? Removing "MUST cn" from the schema gives no difference. 25-Oct-14 00:38, Rich Megginson ?????: > Are you trying to list the schema over LDAP? Where did you get the > above instructions? They are wrong. Use > > ldapsearch -o ldif-wrap=no -Y GSSAPI -s base -b "cn=schema" > attributeTypes objectClasses From rob.verduijn at gmail.com Tue Oct 28 15:10:45 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Tue, 28 Oct 2014 16:10:45 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: <544D5BB2.5090003@redhat.com> Message-ID: Hello all, I've been digging into my problem of being unable to update from 3.3.5 to 4.1 First I add the repo from copr Then I used to update it by issueing 'yum update' which resulted in an update in which my local dns zone entries no longer resolved. So i tried the instructions mentioned on the site : yum update freeipa-server And this failed with a conflict in bind-32:9.9.4-18.fc20.1.pkcs11.x86_64 and bind-utils-32:9.9.4-15.P2.fc20.x86_64 I noticed the new bind comes from the copr repo and the old bind utils from fedora. So I first run 'yum update bind-utils -y' Then I ran yum update freeipa-server and see it fail with errors about softhsm I remembered reading about package errors with softhsm and installed the softhsm-devel package first. so revert back the freeipa kvm snapshot to 3.3.5 and try again yum update bind-utils -y ; yum install softhsm-devel -y ; yum update freeipa-server -y However when restarting named-pkcs11 I can see in the system log that it has 0 zones loaded Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: managed-keys-zone: loaded serial 0 Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone 0.in-addr.arpa/IN: loaded serial 0 Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone localhost/IN: loaded serial 0 Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone localhost.localdomain/IN: loaded serial 0 Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0 Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: all zones loaded Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: running Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: 0 zones from LDAP instance 'ipa' loaded (0 zones defined, 0 inactive, 0 failed to load) It claims 0 zones loaded but I can see my forward and reverse zones in ipa what could cause it not to load the zones that I defined in ipa ? Rob 2014-10-27 23:05 GMT+01:00 Rob Verduijn : > sorry for the xml formatting didn't realize it would mess up some mail > clients > > The last bit of the message again > > ipa-upgradeconfig gives the following : > [Verifying that root certificate is published] > Failed to backup CS.cfg: no magic attribute 'dogtag' > [Migrate CRL publish directory] > CRL tree already moved > [Verifying that CA proxy configuration is correct] > [Verifying that KDC configuration is using ipa-kdb backend] > [Fixing trust flags in /etc/httpd/alias] > Trust flags already processed > [Fix DS schema file syntax] > Syntax already fixed > [Removing RA cert from DS NSS database] > RA cert already removed > [Removing self-signed CA] > [Checking for deprecated KDC configuration files] > [Checking for deprecated backups of Samba configuration files] > [Setting up Firefox extension] > [Add missing CA DNS records] > IPA CA DNS records already processed > [Removing deprecated DNS configuration options] > [Ensuring minimal number of connections] > [Enabling serial autoincrement in DNS] > [Updating GSSAPI configuration in DNS] > [Updating pid-file configuration in DNS] > [Masking named] > Changes to named.conf have been made, restart named > [Verifying that CA service certificate profile is updated] > [Update certmonger certificate renewal configuration to version 2] > [Enable PKIX certificate path discovery and validation] > PKIX already enabled > The ipa-upgradeconfig command was successful > > Any ideas ? > I'm rather stuck now. > Rob > > 2014-10-27 22:59 GMT+01:00 Rob Verduijn : > >> Hello, >> >> I'm rather at a loss here. >> Everything seems to be running >> ipactl status >> Directory Service: RUNNING >> krb5kdc Service: RUNNING >> kadmin Service: RUNNING >> named Service: RUNNING >> ipa_memcached Service: RUNNING >> httpd Service: RUNNING >> pki-tomcatd Service: RUNNING >> ipa-otpd Service: RUNNING >> ipa-dnskeysyncd Service: RUNNING >> ipa: INFO: The ipactl command was successful >> >> but the upgrade log is flooded with this error : >> 2014-10-27T21:52:10Z DEBUG Waiting for CA to start... >> 2014-10-27T21:52:11Z DEBUG request ' >> https://freeipa.x.x:443/ca/admin/ca/getStatus' >> 2014-10-27T21:52:11Z DEBUG request body '' >> 2014-10-27T21:52:11Z DEBUG The CA status is: check interrupted >> 2014-10-27T21:52:11Z DEBUG Waiting for CA to start... >> 2014-10-27T21:52:12Z DEBUG request ' >> https://freeipa.x.x:443/ca/admin/ca/getStatus' >> 2014-10-27T21:52:12Z DEBUG request body '' >> >> I've tried the url and it works fine. >> https://freeipa.x.x/ca/admin/ca/getStatus >> it gives the following xml: >> >> 1CArunning >> 10.2.0-3.fc20 >> >> After I run ipa-upgradeconfig it complains about a missing magic dog tag >> attribute >> ipa-upgradeconfig [Verifying that root certificate is published]Failed >> to backup CS.cfg: no magic attribute 'dogtag'[Migrate CRL publish >> directory]CRL tree already moved[Verifying that CA proxy configuration >> is correct][Verifying that KDC configuration is using ipa-kdb backend][Fixing >> trust flags in /etc/httpd/alias]Trust flags already processed[Fix DS >> schema file syntax]Syntax already fixed[Removing RA cert from DS NSS >> database]RA cert already removed[Removing self-signed CA][Checking for >> deprecated KDC configuration files][Checking for deprecated backups of >> Samba configuration files][Setting up Firefox extension][Add missing CA >> DNS records]IPA CA DNS records already processed[Removing deprecated DNS >> configuration options][Ensuring minimal number of connections][Enabling >> serial autoincrement in DNS][Updating GSSAPI configuration in DNS][Updating >> pid-file configuration in DNS][Masking named]Changes to named.conf have >> been made, restart named[Verifying that CA service certificate profile >> is updated][Update certmonger certificate renewal configuration to >> version 2][Enable PKIX certificate path discovery and validation]PKIX >> already enabledThe ipa-upgradeconfig command was successful >> >> But my local dns zone does no longer resolve :( >> >> reverting back to the 3.3 snapshot again :( >> >> Please help >> Rob >> >> 2014-10-26 21:38 GMT+01:00 Rob Crittenden : >> >>> Rob Verduijn wrote: >>> > hmmmm.... >>> > >>> > after some more digging (monitoring the upgrade more closely.) >>> > I saw that the upgrade kept waiting for the ca to start, which it did >>> > not do. >>> > and after 5 minutes the upgrade gave up with the following errors in >>> the >>> > ipaupgrade log : >>> > >>> > at 85% it says : >>> > 2014-10-26T15:04:35Z DEBUG retrieving schema for SchemaCache >>> > url=ldapi://%2fvar%2frun%2fslapd-XXXX-XXXX.socket >>> > conn= >>> > 2014-10-26T15:04:35Z DEBUG Starting external process >>> > 2014-10-26T15:04:35Z DEBUG args='/usr/bin/certutil' '-d' >>> > '/etc/httpd/alias' '-L' >>> > 2014-10-26T15:04:35Z DEBUG Process finished, return code=0 >>> > 2014-10-26T15:04:35Z DEBUG stdout= >>> > Certificate Nickname Trust >>> > Attributes >>> > >>> > SSL,S/MIME,JAR/XPI >>> > >>> > Signing-Cert u,u,u >>> > XXXX.XXXX IPA CA CT,C,C >>> > ipaCert u,u,u >>> > Server-Cert u,u,u >>> > >>> > 2014-10-26T15:04:35Z DEBUG stderr= >>> > 2014-10-26T15:04:35Z DEBUG Starting external process >>> > 2014-10-26T15:04:35Z DEBUG args='/usr/bin/certutil' '-d' >>> > '/etc/httpd/alias' '-L' '-n' 'TJAKO.THUIS IPA CA' '-a' >>> > 2014-10-26T15:04:35Z DEBUG Process finished, return code=0 >>> > 2014-10-26T15:04:35Z DEBUG stdout=-----BEGIN CERTIFICATE----- >>> > < certificate-removed > >>> > -----END CERTIFICATE----- >>> > 2014-10-26T15:04:35Z DEBUG stderr= >>> > 2014-10-26T15:04:36Z ERROR Upgrade failed with cannot connect to >>> > 'ldapi://%2fvar%2frun%2fslapd-XXXX-XXXX.socket':\ >>> >>> This has nothing to do with the CA, the LDAP server didn't come up. I'd >>> start with those logs or look earlier in ipaupgrade.log >>> >>> The CA requires 389-ds to be running so if it isn't up, then it will >>> fail to start too. >>> >>> rob >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Oct 28 15:27:58 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 28 Oct 2014 11:27:58 -0400 Subject: [Freeipa-users] Recovering from messed-up certs In-Reply-To: References: <544932A1.8030909@redhat.com> <54495F8F.1030504@redhat.com> Message-ID: <544FB5FE.8040800@redhat.com> Eric McCoy wrote: > Sorry it took me so long to try this and get back to you. I tried > modifying that Python script and running it, and this is what I get: > > Initializing API > Setting up NSS databases > Untracking existing Apache Server-Cert > Issuing new cert > Tracking Server-Cert > ipa: ERROR: certmonger failed starting to track certificate: Nickname > "Server-Cert" doesn't exist in NSS database "/etc/httpd/alias" > > I checked and it's right. The output of certutil -L -d /etc/httpd/alias > is... confusing, actually. So I got the above output. Then I realized > my Kerberos ticket was expired and I ought to get a new one. When I did > so, I retried the command and got the exact same output. However, this > time certutil's output is different: > > # certutil -L -d /etc/httpd/alias > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > puppetmaster/hostname u,u,u > REALMNAME IPA CA CT,C,C > ipaCert u,u,u > Signing-Cert u,u,u > puppetmaster/hostname u,u,u > > The puppetmaster/hostname entry is in there twice. The first attempt at > newcert.py is still in my scroll buffer: the puppetmaster entry > definitely only appears once until after this most recent run. I'm > starting to wonder if my attempts to create that puppetmaster cert > somehow screwed up the database. NSS apparently doesn't like two certificates with the same subject. Nickname doesn't seem to matter in this case. I found this bug which is mail specific but seems to cover the same problem: https://bugzilla.mozilla.org/show_bug.cgi?id=278689 I think the only solution is to remove the puppetmaster cert. Does it need to reside in the Apache database? rob > > > On Thu, Oct 23, 2014 at 4:05 PM, Rob Crittenden > wrote: > > Eric McCoy wrote: > > Some nicknames changed to protect the innocent. The > > puppetmaster/hostname cert is nominally unrelated, though its creation > > was contemporaneous with the disappearance of server-cert so I can't > > entirely rule it out. > > > > Certificate Nickname Trust > > Attributes > > > > SSL,S/MIME,JAR/XPI > > > > puppetmaster/hostname u,u,u > > REALMNAME IPA CA CT,C,C > > ipaCert u,u,u > > Signing-Cert u,u,u > > Ok, this is good. If we have ipaCert we can get a cert directly from the > CA like we do during installation. > > The attached python script should fix things up for you. > > Save it, modify it and replace subjectbase with what matches your > environment. You can get the base from an existing cert with: > > # certutil -L -d /etc/dirsrv/slapd-REALM -n Server-Cert |grep Subject > > Unless you changed it during installation it should be O= > > Then just run the script: > > # python newcert.py > Initializing API > Setting up NSS databases > Untracking existing Apache Server-Cert > Issuing new cert > Tracking Server-Cert > > # service httpd start > > The only thing this script doesn't do is put this updated certificate in > the service record's LDAP entry. > > rob > > > > > > > On Thu, Oct 23, 2014 at 12:53 PM, Rob Crittenden > > >> wrote: > > > > Eric McCoy wrote: > > > Hi all, > > > > > > I somehow destroyed my primary IPA server's Server-Cert in > > > /etc/httpd/alias. I don't understand how or why it > happened, all > > I know > > > is that I went to restart Apache and it was gone. Apache > won't start, > > > of course, because the cert is missing. I can't issue a new > cert > > on the > > > primary because Apache is down. I tried using the > secondary, but it > > > fails saying that it can't connect to the web server on the > primary > > > (it's the same error message I get when I try to issue a > cert from the > > > primary). I can't figure out how to tell ipa-getcert et al. to > > talk to > > > the secondary and not the primary. I'm not using DNS for > service > > > discovery, so I'm not sure how the various tools figure out > where > > things > > > are. > > > > > > This is all on CentOS 6.5 with IPA 3.0.0-37. > > > > > > > > > > What certs do you have in the database? > > > > # certutil -L -d /etc/httpd/alias > > > > rob > > > > > > From rcritten at redhat.com Tue Oct 28 15:51:14 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 28 Oct 2014 11:51:14 -0400 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: <544D5BB2.5090003@redhat.com> Message-ID: <544FBB72.8000304@redhat.com> Rob Verduijn wrote: > Ok after some more digging : > > I found some warnings (see below) > > Is any of these the cause for the error ? > > Rob > > > > 2014-10-27T13:56:28Z INFO Updating existing entry: > cn=ipaConfig,cn=etc,dc=XXXXX,dc=XXXXX > > 2014-10-27T13:56:28Z WARNING remove: 'AllowLMhash' not in ipaConfigString > AFAICT these are all normal. It basically means the LDAP data is already in the state we want. > and then we get to the traceback: > 2014-10-27T13:56:34Z ERROR Upgrade failed with cannot connect to > 'ldapi://%2fvar%2frun%2fslapd-XXXXX-XXXXX.socket': > 2014-10-27T13:56:34Z DEBUG Traceback (most recent call last): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", > line 152, in __upgrade > self.modified = (ld.update(self.files, ordered=True) or > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line > 874, in update > updates = api.Backend.updateclient.update(POST_UPDATE, > self.dm_password, self.ldapi, self.live_run) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py", > line 131, in update > ld.update_from_dict(updates) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line > 889, in update_from_dict > self._run_updates(updates) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line > 799, in _run_updates > self._update_record(update) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line > 661, in _update_record > e = self._get_entry(new_entry.dn) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line > 544, in _get_entry > return self.conn.get_entries(dn, scope, searchfilter, sattrs) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line > 1421, in get_entries > base_dn=base_dn, scope=scope, filter=filter, attrs_list=attrs_list) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line > 1527, in find_entries > break > File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ > self.gen.throw(type, value, traceback) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line > 1206, in error_handler > error=info) > NetworkError: cannot connect to > 'ldapi://%2fvar%2frun%2fslapd-XXXXX-XXXXX.socket': I'd poke around more in the ipaupgrade.log to see if you can find a failed dirsrv restart. Looking at the 389-ds logs might be handy too, and I'd check (dmesg, for example) to see if it core dumped. rob > > > > 2014-10-26 21:38 GMT+01:00 Rob Crittenden >: > > Rob Verduijn wrote: > > hmmmm.... > > > > after some more digging (monitoring the upgrade more closely.) > > I saw that the upgrade kept waiting for the ca to start, which it did > > not do. > > and after 5 minutes the upgrade gave up with the following errors > in the > > ipaupgrade log : > > > > at 85% it says : > > 2014-10-26T15:04:35Z DEBUG retrieving schema for SchemaCache > > url=ldapi://%2fvar%2frun%2fslapd-XXXX-XXXX.socket > > conn= > > 2014-10-26T15:04:35Z DEBUG Starting external process > > 2014-10-26T15:04:35Z DEBUG args='/usr/bin/certutil' '-d' > > '/etc/httpd/alias' '-L' > > 2014-10-26T15:04:35Z DEBUG Process finished, return code=0 > > 2014-10-26T15:04:35Z DEBUG stdout= > > Certificate Nickname Trust > > Attributes > > > > SSL,S/MIME,JAR/XPI > > > > Signing-Cert u,u,u > > XXXX.XXXX IPA CA CT,C,C > > ipaCert u,u,u > > Server-Cert u,u,u > > > > 2014-10-26T15:04:35Z DEBUG stderr= > > 2014-10-26T15:04:35Z DEBUG Starting external process > > 2014-10-26T15:04:35Z DEBUG args='/usr/bin/certutil' '-d' > > '/etc/httpd/alias' '-L' '-n' 'TJAKO.THUIS IPA CA' '-a' > > 2014-10-26T15:04:35Z DEBUG Process finished, return code=0 > > 2014-10-26T15:04:35Z DEBUG stdout=-----BEGIN CERTIFICATE----- > > < certificate-removed > > > -----END CERTIFICATE----- > > 2014-10-26T15:04:35Z DEBUG stderr= > > 2014-10-26T15:04:36Z ERROR Upgrade failed with cannot connect to > > 'ldapi://%2fvar%2frun%2fslapd-XXXX-XXXX.socket':\ > > This has nothing to do with the CA, the LDAP server didn't come up. I'd > start with those logs or look earlier in ipaupgrade.log > > The CA requires 389-ds to be running so if it isn't up, then it will > fail to start too. > > rob > > From CWhite at skytouchtechnology.com Tue Oct 28 16:11:05 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Tue, 28 Oct 2014 16:11:05 +0000 Subject: [Freeipa-users] getent passwd / group In-Reply-To: <544EE402.4010108@redhat.com> References: <4c0def2865e24b7182481c4a33837a75@BLUPR08MB488.namprd08.prod.outlook.com> <544EE402.4010108@redhat.com> Message-ID: From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Monday, October 27, 2014 5:32 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] getent passwd / group On 10/27/2014 07:38 PM, Craig White wrote: RHEL 6.5 - new install ipa-server-3.0.0-42.el6.x86_64 389-ds-base-1.2.11.15-47.el6.x86_64 On the master, I get nothing [root at ipa001 log]# getent passwd admin [root at ipa001 log]# But it works on the replica as expected [root at ipa002nadev01 ~]# getent passwd admin admin:*:1140000000:1110000000:Administrator:/home/admin:/bin/bash I am used to using PADL / NSSWITCH with OpenLDAP and I am rather surprised that on both, 'getent passwd' and 'getent group' return only entries from local files but then again, I've never used sssd before. Partial from /etc/sssd/sssd.conf [domain/stt.local] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = stt.local id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ipa001nadev01.stt.local chpass_provider = ipa ipa_server = ipa001nadev01.stt.local ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = stt.local debug_level = 6 Shouldn't I be seeing both local files and IPA defined users with 'getent passwd' and IPA defined users with 'getent group' commands? What could cause 'getent passwd admin' not to work on the master server now when I know I tested it when I first set it up and it worked? I have done little more than import users and groups from OpenLDAP and configure HBAC, sudo stuff in the IPA web UI. Please check on master: 1. Installation logs. Client on the server is installed last and may be there is something that went wrong at this stage but the rest of the server is OK. 2. DNS. Can you resolve the host properly? 3. Firewall. Can you kinit admin or or do an ldap search? ---- It's weird because it is mostly functioning perfectly. /var/log/ipaclient-install.log doesn't show any errors. Gives every indication that things went as planned. The /var/log/ipaserver-install.log is a rather large file and a cursory inspection doesn't reveal anything that is interesting. The only thing that was not normal about the install was the first install was un-installed because I used DNS forwarders and the boss said no forwarders. So I installed a second time but nothing seemed unusual about either server or client install. DNS - resolves / working perfectly for the authoritative and non-authoritative zones - forward and reverse. I thought the 'ipa-client-install -enable-dns-updates' worked extremely well after modifying it to ensure that both forward and reverse zone entries were created. kinit admin at STT.LOCAL works - rejects wrong password entries and accepts correct password entries. Ldapsearch works fine Firewall... (we are talking about localhost but) ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:22 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:53 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:53 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:88 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:88 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:123 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:389 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:464 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:464 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:636 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:7389 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:7389 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:9443 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:9444 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:9445 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited -------------- next part -------------- An HTML attachment was scrubbed... URL: From sipazzo at yahoo.com Tue Oct 28 16:41:16 2014 From: sipazzo at yahoo.com (sipazzo) Date: Tue, 28 Oct 2014 09:41:16 -0700 Subject: [Freeipa-users] Solaris 10 client configuration using profile In-Reply-To: <544ECA2A.2000700@redhat.com> Message-ID: <1414514476.87630.YahooMailBasic@web122501.mail.ne1.yahoo.com> Yes I did generate the database on the IPA server and copied it over. I thought that was what the instructions indicated to do: Create NSS DB (Don't enter password. Just hit return) ipaserver $ certutil -N -d /var/ldap Convert the IPA certificate to PEM format: ipaserver $ openssl x509 -in /etc/ipa/ca.crt -outform pem -out /etc/ipa/ca.pem Add CA certificate to the NSS DB ipaserver $ certutil -A -n "ca-cert" -i /etc/ipa/ca.pem -a -t CT -d /var/ldap Copy the *.db files from /var/ldap/ on the ipa server to /var/ldap on the Solaris host. solarishost $ scp ipaserver:/var/ldap/*.db /var/ldap/ solarishost $ chmod 444 /var/ldap/*.db There is not an /etc/ipa directory on the client so I assumed it was generated on the Linux ipa server side. However, I created the /etc/ipa directory on the solaris client and copied my ca.crt and ca.pem from the ipa server to the directory on the solaris client. I then ran certutil -N -d /var/ldap on the solaris client as well as certutil -A -n "ca-cert" -i /etc/ipa/ca.pem -a -t CT -d /var/ldap/ According to timestamp the .db files changed but their names remained the same: -r--r--r-- 1 root root 65536 Oct 27 15:48 cert8.db -r--r--r-- 1 root root 16384 Oct 27 15:48 key3.db -r--r--r-- 1 root root 16384 Oct 27 14:47 secmod.db But still get same errors in log files and using ldapsearch. -------------------------------------------- On Mon, 10/27/14, Rob Crittenden wrote: Subject: Re: [Freeipa-users] Solaris 10 client configuration using profile To: "sipazzo" , "Freeipa-users at redhat.com" Date: Monday, October 27, 2014, 3:41 PM sipazzo wrote: > /var/ldap exists on both client and server and I was able to sudo to root and generate the *.db files without getting the legacy database error. I scp'd them to the hosts and restarted ldap_cachemgr but errors continued. I then re-initialized the client and am still getting same errors in log files and same error when running an ldapsearch using ssl > > > SSL initialization failed: error -8174 (security library: bad database.) > > The .db files all have 444 permissions This database is only needed on the client. I gather you created the NSS database on your Linux server and copied it over? I wonder if the database version isn't supported. What are the names of the db files in /var/ldap? Do you have a certutil on the Solaris machine to do this work? The Oracle docs suggest that cert8/key3 should be fine though. rob > > > -------------------------------------------- > On Mon, 10/27/14, Rob Crittenden wrote: > >? Subject: Re: [Freeipa-users] Solaris 10 client configuration using profile >? To: "sipazzo" , "Alexander Bokovoy" >? Cc: "Freeipa-users at redhat.com" >? Date: Monday, October 27, 2014, 2:07 PM >? >? sipazzo wrote: >? > okay so this is working with the secure >? profile, thank you all, but I am getting a ton of errors in >? my logs on the solaris clients like this: >? > >? > Oct 27 13:08:51 >? dc2.ipadomain.com ldap_cachemgr[15004]: [ID 545954 >? daemon.error] libsldap: makeConnection: failed to open >? connection to idm1.ipadomain.com >? > Oct 27 >? 13:08:51 dc2.ipadomain.com ldap_cachemgr[15004]: [ID 545954 >? daemon.error] libsldap: makeConnection: failed to open >? connection to idm2.ipadomain.com >? > Oct 27 >? 13:08:51 dc2.ipadomain.com ldap_cachemgr[15004]: [ID 687686 >? daemon.warning] libsldap: Falling back to anonymous, non-SSL >? mode for __ns_ldap_getRootDSE. openConnection: simple bind >? failed - Can't contact LDAP server >? > >? Oct 27 13:08:51 dc2.ipadomain.com last message repeated 1 >? time >? > Oct 27 13:08:51 dc2.ipadomain.com >? ldap_cachemgr[15004]: [ID 293258 daemon.warning] libsldap: >? Status: 81? Mesg: openConnection: simple bind failed - >? Can't contact LDAP server >? > Oct 27 >? 13:08:51 dc2.ipadomain.com ldap_cachemgr[15004]: [ID 545954 >? daemon.error] libsldap: makeConnection: failed to open >? connection to idm1-corp.ipadomain.com >? > >? Oct 27 13:08:51 dc2-io.ipadomain.com ldap_cachemgr[15004]: >? [ID 687686 daemon.warning] libsldap: Falling back to >? anonymous, non-SSL mode for __ns_ldap_getRootDSE. >? openConnection: simple bind failed - Can't contact LDAP >? server >? > >? > >? > I think this might be related to trying to >? use tls:simple for authentication so I went back over the >? steps for the cert set up and I am unable to generate or >? import the ca.pem cert into the nssdb database >? > >? > certutil -N -d >? /var/ldap >? > certutil: function failed: >? SEC_ERROR_LEGACY_DATABASE: The certificate/key database is >? in an old, unsupported format. >? > >? > >? > certutil -A -n >? "ca-cert" -i /etc/ipa/ca.pem -a -t CT -d >? /var/ldap >? > certutil: function failed: >? SEC_ERROR_LEGACY_DATABASE: The certificate/key database is >? in an old, unsupported format. >? >? Does the directory /var/ldap exist and can the >? current user write to it? >? >? rob >? > From mbasti at redhat.com Tue Oct 28 16:58:50 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 28 Oct 2014 17:58:50 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: <544D5BB2.5090003@redhat.com> Message-ID: <544FCB4A.8030900@redhat.com> On 28/10/14 16:10, Rob Verduijn wrote: > Hello all, > > I've been digging into my problem of being unable to update from 3.3.5 > to 4.1 > > First I add the repo from copr > > Then I used to update it by issueing 'yum update' which resulted in > an update in which my local dns zone entries no longer resolved. > > So i tried the instructions mentioned on the site : > yum update freeipa-server > And this failed with a conflict in > > bind-32:9.9.4-18.fc20.1.pkcs11.x86_64 and > bind-utils-32:9.9.4-15.P2.fc20.x86_64 > > I noticed the new bind comes from the copr repo and the old bind utils > from fedora. > > So I first run 'yum update bind-utils -y' > Then I ran yum update freeipa-server > and see it fail with errors about softhsm > > I remembered reading about package errors with softhsm and installed > the softhsm-devel package first. > > so revert back the freeipa kvm snapshot to 3.3.5 and try again > yum update bind-utils -y ; yum install softhsm-devel -y ; yum update > freeipa-server -y > > However when restarting named-pkcs11 I can see in the system log that > it has 0 zones loaded > > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: managed-keys-zone: > loaded serial 0 > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone > 0.in-addr.arpa/IN: loaded serial 0 > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone localhost/IN: > loaded serial 0 > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone > 1.0.0.127.in-addr.arpa/IN: loaded serial 0 > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone > localhost.localdomain/IN: loaded serial 0 > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: > loaded serial 0 > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: all zones loaded > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: running > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: 0 zones from LDAP > instance 'ipa' loaded (0 zones defined, 0 inactive, 0 failed to load) > > It claims 0 zones loaded but I can see my forward and reverse zones in ipa > > what could cause it not to load the zones that I defined in ipa ? > Rob > > > 2014-10-27 23:05 GMT+01:00 Rob Verduijn >: > > sorry for the xml formatting didn't realize it would mess up some > mail clients > > The last bit of the message again > > ipa-upgradeconfig gives the following : > [Verifying that root certificate is published] > Failed to backup CS.cfg: no magic attribute 'dogtag' > [Migrate CRL publish directory] > CRL tree already moved > [Verifying that CA proxy configuration is correct] > [Verifying that KDC configuration is using ipa-kdb backend] > [Fixing trust flags in /etc/httpd/alias] > Trust flags already processed > [Fix DS schema file syntax] > Syntax already fixed > [Removing RA cert from DS NSS database] > RA cert already removed > [Removing self-signed CA] > [Checking for deprecated KDC configuration files] > [Checking for deprecated backups of Samba configuration files] > [Setting up Firefox extension] > [Add missing CA DNS records] > IPA CA DNS records already processed > [Removing deprecated DNS configuration options] > [Ensuring minimal number of connections] > [Enabling serial autoincrement in DNS] > [Updating GSSAPI configuration in DNS] > [Updating pid-file configuration in DNS] > [Masking named] > Changes to named.conf have been made, restart named > [Verifying that CA service certificate profile is updated] > [Update certmonger certificate renewal configuration to version 2] > [Enable PKIX certificate path discovery and validation] > PKIX already enabled > The ipa-upgradeconfig command was successful > > Any ideas ? > I'm rather stuck now. > Rob > > 2014-10-27 22:59 GMT+01:00 Rob Verduijn >: > > Hello, > > I'm rather at a loss here. > Everything seems to be running > ipactl status > Directory Service: RUNNING > krb5kdc Service: RUNNING > kadmin Service: RUNNING > named Service: RUNNING > ipa_memcached Service: RUNNING > httpd Service: RUNNING > pki-tomcatd Service: RUNNING > ipa-otpd Service: RUNNING > ipa-dnskeysyncd Service: RUNNING > ipa: INFO: The ipactl command was successful > > but the upgrade log is flooded with this error : > 2014-10-27T21:52:10Z DEBUG Waiting for CA to start... > 2014-10-27T21:52:11Z DEBUG request > 'https://freeipa.x.x:443/ca/admin/ca/getStatus' > 2014-10-27T21:52:11Z DEBUG request body '' > 2014-10-27T21:52:11Z DEBUG The CA status is: check interrupted > 2014-10-27T21:52:11Z DEBUG Waiting for CA to start... > 2014-10-27T21:52:12Z DEBUG request > 'https://freeipa.x.x:443/ca/admin/ca/getStatus' > 2014-10-27T21:52:12Z DEBUG request body '' > > I've tried the url and it works fine. > https://freeipa.x.x/ca/admin/ca/getStatus > it gives the following xml: > > standalone="no"?>1CArunning10.2.0-3.fc20 > > After I run ipa-upgradeconfig it complains about a missing > magic dog tag attribute > ipa-upgradeconfig [Verifying that root certificate is > published] Failed to backup CS.cfg: no magic attribute > 'dogtag' [Migrate CRL publish directory] CRL tree already > moved [Verifying that CA proxy configuration is correct] > [Verifying that KDC configuration is using ipa-kdb backend] > [Fixing trust flags in /etc/httpd/alias] Trust flags already > processed [Fix DS schema file syntax] Syntax already fixed > [Removing RA cert from DS NSS database] RA cert already > removed [Removing self-signed CA] [Checking for deprecated > KDC configuration files] [Checking for deprecated backups of > Samba configuration files] [Setting up Firefox extension] > [Add missing CA DNS records] IPA CA DNS records already > processed [Removing deprecated DNS configuration options] > [Ensuring minimal number of connections] [Enabling serial > autoincrement in DNS] [Updating GSSAPI configuration in > DNS] [Updating pid-file configuration in DNS] [Masking > named] Changes to named.conf have been made, restart named > [Verifying that CA service certificate profile is updated] > [Update certmonger certificate renewal configuration to > version 2] [Enable PKIX certificate path discovery and > validation] PKIX already enabled The ipa-upgradeconfig > command was successful > > But my local dns zone does no longer resolve :( > > reverting back to the 3.3 snapshot again :( > > Please help > Rob > > > 2014-10-26 21:38 GMT+01:00 Rob Crittenden >: > > Rob Verduijn wrote: > > hmmmm.... > > > > after some more digging (monitoring the upgrade more > closely.) > > I saw that the upgrade kept waiting for the ca to start, > which it did > > not do. > > and after 5 minutes the upgrade gave up with the > following errors in the > > ipaupgrade log : > > > > at 85% it says : > > 2014-10-26T15:04:35Z DEBUG retrieving schema for SchemaCache > > url=ldapi://%2fvar%2frun%2fslapd-XXXX-XXXX.socket > > conn= 0x2b18cb0> > > 2014-10-26T15:04:35Z DEBUG Starting external process > > 2014-10-26T15:04:35Z DEBUG args='/usr/bin/certutil' '-d' > > '/etc/httpd/alias' '-L' > > 2014-10-26T15:04:35Z DEBUG Process finished, return code=0 > > 2014-10-26T15:04:35Z DEBUG stdout= > > Certificate Nickname Trust > > Attributes > > > > SSL,S/MIME,JAR/XPI > > > > Signing-Cert u,u,u > > XXXX.XXXX IPA CA CT,C,C > > ipaCert u,u,u > > Server-Cert u,u,u > > > > 2014-10-26T15:04:35Z DEBUG stderr= > > 2014-10-26T15:04:35Z DEBUG Starting external process > > 2014-10-26T15:04:35Z DEBUG args='/usr/bin/certutil' '-d' > > '/etc/httpd/alias' '-L' '-n' 'TJAKO.THUIS IPA CA' '-a' > > 2014-10-26T15:04:35Z DEBUG Process finished, return code=0 > > 2014-10-26T15:04:35Z DEBUG stdout=-----BEGIN > CERTIFICATE----- > > < certificate-removed > > > -----END CERTIFICATE----- > > 2014-10-26T15:04:35Z DEBUG stderr= > > 2014-10-26T15:04:36Z ERROR Upgrade failed with cannot > connect to > > 'ldapi://%2fvar%2frun%2fslapd-XXXX-XXXX.socket':\ > > This has nothing to do with the CA, the LDAP server didn't > come up. I'd > start with those logs or look earlier in ipaupgrade.log > > The CA requires 389-ds to be running so if it isn't up, > then it will > fail to start too. > > rob > > > > > > Hello, Please which version of bind-dyndb-ldap do you have installed? -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Oct 28 17:04:18 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 28 Oct 2014 13:04:18 -0400 Subject: [Freeipa-users] getent passwd / group In-Reply-To: References: <4c0def2865e24b7182481c4a33837a75@BLUPR08MB488.namprd08.prod.outlook.com> <544EE402.4010108@redhat.com> Message-ID: <544FCC92.8040104@redhat.com> On 10/28/2014 12:11 PM, Craig White wrote: > > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* Monday, October 27, 2014 5:32 PM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] getent passwd / group > > On 10/27/2014 07:38 PM, Craig White wrote: > > RHEL 6.5 -- new install > > ipa-server-3.0.0-42.el6.x86_64 > > 389-ds-base-1.2.11.15-47.el6.x86_64 > > On the master, I get nothing > > [root at ipa001 log]# getent passwd admin > > [root at ipa001 log]# > > But it works on the replica as expected > > [root at ipa002nadev01 ~]# getent passwd admin > > admin:*:1140000000:1110000000:Administrator:/home/admin:/bin/bash > > I am used to using PADL / NSSWITCH with OpenLDAP and I am rather > surprised that on both, 'getent passwd' and 'getent group' return > only entries from local files but then again, I've never used sssd > before. > > Partial from /etc/sssd/sssd.conf > > [domain/stt.local] > > cache_credentials = True > > krb5_store_password_if_offline = True > > ipa_domain = stt.local > > id_provider = ipa > > auth_provider = ipa > > access_provider = ipa > > ipa_hostname = ipa001nadev01.stt.local > > chpass_provider = ipa > > ipa_server = ipa001nadev01.stt.local > > ldap_tls_cacert = /etc/ipa/ca.crt > > [sssd] > > services = nss, sudo, pam, ssh > > config_file_version = 2 > > domains = stt.local > > debug_level = 6 > > Shouldn't I be seeing both local files and IPA defined users with > 'getent passwd' and IPA defined users with 'getent group' commands? > > What could cause 'getent passwd admin' not to work on the master > server now when I know I tested it when I first set it up and it > worked? I have done little more than import users and groups from > OpenLDAP and configure HBAC, sudo stuff in the IPA web UI. > > > Please check on master: > 1. Installation logs. Client on the server is installed last and may > be there is something that went wrong at this stage but the rest of > the server is OK. > 2. DNS. Can you resolve the host properly? > 3. Firewall. Can you kinit admin or or do an ldap search? > ---- > > It's weird because it is mostly functioning perfectly. > > /var/log/ipaclient-install.log doesn't show any errors. Gives every > indication that things went as planned. The > /var/log/ipaserver-install.log is a rather large file and a cursory > inspection doesn't reveal anything that is interesting. The only thing > that was not normal about the install was the first install was > un-installed because I used DNS forwarders and the boss said no > forwarders. So I installed a second time but nothing seemed unusual > about either server or client install. > > DNS -- resolves / working perfectly for the authoritative and > non-authoritative zones -- forward and reverse. I thought the > 'ipa-client-install --enable-dns-updates' worked extremely well after > modifying it to ensure that both forward and reverse zone entries were > created. > > kinit admin at STT.LOCAL works -- rejects wrong > password entries and accepts correct password entries. > > Ldapsearch works fine > > Firewall... (we are talking about localhost but) > > ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate > RELATED,ESTABLISHED > > ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 > > ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 > > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:22 > > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80 > > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:53 > > ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:53 > > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:88 > > ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:88 > > ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:123 > > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:389 > > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443 > > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:464 > > ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:464 > > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:636 > > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:7389 > > ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:7389 > > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:9443 > > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:9444 > > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:9445 > > REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with > icmp-host-prohibited > Then we need SSSD logs with the debug_level in the right sections as Jakub mentioned in his mail. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Tue Oct 28 17:42:30 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Tue, 28 Oct 2014 18:42:30 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <544FCB4A.8030900@redhat.com> References: <544D5BB2.5090003@redhat.com> <544FCB4A.8030900@redhat.com> Message-ID: before the update its 4.5-1.fc20.x86_64.rpm from fedora 20 updates repo after the update its 6.0-5.fc20.x86_64.rpm from copr repo Regards Rob 2014-10-28 17:58 GMT+01:00 Martin Basti : > On 28/10/14 16:10, Rob Verduijn wrote: > > Hello all, > > I've been digging into my problem of being unable to update from 3.3.5 > to 4.1 > > First I add the repo from copr > > Then I used to update it by issueing 'yum update' which resulted in an > update in which my local dns zone entries no longer resolved. > > So i tried the instructions mentioned on the site : > yum update freeipa-server > And this failed with a conflict in > > bind-32:9.9.4-18.fc20.1.pkcs11.x86_64 and > bind-utils-32:9.9.4-15.P2.fc20.x86_64 > > I noticed the new bind comes from the copr repo and the old bind utils > from fedora. > > So I first run 'yum update bind-utils -y' > Then I ran yum update freeipa-server > and see it fail with errors about softhsm > > I remembered reading about package errors with softhsm and installed the > softhsm-devel package first. > > so revert back the freeipa kvm snapshot to 3.3.5 and try again > yum update bind-utils -y ; yum install softhsm-devel -y ; yum update > freeipa-server -y > > However when restarting named-pkcs11 I can see in the system log that it > has 0 zones loaded > > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: managed-keys-zone: > loaded serial 0 > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone 0.in-addr.arpa/IN: > loaded serial 0 > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone localhost/IN: loaded > serial 0 > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone > 1.0.0.127.in-addr.arpa/IN: loaded serial 0 > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone > localhost.localdomain/IN: loaded serial 0 > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: > loaded serial 0 > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: all zones loaded > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: running > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: 0 zones from LDAP instance > 'ipa' loaded (0 zones defined, 0 inactive, 0 failed to load) > > It claims 0 zones loaded but I can see my forward and reverse zones in > ipa > > what could cause it not to load the zones that I defined in ipa ? > Rob > > > 2014-10-27 23:05 GMT+01:00 Rob Verduijn : > >> sorry for the xml formatting didn't realize it would mess up some mail >> clients >> >> The last bit of the message again >> >> ipa-upgradeconfig gives the following : >> [Verifying that root certificate is published] >> Failed to backup CS.cfg: no magic attribute 'dogtag' >> [Migrate CRL publish directory] >> CRL tree already moved >> [Verifying that CA proxy configuration is correct] >> [Verifying that KDC configuration is using ipa-kdb backend] >> [Fixing trust flags in /etc/httpd/alias] >> Trust flags already processed >> [Fix DS schema file syntax] >> Syntax already fixed >> [Removing RA cert from DS NSS database] >> RA cert already removed >> [Removing self-signed CA] >> [Checking for deprecated KDC configuration files] >> [Checking for deprecated backups of Samba configuration files] >> [Setting up Firefox extension] >> [Add missing CA DNS records] >> IPA CA DNS records already processed >> [Removing deprecated DNS configuration options] >> [Ensuring minimal number of connections] >> [Enabling serial autoincrement in DNS] >> [Updating GSSAPI configuration in DNS] >> [Updating pid-file configuration in DNS] >> [Masking named] >> Changes to named.conf have been made, restart named >> [Verifying that CA service certificate profile is updated] >> [Update certmonger certificate renewal configuration to version 2] >> [Enable PKIX certificate path discovery and validation] >> PKIX already enabled >> The ipa-upgradeconfig command was successful >> >> Any ideas ? >> I'm rather stuck now. >> Rob >> >> 2014-10-27 22:59 GMT+01:00 Rob Verduijn : >> >>> Hello, >>> >>> I'm rather at a loss here. >>> Everything seems to be running >>> ipactl status >>> Directory Service: RUNNING >>> krb5kdc Service: RUNNING >>> kadmin Service: RUNNING >>> named Service: RUNNING >>> ipa_memcached Service: RUNNING >>> httpd Service: RUNNING >>> pki-tomcatd Service: RUNNING >>> ipa-otpd Service: RUNNING >>> ipa-dnskeysyncd Service: RUNNING >>> ipa: INFO: The ipactl command was successful >>> >>> but the upgrade log is flooded with this error : >>> 2014-10-27T21:52:10Z DEBUG Waiting for CA to start... >>> 2014-10-27T21:52:11Z DEBUG request ' >>> https://freeipa.x.x:443/ca/admin/ca/getStatus' >>> 2014-10-27T21:52:11Z DEBUG request body '' >>> 2014-10-27T21:52:11Z DEBUG The CA status is: check interrupted >>> 2014-10-27T21:52:11Z DEBUG Waiting for CA to start... >>> 2014-10-27T21:52:12Z DEBUG request ' >>> https://freeipa.x.x:443/ca/admin/ca/getStatus' >>> 2014-10-27T21:52:12Z DEBUG request body '' >>> >>> I've tried the url and it works fine. >>> https://freeipa.x.x/ca/admin/ca/getStatus >>> it gives the following xml: >>> >>> >>> 1CArunning >>> 10.2.0-3.fc20 >>> >>> After I run ipa-upgradeconfig it complains about a missing magic dog tag >>> attribute >>> ipa-upgradeconfig [Verifying that root certificate is published] Failed >>> to backup CS.cfg: no magic attribute 'dogtag' [Migrate CRL publish >>> directory] CRL tree already moved [Verifying that CA proxy >>> configuration is correct] [Verifying that KDC configuration is using >>> ipa-kdb backend] [Fixing trust flags in /etc/httpd/alias] Trust flags >>> already processed [Fix DS schema file syntax] Syntax already fixed [Removing >>> RA cert from DS NSS database] RA cert already removed [Removing >>> self-signed CA] [Checking for deprecated KDC configuration files] [Checking >>> for deprecated backups of Samba configuration files] [Setting up >>> Firefox extension] [Add missing CA DNS records] IPA CA DNS records >>> already processed [Removing deprecated DNS configuration options] [Ensuring >>> minimal number of connections] [Enabling serial autoincrement in DNS] [Updating >>> GSSAPI configuration in DNS] [Updating pid-file configuration in DNS] [Masking >>> named] Changes to named.conf have been made, restart named [Verifying >>> that CA service certificate profile is updated] [Update certmonger >>> certificate renewal configuration to version 2] [Enable PKIX >>> certificate path discovery and validation] PKIX already enabled The >>> ipa-upgradeconfig command was successful >>> >>> But my local dns zone does no longer resolve :( >>> >>> reverting back to the 3.3 snapshot again :( >>> >>> Please help >>> Rob >>> >>> 2014-10-26 21:38 GMT+01:00 Rob Crittenden : >>> >>>> Rob Verduijn wrote: >>>> > hmmmm.... >>>> > >>>> > after some more digging (monitoring the upgrade more closely.) >>>> > I saw that the upgrade kept waiting for the ca to start, which it did >>>> > not do. >>>> > and after 5 minutes the upgrade gave up with the following errors in >>>> the >>>> > ipaupgrade log : >>>> > >>>> > at 85% it says : >>>> > 2014-10-26T15:04:35Z DEBUG retrieving schema for SchemaCache >>>> > url=ldapi://%2fvar%2frun%2fslapd-XXXX-XXXX.socket >>>> > conn= >>>> > 2014-10-26T15:04:35Z DEBUG Starting external process >>>> > 2014-10-26T15:04:35Z DEBUG args='/usr/bin/certutil' '-d' >>>> > '/etc/httpd/alias' '-L' >>>> > 2014-10-26T15:04:35Z DEBUG Process finished, return code=0 >>>> > 2014-10-26T15:04:35Z DEBUG stdout= >>>> > Certificate Nickname Trust >>>> > Attributes >>>> > >>>> > SSL,S/MIME,JAR/XPI >>>> > >>>> > Signing-Cert u,u,u >>>> > XXXX.XXXX IPA CA CT,C,C >>>> > ipaCert u,u,u >>>> > Server-Cert u,u,u >>>> > >>>> > 2014-10-26T15:04:35Z DEBUG stderr= >>>> > 2014-10-26T15:04:35Z DEBUG Starting external process >>>> > 2014-10-26T15:04:35Z DEBUG args='/usr/bin/certutil' '-d' >>>> > '/etc/httpd/alias' '-L' '-n' 'TJAKO.THUIS IPA CA' '-a' >>>> > 2014-10-26T15:04:35Z DEBUG Process finished, return code=0 >>>> > 2014-10-26T15:04:35Z DEBUG stdout=-----BEGIN CERTIFICATE----- >>>> > < certificate-removed > >>>> > -----END CERTIFICATE----- >>>> > 2014-10-26T15:04:35Z DEBUG stderr= >>>> > 2014-10-26T15:04:36Z ERROR Upgrade failed with cannot connect to >>>> > 'ldapi://%2fvar%2frun%2fslapd-XXXX-XXXX.socket':\ >>>> >>>> This has nothing to do with the CA, the LDAP server didn't come up. I'd >>>> start with those logs or look earlier in ipaupgrade.log >>>> >>>> The CA requires 389-ds to be running so if it isn't up, then it will >>>> fail to start too. >>>> >>>> rob >>>> >>>> >>> >> > > > Hello, > Please which version of bind-dyndb-ldap do you have installed? > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ctr2sprt at gmail.com Tue Oct 28 18:30:57 2014 From: ctr2sprt at gmail.com (Eric McCoy) Date: Tue, 28 Oct 2014 14:30:57 -0400 Subject: [Freeipa-users] Recovering from messed-up certs In-Reply-To: <544FB5FE.8040800@redhat.com> References: <544932A1.8030909@redhat.com> <54495F8F.1030504@redhat.com> <544FB5FE.8040800@redhat.com> Message-ID: You're right. When I deleted the puppetmaster certs and reran newcert.py, it worked like a champ. Presumably this is how the main cert disappeared in the first place: NSS silently overwrote it. This does mean that I won't be able to run puppet on this server, but... Well, even when I was doing it, I knew it was a bad idea. I just figured I could maybe get away with it. Should I submit a bug someplace? From the age of that BZ I don't have a lot of faith that the actual NSS bug is going to get fixed anytime soon. But if it can be worked around in IPA (or is it certmonger?) -- perhaps simply by showing an error message -- I think that would be sufficient. Clearly this is something of a corner case. On Tue, Oct 28, 2014 at 11:27 AM, Rob Crittenden wrote: > Eric McCoy wrote: > > Sorry it took me so long to try this and get back to you. I tried > > modifying that Python script and running it, and this is what I get: > > > > Initializing API > > Setting up NSS databases > > Untracking existing Apache Server-Cert > > Issuing new cert > > Tracking Server-Cert > > ipa: ERROR: certmonger failed starting to track certificate: Nickname > > "Server-Cert" doesn't exist in NSS database "/etc/httpd/alias" > > > > I checked and it's right. The output of certutil -L -d /etc/httpd/alias > > is... confusing, actually. So I got the above output. Then I realized > > my Kerberos ticket was expired and I ought to get a new one. When I did > > so, I retried the command and got the exact same output. However, this > > time certutil's output is different: > > > > # certutil -L -d /etc/httpd/alias > > > > Certificate Nickname Trust > > Attributes > > > > SSL,S/MIME,JAR/XPI > > > > puppetmaster/hostname u,u,u > > REALMNAME IPA CA CT,C,C > > ipaCert u,u,u > > Signing-Cert u,u,u > > puppetmaster/hostname u,u,u > > > > The puppetmaster/hostname entry is in there twice. The first attempt at > > newcert.py is still in my scroll buffer: the puppetmaster entry > > definitely only appears once until after this most recent run. I'm > > starting to wonder if my attempts to create that puppetmaster cert > > somehow screwed up the database. > > NSS apparently doesn't like two certificates with the same subject. > Nickname doesn't seem to matter in this case. I found this bug which is > mail specific but seems to cover the same problem: > https://bugzilla.mozilla.org/show_bug.cgi?id=278689 > > I think the only solution is to remove the puppetmaster cert. Does it > need to reside in the Apache database? > > rob > > > > > > > On Thu, Oct 23, 2014 at 4:05 PM, Rob Crittenden > > wrote: > > > > Eric McCoy wrote: > > > Some nicknames changed to protect the innocent. The > > > puppetmaster/hostname cert is nominally unrelated, though its > creation > > > was contemporaneous with the disappearance of server-cert so I > can't > > > entirely rule it out. > > > > > > Certificate Nickname Trust > > > Attributes > > > > > > SSL,S/MIME,JAR/XPI > > > > > > puppetmaster/hostname u,u,u > > > REALMNAME IPA CA CT,C,C > > > ipaCert u,u,u > > > Signing-Cert u,u,u > > > > Ok, this is good. If we have ipaCert we can get a cert directly from > the > > CA like we do during installation. > > > > The attached python script should fix things up for you. > > > > Save it, modify it and replace subjectbase with what matches your > > environment. You can get the base from an existing cert with: > > > > # certutil -L -d /etc/dirsrv/slapd-REALM -n Server-Cert |grep Subject > > > > Unless you changed it during installation it should be O= > > > > Then just run the script: > > > > # python newcert.py > > Initializing API > > Setting up NSS databases > > Untracking existing Apache Server-Cert > > Issuing new cert > > Tracking Server-Cert > > > > # service httpd start > > > > The only thing this script doesn't do is put this updated > certificate in > > the service record's LDAP entry. > > > > rob > > > > > > > > > > > On Thu, Oct 23, 2014 at 12:53 PM, Rob Crittenden < > rcritten at redhat.com > > > >> wrote: > > > > > > Eric McCoy wrote: > > > > Hi all, > > > > > > > > I somehow destroyed my primary IPA server's Server-Cert in > > > > /etc/httpd/alias. I don't understand how or why it > > happened, all > > > I know > > > > is that I went to restart Apache and it was gone. Apache > > won't start, > > > > of course, because the cert is missing. I can't issue a new > > cert > > > on the > > > > primary because Apache is down. I tried using the > > secondary, but it > > > > fails saying that it can't connect to the web server on the > > primary > > > > (it's the same error message I get when I try to issue a > > cert from the > > > > primary). I can't figure out how to tell ipa-getcert et al. > to > > > talk to > > > > the secondary and not the primary. I'm not using DNS for > > service > > > > discovery, so I'm not sure how the various tools figure out > > where > > > things > > > > are. > > > > > > > > This is all on CentOS 6.5 with IPA 3.0.0-37. > > > > > > > > > > > > > > What certs do you have in the database? > > > > > > # certutil -L -d /etc/httpd/alias > > > > > > rob > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jasonsmith at attask.com Tue Oct 28 18:36:58 2014 From: jasonsmith at attask.com (Jason Smith) Date: Tue, 28 Oct 2014 12:36:58 -0600 Subject: [Freeipa-users] FreeIPA 3.3.3-28 Integration with Samba 4.1.1-37 Problems Message-ID: A little history. We migrated from an OpenLDAP system to FreeIPA. The IPA version is listed above. I have samba installed and integrated directly on the FreeIPA box. The problem we're having are users who were migrated can no longer can see the samba shares. We are connecting to these shares through Mac OSX. When accessing the share with smbclient -L mydomain at domain.com I get the response *session setup failed: NT_STATUS_CONNECTION_DISCONNECTED. *This is the response I get when connected to the FreeIPA/Samba box. Users were able to access these shares, then overnight, they weren't. No changes were made to the samba config or the FreeIPA. *Any new user created through FreeIPA can see and browse any share they have access to.* If there's any other information needed, please let me know. Thank you!!! Below are a couple configs I have set: *Samba global settings* [global] workgroup = ATTASK netbios name = IPA01 realm = ATTASK.CORP passdb backend = ipasam:ldapi://%2fvar%2frun%2fslapd-ATTASK-CORP.socket kerberos method = dedicated keytab dedicated keytab file = FILE:/etc/samba/samba.keytab log file = /var/log/samba/log.%m max log size = 100000 disable spoolss = Yes domain logons = Yes domain master = Yes ldap group suffix = cn=groups,cn=accounts ldap machine suffix = cn=computers,cn=accounts ldap suffix = dc=attask,dc=corp ldap ssl = no ldap user suffix = cn=users,cn=accounts registry shares = Yes create krb5 conf = No rpc_daemon:lsasd = fork rpc_daemon:epmd = fork rpc_server:tcpip = yes rpc_server:netlogon = external rpc_server:samr = external rpc_server:lsasd = external rpc_server:lsass = external rpc_server:lsarpc = external rpc_server:epmapper = external ldapsam:trusted = yes idmap config * : backend = tdb *User Not Working:* dn: uid=test,cn=users,cn=accounts,dc=attask,dc=corp uid: test sn: test cn: test mail: test at test.com nsaccountlock: False has_password: True has_keytab: True dialupAccess: yes displayName: test test emailPassword: YTdiMDE4Y2Q1N2QwOWJjZTg0OWMxZThjNTgyNTFmNTlw== gidNumber: 107001365 givenName: test homeDirectory: /home/test ipaNTSecurityIdentifier: S-1-5-21-1103557689-1565082434-1264062975-2355 ipaUniqueID: 607de82c-562b-11e4-b263-5254003b1df7 krbExtraData: AAJwtE9Ucm9vdC9hZG1pbkdvvBBVFR09SUAA= krbLastFailedAuth: 20141028151647Z krbLastPwdChange: 20141028152120Z krbLastSuccessfulAuth: 20141028152012Z krbLoginFailedCount: 0 krbPasswordExpiration: 20150122152120Z krbPrincipalName: test at ATTASK.CORP krbTicketFlags: 128 loginShell: /sbin/nologin memberof: cn=ipausers,cn=groups,cn=accounts,dc=attask,dc=corp memberof: cn=attask,cn=groups,cn=accounts,dc=attask,dc=corp memberof: cn=clientservices,cn=groups,cn=accounts,dc=attask,dc=corp objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: organizationalperson objectClass: top objectClass: customPersonAttributes objectClass: ipasshuser objectClass: inetorgperson objectClass: sambaSamAccount objectClass: person objectClass: inetuser objectClass: krbprincipalaux objectClass: radiusProfile objectClass: posixaccount objectClass: ipaSshGroupOfPubKeys objectClass: ipantuserattrs radiusTunnelMediumType: IEEE-802 radiusTunnelPrivateGroupId: 1424 radiusTunnelType: VLAN sambaPwdLastSet: 0 sambaSID: S-1-5-21-1103557689-1565082434-1264062975-5622 uidNumber: 107001355 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlasevich at gmail.com Tue Oct 28 19:54:46 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Tue, 28 Oct 2014 12:54:46 -0700 Subject: [Freeipa-users] F20 Problem upgrading to 4.1 In-Reply-To: <544F6E3C.3050000@redhat.com> References: <544E2A5C.50209@redhat.com> <544E897F.4050801@redhat.com> <544E9864.9060804@redhat.com> <544E9FC3.6020809@redhat.com> <544EA28B.5050402@redhat.com> <544F262E.1050400@gmail.com> <544F6E3C.3050000@redhat.com> Message-ID: <544FF486.1090905@gmail.com> I have a pair of servers that were both installed on clean Fedora20 4.0.1 from pviktori copr repo and then upgraded from mkosek to 4.1 During update, secondary was done first and worked but primary run into trouble as described Looking under cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com I get one entry with dn: ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com Not sure what of that you need there, but for ipk11Label it has: dnssec-replica:infra-dc-02.my.domain.com. (which is the replica that IS working) Thanks, -M On 10/28/14, 3:21 AM, Martin Basti wrote: > On 28/10/14 06:14, Michael Lasevich wrote: >> Running into same thing, but running ipa-dnsinstall does not complete: >> >> ============================= >> Configuring DNS (named) >> [1/8]: generating rndc key file >> WARNING: Your system is running out of entropy, you may experience >> long delays >> [2/8]: setting up our own record >> [3/8]: adding NS record to the zones >> [4/8]: setting up CA record >> [5/8]: setting up kerberos principal >> [6/8]: setting up named.conf >> [7/8]: configuring named to start on boot >> [8/8]: changing resolv.conf to point to ourselves >> Done configuring DNS (named). >> Configuring DNS key synchronization service (ipa-dnskeysyncd) >> [1/6]: checking status >> [2/6]: setting up kerberos principal >> [3/6]: setting up SoftHSM >> [4/6]: adding DNSSEC containers >> [5/6]: creating replica keys >> [error] DuplicateEntry: This entry already exists >> Unexpected error - see /var/log/ipaserver-install.log for details: >> DuplicateEntry: This entry already exists >> ============================= >> >> Looking into the /var/log/ipaserver-install.log gets: >> ============================= >> 2014-10-28T05:01:24Z DEBUG Storing replica public key to LDAP, >> ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com >> 2014-10-28T05:01:24Z DEBUG flushing >> ldap://infra-dc-01.my.domain.com:389 from SchemaCache >> 2014-10-28T05:01:24Z DEBUG retrieving schema for SchemaCache >> url=ldap://infra-dc-01.my.domain.com:389 >> conn= >> 2014-10-28T05:01:24Z DEBUG Traceback (most recent call last): >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >> 382, in start_creation run_step(full_msg, method) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >> 372, in run_step method() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", >> line 340, in __setup_replica_keys ldap.add_entry(entry) >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >> 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) >> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ >> self.gen.throw(type, value, traceback) >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >> 1169, in error_handler raise errors.DuplicateEntry() >> DuplicateEntry: This entry already exists >> >> 2014-10-28T05:01:24Z DEBUG [error] DuplicateEntry: This entry >> already exists >> 2014-10-28T05:01:24Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> line 646, in run_script >> return_value = main_function() >> File "/sbin/ipa-dns-install", line 218, in main >> dnskeysyncd.create_instance(api.env.host, api.env.realm) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", >> line 128, in create_instance self.start_creation() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >> 382, in start_creation run_step(full_msg, method) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >> 372, in run_step method() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", >> line 340, in __setup_replica_keys ldap.add_entry(entry) >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >> 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) >> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ >> self.gen.throw(type, value, traceback) >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >> 1169, in error_handler raise errors.DuplicateEntry() >> 2014-10-28T05:01:24Z DEBUG The ipa-dns-install command failed, >> exception: DuplicateEntry: This entry already exists > Hello Michael, > > can you send me which entries do you have in > cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com, it looks like directory > server doesn't generate uniqueID for keys. > > Do you have upgraded IPA or fresh installed? > > Martin^2 > From CWhite at skytouchtechnology.com Tue Oct 28 20:28:08 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Tue, 28 Oct 2014 20:28:08 +0000 Subject: [Freeipa-users] getent passwd / group [SOLVED] Message-ID: From: Dmitri Pal [mailto:dpal at redhat.com] Sent: Tuesday, October 28, 2014 10:04 AM To: Craig White; freeipa-users at redhat.com Subject: Re: [Freeipa-users] getent passwd / group On 10/28/2014 12:11 PM, Craig White wrote: From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Monday, October 27, 2014 5:32 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] getent passwd / group On 10/27/2014 07:38 PM, Craig White wrote: RHEL 6.5 - new install ipa-server-3.0.0-42.el6.x86_64 389-ds-base-1.2.11.15-47.el6.x86_64 On the master, I get nothing [root at ipa001 log]# getent passwd admin [root at ipa001 log]# But it works on the replica as expected [root at ipa002nadev01 ~]# getent passwd admin admin:*:1140000000:1110000000:Administrator:/home/admin:/bin/bash I am used to using PADL / NSSWITCH with OpenLDAP and I am rather surprised that on both, 'getent passwd' and 'getent group' return only entries from local files but then again, I've never used sssd before. Partial from /etc/sssd/sssd.conf [domain/stt.local] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = stt.local id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ipa001nadev01.stt.local chpass_provider = ipa ipa_server = ipa001nadev01.stt.local ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = stt.local debug_level = 6 Shouldn't I be seeing both local files and IPA defined users with 'getent passwd' and IPA defined users with 'getent group' commands? What could cause 'getent passwd admin' not to work on the master server now when I know I tested it when I first set it up and it worked? I have done little more than import users and groups from OpenLDAP and configure HBAC, sudo stuff in the IPA web UI. Please check on master: 1. Installation logs. Client on the server is installed last and may be there is something that went wrong at this stage but the rest of the server is OK. 2. DNS. Can you resolve the host properly? 3. Firewall. Can you kinit admin or or do an ldap search? ---- It's weird because it is mostly functioning perfectly. /var/log/ipaclient-install.log doesn't show any errors. Gives every indication that things went as planned. The /var/log/ipaserver-install.log is a rather large file and a cursory inspection doesn't reveal anything that is interesting. The only thing that was not normal about the install was the first install was un-installed because I used DNS forwarders and the boss said no forwarders. So I installed a second time but nothing seemed unusual about either server or client install. DNS - resolves / working perfectly for the authoritative and non-authoritative zones - forward and reverse. I thought the 'ipa-client-install -enable-dns-updates' worked extremely well after modifying it to ensure that both forward and reverse zone entries were created. kinit admin at STT.LOCAL works - rejects wrong password entries and accepts correct password entries. Ldapsearch works fine Firewall... (we are talking about localhost but) ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:22 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:53 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:53 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:88 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:88 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:123 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:389 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:464 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:464 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:636 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:7389 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:7389 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:9443 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:9444 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:9445 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Then we need SSSD logs with the debug_level in the right sections as Jakub mentioned in his mail. ---- Sorry - I had a long meeting and should have noted that after restarting SSSD, it all started working again as expected. Clearly something I have to watch for and indeed, I moved the debug to the domain section for future. Thanks Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From CWhite at skytouchtechnology.com Tue Oct 28 20:41:49 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Tue, 28 Oct 2014 20:41:49 +0000 Subject: [Freeipa-users] getent passwd / group [SOLVED] In-Reply-To: References: Message-ID: From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Craig White Sent: Tuesday, October 28, 2014 1:28 PM To: dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] getent passwd / group [SOLVED] From: Dmitri Pal [mailto:dpal at redhat.com] Sent: Tuesday, October 28, 2014 10:04 AM To: Craig White; freeipa-users at redhat.com Subject: Re: [Freeipa-users] getent passwd / group On 10/28/2014 12:11 PM, Craig White wrote: From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Monday, October 27, 2014 5:32 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] getent passwd / group On 10/27/2014 07:38 PM, Craig White wrote: RHEL 6.5 - new install ipa-server-3.0.0-42.el6.x86_64 389-ds-base-1.2.11.15-47.el6.x86_64 On the master, I get nothing [root at ipa001 log]# getent passwd admin [root at ipa001 log]# But it works on the replica as expected [root at ipa002nadev01 ~]# getent passwd admin admin:*:1140000000:1110000000:Administrator:/home/admin:/bin/bash I am used to using PADL / NSSWITCH with OpenLDAP and I am rather surprised that on both, 'getent passwd' and 'getent group' return only entries from local files but then again, I've never used sssd before. REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Then we need SSSD logs with the debug_level in the right sections as Jakub mentioned in his mail. ---- Sorry - I had a long meeting and should have noted that after restarting SSSD, it all started working again as expected. Clearly something I have to watch for and indeed, I moved the debug to the domain section for future. I should add - came to the realization that restarting sssd and went to long meeting, then came back and couldn't log into ipa console or Kerberos and had to restart IPA service to restart Kerberos. IPA is logging nothing. This is not the first time I have had to go through this cycle - it seems that somehow, the IPA server is sensitive to the SSSD daemon and if the SSSD goes haywire, when I restart SSSD, IPA is not functioning and must be restarted too. Thanks Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From CWhite at skytouchtechnology.com Tue Oct 28 20:45:24 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Tue, 28 Oct 2014 20:45:24 +0000 Subject: [Freeipa-users] 389 DS & admin consoles Message-ID: <8e50b6ebd9804b8ab9a7c47d43bd161c@BLUPR08MB488.namprd08.prod.outlook.com> RHEL 6.5 - new install ipa-server-3.0.0-42.el6.x86_64 389-ds-base-1.2.11.15-47.el6.x86_64 Is it safe to install the 389 DS and admin console packages and use them? I think it would be useful to use for things like editing ACI's, etc. Craig White System Administrator O 623-201-8179 M 602-377-9752 [cid:image001.png at 01CF86FE.42D51630] SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7660 bytes Desc: image001.png URL: From rcritten at redhat.com Tue Oct 28 21:47:12 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 28 Oct 2014 17:47:12 -0400 Subject: [Freeipa-users] Recovering from messed-up certs In-Reply-To: References: <544932A1.8030909@redhat.com> <54495F8F.1030504@redhat.com> <544FB5FE.8040800@redhat.com> Message-ID: <54500EE0.9090202@redhat.com> Eric McCoy wrote: > You're right. When I deleted the puppetmaster certs and reran > newcert.py, it worked like a champ. Presumably this is how the main > cert disappeared in the first place: NSS silently overwrote it. This > does mean that I won't be able to run puppet on this server, but... > Well, even when I was doing it, I knew it was a bad idea. I just > figured I could maybe get away with it. > > Should I submit a bug someplace? From the age of that BZ I don't have a > lot of faith that the actual NSS bug is going to get fixed anytime > soon. But if it can be worked around in IPA (or is it certmonger?) -- > perhaps simply by showing an error message -- I think that would be > sufficient. Clearly this is something of a corner case. Well, we really need to switch to using NSS sqlite databases which doesn't appear to have this problem. We've never qualified all the dependencies to actually support this though. I started looking at mod_nss today and it's pretty easy to fix support there, https://bugzilla.redhat.com/show_bug.cgi?id=1057650 We also need to check 389-ds, the CA, the client and probably lots of corner cases as well. Here is the IPA ticket to track this: https://fedorahosted.org/freeipa/ticket/4140 rob > > On Tue, Oct 28, 2014 at 11:27 AM, Rob Crittenden > wrote: > > Eric McCoy wrote: > > Sorry it took me so long to try this and get back to you. I tried > > modifying that Python script and running it, and this is what I get: > > > > Initializing API > > Setting up NSS databases > > Untracking existing Apache Server-Cert > > Issuing new cert > > Tracking Server-Cert > > ipa: ERROR: certmonger failed starting to track certificate: Nickname > > "Server-Cert" doesn't exist in NSS database "/etc/httpd/alias" > > > > I checked and it's right. The output of certutil -L -d > /etc/httpd/alias > > is... confusing, actually. So I got the above output. Then I > realized > > my Kerberos ticket was expired and I ought to get a new one. When > I did > > so, I retried the command and got the exact same output. However, > this > > time certutil's output is different: > > > > # certutil -L -d /etc/httpd/alias > > > > Certificate Nickname Trust > > Attributes > > > > SSL,S/MIME,JAR/XPI > > > > puppetmaster/hostname u,u,u > > REALMNAME IPA CA CT,C,C > > ipaCert u,u,u > > Signing-Cert u,u,u > > puppetmaster/hostname u,u,u > > > > The puppetmaster/hostname entry is in there twice. The first > attempt at > > newcert.py is still in my scroll buffer: the puppetmaster entry > > definitely only appears once until after this most recent run. I'm > > starting to wonder if my attempts to create that puppetmaster cert > > somehow screwed up the database. > > NSS apparently doesn't like two certificates with the same subject. > Nickname doesn't seem to matter in this case. I found this bug which is > mail specific but seems to cover the same problem: > https://bugzilla.mozilla.org/show_bug.cgi?id=278689 > > I think the only solution is to remove the puppetmaster cert. Does it > need to reside in the Apache database? > > rob > > > > > > > On Thu, Oct 23, 2014 at 4:05 PM, Rob Crittenden > > >> wrote: > > > > Eric McCoy wrote: > > > Some nicknames changed to protect the innocent. The > > > puppetmaster/hostname cert is nominally unrelated, though > its creation > > > was contemporaneous with the disappearance of server-cert so > I can't > > > entirely rule it out. > > > > > > Certificate Nickname > Trust > > > Attributes > > > > > > SSL,S/MIME,JAR/XPI > > > > > > puppetmaster/hostname u,u,u > > > REALMNAME IPA CA > CT,C,C > > > ipaCert > u,u,u > > > Signing-Cert > u,u,u > > > > Ok, this is good. If we have ipaCert we can get a cert > directly from the > > CA like we do during installation. > > > > The attached python script should fix things up for you. > > > > Save it, modify it and replace subjectbase with what matches your > > environment. You can get the base from an existing cert with: > > > > # certutil -L -d /etc/dirsrv/slapd-REALM -n Server-Cert |grep > Subject > > > > Unless you changed it during installation it should be O= > > > > Then just run the script: > > > > # python newcert.py > > Initializing API > > Setting up NSS databases > > Untracking existing Apache Server-Cert > > Issuing new cert > > Tracking Server-Cert > > > > # service httpd start > > > > The only thing this script doesn't do is put this updated > certificate in > > the service record's LDAP entry. > > > > rob > > > > > > > > > > > On Thu, Oct 23, 2014 at 12:53 PM, Rob Crittenden > > > > > > > >>> wrote: > > > > > > Eric McCoy wrote: > > > > Hi all, > > > > > > > > I somehow destroyed my primary IPA server's Server-Cert in > > > > /etc/httpd/alias. I don't understand how or why it > > happened, all > > > I know > > > > is that I went to restart Apache and it was gone. Apache > > won't start, > > > > of course, because the cert is missing. I can't issue > a new > > cert > > > on the > > > > primary because Apache is down. I tried using the > > secondary, but it > > > > fails saying that it can't connect to the web server > on the > > primary > > > > (it's the same error message I get when I try to issue a > > cert from the > > > > primary). I can't figure out how to tell ipa-getcert > et al. to > > > talk to > > > > the secondary and not the primary. I'm not using DNS for > > service > > > > discovery, so I'm not sure how the various tools > figure out > > where > > > things > > > > are. > > > > > > > > This is all on CentOS 6.5 with IPA 3.0.0-37. > > > > > > > > > > > > > > What certs do you have in the database? > > > > > > # certutil -L -d /etc/httpd/alias > > > > > > rob > > > > > > > > > > > > From rcritten at redhat.com Tue Oct 28 21:55:54 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 28 Oct 2014 17:55:54 -0400 Subject: [Freeipa-users] Solaris 10 client configuration using profile In-Reply-To: <1414514476.87630.YahooMailBasic@web122501.mail.ne1.yahoo.com> References: <1414514476.87630.YahooMailBasic@web122501.mail.ne1.yahoo.com> Message-ID: <545010EA.7060002@redhat.com> sipazzo wrote: > Yes I did generate the database on the IPA server and copied it over. I thought that was what the instructions indicated to do: So NSS is not known for the greatest error messages. The error you're seeing, SEC_ERROR_LEGACY_DATABASE, can happen for any number of reasons, including there being no database at all or there is a database but the wrong version. So using native tools was a shot in the dark. truss might be of some help here to figure out what it is trying to open. rob > > Create NSS DB (Don't enter password. Just hit return) > ipaserver $ certutil -N -d /var/ldap > > Convert the IPA certificate to PEM format: > ipaserver $ openssl x509 -in /etc/ipa/ca.crt -outform pem -out /etc/ipa/ca.pem > > Add CA certificate to the NSS DB > ipaserver $ certutil -A -n "ca-cert" -i /etc/ipa/ca.pem -a -t CT -d /var/ldap > > Copy the *.db files from /var/ldap/ on the ipa server to /var/ldap on the Solaris host. > solarishost $ scp ipaserver:/var/ldap/*.db /var/ldap/ > solarishost $ chmod 444 /var/ldap/*.db > > > There is not an /etc/ipa directory on the client so I assumed it was generated on the Linux ipa server side. > > However, I created the /etc/ipa directory on the solaris client and copied my ca.crt and ca.pem from the ipa server to the directory on the solaris client. I then ran certutil -N -d /var/ldap on the solaris client as well as certutil -A -n "ca-cert" -i /etc/ipa/ca.pem -a -t CT -d /var/ldap/ > > According to timestamp the .db files changed but their names remained the same: > -r--r--r-- 1 root root 65536 Oct 27 15:48 cert8.db > -r--r--r-- 1 root root 16384 Oct 27 15:48 key3.db > -r--r--r-- 1 root root 16384 Oct 27 14:47 secmod.db > > > But still get same errors in log files and using ldapsearch. > > -------------------------------------------- > On Mon, 10/27/14, Rob Crittenden wrote: > > Subject: Re: [Freeipa-users] Solaris 10 client configuration using profile > To: "sipazzo" , "Freeipa-users at redhat.com" > Date: Monday, October 27, 2014, 3:41 PM > > sipazzo wrote: > > /var/ldap exists on both client and server > and I was able to sudo to root and generate the *.db files > without getting the legacy database error. I scp'd them > to the hosts and restarted ldap_cachemgr but errors > continued. I then re-initialized the client and am still > getting same errors in log files and same error when running > an ldapsearch using ssl > > > > > > SSL initialization > failed: error -8174 (security library: bad database.) > > > > The .db files all > have 444 permissions > > This > database is only needed on the client. > > I gather you created the NSS database on your > Linux server and copied it > over? I wonder if > the database version isn't supported. What are the > names of the db files in /var/ldap? Do you have > a certutil on the > Solaris machine to do this > work? > > The Oracle docs > suggest that cert8/key3 should be fine though. > > rob > > > > > > > > -------------------------------------------- > > On Mon, 10/27/14, Rob Crittenden > wrote: > > > > Subject: > Re: [Freeipa-users] Solaris 10 client configuration using > profile > > To: "sipazzo" > , > "Alexander Bokovoy" > > Cc: "Freeipa-users at redhat.com" > > > Date: Monday, October 27, 2014, 2:07 > PM > > > > sipazzo > wrote: > > > okay so this is working > with the secure > > profile, thank you > all, but I am getting a ton of errors in > > my logs on the solaris clients like > this: > > > > > > > Oct 27 13:08:51 > > > dc2.ipadomain.com ldap_cachemgr[15004]: [ID 545954 > > daemon.error] libsldap: makeConnection: > failed to open > > connection to > idm1.ipadomain.com > > > Oct 27 > > 13:08:51 dc2.ipadomain.com > ldap_cachemgr[15004]: [ID 545954 > > > daemon.error] libsldap: makeConnection: failed to open > > connection to idm2.ipadomain.com > > > Oct 27 > > > 13:08:51 dc2.ipadomain.com ldap_cachemgr[15004]: [ID > 687686 > > daemon.warning] libsldap: > Falling back to anonymous, non-SSL > > > mode for __ns_ldap_getRootDSE. openConnection: simple > bind > > failed - Can't contact LDAP > server > > > > > > Oct 27 13:08:51 dc2.ipadomain.com last message repeated 1 > > time > > > Oct 27 > 13:08:51 dc2.ipadomain.com > > > ldap_cachemgr[15004]: [ID 293258 daemon.warning] > libsldap: > > Status: 81 Mesg: > openConnection: simple bind failed - > > > Can't contact LDAP server > > > > Oct 27 > > 13:08:51 dc2.ipadomain.com > ldap_cachemgr[15004]: [ID 545954 > > > daemon.error] libsldap: makeConnection: failed to open > > connection to idm1-corp.ipadomain.com > > > > > Oct 27 > 13:08:51 dc2-io.ipadomain.com ldap_cachemgr[15004]: > > [ID 687686 daemon.warning] libsldap: > Falling back to > > anonymous, non-SSL > mode for __ns_ldap_getRootDSE. > > > openConnection: simple bind failed - Can't contact > LDAP > > server > > > > > > > > > > > I think this might be related to trying to > > use tls:simple for authentication so I > went back over the > > steps for the cert > set up and I am unable to generate or > > > import the ca.pem cert into the nssdb database > > > > > > > certutil -N -d > > /var/ldap > > > certutil: function failed: > > SEC_ERROR_LEGACY_DATABASE: The > certificate/key database is > > in an > old, unsupported format. > > > > > > > > > > certutil -A -n > > "ca-cert" -i > /etc/ipa/ca.pem -a -t CT -d > > > /var/ldap > > > certutil: function > failed: > > SEC_ERROR_LEGACY_DATABASE: > The certificate/key database is > > in an > old, unsupported format. > > > > Does the directory /var/ldap exist and > can the > > current user write to it? > > > > rob > > > > > > > From rmeggins at redhat.com Tue Oct 28 22:02:18 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 28 Oct 2014 16:02:18 -0600 Subject: [Freeipa-users] 389 DS & admin consoles In-Reply-To: <8e50b6ebd9804b8ab9a7c47d43bd161c@BLUPR08MB488.namprd08.prod.outlook.com> References: <8e50b6ebd9804b8ab9a7c47d43bd161c@BLUPR08MB488.namprd08.prod.outlook.com> Message-ID: <5450126A.2000004@redhat.com> On 10/28/2014 02:45 PM, Craig White wrote: > > RHEL 6.5 ? new install > > ipa-server-3.0.0-42.el6.x86_64 > > 389-ds-base-1.2.11.15-47.el6.x86_64 > > Is it safe to install the 389 DS and admin console packages and use them? > In general, no, it is not supported. IPA depends on a certain tree structure, schema, etc. > I think it would be useful to use for things like editing ACI?s, etc. > It would be useful for a lot of lower level management and monitoring. But unfortunately it is not supported. You might be able to install it and make it work, but it might also mess up your IdM deployment. > Craig White > > System Administrator > > O623-201-8179 M602-377-9752 > > cid:image001.png at 01CF86FE.42D51630 > > SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 7660 bytes Desc: not available URL: From rcritten at redhat.com Tue Oct 28 22:29:35 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 28 Oct 2014 18:29:35 -0400 Subject: [Freeipa-users] Solaris 10 client configuration using profile In-Reply-To: <545010EA.7060002@redhat.com> References: <1414514476.87630.YahooMailBasic@web122501.mail.ne1.yahoo.com> <545010EA.7060002@redhat.com> Message-ID: <545018CF.7090406@redhat.com> Rob Crittenden wrote: > sipazzo wrote: >> Yes I did generate the database on the IPA server and copied it over. I thought that was what the instructions indicated to do: > > So NSS is not known for the greatest error messages. The error you're > seeing, SEC_ERROR_LEGACY_DATABASE, can happen for any number of reasons, > including there being no database at all or there is a database but the > wrong version. So using native tools was a shot in the dark. > > truss might be of some help here to figure out what it is trying to open. Replying to myself. Check /etc/nsswitch.conf. I'll bet you've got ldap defined for every service. If so, this is the reason. What you need to do is edit /etc/nsswitch.ldap and replace at least hosts and ipnodes with: hosts: files dns ipnodes: files dns Now, to back out what you've done, I'd do this: - edit /etc/nsswitch.conf and do the above hosts & inodes replacement - ldapclient -v uninit - edit /etc/nsswitch.ldap and fix it up - re-run ldapclient -v init That should do the trick. It did for me anyway. Note that the BZ instructions have that openssl PEM conversion thing. That isn't necessary as the CA is already in PEM format. rob From CWhite at skytouchtechnology.com Tue Oct 28 23:05:45 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Tue, 28 Oct 2014 23:05:45 +0000 Subject: [Freeipa-users] 389 DS & admin consoles In-Reply-To: <5450126A.2000004@redhat.com> References: <8e50b6ebd9804b8ab9a7c47d43bd161c@BLUPR08MB488.namprd08.prod.outlook.com> <5450126A.2000004@redhat.com> Message-ID: <21b324a15bf74a138988b304733b59aa@BLUPR08MB488.namprd08.prod.outlook.com> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson Sent: Tuesday, October 28, 2014 3:02 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] 389 DS & admin consoles On 10/28/2014 02:45 PM, Craig White wrote: RHEL 6.5 - new install ipa-server-3.0.0-42.el6.x86_64 389-ds-base-1.2.11.15-47.el6.x86_64 Is it safe to install the 389 DS and admin console packages and use them? In general, no, it is not supported. IPA depends on a certain tree structure, schema, etc. I think it would be useful to use for things like editing ACI's, etc. It would be useful for a lot of lower level management and monitoring. But unfortunately it is not supported. You might be able to install it and make it work, but it might also mess up your IdM deployment. ---- Not worth it then. I have been all over your Documentation page on FreeIPA.org (http://www.freeipa.org/page/Documentation) I have not found any way to actually edit ACL's (I believe the terminology in 389 Server was ACI when I last used it some 8 or so years ago). Is there any way to edit them? Is there any tools similar to the 389-DS-Server console like the Certificate manager? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Oct 28 23:23:20 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 28 Oct 2014 17:23:20 -0600 Subject: [Freeipa-users] 389 DS & admin consoles In-Reply-To: <21b324a15bf74a138988b304733b59aa@BLUPR08MB488.namprd08.prod.outlook.com> References: <8e50b6ebd9804b8ab9a7c47d43bd161c@BLUPR08MB488.namprd08.prod.outlook.com> <5450126A.2000004@redhat.com> <21b324a15bf74a138988b304733b59aa@BLUPR08MB488.namprd08.prod.outlook.com> Message-ID: <54502568.7000805@redhat.com> On 10/28/2014 05:05 PM, Craig White wrote: > > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Rich Megginson > *Sent:* Tuesday, October 28, 2014 3:02 PM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] 389 DS & admin consoles > > On 10/28/2014 02:45 PM, Craig White wrote: > > RHEL 6.5 ? new install > > ipa-server-3.0.0-42.el6.x86_64 > > 389-ds-base-1.2.11.15-47.el6.x86_64 > > Is it safe to install the 389 DS and admin console packages and > use them? > > > In general, no, it is not supported. IPA depends on a certain tree > structure, schema, etc. > > > I think it would be useful to use for things like editing ACI?s, etc. > > > It would be useful for a lot of lower level management and > monitoring. But unfortunately it is not supported. You might be able > to install it and make it work, but it might also mess up your IdM > deployment. > ---- > > Not worth it then. I have been all over your Documentation page on > FreeIPA.org (http://www.freeipa.org/page/Documentation) > > I have not found any way to actually edit ACL?s (I believe the > terminology in 389 Server was ACI when I last used it some 8 or so > years ago). Is there any way to edit them? > I'm assuming you mean something that can parse and understand 389 acis. No, not afaik. > Is there any tools similar to the 389-DS-Server console like the > Certificate manager? > Not sure what you mean by "the Certificate manager". Do you mean the 389 console GUI that allows you to Manage Certificates? With IPA, that functionality is supposed to be largely automated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sipazzo at yahoo.com Wed Oct 29 00:00:41 2014 From: sipazzo at yahoo.com (sipazzo) Date: Tue, 28 Oct 2014 17:00:41 -0700 Subject: [Freeipa-users] Solaris 10 client configuration using profile In-Reply-To: <545018CF.7090406@redhat.com> Message-ID: <1414540841.72443.YahooMailBasic@web122501.mail.ne1.yahoo.com> I only have ldap defined in nsswitch.conf for passwd and group, ipnodes and host correctly reference dns. The fact that I get an SSL initialization failed: error -8174 (security library: bad database) when performing an ldapsearch with the -ZZ option seems to indicate that there is something wrong with the .db files. I have tried uninitializing the client, regenerating the .db files and re-copying them to the server but having same errors. -------------------------------------------- On Tue, 10/28/14, Rob Crittenden wrote: Subject: Re: [Freeipa-users] Solaris 10 client configuration using profile To: "sipazzo" , "Freeipa-users at redhat.com" Date: Tuesday, October 28, 2014, 3:29 PM Rob Crittenden wrote: > sipazzo wrote: >> Yes I did generate the database on the IPA server and copied it over. I thought that was what the instructions indicated to do: > > So NSS is not known for the greatest error messages. The error you're > seeing, SEC_ERROR_LEGACY_DATABASE, can happen for any number of reasons, > including there being no database at all or there is a database but the > wrong version. So using native tools was a shot in the dark. > > truss might be of some help here to figure out what it is trying to open. Replying to myself. Check /etc/nsswitch.conf. I'll bet you've got ldap defined for every service. If so, this is the reason. What you need to do is edit /etc/nsswitch.ldap and replace at least hosts and ipnodes with: hosts:??? ??? files dns ipnodes:??? files dns Now, to back out what you've done, I'd do this: - edit /etc/nsswitch.conf and do the above hosts & inodes replacement - ldapclient -v uninit - edit /etc/nsswitch.ldap and fix it up - re-run ldapclient -v init That should do the trick. It did for me anyway. Note that the BZ instructions have that openssl PEM conversion thing. That isn't necessary as the CA is already in PEM format. rob From dpal at redhat.com Wed Oct 29 00:10:13 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 28 Oct 2014 20:10:13 -0400 Subject: [Freeipa-users] getent passwd / group [SOLVED] In-Reply-To: References: Message-ID: <54503065.4070600@redhat.com> On 10/28/2014 04:41 PM, Craig White wrote: > > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Craig White > *Sent:* Tuesday, October 28, 2014 1:28 PM > *To:* dpal at redhat.com; freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] getent passwd / group [SOLVED] > > *From:*Dmitri Pal [mailto:dpal at redhat.com] > *Sent:* Tuesday, October 28, 2014 10:04 AM > *To:* Craig White; freeipa-users at redhat.com > > *Subject:* Re: [Freeipa-users] getent passwd / group > > On 10/28/2014 12:11 PM, Craig White wrote: > > *From:*freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* Monday, October 27, 2014 5:32 PM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] getent passwd / group > > On 10/27/2014 07:38 PM, Craig White wrote: > > RHEL 6.5 -- new install > > ipa-server-3.0.0-42.el6.x86_64 > > 389-ds-base-1.2.11.15-47.el6.x86_64 > > On the master, I get nothing > > [root at ipa001 log]# getent passwd admin > > [root at ipa001 log]# > > But it works on the replica as expected > > [root at ipa002nadev01 ~]# getent passwd admin > > admin:*:1140000000:1110000000:Administrator:/home/admin:/bin/bash > > I am used to using PADL / NSSWITCH with OpenLDAP and I am > rather surprised that on both, 'getent passwd' and 'getent > group' return only entries from local files but then again, > I've never used sssd before. > > REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with > icmp-host-prohibited > > > Then we need SSSD logs with the debug_level in the right sections as > Jakub mentioned in his mail. > ---- > > Sorry -- I had a long meeting and should have noted that after > restarting SSSD, it all started working again as expected. Clearly > something I have to watch for and indeed, I moved the debug to the > domain section for future. > > I should add -- came to the realization that restarting sssd and went to long meeting, then came back and couldn't log into ipa console or Kerberos and had to restart IPA service to restart Kerberos. > > IPA is logging nothing. > > This is not the first time I have had to go through this cycle -- it seems that somehow, the IPA server is sensitive to the SSSD daemon and if the SSSD goes haywire, when I restart SSSD, IPA is not functioning and must be restarted too. > > Thanks > > Craig Is this on the same server? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Oct 29 00:13:36 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 28 Oct 2014 20:13:36 -0400 Subject: [Freeipa-users] 389 DS & admin consoles In-Reply-To: <54502568.7000805@redhat.com> References: <8e50b6ebd9804b8ab9a7c47d43bd161c@BLUPR08MB488.namprd08.prod.outlook.com> <5450126A.2000004@redhat.com> <21b324a15bf74a138988b304733b59aa@BLUPR08MB488.namprd08.prod.outlook.com> <54502568.7000805@redhat.com> Message-ID: <54503130.8090701@redhat.com> On 10/28/2014 07:23 PM, Rich Megginson wrote: > On 10/28/2014 05:05 PM, Craig White wrote: >> >> *From:*freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Rich Megginson >> *Sent:* Tuesday, October 28, 2014 3:02 PM >> *To:* freeipa-users at redhat.com >> *Subject:* Re: [Freeipa-users] 389 DS & admin consoles >> >> On 10/28/2014 02:45 PM, Craig White wrote: >> >> RHEL 6.5 -- new install >> >> ipa-server-3.0.0-42.el6.x86_64 >> >> 389-ds-base-1.2.11.15-47.el6.x86_64 >> >> Is it safe to install the 389 DS and admin console packages and >> use them? >> >> >> In general, no, it is not supported. IPA depends on a certain tree >> structure, schema, etc. >> >> >> I think it would be useful to use for things like editing ACI's, etc. >> >> >> It would be useful for a lot of lower level management and >> monitoring. But unfortunately it is not supported. You might be >> able to install it and make it work, but it might also mess up your >> IdM deployment. >> ---- >> >> Not worth it then. I have been all over your Documentation page on >> FreeIPA.org (http://www.freeipa.org/page/Documentation) >> >> I have not found any way to actually edit ACL's (I believe the >> terminology in 389 Server was ACI when I last used it some 8 or so >> years ago). Is there any way to edit them? >> > > I'm assuming you mean something that can parse and understand 389 > acis. No, not afaik. The actual low level ACIs are hidden under: roles, privileges, permissions and delegations. Have you looked at those? Managing low level ACIs directly is not supported or recommended. > >> Is there any tools similar to the 389-DS-Server console like the >> Certificate manager? >> > Not sure what you mean by "the Certificate manager". Do you mean the > 389 console GUI that allows you to Manage Certificates? With IPA, > that functionality is supposed to be largely automated. > > No everything that is supported from CA is exposed via CLI and UI. We are working on exposing more but what you have now is what you get. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From CWhite at skytouchtechnology.com Wed Oct 29 00:15:50 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Wed, 29 Oct 2014 00:15:50 +0000 Subject: [Freeipa-users] getent passwd / group [SOLVED] In-Reply-To: <54503065.4070600@redhat.com> References: <54503065.4070600@redhat.com> Message-ID: <3c0fa0a2867c4d1584baac5b51d6c771@BLUPR08MB488.namprd08.prod.outlook.com> From: Dmitri Pal [mailto:dpal at redhat.com] Sent: Tuesday, October 28, 2014 5:10 PM To: Craig White; freeipa-users at redhat.com Subject: Re: [Freeipa-users] getent passwd / group [SOLVED] On 10/28/2014 04:41 PM, Craig White wrote: From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Craig White Sent: Tuesday, October 28, 2014 1:28 PM To: dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] getent passwd / group [SOLVED] From: Dmitri Pal [mailto:dpal at redhat.com] Sent: Tuesday, October 28, 2014 10:04 AM To: Craig White; freeipa-users at redhat.com Subject: Re: [Freeipa-users] getent passwd / group On 10/28/2014 12:11 PM, Craig White wrote: From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Monday, October 27, 2014 5:32 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] getent passwd / group On 10/27/2014 07:38 PM, Craig White wrote: RHEL 6.5 - new install ipa-server-3.0.0-42.el6.x86_64 389-ds-base-1.2.11.15-47.el6.x86_64 On the master, I get nothing [root at ipa001 log]# getent passwd admin [root at ipa001 log]# But it works on the replica as expected [root at ipa002nadev01 ~]# getent passwd admin admin:*:1140000000:1110000000:Administrator:/home/admin:/bin/bash I am used to using PADL / NSSWITCH with OpenLDAP and I am rather surprised that on both, 'getent passwd' and 'getent group' return only entries from local files but then again, I've never used sssd before. REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Then we need SSSD logs with the debug_level in the right sections as Jakub mentioned in his mail. ---- Sorry - I had a long meeting and should have noted that after restarting SSSD, it all started working again as expected. Clearly something I have to watch for and indeed, I moved the debug to the domain section for future. I should add - came to the realization that restarting sssd and went to long meeting, then came back and couldn't log into ipa console or Kerberos and had to restart IPA service to restart Kerberos. IPA is logging nothing. This is not the first time I have had to go through this cycle - it seems that somehow, the IPA server is sensitive to the SSSD daemon and if the SSSD goes haywire, when I restart SSSD, IPA is not functioning and must be restarted too. Thanks Craig Is this on the same server? ---- Yes, same server... the one I call the master. The first one I set up. I'm getting tuned in to the checking the status of dirsrv and ipa but now I know to check the status of the sssd too. Seems like it crashes a little too easily - I doubt I did much to harm it... I am fairly experienced with OpenLDAP and in fact used 389-server back when it was called FedoraDS. But it is running now, and seemingly will stay running for some time and I am upping the logging and watching for a crash like Richard said to provide some debug logs if possible. Sort of wish I could have just started with RHEL 7 and the updated IPA. Thanks Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Oct 29 00:19:11 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 28 Oct 2014 20:19:11 -0400 Subject: [Freeipa-users] getent passwd / group [SOLVED] In-Reply-To: <3c0fa0a2867c4d1584baac5b51d6c771@BLUPR08MB488.namprd08.prod.outlook.com> References: <54503065.4070600@redhat.com> <3c0fa0a2867c4d1584baac5b51d6c771@BLUPR08MB488.namprd08.prod.outlook.com> Message-ID: <5450327F.9000200@redhat.com> On 10/28/2014 08:15 PM, Craig White wrote: > > *From:*Dmitri Pal [mailto:dpal at redhat.com] > *Sent:* Tuesday, October 28, 2014 5:10 PM > *To:* Craig White; freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] getent passwd / group [SOLVED] > > On 10/28/2014 04:41 PM, Craig White wrote: > > *From:*freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Craig White > *Sent:* Tuesday, October 28, 2014 1:28 PM > *To:* dpal at redhat.com ; > freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] getent passwd / group [SOLVED] > > *From:*Dmitri Pal [mailto:dpal at redhat.com] > *Sent:* Tuesday, October 28, 2014 10:04 AM > *To:* Craig White; freeipa-users at redhat.com > > *Subject:* Re: [Freeipa-users] getent passwd / group > > On 10/28/2014 12:11 PM, Craig White wrote: > > *From:*freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of > *Dmitri Pal > *Sent:* Monday, October 27, 2014 5:32 PM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] getent passwd / group > > On 10/27/2014 07:38 PM, Craig White wrote: > > RHEL 6.5 -- new install > > ipa-server-3.0.0-42.el6.x86_64 > > 389-ds-base-1.2.11.15-47.el6.x86_64 > > On the master, I get nothing > > [root at ipa001 log]# getent passwd admin > > [root at ipa001 log]# > > But it works on the replica as expected > > [root at ipa002nadev01 ~]# getent passwd admin > > admin:*:1140000000:1110000000:Administrator:/home/admin:/bin/bash > > I am used to using PADL / NSSWITCH with OpenLDAP and I am > rather surprised that on both, 'getent passwd' and 'getent > group' return only entries from local files but then > again, I've never used sssd before. > > REJECT all -- 0.0.0.0/0 0.0.0.0/0 > reject-with icmp-host-prohibited > > > Then we need SSSD logs with the debug_level in the right sections > as Jakub mentioned in his mail. > ---- > > Sorry -- I had a long meeting and should have noted that after > restarting SSSD, it all started working again as expected. Clearly > something I have to watch for and indeed, I moved the debug to the > domain section for future. > > I should add -- came to the realization that restarting sssd and went to long meeting, then came back and couldn't log into ipa console or Kerberos and had to restart IPA service to restart Kerberos. > > > > IPA is logging nothing. > > > > This is not the first time I have had to go through this cycle -- it seems that somehow, the IPA server is sensitive to the SSSD daemon and if the SSSD goes haywire, when I restart SSSD, IPA is not functioning and must be restarted too. > > > > Thanks > > > > Craig > > > Is this on the same server? > ---- > > Yes, same server... the one I call the master. The first one I set up. > I'm getting tuned in to the checking the status of dirsrv and ipa but > now I know to check the status of the sssd too. > > > Seems like it crashes a little too easily -- I doubt I did much to harm it... I am fairly experienced with OpenLDAP and in fact used 389-server back when it was called FedoraDS. > > But it is running now, and seemingly will stay running for some time and I am upping the logging and watching for a crash like Richard said to provide some debug logs if possible. Sort of wish I could have just started with RHEL 7 and the updated IPA. > > Thanks > > Craig 6.5 was pretty stable but things happen from time to time so it is not clear what exactly went wrong. I suspect some race condition that is rare but happens sometimes. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Oct 29 00:32:48 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 28 Oct 2014 20:32:48 -0400 Subject: [Freeipa-users] Solaris 10 client configuration using profile In-Reply-To: <1414540841.72443.YahooMailBasic@web122501.mail.ne1.yahoo.com> References: <1414540841.72443.YahooMailBasic@web122501.mail.ne1.yahoo.com> Message-ID: <545035B0.30200@redhat.com> sipazzo wrote: > I only have ldap defined in nsswitch.conf for passwd and group, ipnodes and host correctly reference dns. The fact that I get an SSL initialization failed: error -8174 (security library: bad database) when performing an ldapsearch with the -ZZ option seems to indicate that there is something wrong with the .db files. I have tried uninitializing the client, regenerating the .db files and re-copying them to the server but having same errors. I think ldapsearch is a red herring. /usr/bin/ldapsearch on my Solaris 10 box is the mozldap version so the second Z seems to be ignored (I tried 10 Z's and no errors where thrown). -Z for mozldap means require SSL, not startTLS, so you need to set the port to 636. That worked for me as long as the IPA CA was in /var/ldap and properly trusted. I was getting a LOT less specific errors than you though. rob > -------------------------------------------- > On Tue, 10/28/14, Rob Crittenden wrote: > > Subject: Re: [Freeipa-users] Solaris 10 client configuration using profile > To: "sipazzo" , "Freeipa-users at redhat.com" > Date: Tuesday, October 28, 2014, 3:29 PM > > Rob Crittenden wrote: > > sipazzo wrote: > >> > Yes I did generate the database on the IPA server and copied > it over. I thought that was what the instructions indicated > to do: > > > > So NSS is > not known for the greatest error messages. The error > you're > > seeing, > SEC_ERROR_LEGACY_DATABASE, can happen for any number of > reasons, > > including there being no > database at all or there is a database but the > > wrong version. So using native tools was a > shot in the dark. > > > > > truss might be of some help here to figure out what it is > trying to open. > > Replying to > myself. > > Check > /etc/nsswitch.conf. I'll bet you've got ldap defined > for every > service. If so, this is the > reason. > > What you need to do > is edit /etc/nsswitch.ldap and replace at least > hosts and ipnodes with: > > hosts: files dns > ipnodes: files dns > > Now, to back out what you've done, I'd > do this: > > - edit > /etc/nsswitch.conf and do the above hosts & inodes > replacement > - ldapclient -v uninit > - edit /etc/nsswitch.ldap and fix it up > - re-run ldapclient -v init > > That should do the trick. It > did for me anyway. > > Note > that the BZ instructions have that openssl PEM conversion > thing. > That isn't necessary as the CA is > already in PEM format. > > rob > > From rcritten at redhat.com Wed Oct 29 00:34:13 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 28 Oct 2014 20:34:13 -0400 Subject: [Freeipa-users] getent passwd / group [SOLVED] In-Reply-To: <3c0fa0a2867c4d1584baac5b51d6c771@BLUPR08MB488.namprd08.prod.outlook.com> References: <54503065.4070600@redhat.com> <3c0fa0a2867c4d1584baac5b51d6c771@BLUPR08MB488.namprd08.prod.outlook.com> Message-ID: <54503605.5060500@redhat.com> Craig White wrote: > *From:*Dmitri Pal [mailto:dpal at redhat.com] > *Sent:* Tuesday, October 28, 2014 5:10 PM > *To:* Craig White; freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] getent passwd / group [SOLVED] > > > > On 10/28/2014 04:41 PM, Craig White wrote: > > *From:*freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Craig White > *Sent:* Tuesday, October 28, 2014 1:28 PM > *To:* dpal at redhat.com ; > freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] getent passwd / group [SOLVED] > > > > *From:*Dmitri Pal [mailto:dpal at redhat.com] > *Sent:* Tuesday, October 28, 2014 10:04 AM > *To:* Craig White; freeipa-users at redhat.com > > *Subject:* Re: [Freeipa-users] getent passwd / group > > > > On 10/28/2014 12:11 PM, Craig White wrote: > > *From:*freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* Monday, October 27, 2014 5:32 PM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] getent passwd / group > > > > On 10/27/2014 07:38 PM, Craig White wrote: > > RHEL 6.5 ? new install > > ipa-server-3.0.0-42.el6.x86_64 > > 389-ds-base-1.2.11.15-47.el6.x86_64 > > > > On the master, I get nothing > > > > [root at ipa001 log]# getent passwd admin > > [root at ipa001 log]# > > > > But it works on the replica as expected > > > > [root at ipa002nadev01 ~]# getent passwd admin > > admin:*:1140000000:1110000000:Administrator:/home/admin:/bin/bash > > > > I am used to using PADL / NSSWITCH with OpenLDAP and I am > rather surprised that on both, ?getent passwd? and ?getent > group? return only entries from local files but then again, > I?ve never used sssd before. > > > > REJECT all -- 0.0.0.0/0 0.0.0.0/0 > reject-with icmp-host-prohibited > > > Then we need SSSD logs with the debug_level in the right sections as > Jakub mentioned in his mail. > ---- > > Sorry ? I had a long meeting and should have noted that after > restarting SSSD, it all started working again as expected. Clearly > something I have to watch for and indeed, I moved the debug to the > domain section for future. > > I should add ? came to the realization that restarting sssd and went to long meeting, then came back and couldn?t log into ipa console or Kerberos and had to restart IPA service to restart Kerberos. > > > > IPA is logging nothing. > > > > This is not the first time I have had to go through this cycle ? it seems that somehow, the IPA server is sensitive to the SSSD daemon and if the SSSD goes haywire, when I restart SSSD, IPA is not functioning and must be restarted too. > > > > Thanks > > > > Craig > > > Is this on the same server? > ---- > > Yes, same server the one I call the master. The first one I set up. I?m > getting tuned in to the checking the status of dirsrv and ipa but now I > know to check the status of the sssd too. > > > > Seems like it crashes a little too easily ? I doubt I did much to harm it I am fairly experienced with OpenLDAP and in fact used 389-server back when it was called FedoraDS. > > > > But it is running now, and seemingly will stay running for some time and I am upping the logging and watching for a crash like Richard said to provide some debug logs if possible. Sort of wish I could have just started with RHEL 7 and the updated IPA. Ok, and to be clear if it crashes again Rich needs to get a stacktrace. Logs won't be enough. rob From orkhan-azeri at mail.ru Wed Oct 29 05:50:24 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Wed, 29 Oct 2014 09:50:24 +0400 Subject: [Freeipa-users] Radius schema addition to default user objectclasses in FreeIPA 4.1 In-Reply-To: <544F8151.7030707@mail.ru> References: <1414153659.837745408@f356.i.mail.ru> <544AAA9C.3060007@redhat.com> <544F8151.7030707@mail.ru> Message-ID: <54508020.2050904@mail.ru> I solved the problem. I tried to add my radiusschema.ldif using LDAP admin, and it gave an error: "Line 64: "dn" expected, but "add" found". So instructions here: https://www.redhat.com/archives/freeipa-users/2014-February/msg00050.html are incomplete. When creating an ldif-file from the schema-file, it's necessary to repeat this part: dn: cn=schema changetype: modify before this part: add: objectclasses After that everything proceeds normally, and it's possible to add "radiusprofile" objectclass to default user objectclasses. 28-Oct-14 15:43, Orkhan Gasimov ?????: > OK, thanks for info. > First I used that command with " | grep radius" at the end prior to > adding my radiusschema.ldif. > It returned no data. > Then I added my radiusschema.ldif using the command: > > # ldapmodify -ZZ -x -D "cn=Directory Manager" -W -H ldap://localhost > -f /usr/share/radiusschema.ldif > > Then I issued the command you suggested again with " | grep > radius|less" at the end. > This time it retrned a lot of entries (apparently those that were in > the radiusschema.ldif file). > > But when I tried to switch to GUI and add "radiusprofile" objectclass, > I got the same message: > > "IPA Error 4001: NotFound > > objectclass radiusprofile not found" > > I know that radius schema taken from > http://open.rhx.it/phamm/schema/radius.schema works, > it was checked by me with OpenLDAP 2.4 and FreeRadius 2.2. > > What am I doing wrong? Removing "MUST cn" from the schema gives no > difference. > > > > 25-Oct-14 00:38, Rich Megginson ?????: >> Are you trying to list the schema over LDAP? Where did you get the >> above instructions? They are wrong. Use >> >> ldapsearch -o ldif-wrap=no -Y GSSAPI -s base -b "cn=schema" >> attributeTypes objectClasses > From orkhan-azeri at mail.ru Wed Oct 29 06:16:01 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Wed, 29 Oct 2014 10:16:01 +0400 Subject: [Freeipa-users] Radius schema addition to default user objectclasses in FreeIPA 4.1 In-Reply-To: <54508020.2050904@mail.ru> References: <1414153659.837745408@f356.i.mail.ru> <544AAA9C.3060007@redhat.com> <544F8151.7030707@mail.ru> <54508020.2050904@mail.ru> Message-ID: <54508621.3000000@mail.ru> One last question: if I'm using 2 FreeIPA servers in a multi-master replication scenario, should I add the radiusschema.ldif file on both servers? Or it's sufficient to add it on just one server? 29-Oct-14 09:50, Orkhan Gasimov ?????: > I solved the problem. > I tried to add my radiusschema.ldif using LDAP admin, and it gave an > error: "Line 64: "dn" expected, but "add" found". > So instructions here: > https://www.redhat.com/archives/freeipa-users/2014-February/msg00050.html > are incomplete. > When creating an ldif-file from the schema-file, it's necessary to > repeat this part: > > dn: cn=schema > changetype: modify > > before this part: > > add: objectclasses > > After that everything proceeds normally, and it's possible to add > "radiusprofile" objectclass to default user objectclasses. > > 28-Oct-14 15:43, Orkhan Gasimov ?????: >> OK, thanks for info. >> First I used that command with " | grep radius" at the end prior to >> adding my radiusschema.ldif. >> It returned no data. >> Then I added my radiusschema.ldif using the command: >> >> # ldapmodify -ZZ -x -D "cn=Directory Manager" -W -H >> ldap://localhost -f /usr/share/radiusschema.ldif >> >> Then I issued the command you suggested again with " | grep >> radius|less" at the end. >> This time it retrned a lot of entries (apparently those that were in >> the radiusschema.ldif file). >> >> But when I tried to switch to GUI and add "radiusprofile" >> objectclass, I got the same message: >> >> "IPA Error 4001: NotFound >> >> objectclass radiusprofile not found" >> >> I know that radius schema taken from >> http://open.rhx.it/phamm/schema/radius.schema works, >> it was checked by me with OpenLDAP 2.4 and FreeRadius 2.2. >> >> What am I doing wrong? Removing "MUST cn" from the schema gives no >> difference. >> >> >> >> 25-Oct-14 00:38, Rich Megginson ?????: >>> Are you trying to list the schema over LDAP? Where did you get the >>> above instructions? They are wrong. Use >>> >>> ldapsearch -o ldif-wrap=no -Y GSSAPI -s base -b "cn=schema" >>> attributeTypes objectClasses >> > From pspacek at redhat.com Wed Oct 29 08:56:21 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 29 Oct 2014 09:56:21 +0100 Subject: [Freeipa-users] Question About Properly Configuring DNS In-Reply-To: <20141027141509.416baa61@willson.usersys.redhat.com> References: <20141027123005.1ba14cf4@willson.usersys.redhat.com> <20141027141509.416baa61@willson.usersys.redhat.com> Message-ID: <5450ABB5.60509@redhat.com> On 27.10.2014 19:15, Simo Sorce wrote: > On Mon, 27 Oct 2014 17:50:13 +0000 > "Trevor T Kates (Services - 6)" wrote: > >>> -----Original Message----- >>> From: Simo Sorce [mailto:simo at redhat.com] >>> Sent: Monday, October 27, 2014 12:30 PM >>> To: Trevor T Kates (Services - 6) >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] Question About Properly Configuring DNS >>> >>> On Mon, 27 Oct 2014 14:07:42 +0000 >>> "Trevor T Kates (Services - 6)" wrote: >>> >>>> Hi, all: >>>> >>>> I have four servers (two in one location, two in another) running >>>> IPA 3.0 set to replicate like so: >>>> >>>> Location A Server 1 - - - - - - - - Location B Server 1 >>>> | | >>>> | | >>>> | | >>>> | | >>>> Location A Server 2 - - - - - - - - Location B Server 2 >>>> >>>> Each server has DNS configured; however, I think I have configured >>>> something inappropriately with respect to authoritative records. >>>> >>>> I have eight zones configured and ipa dnszone-show for any one of >>>> them has Location B Server 1's name as authoritative. In each of >>>> the eight zones, I have added NS records for the other three >>>> servers. On all of the servers except Location B Server >>>> 1, /var/log/messages will show: >>>> >>>> client x.xxx.x.xxx#14366: received notify for zone >>>> 'x.xxx.x.in-addr.arpa': not authoritative >>>> >>>> This occurs for most, but not all, zones. Along with this: >>>> >>>> LDAP query timed out. Try to adjust "timeout" parameter >>>> update_record (psearch) failed, dn >>>> 'idnsname=xxx,idnsname=x.xxx.xx.in-addr.arpa.,cn=dns,dc=example,dc=com' >>>> change type 0x0. Records can be outdated, run `rndc reload`: not >>>> found >>>> >>>> I feel like I've misconfigured a few things along the way and I'd >>>> love some help. Along with that if anyone has recommendations on >>>> things I should read to help me better understand what I should be >>>> doing with DNS, I'd appreciate it. >>> >>> Uhmm sounds like a bug in reloading the info in the bind ldap >>> plugin. >>> >>> Can you restart named on one of the other servers and tell if the >>> warning goes away and/or if the client returns that server as >>> authoritative after the bounce ? >>> >>> Simo. >>> >>> -- >>> Simo Sorce * Red Hat, Inc * New York >> >> Upon restarting named, 'not authoritative' is not present for any of >> the zones and dig on clients shows all of the servers as >> authoritative. The restart of named did not always go cleanly, >> however. Sometimes, the same timeout issue as before would present >> itself. Should I not worry about those? > > Ok would you be able to opne a bug (bugzilla or trac, either is fine) > for the 2 issues ? > > One seem to be that changing the NS record is not causing a proper > change in authoritative status. > The second should be about the timeout error you are seeing. Please keep in mind that bind-dyndb-ldap just reads data from LDAP so naturally changes done in LDAP are not visible in DNS if directory server is not working properly. Default LDAP search timeout used by bind-dyndb-ldap is 60 seconds which is *a lot*, i.e. it should not happen at all. I would recommend you to dig in directory server logs /var/log/dirsrv/ to see if there is a problem before you open a bind-dyndb-ldap bug - I would point you to DS logs anyway :-) Do you see high CPU/memory utilization or something like that? Does the LDAP server respond to normal LDAP query when you see messages like "LDAP query timeout"? Which version of bind-dyndb-ldap and 389-ds-base do you use? -- Petr^2 Spacek From mbasti at redhat.com Wed Oct 29 10:03:34 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 29 Oct 2014 11:03:34 +0100 Subject: [Freeipa-users] F20 Problem upgrading to 4.1 In-Reply-To: <544FF486.1090905@gmail.com> References: <544E2A5C.50209@redhat.com> <544E897F.4050801@redhat.com> <544E9864.9060804@redhat.com> <544E9FC3.6020809@redhat.com> <544EA28B.5050402@redhat.com> <544F262E.1050400@gmail.com> <544F6E3C.3050000@redhat.com> <544FF486.1090905@gmail.com> Message-ID: <5450BB76.8050300@redhat.com> On 28/10/14 20:54, Michael Lasevich wrote: > I have a pair of servers that were both installed on clean Fedora20 > 4.0.1 from pviktori copr repo and then upgraded from mkosek to 4.1 > > During update, secondary was done first and worked but primary run into > trouble as described > > Looking under cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com I get one > entry with dn: > > ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com > > Not sure what of that you need there, but for ipk11Label it has: > dnssec-replica:infra-dc-02.my.domain.com. (which is the replica that IS > working) > > Thanks, > > -M > > On 10/28/14, 3:21 AM, Martin Basti wrote: >> On 28/10/14 06:14, Michael Lasevich wrote: >>> Running into same thing, but running ipa-dnsinstall does not complete: >>> >>> ============================= >>> Configuring DNS (named) >>> [1/8]: generating rndc key file >>> WARNING: Your system is running out of entropy, you may experience >>> long delays >>> [2/8]: setting up our own record >>> [3/8]: adding NS record to the zones >>> [4/8]: setting up CA record >>> [5/8]: setting up kerberos principal >>> [6/8]: setting up named.conf >>> [7/8]: configuring named to start on boot >>> [8/8]: changing resolv.conf to point to ourselves >>> Done configuring DNS (named). >>> Configuring DNS key synchronization service (ipa-dnskeysyncd) >>> [1/6]: checking status >>> [2/6]: setting up kerberos principal >>> [3/6]: setting up SoftHSM >>> [4/6]: adding DNSSEC containers >>> [5/6]: creating replica keys >>> [error] DuplicateEntry: This entry already exists >>> Unexpected error - see /var/log/ipaserver-install.log for details: >>> DuplicateEntry: This entry already exists >>> ============================= >>> >>> Looking into the /var/log/ipaserver-install.log gets: >>> ============================= >>> 2014-10-28T05:01:24Z DEBUG Storing replica public key to LDAP, >>> ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com >>> 2014-10-28T05:01:24Z DEBUG flushing >>> ldap://infra-dc-01.my.domain.com:389 from SchemaCache >>> 2014-10-28T05:01:24Z DEBUG retrieving schema for SchemaCache >>> url=ldap://infra-dc-01.my.domain.com:389 >>> conn= >>> 2014-10-28T05:01:24Z DEBUG Traceback (most recent call last): >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>> 382, in start_creation run_step(full_msg, method) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>> 372, in run_step method() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", >>> line 340, in __setup_replica_keys ldap.add_entry(entry) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) >>> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ >>> self.gen.throw(type, value, traceback) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1169, in error_handler raise errors.DuplicateEntry() >>> DuplicateEntry: This entry already exists >>> >>> 2014-10-28T05:01:24Z DEBUG [error] DuplicateEntry: This entry >>> already exists >>> 2014-10-28T05:01:24Z DEBUG File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>> line 646, in run_script >>> return_value = main_function() >>> File "/sbin/ipa-dns-install", line 218, in main >>> dnskeysyncd.create_instance(api.env.host, api.env.realm) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", >>> line 128, in create_instance self.start_creation() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>> 382, in start_creation run_step(full_msg, method) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>> 372, in run_step method() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", >>> line 340, in __setup_replica_keys ldap.add_entry(entry) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) >>> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ >>> self.gen.throw(type, value, traceback) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1169, in error_handler raise errors.DuplicateEntry() >>> 2014-10-28T05:01:24Z DEBUG The ipa-dns-install command failed, >>> exception: DuplicateEntry: This entry already exists >> Hello Michael, >> >> can you send me which entries do you have in >> cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com, it looks like directory >> server doesn't generate uniqueID for keys. >> >> Do you have upgraded IPA or fresh installed? >> >> Martin^2 >> Can you send me content of cn=IPK11 Unique IDs,cn=IPA UUID,cn=plugins,cn=config entry? (If exists) It looks like DS doesn't generate unique IDs Martin^2 -- Martin Basti From orkhan-azeri at mail.ru Wed Oct 29 10:23:58 2014 From: orkhan-azeri at mail.ru (Orkhan Gasimov) Date: Wed, 29 Oct 2014 14:23:58 +0400 Subject: [Freeipa-users] Radius schema addition to default user objectclasses in FreeIPA 4.1 In-Reply-To: <54508621.3000000@mail.ru> References: <1414153659.837745408@f356.i.mail.ru> <544AAA9C.3060007@redhat.com> <544F8151.7030707@mail.ru> <54508020.2050904@mail.ru> <54508621.3000000@mail.ru> Message-ID: <5450C03E.7010306@mail.ru> I checked myself on test VMs. It's enough to add Radius schema to one FreeIPA server and issue "ipactl restart" on another. 29-Oct-14 10:16, Orkhan Gasimov ?????: > One last question: if I'm using 2 FreeIPA servers in a multi-master > replication scenario, should I add the radiusschema.ldif file on both > servers? Or it's sufficient to add it on just one server? > > > 29-Oct-14 09:50, Orkhan Gasimov ?????: >> I solved the problem. >> I tried to add my radiusschema.ldif using LDAP admin, and it gave an >> error: "Line 64: "dn" expected, but "add" found". >> So instructions here: >> https://www.redhat.com/archives/freeipa-users/2014-February/msg00050.html >> are incomplete. >> When creating an ldif-file from the schema-file, it's necessary to >> repeat this part: >> >> dn: cn=schema >> changetype: modify >> >> before this part: >> >> add: objectclasses >> >> After that everything proceeds normally, and it's possible to add >> "radiusprofile" objectclass to default user objectclasses. >> >> 28-Oct-14 15:43, Orkhan Gasimov ?????: >>> OK, thanks for info. >>> First I used that command with " | grep radius" at the end prior to >>> adding my radiusschema.ldif. >>> It returned no data. >>> Then I added my radiusschema.ldif using the command: >>> >>> # ldapmodify -ZZ -x -D "cn=Directory Manager" -W -H >>> ldap://localhost -f /usr/share/radiusschema.ldif >>> >>> Then I issued the command you suggested again with " | grep >>> radius|less" at the end. >>> This time it retrned a lot of entries (apparently those that were in >>> the radiusschema.ldif file). >>> >>> But when I tried to switch to GUI and add "radiusprofile" >>> objectclass, I got the same message: >>> >>> "IPA Error 4001: NotFound >>> >>> objectclass radiusprofile not found" >>> >>> I know that radius schema taken from >>> http://open.rhx.it/phamm/schema/radius.schema works, >>> it was checked by me with OpenLDAP 2.4 and FreeRadius 2.2. >>> >>> What am I doing wrong? Removing "MUST cn" from the schema gives no >>> difference. >>> >>> >>> >>> 25-Oct-14 00:38, Rich Megginson ?????: >>>> Are you trying to list the schema over LDAP? Where did you get the >>>> above instructions? They are wrong. Use >>>> >>>> ldapsearch -o ldif-wrap=no -Y GSSAPI -s base -b "cn=schema" >>>> attributeTypes objectClasses >>> >> > From john.obaterspok at gmail.com Wed Oct 29 12:15:09 2014 From: john.obaterspok at gmail.com (John Obaterspok) Date: Wed, 29 Oct 2014 13:15:09 +0100 Subject: [Freeipa-users] Woes adding a samba server to the ipa domain In-Reply-To: <20141023103255.GA2826@localhost.localdomain> References: <1413810952.3012.22.camel@toron.pzo.lgs.com.ve> <5445B498.9090608@redhat.com> <1413893951.3184.15.camel@toron.pzo.lgs.com.ve> <20141023103255.GA2826@localhost.localdomain> Message-ID: Hello, I might be interested in this as well. Does this mean it would be possible for a windows client to access samba FS through IPA provided credentials? Currently my Windows PC gets IPA ticket (through MIT kerberos application) and can use this ticket to login to Linux server via putty. I would jump up and down if I could access samba FS in the same way from Windows:) (I got sssd 1.12.1 and freeipa 4.1 running on F20) -- john 2014-10-23 12:32 GMT+02:00 Sumit Bose : > On Tue, Oct 21, 2014 at 07:49:11AM -0430, Loris Santamaria wrote: > > El lun, 20-10-2014 a las 21:19 -0400, Dmitri Pal escribi?: > > > On 10/20/2014 09:15 AM, Loris Santamaria wrote: > > > > [...] > > > > > > > > > > Trying to join the server to the domain (net rpc join -U domainadmin > -S > > > > ipaserver) fails, and it causes a samba crash on the ipa server. > > > > Investigating the cause of the crash I found that pdbedit crashes as > > > > well (backtrace attached). I couldn't get a meaningful backtrace from > > > > the samba crash however I attached it as well. > > > > > > > > Seems to me that the samba ipasam backend on ipa doesn't like > something > > > > in the host or the "domain computers" group object in ldap, but I > cannot > > > > see what could be the problem. Perhaps someone more familiar with the > > > > ipasam code can spot it quickly. > > > > > Do I get it right that you really looking for > > > https://fedorahosted.org/sssd/ticket/1588 that was just released > > > upstream? > > > It would be cool if you can try using SSSD 1.12.1 under Samba FS in > > > the use case you have and provide feedback on how it works for you. > > > > > > AFAIU you install Samba FS and then use ipa-client to configure SSSD > > > under it and it should work. > > > If not we probably should document it (but I do not see any special > > > design page which leads me to the above expectation). > > > > Ok, I'll happily try sssd 1.12.1. > > > > Just a question, in smb.conf one should use "security = domain" or > > "security = ads"? > > 'ads' because we want to use Kerberos. But there some other > configuration options which needs attention, e.g. you have to create a > keytab for the cifs service and make it available to samba. I'll try to > set up an small howto page listing the needed steps and come back to you > early next week. > > bye, > Sumit > > > > > Best regards > > > > -- > > Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve > > Links Global Services, C.A. http://www.lgs.com.ve > > Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve > > ------------------------------------------------------------ > > "If I'd asked my customers what they wanted, they'd have said > > a faster horse" - Henry Ford > > > > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Oct 29 12:27:32 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 29 Oct 2014 08:27:32 -0400 Subject: [Freeipa-users] Woes adding a samba server to the ipa domain In-Reply-To: References: <1413810952.3012.22.camel@toron.pzo.lgs.com.ve> <5445B498.9090608@redhat.com> <1413893951.3184.15.camel@toron.pzo.lgs.com.ve> <20141023103255.GA2826@localhost.localdomain> Message-ID: <5450DD34.3090302@redhat.com> On 10/29/2014 08:15 AM, John Obaterspok wrote: > Hello, > > I might be interested in this as well. Does this mean it would be > possible for a windows client to access samba FS through IPA provided > credentials? > Currently my Windows PC gets IPA ticket (through MIT kerberos > application) and can use this ticket to login to Linux server via > putty. I would jump up and down if I could access samba FS in the same > way from Windows:) > > (I got sssd 1.12.1 and freeipa 4.1 running on F20) > I suspect that if you deploy Samba FS with SSSD configured as a member server of the IPA domain it should be possible. > -- john > > 2014-10-23 12:32 GMT+02:00 Sumit Bose >: > > On Tue, Oct 21, 2014 at 07:49:11AM -0430, Loris Santamaria wrote: > > El lun, 20-10-2014 a las 21:19 -0400, Dmitri Pal escribi?: > > > On 10/20/2014 09:15 AM, Loris Santamaria wrote: > > > > [...] > > > > > > > > > > Trying to join the server to the domain (net rpc join -U > domainadmin -S > > > > ipaserver) fails, and it causes a samba crash on the ipa server. > > > > Investigating the cause of the crash I found that pdbedit > crashes as > > > > well (backtrace attached). I couldn't get a meaningful > backtrace from > > > > the samba crash however I attached it as well. > > > > > > > > Seems to me that the samba ipasam backend on ipa doesn't > like something > > > > in the host or the "domain computers" group object in ldap, > but I cannot > > > > see what could be the problem. Perhaps someone more familiar > with the > > > > ipasam code can spot it quickly. > > > > > Do I get it right that you really looking for > > > https://fedorahosted.org/sssd/ticket/1588 that was just released > > > upstream? > > > It would be cool if you can try using SSSD 1.12.1 under Samba > FS in > > > the use case you have and provide feedback on how it works for > you. > > > > > > AFAIU you install Samba FS and then use ipa-client to > configure SSSD > > > under it and it should work. > > > If not we probably should document it (but I do not see any > special > > > design page which leads me to the above expectation). > > > > Ok, I'll happily try sssd 1.12.1. > > > > Just a question, in smb.conf one should use "security = domain" or > > "security = ads"? > > 'ads' because we want to use Kerberos. But there some other > configuration options which needs attention, e.g. you have to create a > keytab for the cifs service and make it available to samba. I'll > try to > set up an small howto page listing the needed steps and come back > to you > early next week. > > bye, > Sumit > > > > > Best regards > > > > -- > > Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve > > > Links Global Services, C.A. http://www.lgs.com.ve > > Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve > > > ------------------------------------------------------------ > > "If I'd asked my customers what they wanted, they'd have said > > a faster horse" - Henry Ford > > > > > -- > > 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 > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Oct 29 12:28:38 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 29 Oct 2014 13:28:38 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: <544D5BB2.5090003@redhat.com> <544FCB4A.8030900@redhat.com> Message-ID: <5450DD76.50908@redhat.com> On 28.10.2014 18:42, Rob Verduijn wrote: > before the update its 4.5-1.fc20.x86_64.rpm from fedora 20 updates repo > after the update its 6.0-5.fc20.x86_64.rpm from copr repo > > Regards > Rob > > > 2014-10-28 17:58 GMT+01:00 Martin Basti : > >> On 28/10/14 16:10, Rob Verduijn wrote: >> >> Hello all, >> >> I've been digging into my problem of being unable to update from 3.3.5 >> to 4.1 >> >> First I add the repo from copr >> >> Then I used to update it by issueing 'yum update' which resulted in an >> update in which my local dns zone entries no longer resolved. >> >> So i tried the instructions mentioned on the site : >> yum update freeipa-server >> And this failed with a conflict in >> >> bind-32:9.9.4-18.fc20.1.pkcs11.x86_64 and >> bind-utils-32:9.9.4-15.P2.fc20.x86_64 >> >> I noticed the new bind comes from the copr repo and the old bind utils >> from fedora. >> >> So I first run 'yum update bind-utils -y' >> Then I ran yum update freeipa-server >> and see it fail with errors about softhsm >> >> I remembered reading about package errors with softhsm and installed the >> softhsm-devel package first. >> >> so revert back the freeipa kvm snapshot to 3.3.5 and try again >> yum update bind-utils -y ; yum install softhsm-devel -y ; yum update >> freeipa-server -y >> >> However when restarting named-pkcs11 I can see in the system log that it >> has 0 zones loaded >> >> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: managed-keys-zone: >> loaded serial 0 >> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone 0.in-addr.arpa/IN: >> loaded serial 0 >> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone localhost/IN: loaded >> serial 0 >> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >> 1.0.0.127.in-addr.arpa/IN: loaded serial 0 >> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >> localhost.localdomain/IN: loaded serial 0 >> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: >> loaded serial 0 >> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: all zones loaded >> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: running >> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: 0 zones from LDAP instance >> 'ipa' loaded (0 zones defined, 0 inactive, 0 failed to load) >> >> It claims 0 zones loaded but I can see my forward and reverse zones in >> ipa >> >> what could cause it not to load the zones that I defined in ipa ? This problem is usually caused by broken IPA upgrade which destroys ACIs in LDAP which allow access to DNS sub-tree. Please follow instructions on: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a5.NozonesfromLDAPareloaded ... and let us know if you are able to see idnsZone objects in LDAP or not. -- Petr^2 Spacek From unitaip at gmail.com Wed Oct 29 09:19:29 2014 From: unitaip at gmail.com (=?UTF-8?B?0KHQsNC/0LXQs9C40L0g0JLQsNC70LXRgNC40Lk=?=) Date: Wed, 29 Oct 2014 13:19:29 +0400 Subject: [Freeipa-users] Synchronization Agreements between FreeIPA and AD In-Reply-To: References: Message-ID: Yes Dmitri, ldapsearch works good: [root at ipa ~]# LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-TEST-CSBI-ITS-RU/ ldapsearch -xLLL -ZZ -h csbi-it-dc01.csbigroup.ru -D "cn=ipa-test,cn=users,dc=csbigroup,dc=ru" -w "ttttttttt" -s base -b "cn=users,dc=csbigroup,dc=ru" dn: cn=users,dc=csbigroup,dc=ru objectClass: top objectClass: container cn: Users description: Default container for upgraded user accounts distinguishedName: CN=Users,DC=csbigroup,DC=ru instanceType: 4 ... ... ? ?????????, ??????? ??????? 2014-10-23 16:19 GMT+04:00 ??????? ??????? : > Hello! > > I tryed to configure synchronization between FreeIPA and Windows AD 2012. > In the thirst time accounts from AD synchronization properly but next > schedule after 5 min is not work and in error log I see the following > errors: > > # tail -f /var/log/dirsrv/slapd-TEST-CSBI-ITS-RU/errors > [23/Oct/2014:15:51:34 +0300] NSMMReplicationPlugin - agmt="cn= > meTocsbi-it-dc01.csbigroup.ru" (csbi-it-dc01:389): Replica has no update > vector. It has never been initialized. > [23/Oct/2014:15:51:37 +0300] NSMMReplicationPlugin - agmt="cn= > meTocsbi-it-dc01.csbigroup.ru" (csbi-it-dc01:389): Replica has no update > vector. It has never been initialized. > [23/Oct/2014:15:51:40 +0300] NSMMReplicationPlugin - agmt="cn= > meTocsbi-it-dc01.csbigroup.ru" (csbi-it-dc01:389): Replica has no update > vector. It has never been initialized. > > Thirst synchronization out > > Added CA certificate /etc/openldap/certs/CSBIGROUP-CA.crt to certificate > database for ipa.test-csbi-its.ru > ipa: INFO: AD Suffix is: DC=csbigroup,DC=ru > The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=test-csbi-its,dc=ru > Windows PassSync entry exists, not resetting password > ipa: INFO: Added new sync agreement, waiting for it to become ready . . . > ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica > acquired successfully: Incremental update started: start: 0: end: 0 > ipa: INFO: Agreement is ready, starting replication . . . > Starting replication, please wait until this has completed. > Update in progress, 13 seconds elapsed > [ipa.test-csbi-its.ru] reports: Update failed! Status: [-1 Total update > abortedLDAP error: Can't contact LDAP server] > > Failed to start replication > > > > FreeIPA server version 3.3.3 > OS version Centos 7 > AD Domain 2012 > > Can you help me to resolve this problem? > > Best regards, Valeriy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Oct 29 13:04:22 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 29 Oct 2014 09:04:22 -0400 Subject: [Freeipa-users] 389 DS & admin consoles In-Reply-To: <21b324a15bf74a138988b304733b59aa@BLUPR08MB488.namprd08.prod.outlook.com> References: <8e50b6ebd9804b8ab9a7c47d43bd161c@BLUPR08MB488.namprd08.prod.outlook.com> <5450126A.2000004@redhat.com> <21b324a15bf74a138988b304733b59aa@BLUPR08MB488.namprd08.prod.outlook.com> Message-ID: <5450E5D6.7050704@redhat.com> Craig White wrote: > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Rich Megginson > *Sent:* Tuesday, October 28, 2014 3:02 PM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] 389 DS & admin consoles > > > > On 10/28/2014 02:45 PM, Craig White wrote: > > RHEL 6.5 ? new install > > ipa-server-3.0.0-42.el6.x86_64 > > 389-ds-base-1.2.11.15-47.el6.x86_64 > > > > Is it safe to install the 389 DS and admin console packages and use > them? > > > In general, no, it is not supported. IPA depends on a certain tree > structure, schema, etc. > > > > > I think it would be useful to use for things like editing ACI?s, etc. > > > It would be useful for a lot of lower level management and monitoring. > But unfortunately it is not supported. You might be able to install it > and make it work, but it might also mess up your IdM deployment. > ---- > > Not worth it then. I have been all over your Documentation page on > FreeIPA.org (http://www.freeipa.org/page/Documentation) > > > > I have not found any way to actually edit ACL?s (I believe the > terminology in 389 Server was ACI when I last used it some 8 or so years > ago). Is there any way to edit them? The permission plugin, ipa help permission rob From rob.verduijn at gmail.com Wed Oct 29 13:32:59 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Wed, 29 Oct 2014 14:32:59 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <5450DD76.50908@redhat.com> References: <544D5BB2.5090003@redhat.com> <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> Message-ID: Hello, I've checked and I see a lot of objects representing my dns entries. Still I get no answers if i try to resolve any of them :( Rob 2014-10-29 13:28 GMT+01:00 Petr Spacek : > On 28.10.2014 18:42, Rob Verduijn wrote: > >> before the update its 4.5-1.fc20.x86_64.rpm from fedora 20 updates repo >> after the update its 6.0-5.fc20.x86_64.rpm from copr repo >> >> Regards >> Rob >> >> >> 2014-10-28 17:58 GMT+01:00 Martin Basti : >> >> On 28/10/14 16:10, Rob Verduijn wrote: >>> >>> Hello all, >>> >>> I've been digging into my problem of being unable to update from 3.3.5 >>> to 4.1 >>> >>> First I add the repo from copr >>> >>> Then I used to update it by issueing 'yum update' which resulted in an >>> update in which my local dns zone entries no longer resolved. >>> >>> So i tried the instructions mentioned on the site : >>> yum update freeipa-server >>> And this failed with a conflict in >>> >>> bind-32:9.9.4-18.fc20.1.pkcs11.x86_64 and >>> bind-utils-32:9.9.4-15.P2.fc20.x86_64 >>> >>> I noticed the new bind comes from the copr repo and the old bind utils >>> from fedora. >>> >>> So I first run 'yum update bind-utils -y' >>> Then I ran yum update freeipa-server >>> and see it fail with errors about softhsm >>> >>> I remembered reading about package errors with softhsm and installed >>> the >>> softhsm-devel package first. >>> >>> so revert back the freeipa kvm snapshot to 3.3.5 and try again >>> yum update bind-utils -y ; yum install softhsm-devel -y ; yum update >>> freeipa-server -y >>> >>> However when restarting named-pkcs11 I can see in the system log that >>> it >>> has 0 zones loaded >>> >>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: managed-keys-zone: >>> loaded serial 0 >>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone 0.in-addr.arpa/IN: >>> loaded serial 0 >>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone localhost/IN: loaded >>> serial 0 >>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>> 1.0.0.127.in-addr.arpa/IN: loaded serial 0 >>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>> localhost.localdomain/IN: loaded serial 0 >>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. >>> 0.0.ip6.arpa/IN: >>> loaded serial 0 >>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: all zones loaded >>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: running >>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: 0 zones from LDAP >>> instance >>> 'ipa' loaded (0 zones defined, 0 inactive, 0 failed to load) >>> >>> It claims 0 zones loaded but I can see my forward and reverse zones in >>> ipa >>> >>> what could cause it not to load the zones that I defined in ipa ? >>> >> > This problem is usually caused by broken IPA upgrade which destroys ACIs > in LDAP which allow access to DNS sub-tree. > > Please follow instructions on: > > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a5. > NozonesfromLDAPareloaded > > ... and let us know if you are able to see idnsZone objects in LDAP or not. > > -- > Petr^2 Spacek > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Oct 29 13:50:49 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 29 Oct 2014 14:50:49 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: <544D5BB2.5090003@redhat.com> <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> Message-ID: <5450F0B9.9010907@redhat.com> On 29.10.2014 14:32, Rob Verduijn wrote: > I've checked and I see a lot of objects representing my dns entries. > Still I get no answers if i try to resolve any of them :( Are you running ldapsearch with *exactly* same credentials as you have in /etc/named.conf? Could you post dynamic-db section from your named.conf? Petr^2 Spacek > Rob > > 2014-10-29 13:28 GMT+01:00 Petr Spacek : > >> On 28.10.2014 18:42, Rob Verduijn wrote: >> >>> before the update its 4.5-1.fc20.x86_64.rpm from fedora 20 updates repo >>> after the update its 6.0-5.fc20.x86_64.rpm from copr repo >>> >>> Regards >>> Rob >>> >>> >>> 2014-10-28 17:58 GMT+01:00 Martin Basti : >>> >>> On 28/10/14 16:10, Rob Verduijn wrote: >>>> >>>> Hello all, >>>> >>>> I've been digging into my problem of being unable to update from 3.3.5 >>>> to 4.1 >>>> >>>> First I add the repo from copr >>>> >>>> Then I used to update it by issueing 'yum update' which resulted in an >>>> update in which my local dns zone entries no longer resolved. >>>> >>>> So i tried the instructions mentioned on the site : >>>> yum update freeipa-server >>>> And this failed with a conflict in >>>> >>>> bind-32:9.9.4-18.fc20.1.pkcs11.x86_64 and >>>> bind-utils-32:9.9.4-15.P2.fc20.x86_64 >>>> >>>> I noticed the new bind comes from the copr repo and the old bind utils >>>> from fedora. >>>> >>>> So I first run 'yum update bind-utils -y' >>>> Then I ran yum update freeipa-server >>>> and see it fail with errors about softhsm >>>> >>>> I remembered reading about package errors with softhsm and installed >>>> the >>>> softhsm-devel package first. >>>> >>>> so revert back the freeipa kvm snapshot to 3.3.5 and try again >>>> yum update bind-utils -y ; yum install softhsm-devel -y ; yum update >>>> freeipa-server -y >>>> >>>> However when restarting named-pkcs11 I can see in the system log that >>>> it >>>> has 0 zones loaded >>>> >>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: managed-keys-zone: >>>> loaded serial 0 >>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone 0.in-addr.arpa/IN: >>>> loaded serial 0 >>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone localhost/IN: loaded >>>> serial 0 >>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>>> 1.0.0.127.in-addr.arpa/IN: loaded serial 0 >>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>>> localhost.localdomain/IN: loaded serial 0 >>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>>> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. >>>> 0.0.ip6.arpa/IN: >>>> loaded serial 0 >>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: all zones loaded >>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: running >>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: 0 zones from LDAP >>>> instance >>>> 'ipa' loaded (0 zones defined, 0 inactive, 0 failed to load) >>>> >>>> It claims 0 zones loaded but I can see my forward and reverse zones in >>>> ipa >>>> >>>> what could cause it not to load the zones that I defined in ipa ? >>>> >>> >> This problem is usually caused by broken IPA upgrade which destroys ACIs >> in LDAP which allow access to DNS sub-tree. >> >> Please follow instructions on: >> >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a5. >> NozonesfromLDAPareloaded >> >> ... and let us know if you are able to see idnsZone objects in LDAP or not. -- Petr^2 Spacek From rmeggins at redhat.com Wed Oct 29 14:07:52 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 29 Oct 2014 08:07:52 -0600 Subject: [Freeipa-users] Synchronization Agreements between FreeIPA and AD In-Reply-To: References: Message-ID: <5450F4B8.7090405@redhat.com> On 10/29/2014 03:19 AM, ??????? ??????? wrote: > Yes Dmitri, ldapsearch works good: > > [root at ipa ~]# LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-TEST-CSBI-ITS-RU/ > ldapsearch -xLLL -ZZ -h csbi-it-dc01.csbigroup.ru > -D > "cn=ipa-test,cn=users,dc=csbigroup,dc=ru" -w "ttttttttt" -s base -b > "cn=users,dc=csbigroup,dc=ru" > dn: cn=users,dc=csbigroup,dc=ru > objectClass: top > objectClass: container > cn: Users > description: Default container for upgraded user accounts > distinguishedName: CN=Users,DC=csbigroup,DC=ru > instanceType: 4 > ... > ... > Ok. Now try to do a windows sync with the dirsrv replication error log level - http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting Then we can take a look at the detailed errors. > > ? ?????????, ??????? ??????? > > 2014-10-23 16:19 GMT+04:00 ??????? ??????? >: > > Hello! > > I tryed to configure synchronization between FreeIPA and Windows > AD 2012. In the thirst time accounts from AD synchronization > properly but next schedule after 5 min is not work and in error > log I see the following errors: > > # tail -f /var/log/dirsrv/slapd-TEST-CSBI-ITS-RU/errors > [23/Oct/2014:15:51:34 +0300] NSMMReplicationPlugin - > agmt="cn=meTocsbi-it-dc01.csbigroup.ru > " (csbi-it-dc01:389): > Replica has no update vector. It has never been initialized. > [23/Oct/2014:15:51:37 +0300] NSMMReplicationPlugin - > agmt="cn=meTocsbi-it-dc01.csbigroup.ru > " (csbi-it-dc01:389): > Replica has no update vector. It has never been initialized. > [23/Oct/2014:15:51:40 +0300] NSMMReplicationPlugin - > agmt="cn=meTocsbi-it-dc01.csbigroup.ru > " (csbi-it-dc01:389): > Replica has no update vector. It has never been initialized. > > Thirst synchronization out > > Added CA certificate /etc/openldap/certs/CSBIGROUP-CA.crt to > certificate database for ipa.test-csbi-its.ru > > ipa: INFO: AD Suffix is: DC=csbigroup,DC=ru > The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=test-csbi-its,dc=ru > Windows PassSync entry exists, not resetting password > ipa: INFO: Added new sync agreement, waiting for it to become > ready . . . > ipa: INFO: Replication Update in progress: FALSE: status: 0 > Replica acquired successfully: Incremental update started: start: > 0: end: 0 > ipa: INFO: Agreement is ready, starting replication . . . > Starting replication, please wait until this has completed. > Update in progress, 13 seconds elapsed > [ipa.test-csbi-its.ru ] reports: > Update failed! Status: [-1 Total update abortedLDAP error: Can't > contact LDAP server] > > Failed to start replication > > > > FreeIPA server version 3.3.3 > OS version Centos 7 > AD Domain 2012 > > Can you help me to resolve this problem? > > Best regards, Valeriy > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Wed Oct 29 14:46:50 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Wed, 29 Oct 2014 15:46:50 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <5450F0B9.9010907@redhat.com> References: <544D5BB2.5090003@redhat.com> <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> <5450F0B9.9010907@redhat.com> Message-ID: You're right duh I should read more carefully and not try to do to many things at once. when using the dns principal and keytab the entries are not found. How do i fix the access controll instructions ? I can revert back easely and try a different aproach for the upgrade if you know one (I really started to appreciate snapshots with this upgrade :-) Rob 2014-10-29 14:50 GMT+01:00 Petr Spacek : > On 29.10.2014 14:32, Rob Verduijn wrote: > >> I've checked and I see a lot of objects representing my dns entries. >> Still I get no answers if i try to resolve any of them :( >> > > Are you running ldapsearch with *exactly* same credentials as you have in > /etc/named.conf? > > Could you post dynamic-db section from your named.conf? > > Petr^2 Spacek > > > Rob >> >> 2014-10-29 13:28 GMT+01:00 Petr Spacek : >> >> On 28.10.2014 18:42, Rob Verduijn wrote: >>> >>> before the update its 4.5-1.fc20.x86_64.rpm from fedora 20 updates repo >>>> after the update its 6.0-5.fc20.x86_64.rpm from copr repo >>>> >>>> Regards >>>> Rob >>>> >>>> >>>> 2014-10-28 17:58 GMT+01:00 Martin Basti : >>>> >>>> On 28/10/14 16:10, Rob Verduijn wrote: >>>> >>>>> >>>>> Hello all, >>>>> >>>>> I've been digging into my problem of being unable to update from >>>>> 3.3.5 >>>>> to 4.1 >>>>> >>>>> First I add the repo from copr >>>>> >>>>> Then I used to update it by issueing 'yum update' which resulted >>>>> in an >>>>> update in which my local dns zone entries no longer resolved. >>>>> >>>>> So i tried the instructions mentioned on the site : >>>>> yum update freeipa-server >>>>> And this failed with a conflict in >>>>> >>>>> bind-32:9.9.4-18.fc20.1.pkcs11.x86_64 and >>>>> bind-utils-32:9.9.4-15.P2.fc20.x86_64 >>>>> >>>>> I noticed the new bind comes from the copr repo and the old bind >>>>> utils >>>>> from fedora. >>>>> >>>>> So I first run 'yum update bind-utils -y' >>>>> Then I ran yum update freeipa-server >>>>> and see it fail with errors about softhsm >>>>> >>>>> I remembered reading about package errors with softhsm and installed >>>>> the >>>>> softhsm-devel package first. >>>>> >>>>> so revert back the freeipa kvm snapshot to 3.3.5 and try again >>>>> yum update bind-utils -y ; yum install softhsm-devel -y ; yum update >>>>> freeipa-server -y >>>>> >>>>> However when restarting named-pkcs11 I can see in the system log >>>>> that >>>>> it >>>>> has 0 zones loaded >>>>> >>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: managed-keys-zone: >>>>> loaded serial 0 >>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone 0.in-addr.arpa/IN: >>>>> loaded serial 0 >>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone localhost/IN: >>>>> loaded >>>>> serial 0 >>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>>>> 1.0.0.127.in-addr.arpa/IN: loaded serial 0 >>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>>>> localhost.localdomain/IN: loaded serial 0 >>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>>>> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. >>>>> 0.0.ip6.arpa/IN: >>>>> loaded serial 0 >>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: all zones loaded >>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: running >>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: 0 zones from LDAP >>>>> instance >>>>> 'ipa' loaded (0 zones defined, 0 inactive, 0 failed to load) >>>>> >>>>> It claims 0 zones loaded but I can see my forward and reverse zones >>>>> in >>>>> ipa >>>>> >>>>> what could cause it not to load the zones that I defined in ipa ? >>>>> >>>>> >>>> This problem is usually caused by broken IPA upgrade which destroys >>> ACIs >>> in LDAP which allow access to DNS sub-tree. >>> >>> Please follow instructions on: >>> >>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a5. >>> NozonesfromLDAPareloaded >>> >>> ... and let us know if you are able to see idnsZone objects in LDAP or >>> not. >>> >> > > -- > Petr^2 Spacek > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Oct 29 14:56:53 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 29 Oct 2014 15:56:53 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: <544D5BB2.5090003@redhat.com> <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> <5450F0B9.9010907@redhat.com> Message-ID: <54510035.7010707@redhat.com> On 29/10/14 15:46, Rob Verduijn wrote: > You're right > duh I should read more carefully and not try to do to many things at > once. > > when using the dns principal and keytab the entries are not found. > > How do i fix the access controll instructions ? > I can revert back easely and try a different aproach for the upgrade > if you know one > (I really started to appreciate snapshots with this upgrade :-) > > Rob Please try first this: # ipa-ldap-updater /usr/share/ipa/memberof-task.ldif It should repair privileges. > > 2014-10-29 14:50 GMT+01:00 Petr Spacek >: > > On 29.10.2014 14:32, Rob Verduijn wrote: > > I've checked and I see a lot of objects representing my dns > entries. > Still I get no answers if i try to resolve any of them :( > > > Are you running ldapsearch with *exactly* same credentials as you > have in /etc/named.conf? > > Could you post dynamic-db section from your named.conf? > > Petr^2 Spacek > > > Rob > > 2014-10-29 13:28 GMT+01:00 Petr Spacek >: > > On 28.10.2014 18:42, Rob Verduijn wrote: > > before the update its 4.5-1.fc20.x86_64.rpm from > fedora 20 updates repo > after the update its 6.0-5.fc20.x86_64.rpm from copr repo > > Regards > Rob > > > 2014-10-28 17:58 GMT+01:00 Martin Basti > >: > > On 28/10/14 16:10, Rob Verduijn wrote: > > > Hello all, > > I've been digging into my problem of being > unable to update from 3.3.5 > to 4.1 > > First I add the repo from copr > > Then I used to update it by issueing 'yum > update' which resulted in an > update in which my local dns zone entries no > longer resolved. > > So i tried the instructions mentioned on the site : > yum update freeipa-server > And this failed with a conflict in > > bind-32:9.9.4-18.fc20.1.pkcs11.x86_64 and > bind-utils-32:9.9.4-15.P2.fc20.x86_64 > > I noticed the new bind comes from the copr repo > and the old bind utils > from fedora. > > So I first run 'yum update bind-utils -y' > Then I ran yum update freeipa-server > and see it fail with errors about softhsm > > I remembered reading about package errors with > softhsm and installed > the > softhsm-devel package first. > > so revert back the freeipa kvm snapshot to > 3.3.5 and try again > yum update bind-utils -y ; yum install > softhsm-devel -y ; yum update > freeipa-server -y > > However when restarting named-pkcs11 I can see > in the system log that > it > has 0 zones loaded > > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: > managed-keys-zone: > loaded serial 0 > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: > zone 0.in-addr.arpa/IN: > loaded serial 0 > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: > zone localhost/IN: loaded > serial 0 > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone > 1.0.0.127.in-addr.arpa/IN: loaded serial 0 > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone > localhost.localdomain/IN: loaded serial 0 > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. > 0.0.ip6.arpa/IN: > loaded serial 0 > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: > all zones loaded > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: > running > Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: 0 > zones from LDAP > instance > 'ipa' loaded (0 zones defined, 0 inactive, 0 > failed to load) > > It claims 0 zones loaded but I can see my > forward and reverse zones in > ipa > > what could cause it not to load the zones that > I defined in ipa ? > > > This problem is usually caused by broken IPA upgrade which > destroys ACIs > in LDAP which allow access to DNS sub-tree. > > Please follow instructions on: > > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a5. > NozonesfromLDAPareloaded > > ... and let us know if you are able to see idnsZone > objects in LDAP or not. > > > > -- > Petr^2 Spacek > > > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Oct 29 15:13:40 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 29 Oct 2014 16:13:40 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <54510035.7010707@redhat.com> References: <544D5BB2.5090003@redhat.com> <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> <5450F0B9.9010907@redhat.com> <54510035.7010707@redhat.com> Message-ID: <54510424.8080004@redhat.com> On 29/10/14 15:56, Martin Basti wrote: > On 29/10/14 15:46, Rob Verduijn wrote: >> You're right >> duh I should read more carefully and not try to do to many things at >> once. >> >> when using the dns principal and keytab the entries are not found. >> >> How do i fix the access controll instructions ? >> I can revert back easely and try a different aproach for the upgrade >> if you know one >> (I really started to appreciate snapshots with this upgrade :-) >> >> Rob > > Please try first this: > > # ipa-ldap-updater /usr/share/ipa/memberof-task.ldif > > It should repair privileges. Sorry I wrote you wrong file # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update >> >> 2014-10-29 14:50 GMT+01:00 Petr Spacek > >: >> >> On 29.10.2014 14:32, Rob Verduijn wrote: >> >> I've checked and I see a lot of objects representing my dns >> entries. >> Still I get no answers if i try to resolve any of them :( >> >> >> Are you running ldapsearch with *exactly* same credentials as you >> have in /etc/named.conf? >> >> Could you post dynamic-db section from your named.conf? >> >> Petr^2 Spacek >> >> >> Rob >> >> 2014-10-29 13:28 GMT+01:00 Petr Spacek > >: >> >> On 28.10.2014 18:42, Rob Verduijn wrote: >> >> before the update its 4.5-1.fc20.x86_64.rpm from >> fedora 20 updates repo >> after the update its 6.0-5.fc20.x86_64.rpm from copr repo >> >> Regards >> Rob >> >> >> 2014-10-28 17:58 GMT+01:00 Martin Basti >> >: >> >> On 28/10/14 16:10, Rob Verduijn wrote: >> >> >> Hello all, >> >> I've been digging into my problem of being >> unable to update from 3.3.5 >> to 4.1 >> >> First I add the repo from copr >> >> Then I used to update it by issueing 'yum >> update' which resulted in an >> update in which my local dns zone entries no >> longer resolved. >> >> So i tried the instructions mentioned on the >> site : >> yum update freeipa-server >> And this failed with a conflict in >> >> bind-32:9.9.4-18.fc20.1.pkcs11.x86_64 and >> bind-utils-32:9.9.4-15.P2.fc20.x86_64 >> >> I noticed the new bind comes from the copr >> repo and the old bind utils >> from fedora. >> >> So I first run 'yum update bind-utils -y' >> Then I ran yum update freeipa-server >> and see it fail with errors about softhsm >> >> I remembered reading about package errors with >> softhsm and installed >> the >> softhsm-devel package first. >> >> so revert back the freeipa kvm snapshot to >> 3.3.5 and try again >> yum update bind-utils -y ; yum install >> softhsm-devel -y ; yum update >> freeipa-server -y >> >> However when restarting named-pkcs11 I can see >> in the system log that >> it >> has 0 zones loaded >> >> Oct 28 15:28:30 freeipa.x.x >> named-pkcs11[3029]: managed-keys-zone: >> loaded serial 0 >> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: >> zone 0.in-addr.arpa/IN: >> loaded serial 0 >> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: >> zone localhost/IN: loaded >> serial 0 >> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >> 1.0.0.127.in-addr.arpa/IN: loaded serial 0 >> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >> localhost.localdomain/IN: loaded serial 0 >> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. >> 0.0.ip6.arpa/IN: >> loaded serial 0 >> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: >> all zones loaded >> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: >> running >> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: 0 >> zones from LDAP >> instance >> 'ipa' loaded (0 zones defined, 0 inactive, 0 >> failed to load) >> >> It claims 0 zones loaded but I can see my >> forward and reverse zones in >> ipa >> >> what could cause it not to load the zones that >> I defined in ipa ? >> >> >> This problem is usually caused by broken IPA upgrade >> which destroys ACIs >> in LDAP which allow access to DNS sub-tree. >> >> Please follow instructions on: >> >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a5. >> NozonesfromLDAPareloaded >> >> ... and let us know if you are able to see idnsZone >> objects in LDAP or not. >> >> >> >> -- >> Petr^2 Spacek >> >> >> >> > > > -- > Martin Basti > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Oct 29 15:20:01 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 29 Oct 2014 16:20:01 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <54510424.8080004@redhat.com> References: <544D5BB2.5090003@redhat.com> <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> <5450F0B9.9010907@redhat.com> <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> Message-ID: <545105A1.9030208@redhat.com> On 29/10/14 16:13, Martin Basti wrote: > On 29/10/14 15:56, Martin Basti wrote: >> On 29/10/14 15:46, Rob Verduijn wrote: >>> You're right >>> duh I should read more carefully and not try to do to many things at >>> once. >>> >>> when using the dns principal and keytab the entries are not found. >>> >>> How do i fix the access controll instructions ? >>> I can revert back easely and try a different aproach for the upgrade >>> if you know one >>> (I really started to appreciate snapshots with this upgrade :-) >>> >>> Rob >> >> Please try first this: >> >> # ipa-ldap-updater /usr/share/ipa/memberof-task.ldif >> >> It should repair privileges. > Sorry I wrote you wrong file > # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update If doesn't help, just run ipa-ldap-updater without parameters >>> >>> 2014-10-29 14:50 GMT+01:00 Petr Spacek >> >: >>> >>> On 29.10.2014 14:32, Rob Verduijn wrote: >>> >>> I've checked and I see a lot of objects representing my dns >>> entries. >>> Still I get no answers if i try to resolve any of them :( >>> >>> >>> Are you running ldapsearch with *exactly* same credentials as >>> you have in /etc/named.conf? >>> >>> Could you post dynamic-db section from your named.conf? >>> >>> Petr^2 Spacek >>> >>> >>> Rob >>> >>> 2014-10-29 13:28 GMT+01:00 Petr Spacek >> >: >>> >>> On 28.10.2014 18:42, Rob Verduijn wrote: >>> >>> before the update its 4.5-1.fc20.x86_64.rpm from >>> fedora 20 updates repo >>> after the update its 6.0-5.fc20.x86_64.rpm from copr >>> repo >>> >>> Regards >>> Rob >>> >>> >>> 2014-10-28 17:58 GMT+01:00 Martin Basti >>> >: >>> >>> On 28/10/14 16:10, Rob Verduijn wrote: >>> >>> >>> Hello all, >>> >>> I've been digging into my problem of being >>> unable to update from 3.3.5 >>> to 4.1 >>> >>> First I add the repo from copr >>> >>> Then I used to update it by issueing 'yum >>> update' which resulted in an >>> update in which my local dns zone entries no >>> longer resolved. >>> >>> So i tried the instructions mentioned on the >>> site : >>> yum update freeipa-server >>> And this failed with a conflict in >>> >>> bind-32:9.9.4-18.fc20.1.pkcs11.x86_64 and >>> bind-utils-32:9.9.4-15.P2.fc20.x86_64 >>> >>> I noticed the new bind comes from the copr >>> repo and the old bind utils >>> from fedora. >>> >>> So I first run 'yum update bind-utils -y' >>> Then I ran yum update freeipa-server >>> and see it fail with errors about softhsm >>> >>> I remembered reading about package errors >>> with softhsm and installed >>> the >>> softhsm-devel package first. >>> >>> so revert back the freeipa kvm snapshot to >>> 3.3.5 and try again >>> yum update bind-utils -y ; yum install >>> softhsm-devel -y ; yum update >>> freeipa-server -y >>> >>> However when restarting named-pkcs11 I can >>> see in the system log that >>> it >>> has 0 zones loaded >>> >>> Oct 28 15:28:30 freeipa.x.x >>> named-pkcs11[3029]: managed-keys-zone: >>> loaded serial 0 >>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: >>> zone 0.in-addr.arpa/IN: >>> loaded serial 0 >>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: >>> zone localhost/IN: loaded >>> serial 0 >>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>> 1.0.0.127.in-addr.arpa/IN: loaded serial 0 >>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>> localhost.localdomain/IN: loaded serial 0 >>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. >>> 0.0.ip6.arpa/IN: >>> loaded serial 0 >>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: >>> all zones loaded >>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: >>> running >>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: >>> 0 zones from LDAP >>> instance >>> 'ipa' loaded (0 zones defined, 0 inactive, 0 >>> failed to load) >>> >>> It claims 0 zones loaded but I can see my >>> forward and reverse zones in >>> ipa >>> >>> what could cause it not to load the zones >>> that I defined in ipa ? >>> >>> >>> This problem is usually caused by broken IPA upgrade >>> which destroys ACIs >>> in LDAP which allow access to DNS sub-tree. >>> >>> Please follow instructions on: >>> >>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a5. >>> NozonesfromLDAPareloaded >>> >>> ... and let us know if you are able to see idnsZone >>> objects in LDAP or not. >>> >>> >>> >>> -- >>> Petr^2 Spacek >>> >>> >>> >>> >> >> >> -- >> Martin Basti >> >> > > > -- > Martin Basti > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Wed Oct 29 15:46:05 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Wed, 29 Oct 2014 16:46:05 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <54510424.8080004@redhat.com> References: <544D5BB2.5090003@redhat.com> <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> <5450F0B9.9010907@redhat.com> <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> Message-ID: Hello, # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update fixes the problem. I can resolv my internal dns zones again :-) Many thanx. Since this problem happened every time I tried to update the freeipa server. I could re-run the update with some debug options if you like so you can pinpoint what goes wrong with the update script if you like. Rob 2014-10-29 16:13 GMT+01:00 Martin Basti : > On 29/10/14 15:56, Martin Basti wrote: > > On 29/10/14 15:46, Rob Verduijn wrote: > > You're right > duh I should read more carefully and not try to do to many things at once. > > when using the dns principal and keytab the entries are not found. > > How do i fix the access controll instructions ? > I can revert back easely and try a different aproach for the upgrade if > you know one > (I really started to appreciate snapshots with this upgrade :-) > > Rob > > > Please try first this: > > # ipa-ldap-updater /usr/share/ipa/memberof-task.ldif > > It should repair privileges. > > Sorry I wrote you wrong file > # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update > > > 2014-10-29 14:50 GMT+01:00 Petr Spacek : > >> On 29.10.2014 14:32, Rob Verduijn wrote: >> >>> I've checked and I see a lot of objects representing my dns entries. >>> Still I get no answers if i try to resolve any of them :( >>> >> >> Are you running ldapsearch with *exactly* same credentials as you have >> in /etc/named.conf? >> >> Could you post dynamic-db section from your named.conf? >> >> Petr^2 Spacek >> >> >> Rob >>> >>> 2014-10-29 13:28 GMT+01:00 Petr Spacek : >>> >>> On 28.10.2014 18:42, Rob Verduijn wrote: >>>> >>>> before the update its 4.5-1.fc20.x86_64.rpm from fedora 20 updates repo >>>>> after the update its 6.0-5.fc20.x86_64.rpm from copr repo >>>>> >>>>> Regards >>>>> Rob >>>>> >>>>> >>>>> 2014-10-28 17:58 GMT+01:00 Martin Basti : >>>>> >>>>> On 28/10/14 16:10, Rob Verduijn wrote: >>>>> >>>>>> >>>>>> Hello all, >>>>>> >>>>>> I've been digging into my problem of being unable to update from >>>>>> 3.3.5 >>>>>> to 4.1 >>>>>> >>>>>> First I add the repo from copr >>>>>> >>>>>> Then I used to update it by issueing 'yum update' which resulted >>>>>> in an >>>>>> update in which my local dns zone entries no longer resolved. >>>>>> >>>>>> So i tried the instructions mentioned on the site : >>>>>> yum update freeipa-server >>>>>> And this failed with a conflict in >>>>>> >>>>>> bind-32:9.9.4-18.fc20.1.pkcs11.x86_64 and >>>>>> bind-utils-32:9.9.4-15.P2.fc20.x86_64 >>>>>> >>>>>> I noticed the new bind comes from the copr repo and the old bind >>>>>> utils >>>>>> from fedora. >>>>>> >>>>>> So I first run 'yum update bind-utils -y' >>>>>> Then I ran yum update freeipa-server >>>>>> and see it fail with errors about softhsm >>>>>> >>>>>> I remembered reading about package errors with softhsm and >>>>>> installed >>>>>> the >>>>>> softhsm-devel package first. >>>>>> >>>>>> so revert back the freeipa kvm snapshot to 3.3.5 and try again >>>>>> yum update bind-utils -y ; yum install softhsm-devel -y ; yum update >>>>>> freeipa-server -y >>>>>> >>>>>> However when restarting named-pkcs11 I can see in the system log >>>>>> that >>>>>> it >>>>>> has 0 zones loaded >>>>>> >>>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: managed-keys-zone: >>>>>> loaded serial 0 >>>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>>>>> 0.in-addr.arpa/IN: >>>>>> loaded serial 0 >>>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone localhost/IN: >>>>>> loaded >>>>>> serial 0 >>>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>>>>> 1.0.0.127.in-addr.arpa/IN: loaded serial 0 >>>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>>>>> localhost.localdomain/IN: loaded serial 0 >>>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>>>>> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. >>>>>> 0.0.ip6.arpa/IN: >>>>>> loaded serial 0 >>>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: all zones loaded >>>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: running >>>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: 0 zones from LDAP >>>>>> instance >>>>>> 'ipa' loaded (0 zones defined, 0 inactive, 0 failed to load) >>>>>> >>>>>> It claims 0 zones loaded but I can see my forward and reverse >>>>>> zones in >>>>>> ipa >>>>>> >>>>>> what could cause it not to load the zones that I defined in ipa ? >>>>>> >>>>>> >>>>> This problem is usually caused by broken IPA upgrade which destroys >>>> ACIs >>>> in LDAP which allow access to DNS sub-tree. >>>> >>>> Please follow instructions on: >>>> >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a5 >>>> . >>>> NozonesfromLDAPareloaded >>>> >>>> ... and let us know if you are able to see idnsZone objects in LDAP or >>>> not. >>>> >>> >> >> -- >> Petr^2 Spacek >> > > > > > > -- > Martin Basti > > > > > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Oct 29 15:55:12 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 29 Oct 2014 16:55:12 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: <544D5BB2.5090003@redhat.com> <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> <5450F0B9.9010907@redhat.com> <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> Message-ID: <54510DE0.4090105@redhat.com> On 29/10/14 16:46, Rob Verduijn wrote: > Hello, > > # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update > fixes the problem. > > I can resolv my internal dns zones again :-) > > Many thanx. > > Since this problem happened every time I tried to update the freeipa > server. > I could re-run the update with some debug options if you like so you > can pinpoint what goes wrong with the update script if you like. > > Rob We know where the problem is, and we though we fixed it, but obviously some parts of problem persist. Thank you for your patience :-) > > 2014-10-29 16:13 GMT+01:00 Martin Basti >: > > On 29/10/14 15:56, Martin Basti wrote: >> On 29/10/14 15:46, Rob Verduijn wrote: >>> You're right >>> duh I should read more carefully and not try to do to many >>> things at once. >>> >>> when using the dns principal and keytab the entries are not found. >>> >>> How do i fix the access controll instructions ? >>> I can revert back easely and try a different aproach for the >>> upgrade if you know one >>> (I really started to appreciate snapshots with this upgrade :-) >>> >>> Rob >> >> Please try first this: >> >> # ipa-ldap-updater /usr/share/ipa/memberof-task.ldif >> >> It should repair privileges. > Sorry I wrote you wrong file > # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update > >>> >>> 2014-10-29 14:50 GMT+01:00 Petr Spacek >> >: >>> >>> On 29.10.2014 14:32, Rob Verduijn wrote: >>> >>> I've checked and I see a lot of objects representing my >>> dns entries. >>> Still I get no answers if i try to resolve any of them :( >>> >>> >>> Are you running ldapsearch with *exactly* same credentials >>> as you have in /etc/named.conf? >>> >>> Could you post dynamic-db section from your named.conf? >>> >>> Petr^2 Spacek >>> >>> >>> Rob >>> >>> 2014-10-29 13:28 GMT+01:00 Petr Spacek >>> >: >>> >>> On 28.10.2014 18:42, Rob Verduijn wrote: >>> >>> before the update its 4.5-1.fc20.x86_64.rpm from >>> fedora 20 updates repo >>> after the update its 6.0-5.fc20.x86_64.rpm from >>> copr repo >>> >>> Regards >>> Rob >>> >>> >>> 2014-10-28 17:58 GMT+01:00 Martin Basti >>> >: >>> >>> On 28/10/14 16:10, Rob Verduijn wrote: >>> >>> >>> Hello all, >>> >>> I've been digging into my problem of >>> being unable to update from 3.3.5 >>> to 4.1 >>> >>> First I add the repo from copr >>> >>> Then I used to update it by issueing >>> 'yum update' which resulted in an >>> update in which my local dns zone entries no >>> longer resolved. >>> >>> So i tried the instructions mentioned on >>> the site : >>> yum update freeipa-server >>> And this failed with a conflict in >>> >>> bind-32:9.9.4-18.fc20.1.pkcs11.x86_64 and >>> bind-utils-32:9.9.4-15.P2.fc20.x86_64 >>> >>> I noticed the new bind comes from the >>> copr repo and the old bind utils >>> from fedora. >>> >>> So I first run 'yum update bind-utils -y' >>> Then I ran yum update freeipa-server >>> and see it fail with errors about softhsm >>> >>> I remembered reading about package errors >>> with softhsm and installed >>> the >>> softhsm-devel package first. >>> >>> so revert back the freeipa kvm snapshot >>> to 3.3.5 and try again >>> yum update bind-utils -y ; yum install >>> softhsm-devel -y ; yum update >>> freeipa-server -y >>> >>> However when restarting named-pkcs11 I >>> can see in the system log that >>> it >>> has 0 zones loaded >>> >>> Oct 28 15:28:30 freeipa.x.x >>> named-pkcs11[3029]: managed-keys-zone: >>> loaded serial 0 >>> Oct 28 15:28:30 freeipa.x.x >>> named-pkcs11[3029]: zone 0.in-addr.arpa/IN: >>> loaded serial 0 >>> Oct 28 15:28:30 freeipa.x.x >>> named-pkcs11[3029]: zone localhost/IN: loaded >>> serial 0 >>> Oct 28 15:28:30 freeipa.x.x >>> named-pkcs11[3029]: zone >>> 1.0.0.127.in-addr.arpa/IN: loaded serial 0 >>> Oct 28 15:28:30 freeipa.x.x >>> named-pkcs11[3029]: zone >>> localhost.localdomain/IN: loaded serial 0 >>> Oct 28 15:28:30 freeipa.x.x >>> named-pkcs11[3029]: zone >>> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. >>> 0.0.ip6.arpa/IN: >>> loaded serial 0 >>> Oct 28 15:28:30 freeipa.x.x >>> named-pkcs11[3029]: all zones loaded >>> Oct 28 15:28:30 freeipa.x.x >>> named-pkcs11[3029]: running >>> Oct 28 15:28:30 freeipa.x.x >>> named-pkcs11[3029]: 0 zones from LDAP >>> instance >>> 'ipa' loaded (0 zones defined, 0 inactive, 0 >>> failed to load) >>> >>> It claims 0 zones loaded but I can see my >>> forward and reverse zones in >>> ipa >>> >>> what could cause it not to load the zones >>> that I defined in ipa ? >>> >>> >>> This problem is usually caused by broken IPA upgrade >>> which destroys ACIs >>> in LDAP which allow access to DNS sub-tree. >>> >>> Please follow instructions on: >>> >>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a5. >>> NozonesfromLDAPareloaded >>> >>> ... and let us know if you are able to see idnsZone >>> objects in LDAP or not. >>> >>> >>> >>> -- >>> Petr^2 Spacek >>> >>> >>> >>> >> >> >> -- >> Martin Basti >> >> > > > -- > Martin Basti > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Wed Oct 29 15:58:39 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Wed, 29 Oct 2014 16:58:39 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <54510DE0.4090105@redhat.com> References: <544D5BB2.5090003@redhat.com> <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> <5450F0B9.9010907@redhat.com> <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <54510DE0.4090105@redhat.com> Message-ID: Hello again, I jumped to early. # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update didn't work but "ipa-ldap-updater " fixes the problem for me. Rob 2014-10-29 16:55 GMT+01:00 Martin Basti : > On 29/10/14 16:46, Rob Verduijn wrote: > > Hello, > > # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update > fixes the problem. > > I can resolv my internal dns zones again :-) > > Many thanx. > > Since this problem happened every time I tried to update the freeipa > server. > I could re-run the update with some debug options if you like so you can > pinpoint what goes wrong with the update script if you like. > > Rob > > > We know where the problem is, and we though we fixed it, but obviously > some parts of problem persist. > > Thank you for your patience :-) > > > 2014-10-29 16:13 GMT+01:00 Martin Basti : > >> On 29/10/14 15:56, Martin Basti wrote: >> >> On 29/10/14 15:46, Rob Verduijn wrote: >> >> You're right >> duh I should read more carefully and not try to do to many things at >> once. >> >> when using the dns principal and keytab the entries are not found. >> >> How do i fix the access controll instructions ? >> I can revert back easely and try a different aproach for the upgrade if >> you know one >> (I really started to appreciate snapshots with this upgrade :-) >> >> Rob >> >> >> Please try first this: >> >> # ipa-ldap-updater /usr/share/ipa/memberof-task.ldif >> >> It should repair privileges. >> >> Sorry I wrote you wrong file >> # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update >> >> >> 2014-10-29 14:50 GMT+01:00 Petr Spacek : >> >>> On 29.10.2014 14:32, Rob Verduijn wrote: >>> >>>> I've checked and I see a lot of objects representing my dns entries. >>>> Still I get no answers if i try to resolve any of them :( >>>> >>> >>> Are you running ldapsearch with *exactly* same credentials as you have >>> in /etc/named.conf? >>> >>> Could you post dynamic-db section from your named.conf? >>> >>> Petr^2 Spacek >>> >>> >>> Rob >>>> >>>> 2014-10-29 13:28 GMT+01:00 Petr Spacek : >>>> >>>> On 28.10.2014 18:42, Rob Verduijn wrote: >>>>> >>>>> before the update its 4.5-1.fc20.x86_64.rpm from fedora 20 updates >>>>>> repo >>>>>> after the update its 6.0-5.fc20.x86_64.rpm from copr repo >>>>>> >>>>>> Regards >>>>>> Rob >>>>>> >>>>>> >>>>>> 2014-10-28 17:58 GMT+01:00 Martin Basti : >>>>>> >>>>>> On 28/10/14 16:10, Rob Verduijn wrote: >>>>>> >>>>>>> >>>>>>> Hello all, >>>>>>> >>>>>>> I've been digging into my problem of being unable to update from >>>>>>> 3.3.5 >>>>>>> to 4.1 >>>>>>> >>>>>>> First I add the repo from copr >>>>>>> >>>>>>> Then I used to update it by issueing 'yum update' which resulted >>>>>>> in an >>>>>>> update in which my local dns zone entries no longer resolved. >>>>>>> >>>>>>> So i tried the instructions mentioned on the site : >>>>>>> yum update freeipa-server >>>>>>> And this failed with a conflict in >>>>>>> >>>>>>> bind-32:9.9.4-18.fc20.1.pkcs11.x86_64 and >>>>>>> bind-utils-32:9.9.4-15.P2.fc20.x86_64 >>>>>>> >>>>>>> I noticed the new bind comes from the copr repo and the old bind >>>>>>> utils >>>>>>> from fedora. >>>>>>> >>>>>>> So I first run 'yum update bind-utils -y' >>>>>>> Then I ran yum update freeipa-server >>>>>>> and see it fail with errors about softhsm >>>>>>> >>>>>>> I remembered reading about package errors with softhsm and >>>>>>> installed >>>>>>> the >>>>>>> softhsm-devel package first. >>>>>>> >>>>>>> so revert back the freeipa kvm snapshot to 3.3.5 and try again >>>>>>> yum update bind-utils -y ; yum install softhsm-devel -y ; yum update >>>>>>> freeipa-server -y >>>>>>> >>>>>>> However when restarting named-pkcs11 I can see in the system log >>>>>>> that >>>>>>> it >>>>>>> has 0 zones loaded >>>>>>> >>>>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: managed-keys-zone: >>>>>>> loaded serial 0 >>>>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>>>>>> 0.in-addr.arpa/IN: >>>>>>> loaded serial 0 >>>>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone localhost/IN: >>>>>>> loaded >>>>>>> serial 0 >>>>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>>>>>> 1.0.0.127.in-addr.arpa/IN: loaded serial 0 >>>>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>>>>>> localhost.localdomain/IN: loaded serial 0 >>>>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: zone >>>>>>> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. >>>>>>> 0.0.ip6.arpa/IN: >>>>>>> loaded serial 0 >>>>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: all zones loaded >>>>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: running >>>>>>> Oct 28 15:28:30 freeipa.x.x named-pkcs11[3029]: 0 zones from LDAP >>>>>>> instance >>>>>>> 'ipa' loaded (0 zones defined, 0 inactive, 0 failed to load) >>>>>>> >>>>>>> It claims 0 zones loaded but I can see my forward and reverse >>>>>>> zones in >>>>>>> ipa >>>>>>> >>>>>>> what could cause it not to load the zones that I defined in ipa ? >>>>>>> >>>>>>> >>>>>> This problem is usually caused by broken IPA upgrade which destroys >>>>> ACIs >>>>> in LDAP which allow access to DNS sub-tree. >>>>> >>>>> Please follow instructions on: >>>>> >>>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a5 >>>>> . >>>>> NozonesfromLDAPareloaded >>>>> >>>>> ... and let us know if you are able to see idnsZone objects in LDAP or >>>>> not. >>>>> >>>> >>> >>> -- >>> Petr^2 Spacek >>> >> >> >> >> >> >> -- >> Martin Basti >> >> >> >> >> >> -- >> Martin Basti >> >> > > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From herlo1 at gmail.com Wed Oct 29 16:37:18 2014 From: herlo1 at gmail.com (Clint Savage) Date: Wed, 29 Oct 2014 10:37:18 -0600 Subject: [Freeipa-users] FreeIPA 3.3.3-28 Integration with Samba 4.1.1-37 Problems In-Reply-To: References: Message-ID: Interestingly enough, I have almost the same setup here. I did an ipa-server install, then did ipa-adtrust-install. Afterward, I went through and grabbed the configs with 'net conf list' and modified it to use my shares. This one is just my testing, but the production one works perfectly! How did you import your users? I did mine my setting up an openldap and importing an ldif with the proper DN values. Then ran ipa migrate-ds. In some cases, certain data didn't migrate, so I added that with ldapmodify as necessary. Here's what my samba config looks like with 'net conf list'. It seems it's pretty much the same as yours. Except for mine working, of course. [global] workgroup = EXAMPLE realm = EXAMPLE.COM passdb backend = ipasam:ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket dedicated keytab file = FILE:/etc/samba/samba.keytab kerberos method = dedicated keytab log file = /var/log/samba/log.%m max log size = 100000 disable spoolss = Yes domain logons = Yes domain master = Yes ldap group suffix = cn=groups,cn=accounts ldap machine suffix = cn=computers,cn=accounts ldap suffix = dc=example,dc=com ldap ssl = no ldap user suffix = cn=users,cn=accounts registry shares = Yes create krb5 conf = No rpc_daemon:lsasd = fork rpc_daemon:epmd = fork rpc_server:tcpip = yes rpc_server:netlogon = external rpc_server:samr = external rpc_server:lsasd = external rpc_server:lsass = external rpc_server:lsarpc = external rpc_server:epmapper = external ldapsam:trusted = yes idmap config * : backend = tdb [homes] browseable = no comment = Home Directories read only = no [share1] browseable = yes read only = no path = /srv/samba/share1 comment = Temporary Public Share valid users = @testgroup Cheers, herlo On Tue, Oct 28, 2014 at 12:36 PM, Jason Smith wrote: > A little history. We migrated from an OpenLDAP system to FreeIPA. The > IPA version is listed above. I have samba installed and integrated > directly on the FreeIPA box. > The problem we're having are users who were migrated can no longer can see > the samba shares. We are connecting to these shares through Mac OSX. When > accessing the share with smbclient -L mydomain at domain.com I get the > response *session setup failed: NT_STATUS_CONNECTION_DISCONNECTED. *This > is the response I get when connected to the FreeIPA/Samba box. > > Users were able to access these shares, then overnight, they weren't. No > changes were made to the samba config or the FreeIPA. *Any new user > created through FreeIPA can see and browse any share they have access to.* > > If there's any other information needed, please let me know. Thank you!!! > > Below are a couple configs I have set: > > *Samba global settings* > [global] > workgroup = ATTASK > netbios name = IPA01 > realm = ATTASK.CORP > passdb backend = ipasam:ldapi://%2fvar%2frun%2fslapd-ATTASK-CORP.socket > kerberos method = dedicated keytab > dedicated keytab file = FILE:/etc/samba/samba.keytab > log file = /var/log/samba/log.%m > max log size = 100000 > disable spoolss = Yes > domain logons = Yes > domain master = Yes > ldap group suffix = cn=groups,cn=accounts > ldap machine suffix = cn=computers,cn=accounts > ldap suffix = dc=attask,dc=corp > ldap ssl = no > ldap user suffix = cn=users,cn=accounts > registry shares = Yes > create krb5 conf = No > rpc_daemon:lsasd = fork > rpc_daemon:epmd = fork > rpc_server:tcpip = yes > rpc_server:netlogon = external > rpc_server:samr = external > rpc_server:lsasd = external > rpc_server:lsass = external > rpc_server:lsarpc = external > rpc_server:epmapper = external > ldapsam:trusted = yes > idmap config * : backend = tdb > > *User Not Working:* > dn: uid=test,cn=users,cn=accounts,dc=attask,dc=corp > uid: test > sn: test > cn: test > mail: test at test.com > nsaccountlock: False > has_password: True > has_keytab: True > dialupAccess: yes > displayName: test test > emailPassword: YTdiMDE4Y2Q1N2QwOWJjZTg0OWMxZThjNTgyNTFmNTlw== > gidNumber: 107001365 > givenName: test > homeDirectory: /home/test > ipaNTSecurityIdentifier: S-1-5-21-1103557689-1565082434-1264062975-2355 > ipaUniqueID: 607de82c-562b-11e4-b263-5254003b1df7 > krbExtraData: AAJwtE9Ucm9vdC9hZG1pbkdvvBBVFR09SUAA= > krbLastFailedAuth: 20141028151647Z > krbLastPwdChange: 20141028152120Z > krbLastSuccessfulAuth: 20141028152012Z > krbLoginFailedCount: 0 > krbPasswordExpiration: 20150122152120Z > krbPrincipalName: test at ATTASK.CORP > krbTicketFlags: 128 > loginShell: /sbin/nologin > memberof: cn=ipausers,cn=groups,cn=accounts,dc=attask,dc=corp > memberof: cn=attask,cn=groups,cn=accounts,dc=attask,dc=corp > memberof: cn=clientservices,cn=groups,cn=accounts,dc=attask,dc=corp > objectClass: krbticketpolicyaux > objectClass: ipaobject > objectClass: organizationalperson > objectClass: top > objectClass: customPersonAttributes > objectClass: ipasshuser > objectClass: inetorgperson > objectClass: sambaSamAccount > objectClass: person > objectClass: inetuser > objectClass: krbprincipalaux > objectClass: radiusProfile > objectClass: posixaccount > objectClass: ipaSshGroupOfPubKeys > objectClass: ipantuserattrs > radiusTunnelMediumType: IEEE-802 > radiusTunnelPrivateGroupId: 1424 > radiusTunnelType: VLAN > sambaPwdLastSet: 0 > sambaSID: S-1-5-21-1103557689-1565082434-1264062975-5622 > uidNumber: 107001355 > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Oct 29 17:14:06 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 29 Oct 2014 18:14:06 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: <544D5BB2.5090003@redhat.com> <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> <5450F0B9.9010907@redhat.com> <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> Message-ID: <5451205E.8020408@redhat.com> On 29.10.2014 16:46, Rob Verduijn wrote: > Hello, > > # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update > fixes the problem. > > I can resolv my internal dns zones again:-) > > Many thanx. > > Since this problem happened every time I tried to update the freeipa server. > I could re-run the update with some debug options if you like so you can > pinpoint what goes wrong with the update script if you like. I have re-build some packages in mkosek's CORP so now you should not see encounter dependency problems. Simple 'yum upgrade' should give you all the required packages. We are looking at other problems in upgrade process right now so there is not much to test except package dependencies. -- Petr^2 Spacek From CWhite at skytouchtechnology.com Wed Oct 29 18:40:37 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Wed, 29 Oct 2014 18:40:37 +0000 Subject: [Freeipa-users] getent passwd / group [SOLVED] In-Reply-To: <54503605.5060500@redhat.com> References: <54503065.4070600@redhat.com> <3c0fa0a2867c4d1584baac5b51d6c771@BLUPR08MB488.namprd08.prod.outlook.com> <54503605.5060500@redhat.com> Message-ID: <85a2afce9fed4c35a1b9e54f9f6b94f2@BLUPR08MB488.namprd08.prod.outlook.com> -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Tuesday, October 28, 2014 5:34 PM To: Craig White; dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] getent passwd / group [SOLVED] Craig White wrote: > *From:*Dmitri Pal [mailto:dpal at redhat.com] > *Sent:* Tuesday, October 28, 2014 5:10 PM > *To:* Craig White; freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] getent passwd / group [SOLVED] > > > > On 10/28/2014 04:41 PM, Craig White wrote: > > *From:*freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Craig White > *Sent:* Tuesday, October 28, 2014 1:28 PM > *To:* dpal at redhat.com ; > freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] getent passwd / group [SOLVED] > > > > *From:*Dmitri Pal [mailto:dpal at redhat.com] > *Sent:* Tuesday, October 28, 2014 10:04 AM > *To:* Craig White; freeipa-users at redhat.com > > *Subject:* Re: [Freeipa-users] getent passwd / group > > > > On 10/28/2014 12:11 PM, Craig White wrote: > > *From:*freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* Monday, October 27, 2014 5:32 PM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] getent passwd / group > > > > On 10/27/2014 07:38 PM, Craig White wrote: > > RHEL 6.5 - new install > > ipa-server-3.0.0-42.el6.x86_64 > > 389-ds-base-1.2.11.15-47.el6.x86_64 > > > > On the master, I get nothing > > > > [root at ipa001 log]# getent passwd admin > > [root at ipa001 log]# > > > > But it works on the replica as expected > > > > [root at ipa002nadev01 ~]# getent passwd admin > > > admin:*:1140000000:1110000000:Administrator:/home/admin:/bin/bash > > > > I am used to using PADL / NSSWITCH with OpenLDAP and I am > rather surprised that on both, 'getent passwd' and 'getent > group' return only entries from local files but then again, > I've never used sssd before. > > > > REJECT all -- 0.0.0.0/0 0.0.0.0/0 > reject-with icmp-host-prohibited > > > Then we need SSSD logs with the debug_level in the right sections as > Jakub mentioned in his mail. > ---- > > Sorry - I had a long meeting and should have noted that after > restarting SSSD, it all started working again as expected. Clearly > something I have to watch for and indeed, I moved the debug to the > domain section for future. > > I should add - came to the realization that restarting sssd and went to long meeting, then came back and couldn't log into ipa console or Kerberos and had to restart IPA service to restart Kerberos. > > > > IPA is logging nothing. > > > > This is not the first time I have had to go through this cycle - it seems that somehow, the IPA server is sensitive to the SSSD daemon and if the SSSD goes haywire, when I restart SSSD, IPA is not functioning and must be restarted too. > > > > Thanks > > > > Craig > > > Is this on the same server? > ---- > > Yes, same server... the one I call the master. The first one I set up. > I'm getting tuned in to the checking the status of dirsrv and ipa but > now I know to check the status of the sssd too. > > > > Seems like it crashes a little too easily - I doubt I did much to harm it... I am fairly experienced with OpenLDAP and in fact used 389-server back when it was called FedoraDS. > > > > But it is running now, and seemingly will stay running for some time and I am upping the logging and watching for a crash like Richard said to provide some debug logs if possible. Sort of wish I could have just started with RHEL 7 and the updated IPA. Ok, and to be clear if it crashes again Rich needs to get a stacktrace. Logs won't be enough. rob ---- OK - just after I left work last night - IPA crashed. Oct 28 17:17:11 ipa001 kernel: ns-slapd[1219]: segfault at 0 ip 00007f86cd04e572 sp 00007f86a2bf7f10 error 4 in libslapd.so.0.0.0[7f86cd009000+fd000] Required a 'service ipa restart' to get up and running again ;-( Now Rich directed me to the 'debugging crashes' section which would have me installing debuginfo for 389. I can't find it... # yum search 389-ds-base-debuginfo Loaded plugins: product-id, rhnplugin, subscription-manager This system is receiving updates from RHN Classic or RHN Satellite. rackspace-rhel-x86_64-server-6-common | 871 B 00:00 rackspace-rhel-x86_64-server-6-ius | 871 B 00:00 rhel-x86_64-server-6 | 1.5 kB 00:00 rhel-x86_64-server-optional-6 | 1.5 kB 00:00 rhel-x86_64-server-supplementary-6 | 1.5 kB 00:00 rhn-tools-rhel-x86_64-server-6 | 1.3 kB 00:00 epel/pkgtags | 1.3 MB 00:00 Warning: No matches found for: 389-ds-base-debuginfo No Matches found Which sort of makes sense in that we are forced to use Rackspace mirrors and can't use any public repos. I can probably get around it by separately downloading to my desktop, using SCP to transfer the packages over and installing but that is quite a hassle. Do I have any other options? Is the only debuginfo package I need the 389-ds-base? From loris at lgs.com.ve Wed Oct 29 19:54:19 2014 From: loris at lgs.com.ve (Loris Santamaria) Date: Wed, 29 Oct 2014 15:24:19 -0430 Subject: [Freeipa-users] Woes adding a samba server to the ipa domain In-Reply-To: <20141023103255.GA2826@localhost.localdomain> References: <1413810952.3012.22.camel@toron.pzo.lgs.com.ve> <5445B498.9090608@redhat.com> <1413893951.3184.15.camel@toron.pzo.lgs.com.ve> <20141023103255.GA2826@localhost.localdomain> Message-ID: <1414612459.3112.22.camel@toron.pzo.lgs.com.ve> El jue, 23-10-2014 a las 12:32 +0200, Sumit Bose escribi?: > On Tue, Oct 21, 2014 at 07:49:11AM -0430, Loris Santamaria wrote: > > El lun, 20-10-2014 a las 21:19 -0400, Dmitri Pal escribi?: > > > On 10/20/2014 09:15 AM, Loris Santamaria wrote: > > > > [...] > > > > > > > > > > Trying to join the server to the domain (net rpc join -U domainadmin -S > > > > ipaserver) fails, and it causes a samba crash on the ipa server. > > > > Investigating the cause of the crash I found that pdbedit crashes as > > > > well (backtrace attached). I couldn't get a meaningful backtrace from > > > > the samba crash however I attached it as well. > > > > > > > > Seems to me that the samba ipasam backend on ipa doesn't like something > > > > in the host or the "domain computers" group object in ldap, but I cannot > > > > see what could be the problem. Perhaps someone more familiar with the > > > > ipasam code can spot it quickly. > > > > > Do I get it right that you really looking for > > > https://fedorahosted.org/sssd/ticket/1588 that was just released > > > upstream? > > > It would be cool if you can try using SSSD 1.12.1 under Samba FS in > > > the use case you have and provide feedback on how it works for you. > > > > > > AFAIU you install Samba FS and then use ipa-client to configure SSSD > > > under it and it should work. > > > If not we probably should document it (but I do not see any special > > > design page which leads me to the above expectation). > > > > Ok, I'll happily try sssd 1.12.1. > > > > Just a question, in smb.conf one should use "security = domain" or > > "security = ads"? > > 'ads' because we want to use Kerberos. But there some other > configuration options which needs attention, e.g. you have to create a > keytab for the cifs service and make it available to samba. I'll try to > set up an small howto page listing the needed steps and come back to you > early next week. It Works :D, and here is what I did: Test environment: One realm domain with two Centos 7 / ipa 3.3 masters, one trusted AD forest (windows 2008R2 controllers), one Centos 7 file server. Step 1) On the file server enable mkosek's COPR ipa repo: https://copr.fedoraproject.org/coprs/mkosek/freeipa/ 2) Install required packages packages: yum -y install ipa-client sssd-libwbclient samba samba client 3) join file server to the ipa realm: ipa-client-install --mkhomedir Please note that this step fails, shortly after creating the keytab and configuring sssd, probably caused by the version mismatch between ipa server (3.3) and client (4.1). I will report the failure shortly. Because of the failure I had to complete part of the join procedure manually: authconfig --enablesssdauth --enablemkhomedir --update (on the client) ipa dnsrecord-add my.realm sambatest --a-rec=x.y.w.z (on ipa server) 4) On the ipa server create the cifs principal for samba: ipa service-add cifs/sambatest.my.realm 5) Install keytab on the samba host: ipa-getkeytab -s ipaserver.my.realm -p cifs/sambatest.my.realm -k /etc/samba/samba.keytab 6) Edit /etc/samba/smb.conf on the samba file server: [global] workgroup = MY realm = MY.REALM dedicated keytab file = FILE:/etc/samba/samba.keytab kerberos method = dedicated keytab log file = /var/log/samba/log.%m security = ads [homes] browsable = no writable = yes [shared] path = /home/shared writable = yes browsable=yes write list = @admins 7) To enable samba /home sharing one should turn on a selinux boolean: setsebool -P samba_enable_home_dirs on 8) restart samba Testing: On another linux member of the IPA domain it is possible to connect to the samba shares using smbclient -k : kinit user at MY.REALM smbclient -k -L sambatest.my.realm smbclient -k //sambatest.my.realm/shared On a windows machine, member of the AD domain it is possible to connect to the samba shares typing in the windows explorer location bar: \\sambatest.my.realm Also, if the ad user is an (indirect) member of the IPA admins group, thanks to the trust relationship, with the above smb.conf he may have write access to the \shared folder. Thanks to the ipa and sssd teams for this great enablement! -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5693 bytes Desc: not available URL: From john.obaterspok at gmail.com Wed Oct 29 20:40:33 2014 From: john.obaterspok at gmail.com (John Obaterspok) Date: Wed, 29 Oct 2014 21:40:33 +0100 Subject: [Freeipa-users] Woes adding a samba server to the ipa domain In-Reply-To: <1414612459.3112.22.camel@toron.pzo.lgs.com.ve> References: <1413810952.3012.22.camel@toron.pzo.lgs.com.ve> <5445B498.9090608@redhat.com> <1413893951.3184.15.camel@toron.pzo.lgs.com.ve> <20141023103255.GA2826@localhost.localdomain> <1414612459.3112.22.camel@toron.pzo.lgs.com.ve> Message-ID: Hello, I've tried this as well. My IPA is not connected to an AD. My smb.conf looks almost the same. The differences are: - I got the default workgroup set (MY or something) - No FILE:/ prefix for keytab file I had the samba and ipserver on the same box so I just had to add the cifs server and get keytab file in the same way. I was a bit surprised to see that accessing samba using "smbclient -k \\..." worked right away from a linux box. Then stopped working if I did kdestroy. *But,* I never got it to work from Windows. The Windows PC is not joined to any AD, it uses MIT Kerb client 4.0.1 and I successfully get tickes and can sshlogin via putty without password. Any ideas on how to get this going from Windows as well? -- john 2014-10-29 20:54 GMT+01:00 Loris Santamaria : > El jue, 23-10-2014 a las 12:32 +0200, Sumit Bose escribi?: > > On Tue, Oct 21, 2014 at 07:49:11AM -0430, Loris Santamaria wrote: > > > El lun, 20-10-2014 a las 21:19 -0400, Dmitri Pal escribi?: > > > > On 10/20/2014 09:15 AM, Loris Santamaria wrote: > > > > > > [...] > > > > > > > > > > > > > Trying to join the server to the domain (net rpc join -U > domainadmin -S > > > > > ipaserver) fails, and it causes a samba crash on the ipa server. > > > > > Investigating the cause of the crash I found that pdbedit crashes > as > > > > > well (backtrace attached). I couldn't get a meaningful backtrace > from > > > > > the samba crash however I attached it as well. > > > > > > > > > > Seems to me that the samba ipasam backend on ipa doesn't like > something > > > > > in the host or the "domain computers" group object in ldap, but I > cannot > > > > > see what could be the problem. Perhaps someone more familiar with > the > > > > > ipasam code can spot it quickly. > > > > > > > Do I get it right that you really looking for > > > > https://fedorahosted.org/sssd/ticket/1588 that was just released > > > > upstream? > > > > It would be cool if you can try using SSSD 1.12.1 under Samba FS in > > > > the use case you have and provide feedback on how it works for you. > > > > > > > > AFAIU you install Samba FS and then use ipa-client to configure SSSD > > > > under it and it should work. > > > > If not we probably should document it (but I do not see any special > > > > design page which leads me to the above expectation). > > > > > > Ok, I'll happily try sssd 1.12.1. > > > > > > Just a question, in smb.conf one should use "security = domain" or > > > "security = ads"? > > > > 'ads' because we want to use Kerberos. But there some other > > configuration options which needs attention, e.g. you have to create a > > keytab for the cifs service and make it available to samba. I'll try to > > set up an small howto page listing the needed steps and come back to you > > early next week. > > It Works :D, and here is what I did: > > Test environment: One realm domain with two Centos 7 / ipa 3.3 masters, > one trusted AD forest (windows 2008R2 controllers), one Centos 7 file > server. > > Step 1) On the file server enable mkosek's COPR ipa repo: > https://copr.fedoraproject.org/coprs/mkosek/freeipa/ > > 2) Install required packages packages: > yum -y install ipa-client sssd-libwbclient samba samba client > > 3) join file server to the ipa realm: > ipa-client-install --mkhomedir > > Please note that this step fails, shortly after creating the keytab and > configuring sssd, probably caused by the version mismatch between ipa > server (3.3) and client (4.1). I will report the failure shortly. > Because of the failure I had to complete part of the join procedure > manually: > authconfig --enablesssdauth --enablemkhomedir --update (on the client) > ipa dnsrecord-add my.realm sambatest --a-rec=x.y.w.z (on ipa server) > > 4) On the ipa server create the cifs principal for samba: > ipa service-add cifs/sambatest.my.realm > > 5) Install keytab on the samba host: > ipa-getkeytab -s ipaserver.my.realm -p cifs/sambatest.my.realm > -k /etc/samba/samba.keytab > > 6) Edit /etc/samba/smb.conf on the samba file server: > [global] > workgroup = MY > realm = MY.REALM > dedicated keytab file = FILE:/etc/samba/samba.keytab > kerberos method = dedicated keytab > log file = /var/log/samba/log.%m > security = ads > > [homes] > browsable = no > writable = yes > > [shared] > path = /home/shared > writable = yes > browsable=yes > write list = @admins > > 7) To enable samba /home sharing one should turn on a selinux boolean: > setsebool -P samba_enable_home_dirs on > > 8) restart samba > > Testing: > > On another linux member of the IPA domain it is possible to connect to > the samba shares using smbclient -k : > kinit user at MY.REALM > smbclient -k -L sambatest.my.realm > smbclient -k //sambatest.my.realm/shared > > On a windows machine, member of the AD domain it is possible to connect > to the samba shares typing in the windows explorer location bar: > \\sambatest.my.realm > Also, if the ad user is an (indirect) member of the IPA admins group, > thanks to the trust relationship, with the above smb.conf he may have > write access to the \shared folder. > > Thanks to the ipa and sssd teams for this great enablement! > -- > Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve > Links Global Services, C.A. http://www.lgs.com.ve > Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve > ------------------------------------------------------------ > "If I'd asked my customers what they wanted, they'd have said > a faster horse" - Henry Ford > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From loris at lgs.com.ve Wed Oct 29 21:01:59 2014 From: loris at lgs.com.ve (Loris Santamaria) Date: Wed, 29 Oct 2014 16:31:59 -0430 Subject: [Freeipa-users] Woes adding a samba server to the ipa domain In-Reply-To: References: <1413810952.3012.22.camel@toron.pzo.lgs.com.ve> <5445B498.9090608@redhat.com> <1413893951.3184.15.camel@toron.pzo.lgs.com.ve> <20141023103255.GA2826@localhost.localdomain> <1414612459.3112.22.camel@toron.pzo.lgs.com.ve> Message-ID: <1414616519.3112.28.camel@toron.pzo.lgs.com.ve> El mi?, 29-10-2014 a las 21:40 +0100, John Obaterspok escribi?: > Hello, > > > I've tried this as well. My IPA is not connected to an AD. My smb.conf > looks almost the same. The differences are: > - I got the default workgroup set (MY or something) > - No FILE:/ prefix for keytab file > > > I had the samba and ipserver on the same box so I just had to add the > cifs server and get keytab file in the same way. > I was a bit surprised to see that accessing samba using "smbclient -k > \\..." worked right away from a linux box. Then stopped working if I > did kdestroy. > > > But, I never got it to work from Windows. The Windows PC is not joined > to any AD, it uses MIT Kerb client 4.0.1 and I successfully get tickes > and can sshlogin via putty without password. > > > Any ideas on how to get this going from Windows as well? I guess you should prepare the ipa server for a windows domain trust (even if you won't setup any trust with an ad domain), with ipa-adtrust-install. Beware that it will overwrite your smb.conf. With that configuration and the steps described in http://www.redhat.com/archives/freeipa-users/2013-September/msg00226.html you will be able to use the native windows kerberos libraries and you should be able to open a samba share with your kerberos credentials. Best regards -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5693 bytes Desc: not available URL: From rob.verduijn at gmail.com Wed Oct 29 21:14:14 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Wed, 29 Oct 2014 22:14:14 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <5451205E.8020408@redhat.com> References: <544D5BB2.5090003@redhat.com> <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> <5450F0B9.9010907@redhat.com> <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <5451205E.8020408@redhat.com> Message-ID: Hello, I've tested the update again. The bind-utils conflict is still there when I issue "yum update freeipa-server" ( as indicated on the freeipa 4.1 download page http://www.freeipa.org/page/Downloads#Upgrading ) 'yum update' works fine My internal zones didn't resolv after the update ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update didn't fix it ipa-ldap-updater did fix the 'access control instructions' and my internal dns zones started to resolv again :-) Cheers Rob 2014-10-29 18:14 GMT+01:00 Petr Spacek : > On 29.10.2014 16:46, Rob Verduijn wrote: > >> Hello, >> >> # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update >> fixes the problem. >> >> I can resolv my internal dns zones again:-) >> >> Many thanx. >> >> Since this problem happened every time I tried to update the freeipa >> server. >> I could re-run the update with some debug options if you like so you can >> pinpoint what goes wrong with the update script if you like. >> > > I have re-build some packages in mkosek's CORP so now you should not see > encounter dependency problems. Simple 'yum upgrade' should give you all the > required packages. > > We are looking at other problems in upgrade process right now so there is > not much to test except package dependencies. > > -- > Petr^2 Spacek > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Oct 30 00:45:52 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 29 Oct 2014 20:45:52 -0400 Subject: [Freeipa-users] getent passwd / group [SOLVED] In-Reply-To: <85a2afce9fed4c35a1b9e54f9f6b94f2@BLUPR08MB488.namprd08.prod.outlook.com> References: <54503065.4070600@redhat.com> <3c0fa0a2867c4d1584baac5b51d6c771@BLUPR08MB488.namprd08.prod.outlook.com> <54503605.5060500@redhat.com> <85a2afce9fed4c35a1b9e54f9f6b94f2@BLUPR08MB488.namprd08.prod.outlook.com> Message-ID: <54518A40.60204@redhat.com> On 10/29/2014 02:40 PM, Craig White wrote: > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Tuesday, October 28, 2014 5:34 PM > To: Craig White; dpal at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] getent passwd / group [SOLVED] > > Craig White wrote: >> *From:*Dmitri Pal [mailto:dpal at redhat.com] >> *Sent:* Tuesday, October 28, 2014 5:10 PM >> *To:* Craig White; freeipa-users at redhat.com >> *Subject:* Re: [Freeipa-users] getent passwd / group [SOLVED] >> >> >> >> On 10/28/2014 04:41 PM, Craig White wrote: >> >> *From:*freeipa-users-bounces at redhat.com >> >> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Craig White >> *Sent:* Tuesday, October 28, 2014 1:28 PM >> *To:* dpal at redhat.com ; >> freeipa-users at redhat.com >> *Subject:* Re: [Freeipa-users] getent passwd / group [SOLVED] >> >> >> >> *From:*Dmitri Pal [mailto:dpal at redhat.com] >> *Sent:* Tuesday, October 28, 2014 10:04 AM >> *To:* Craig White; freeipa-users at redhat.com >> >> *Subject:* Re: [Freeipa-users] getent passwd / group >> >> >> >> On 10/28/2014 12:11 PM, Craig White wrote: >> >> *From:*freeipa-users-bounces at redhat.com >> >> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal >> *Sent:* Monday, October 27, 2014 5:32 PM >> *To:* freeipa-users at redhat.com >> *Subject:* Re: [Freeipa-users] getent passwd / group >> >> >> >> On 10/27/2014 07:38 PM, Craig White wrote: >> >> RHEL 6.5 - new install >> >> ipa-server-3.0.0-42.el6.x86_64 >> >> 389-ds-base-1.2.11.15-47.el6.x86_64 >> >> >> >> On the master, I get nothing >> >> >> >> [root at ipa001 log]# getent passwd admin >> >> [root at ipa001 log]# >> >> >> >> But it works on the replica as expected >> >> >> >> [root at ipa002nadev01 ~]# getent passwd admin >> >> >> admin:*:1140000000:1110000000:Administrator:/home/admin:/bin/bash >> >> >> >> I am used to using PADL / NSSWITCH with OpenLDAP and I am >> rather surprised that on both, 'getent passwd' and 'getent >> group' return only entries from local files but then again, >> I've never used sssd before. >> >> >> >> REJECT all -- 0.0.0.0/0 0.0.0.0/0 >> reject-with icmp-host-prohibited >> >> >> Then we need SSSD logs with the debug_level in the right sections as >> Jakub mentioned in his mail. >> ---- >> >> Sorry - I had a long meeting and should have noted that after >> restarting SSSD, it all started working again as expected. Clearly >> something I have to watch for and indeed, I moved the debug to the >> domain section for future. >> >> I should add - came to the realization that restarting sssd and went to long meeting, then came back and couldn't log into ipa console or Kerberos and had to restart IPA service to restart Kerberos. >> >> >> >> IPA is logging nothing. >> >> >> >> This is not the first time I have had to go through this cycle - it seems that somehow, the IPA server is sensitive to the SSSD daemon and if the SSSD goes haywire, when I restart SSSD, IPA is not functioning and must be restarted too. >> >> >> >> Thanks >> >> >> >> Craig >> >> >> Is this on the same server? >> ---- >> >> Yes, same server... the one I call the master. The first one I set up. >> I'm getting tuned in to the checking the status of dirsrv and ipa but >> now I know to check the status of the sssd too. >> >> >> >> Seems like it crashes a little too easily - I doubt I did much to harm it... I am fairly experienced with OpenLDAP and in fact used 389-server back when it was called FedoraDS. >> >> >> >> But it is running now, and seemingly will stay running for some time and I am upping the logging and watching for a crash like Richard said to provide some debug logs if possible. Sort of wish I could have just started with RHEL 7 and the updated IPA. > Ok, and to be clear if it crashes again Rich needs to get a stacktrace. > Logs won't be enough. > > rob > ---- > OK - just after I left work last night - IPA crashed. > > Oct 28 17:17:11 ipa001 kernel: ns-slapd[1219]: segfault at 0 ip 00007f86cd04e572 sp 00007f86a2bf7f10 error 4 in libslapd.so.0.0.0[7f86cd009000+fd000] > > Required a 'service ipa restart' to get up and running again ;-( > > Now Rich directed me to the 'debugging crashes' section which would have me installing debuginfo for 389. > > I can't find it... > # yum search 389-ds-base-debuginfo > Loaded plugins: product-id, rhnplugin, subscription-manager > This system is receiving updates from RHN Classic or RHN Satellite. > rackspace-rhel-x86_64-server-6-common | 871 B 00:00 > rackspace-rhel-x86_64-server-6-ius | 871 B 00:00 > rhel-x86_64-server-6 | 1.5 kB 00:00 > rhel-x86_64-server-optional-6 | 1.5 kB 00:00 > rhel-x86_64-server-supplementary-6 | 1.5 kB 00:00 > rhn-tools-rhel-x86_64-server-6 | 1.3 kB 00:00 > epel/pkgtags | 1.3 MB 00:00 > Warning: No matches found for: 389-ds-base-debuginfo > No Matches found > > Which sort of makes sense in that we are forced to use Rackspace mirrors and can't use any public repos. > > I can probably get around it by separately downloading to my desktop, using SCP to transfer the packages over and installing but that is quite a hassle. I do not think there is another option. Sorry. > > Do I have any other options? Is the only debuginfo package I need the 389-ds-base? AFAIU yes. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu Oct 30 00:49:05 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 29 Oct 2014 20:49:05 -0400 Subject: [Freeipa-users] Woes adding a samba server to the ipa domain In-Reply-To: <1414616519.3112.28.camel@toron.pzo.lgs.com.ve> References: <1413810952.3012.22.camel@toron.pzo.lgs.com.ve> <5445B498.9090608@redhat.com> <1413893951.3184.15.camel@toron.pzo.lgs.com.ve> <20141023103255.GA2826@localhost.localdomain> <1414612459.3112.22.camel@toron.pzo.lgs.com.ve> <1414616519.3112.28.camel@toron.pzo.lgs.com.ve> Message-ID: <54518B01.3050405@redhat.com> On 10/29/2014 05:01 PM, Loris Santamaria wrote: > El mi?, 29-10-2014 a las 21:40 +0100, John Obaterspok escribi?: >> Hello, >> >> >> I've tried this as well. My IPA is not connected to an AD. My smb.conf >> looks almost the same. The differences are: >> - I got the default workgroup set (MY or something) >> - No FILE:/ prefix for keytab file >> >> >> I had the samba and ipserver on the same box so I just had to add the >> cifs server and get keytab file in the same way. >> I was a bit surprised to see that accessing samba using "smbclient -k >> \\..." worked right away from a linux box. Then stopped working if I >> did kdestroy. >> >> >> But, I never got it to work from Windows. The Windows PC is not joined >> to any AD, it uses MIT Kerb client 4.0.1 and I successfully get tickes >> and can sshlogin via putty without password. >> >> >> Any ideas on how to get this going from Windows as well? > I guess you should prepare the ipa server for a windows domain trust > (even if you won't setup any trust with an ad domain), with > ipa-adtrust-install. Beware that it will overwrite your smb.conf. > > With that configuration and the steps described in > http://www.redhat.com/archives/freeipa-users/2013-September/msg00226.html you will be able to use the native windows kerberos libraries and you should be able to open a samba share with your kerberos credentials. > > Best regards > > > > Would by any chance you be able to create a HowTo solution on the FreeIPA wiki? Seems like it would be a simple cut&paste from couple mails. Thanks in advance! http://www.freeipa.org/page/Contribute/Documentation http://www.freeipa.org/page/HowTos -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Oct 30 01:02:08 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 29 Oct 2014 19:02:08 -0600 Subject: [Freeipa-users] getent passwd / group [SOLVED] In-Reply-To: <54518A40.60204@redhat.com> References: <54503065.4070600@redhat.com> <3c0fa0a2867c4d1584baac5b51d6c771@BLUPR08MB488.namprd08.prod.outlook.com> <54503605.5060500@redhat.com> <85a2afce9fed4c35a1b9e54f9f6b94f2@BLUPR08MB488.namprd08.prod.outlook.com> <54518A40.60204@redhat.com> Message-ID: <54518E10.8000609@redhat.com> On 10/29/2014 06:45 PM, Dmitri Pal wrote: > On 10/29/2014 02:40 PM, Craig White wrote: >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Tuesday, October 28, 2014 5:34 PM >> To: Craig White; dpal at redhat.com; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] getent passwd / group [SOLVED] >> >> Craig White wrote: >>> *From:*Dmitri Pal [mailto:dpal at redhat.com] >>> *Sent:* Tuesday, October 28, 2014 5:10 PM >>> *To:* Craig White; freeipa-users at redhat.com >>> *Subject:* Re: [Freeipa-users] getent passwd / group [SOLVED] >>> >>> >>> On 10/28/2014 04:41 PM, Craig White wrote: >>> >>> *From:*freeipa-users-bounces at redhat.com >>> >>> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Craig >>> White >>> *Sent:* Tuesday, October 28, 2014 1:28 PM >>> *To:* dpal at redhat.com ; >>> freeipa-users at redhat.com >>> *Subject:* Re: [Freeipa-users] getent passwd / group [SOLVED] >>> >>> >>> *From:*Dmitri Pal [mailto:dpal at redhat.com] >>> *Sent:* Tuesday, October 28, 2014 10:04 AM >>> *To:* Craig White; freeipa-users at redhat.com >>> >>> *Subject:* Re: [Freeipa-users] getent passwd / group >>> >>> >>> On 10/28/2014 12:11 PM, Craig White wrote: >>> >>> *From:*freeipa-users-bounces at redhat.com >>> >>> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of >>> *Dmitri Pal >>> *Sent:* Monday, October 27, 2014 5:32 PM >>> *To:* freeipa-users at redhat.com >>> >>> *Subject:* Re: [Freeipa-users] getent passwd / group >>> >>> >>> On 10/27/2014 07:38 PM, Craig White wrote: >>> >>> RHEL 6.5 - new install >>> >>> ipa-server-3.0.0-42.el6.x86_64 >>> >>> 389-ds-base-1.2.11.15-47.el6.x86_64 >>> >>> >>> On the master, I get nothing >>> >>> >>> [root at ipa001 log]# getent passwd admin >>> >>> [root at ipa001 log]# >>> >>> >>> But it works on the replica as expected >>> >>> >>> [root at ipa002nadev01 ~]# getent passwd admin >>> >>> admin:*:1140000000:1110000000:Administrator:/home/admin:/bin/bash >>> >>> >>> I am used to using PADL / NSSWITCH with OpenLDAP and I am >>> rather surprised that on both, 'getent passwd' and 'getent >>> group' return only entries from local files but then >>> again, >>> I've never used sssd before. >>> >>> >>> REJECT all -- 0.0.0.0/0 0.0.0.0/0 >>> reject-with icmp-host-prohibited >>> >>> >>> Then we need SSSD logs with the debug_level in the right >>> sections as >>> Jakub mentioned in his mail. >>> ---- >>> >>> Sorry - I had a long meeting and should have noted that after >>> restarting SSSD, it all started working again as expected. Clearly >>> something I have to watch for and indeed, I moved the debug to the >>> domain section for future. >>> >>> I should add - came to the realization that restarting sssd and >>> went to long meeting, then came back and couldn't log into ipa >>> console or Kerberos and had to restart IPA service to restart Kerberos. >>> >>> >>> IPA is logging nothing. >>> >>> >>> This is not the first time I have had to go through this cycle >>> - it seems that somehow, the IPA server is sensitive to the SSSD >>> daemon and if the SSSD goes haywire, when I restart SSSD, IPA is not >>> functioning and must be restarted too. >>> >>> >>> Thanks >>> >>> >>> Craig >>> >>> >>> Is this on the same server? >>> ---- >>> >>> Yes, same server... the one I call the master. The first one I set up. >>> I'm getting tuned in to the checking the status of dirsrv and ipa but >>> now I know to check the status of the sssd too. >>> >>> >>> Seems like it crashes a little too easily - I doubt I did much to >>> harm it... I am fairly experienced with OpenLDAP and in fact used >>> 389-server back when it was called FedoraDS. >>> >>> >>> But it is running now, and seemingly will stay running for some time >>> and I am upping the logging and watching for a crash like Richard >>> said to provide some debug logs if possible. Sort of wish I could >>> have just started with RHEL 7 and the updated IPA. >> Ok, and to be clear if it crashes again Rich needs to get a stacktrace. >> Logs won't be enough. >> >> rob >> ---- >> OK - just after I left work last night - IPA crashed. >> >> Oct 28 17:17:11 ipa001 kernel: ns-slapd[1219]: segfault at 0 ip >> 00007f86cd04e572 sp 00007f86a2bf7f10 error 4 in >> libslapd.so.0.0.0[7f86cd009000+fd000] >> >> Required a 'service ipa restart' to get up and running again ;-( >> >> Now Rich directed me to the 'debugging crashes' section which would >> have me installing debuginfo for 389. >> >> I can't find it... >> # yum search 389-ds-base-debuginfo >> Loaded plugins: product-id, rhnplugin, subscription-manager >> This system is receiving updates from RHN Classic or RHN Satellite. >> rackspace-rhel-x86_64-server-6-common | 871 B 00:00 >> rackspace-rhel-x86_64-server-6-ius | 871 B 00:00 >> rhel-x86_64-server-6 | 1.5 kB 00:00 >> rhel-x86_64-server-optional-6 | 1.5 kB 00:00 >> rhel-x86_64-server-supplementary-6 | 1.5 kB 00:00 >> rhn-tools-rhel-x86_64-server-6 | 1.3 kB 00:00 >> epel/pkgtags | 1.3 MB 00:00 >> Warning: No matches found for: 389-ds-base-debuginfo >> No Matches found >> >> Which sort of makes sense in that we are forced to use Rackspace >> mirrors and can't use any public repos. >> >> I can probably get around it by separately downloading to my desktop, >> using SCP to transfer the packages over and installing but that is >> quite a hassle. > I do not think there is another option. Sorry. >> >> Do I have any other options? Is the only debuginfo package I need >> the 389-ds-base? > AFAIU yes. > You need the ipa-server and slapi-nis debuginfo packages. And all of the dependencies of 389 and ipa . . . Grr - I wish the debuginfo packages were in the default channels . . . See below - if none of these work because you are on Satellite and you cannot configure your Satellite with the correct channels/packages, let me know. With the release of RHEL 6 the debuginfo packages are no longer provided via the Red Hat public FTP site. They have instead moved to Red Hat Network (RHN) classic or Red Hat Satellite for download. Each base Red Hat channel now has a debug child channel. For example, rhel-x86_64-server-6 rhel-x86_64-server-6-debuginfo For RHEL 6 systems registered via subscription-manager: yum install yum-utils yum repolist all | grep debug yum-config-manager --enable rhel-6-server-debug-rpms If the system is registered via subscription-manager, the associated repostory label ends in "debug-rpms". Enable it with yum-config-manager or subscription-manager, e.g., # yum-config-manager --enable rhel-6-client-debug-rpms # subscription-manager repos --enable rhel-6-client-debug-rpms # yum-config-manager --enable rhel-6-server-debug-rpms # subscription-manager repos --enable rhel-6-server-debug-rpms If the system is registered to RHN Classic, add the channel to the system profile in the Customer Portal, or with rhn-channel: # rhn-channel -a -c rhel-`uname -i`-client-6-debuginfo -u -p # rhn-channel -a -c rhel-`uname -i`-server-6-debuginfo -u -p Note: if rhn-channel states that the channel does not exist, use the following command to verify the correct channel label in the list of available channels: # rhn-channel -L to verify the correct channel name in the list of available channels. Additionally, the RHN user interface has been changed to link to the debuginfo packages from the corresponding binary RPMs. For example: https://rhn.redhat.com/rhn/software/packages/details/Overview.do?pid=590664 Note that the "Associated Debug Info Package(s)" link at the bottom goes straight to the debuginfo package instead of to ftp.redhat.com. From loris at lgs.com.ve Thu Oct 30 03:38:42 2014 From: loris at lgs.com.ve (Loris Santamaria) Date: Wed, 29 Oct 2014 23:08:42 -0430 Subject: [Freeipa-users] Woes adding a samba server to the ipa domain In-Reply-To: <54518B01.3050405@redhat.com> References: <1413810952.3012.22.camel@toron.pzo.lgs.com.ve> <5445B498.9090608@redhat.com> <1413893951.3184.15.camel@toron.pzo.lgs.com.ve> <20141023103255.GA2826@localhost.localdomain> <1414612459.3112.22.camel@toron.pzo.lgs.com.ve> <1414616519.3112.28.camel@toron.pzo.lgs.com.ve> <54518B01.3050405@redhat.com> Message-ID: <1414640322.3112.30.camel@toron.pzo.lgs.com.ve> El mi?, 29-10-2014 a las 20:49 -0400, Dmitri Pal escribi?: > On 10/29/2014 05:01 PM, Loris Santamaria wrote: > > > El mi?, 29-10-2014 a las 21:40 +0100, John Obaterspok escribi?: > > > Hello, > > > > > > > > > I've tried this as well. My IPA is not connected to an AD. My smb.conf > > > looks almost the same. The differences are: > > > - I got the default workgroup set (MY or something) > > > - No FILE:/ prefix for keytab file > > > > > > > > > I had the samba and ipserver on the same box so I just had to add the > > > cifs server and get keytab file in the same way. > > > I was a bit surprised to see that accessing samba using "smbclient -k > > > \\..." worked right away from a linux box. Then stopped working if I > > > did kdestroy. > > > > > > > > > But, I never got it to work from Windows. The Windows PC is not joined > > > to any AD, it uses MIT Kerb client 4.0.1 and I successfully get tickes > > > and can sshlogin via putty without password. > > > > > > > > > Any ideas on how to get this going from Windows as well? > > I guess you should prepare the ipa server for a windows domain trust > > (even if you won't setup any trust with an ad domain), with > > ipa-adtrust-install. Beware that it will overwrite your smb.conf. > > > > With that configuration and the steps described in > > http://www.redhat.com/archives/freeipa-users/2013-September/msg00226.html you will be able to use the native windows kerberos libraries and you should be able to open a samba share with your kerberos credentials. > > > > Best regards > > > > > > > > > Would by any chance you be able to create a HowTo solution on the > FreeIPA wiki? > Seems like it would be a simple cut&paste from couple mails. Thanks in > advance! Here it is: http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA Best regards -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5693 bytes Desc: not available URL: From mlasevich at gmail.com Thu Oct 30 05:09:46 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Wed, 29 Oct 2014 22:09:46 -0700 Subject: [Freeipa-users] F20 Problem upgrading to 4.1 In-Reply-To: <5450BB76.8050300@redhat.com> References: <544E2A5C.50209@redhat.com> <544E897F.4050801@redhat.com> <544E9864.9060804@redhat.com> <544E9FC3.6020809@redhat.com> <544EA28B.5050402@redhat.com> <544F262E.1050400@gmail.com> <544F6E3C.3050000@redhat.com> <544FF486.1090905@gmail.com> <5450BB76.8050300@redhat.com> Message-ID: <5451C81A.6070800@gmail.com> Maybe I should not be doing this late at night, but I cannot find "cn=IPK11 Unique IDs,cn=IPA UUID,cn=plugins,cn=config " anywhere. -M On 10/29/14, 3:03 AM, Martin Basti wrote: > On 28/10/14 20:54, Michael Lasevich wrote: >> I have a pair of servers that were both installed on clean Fedora20 >> 4.0.1 from pviktori copr repo and then upgraded from mkosek to 4.1 >> >> During update, secondary was done first and worked but primary run into >> trouble as described >> >> Looking under cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com I get one >> entry with dn: >> >> ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com >> >> Not sure what of that you need there, but for ipk11Label it has: >> dnssec-replica:infra-dc-02.my.domain.com. (which is the replica that IS >> working) >> >> Thanks, >> >> -M >> >> On 10/28/14, 3:21 AM, Martin Basti wrote: >>> On 28/10/14 06:14, Michael Lasevich wrote: >>>> Running into same thing, but running ipa-dnsinstall does not complete: >>>> >>>> ============================= >>>> Configuring DNS (named) >>>> [1/8]: generating rndc key file >>>> WARNING: Your system is running out of entropy, you may experience >>>> long delays >>>> [2/8]: setting up our own record >>>> [3/8]: adding NS record to the zones >>>> [4/8]: setting up CA record >>>> [5/8]: setting up kerberos principal >>>> [6/8]: setting up named.conf >>>> [7/8]: configuring named to start on boot >>>> [8/8]: changing resolv.conf to point to ourselves >>>> Done configuring DNS (named). >>>> Configuring DNS key synchronization service (ipa-dnskeysyncd) >>>> [1/6]: checking status >>>> [2/6]: setting up kerberos principal >>>> [3/6]: setting up SoftHSM >>>> [4/6]: adding DNSSEC containers >>>> [5/6]: creating replica keys >>>> [error] DuplicateEntry: This entry already exists >>>> Unexpected error - see /var/log/ipaserver-install.log for details: >>>> DuplicateEntry: This entry already exists >>>> ============================= >>>> >>>> Looking into the /var/log/ipaserver-install.log gets: >>>> ============================= >>>> 2014-10-28T05:01:24Z DEBUG Storing replica public key to LDAP, >>>> ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com >>>> >>>> 2014-10-28T05:01:24Z DEBUG flushing >>>> ldap://infra-dc-01.my.domain.com:389 from SchemaCache >>>> 2014-10-28T05:01:24Z DEBUG retrieving schema for SchemaCache >>>> url=ldap://infra-dc-01.my.domain.com:389 >>>> conn= >>>> 2014-10-28T05:01:24Z DEBUG Traceback (most recent call last): >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>>> 382, in start_creation run_step(full_msg, method) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>>> 372, in run_step method() >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", >>>> >>>> line 340, in __setup_replica_keys ldap.add_entry(entry) >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>> 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) >>>> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ >>>> self.gen.throw(type, value, traceback) >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>> 1169, in error_handler raise errors.DuplicateEntry() >>>> DuplicateEntry: This entry already exists >>>> >>>> 2014-10-28T05:01:24Z DEBUG [error] DuplicateEntry: This entry >>>> already exists >>>> 2014-10-28T05:01:24Z DEBUG File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>> line 646, in run_script >>>> return_value = main_function() >>>> File "/sbin/ipa-dns-install", line 218, in main >>>> dnskeysyncd.create_instance(api.env.host, api.env.realm) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", >>>> >>>> line 128, in create_instance self.start_creation() >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>>> 382, in start_creation run_step(full_msg, method) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>>> 372, in run_step method() >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", >>>> >>>> line 340, in __setup_replica_keys ldap.add_entry(entry) >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>> 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) >>>> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ >>>> self.gen.throw(type, value, traceback) >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>> 1169, in error_handler raise errors.DuplicateEntry() >>>> 2014-10-28T05:01:24Z DEBUG The ipa-dns-install command failed, >>>> exception: DuplicateEntry: This entry already exists >>> Hello Michael, >>> >>> can you send me which entries do you have in >>> cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com, it looks like directory >>> server doesn't generate uniqueID for keys. >>> >>> Do you have upgraded IPA or fresh installed? >>> >>> Martin^2 >>> > Can you send me content of cn=IPK11 Unique IDs,cn=IPA > UUID,cn=plugins,cn=config entry? (If exists) > It looks like DS doesn't generate unique IDs > > Martin^2 > > From mbasti at redhat.com Thu Oct 30 08:44:36 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 30 Oct 2014 09:44:36 +0100 Subject: [Freeipa-users] F20 Problem upgrading to 4.1 In-Reply-To: <5451C81A.6070800@gmail.com> References: <544E2A5C.50209@redhat.com> <544E897F.4050801@redhat.com> <544E9864.9060804@redhat.com> <544E9FC3.6020809@redhat.com> <544EA28B.5050402@redhat.com> <544F262E.1050400@gmail.com> <544F6E3C.3050000@redhat.com> <544FF486.1090905@gmail.com> <5450BB76.8050300@redhat.com> <5451C81A.6070800@gmail.com> Message-ID: <5451FA74.7070401@redhat.com> On 30/10/14 06:09, Michael Lasevich wrote: > Maybe I should not be doing this late at night, but I cannot find > "cn=IPK11 Unique IDs,cn=IPA UUID,cn=plugins,cn=config " anywhere. > > -M IMO something bad happens during the ipa upgrade, can you remove ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com entry, and run ipa-ldap-updater --upgrade, then reinstall DNS (rerun ipa-dns-install) Let me know if it works. > > On 10/29/14, 3:03 AM, Martin Basti wrote: >> On 28/10/14 20:54, Michael Lasevich wrote: >>> I have a pair of servers that were both installed on clean Fedora20 >>> 4.0.1 from pviktori copr repo and then upgraded from mkosek to 4.1 >>> >>> During update, secondary was done first and worked but primary run into >>> trouble as described >>> >>> Looking under cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com I get one >>> entry with dn: >>> >>> ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com >>> >>> Not sure what of that you need there, but for ipk11Label it has: >>> dnssec-replica:infra-dc-02.my.domain.com. (which is the replica that IS >>> working) >>> >>> Thanks, >>> >>> -M >>> >>> On 10/28/14, 3:21 AM, Martin Basti wrote: >>>> On 28/10/14 06:14, Michael Lasevich wrote: >>>>> Running into same thing, but running ipa-dnsinstall does not complete: >>>>> >>>>> ============================= >>>>> Configuring DNS (named) >>>>> [1/8]: generating rndc key file >>>>> WARNING: Your system is running out of entropy, you may experience >>>>> long delays >>>>> [2/8]: setting up our own record >>>>> [3/8]: adding NS record to the zones >>>>> [4/8]: setting up CA record >>>>> [5/8]: setting up kerberos principal >>>>> [6/8]: setting up named.conf >>>>> [7/8]: configuring named to start on boot >>>>> [8/8]: changing resolv.conf to point to ourselves >>>>> Done configuring DNS (named). >>>>> Configuring DNS key synchronization service (ipa-dnskeysyncd) >>>>> [1/6]: checking status >>>>> [2/6]: setting up kerberos principal >>>>> [3/6]: setting up SoftHSM >>>>> [4/6]: adding DNSSEC containers >>>>> [5/6]: creating replica keys >>>>> [error] DuplicateEntry: This entry already exists >>>>> Unexpected error - see /var/log/ipaserver-install.log for details: >>>>> DuplicateEntry: This entry already exists >>>>> ============================= >>>>> >>>>> Looking into the /var/log/ipaserver-install.log gets: >>>>> ============================= >>>>> 2014-10-28T05:01:24Z DEBUG Storing replica public key to LDAP, >>>>> ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com >>>>> >>>>> 2014-10-28T05:01:24Z DEBUG flushing >>>>> ldap://infra-dc-01.my.domain.com:389 from SchemaCache >>>>> 2014-10-28T05:01:24Z DEBUG retrieving schema for SchemaCache >>>>> url=ldap://infra-dc-01.my.domain.com:389 >>>>> conn= >>>>> 2014-10-28T05:01:24Z DEBUG Traceback (most recent call last): >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>>>> 382, in start_creation run_step(full_msg, method) >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>>>> 372, in run_step method() >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", >>>>> >>>>> line 340, in __setup_replica_keys ldap.add_entry(entry) >>>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>>> 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) >>>>> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ >>>>> self.gen.throw(type, value, traceback) >>>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>>> 1169, in error_handler raise errors.DuplicateEntry() >>>>> DuplicateEntry: This entry already exists >>>>> >>>>> 2014-10-28T05:01:24Z DEBUG [error] DuplicateEntry: This entry >>>>> already exists >>>>> 2014-10-28T05:01:24Z DEBUG File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>> line 646, in run_script >>>>> return_value = main_function() >>>>> File "/sbin/ipa-dns-install", line 218, in main >>>>> dnskeysyncd.create_instance(api.env.host, api.env.realm) >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", >>>>> >>>>> line 128, in create_instance self.start_creation() >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>>>> 382, in start_creation run_step(full_msg, method) >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>>>> 372, in run_step method() >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", >>>>> >>>>> line 340, in __setup_replica_keys ldap.add_entry(entry) >>>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>>> 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) >>>>> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ >>>>> self.gen.throw(type, value, traceback) >>>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>>> 1169, in error_handler raise errors.DuplicateEntry() >>>>> 2014-10-28T05:01:24Z DEBUG The ipa-dns-install command failed, >>>>> exception: DuplicateEntry: This entry already exists >>>> Hello Michael, >>>> >>>> can you send me which entries do you have in >>>> cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com, it looks like directory >>>> server doesn't generate uniqueID for keys. >>>> >>>> Do you have upgraded IPA or fresh installed? >>>> >>>> Martin^2 >>>> >> Can you send me content of cn=IPK11 Unique IDs,cn=IPA >> UUID,cn=plugins,cn=config entry? (If exists) >> It looks like DS doesn't generate unique IDs >> >> Martin^2 >> >> -- Martin Basti From shashi.dahal at spilgames.com Thu Oct 30 14:47:53 2014 From: shashi.dahal at spilgames.com (Shashi Dahal) Date: Thu, 30 Oct 2014 14:47:53 +0000 Subject: [Freeipa-users] adding trust relationships Message-ID: Hi, I have ipa master server: A and I have 2 ipa replicas: B and C replica B crashed, so it was deleted from A and recreated using ipa-replica-parepare to generate the file and set it up from there. in server A B and C, if I do ipa-replica-manage list serverA lists A B and C as master serverB lists A B and C as master serverC lists only A and C as master .. B is missing. trying the command ipa-replica-manage connect B from serverC gives: You cannot connect to a previously deleted master now how do I add trust relationship between C and B ? Thanks, Shashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Thu Oct 30 14:59:31 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 30 Oct 2014 15:59:31 +0100 Subject: [Freeipa-users] Errors upgrading 4.0.1 to 4.1 In-Reply-To: <544A0340.8050702@redhat.com> References: <544A0340.8050702@redhat.com> Message-ID: <54525253.1070406@redhat.com> On 10/24/2014 09:44 AM, Martin Kosek wrote: > On 10/24/2014 05:17 AM, Michael Lasevich wrote: >> While upgrading from 4.0.1. to 4.1 on fedora 20 got following on one >> of the two >> boxes: >> >> Upgrade failed with attribute "allowWeakCipher" not allowed >> IPA upgrade failed. >> Unexpected error >> DuplicateEntry: This entry already exists >> >> >> It seems the ipa no longer starts up after this. The replica server >> seems to >> have had same error,but it runs just fine. >> >> From digging around, it appears that there are a number of GSS >> errors in >> dirsrv and bind fails with something like: >> >> named-pkcs11[2212]: ObjectStore.cpp(74): Failed to open token >> e919db16-6329-406c-6ae4-120ad68508c4 >> named-pkcs11[2212]: sha1.c:92: fatal error: >> named-pkcs11[2212]: RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, >> isc_boolean_true, isc_boolean_false, isc_boolean_false, ((void *)0), >> 0) == 0) >> failed >> >> Any help would be appreciated >> >> >> -M > > What Directory Server version do you use? This is an attribute > introduced in 389-ds-base 1.3.3+ which should be included in the > FreeIPA Copr (DS 1.3.3 is native to F21+). CCing Ludwig to advise > further. can you check your schema files for the definition of the nsEncryptionConfig objectclass, itshould be only in 01core389.ldif and contain allowWeakCipher, but it could have been added also to 99user.ldif during replication when schema changes have been comsolodated. > > Thanks, > Martin From rcritten at redhat.com Thu Oct 30 15:31:46 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 30 Oct 2014 11:31:46 -0400 Subject: [Freeipa-users] adding replication agreements In-Reply-To: References: Message-ID: <545259E2.9020703@redhat.com> Shashi Dahal wrote: > Hi, > > I have ipa master server: A > and I have 2 ipa replicas: B and C > > > replica B crashed, so it was deleted from A and recreated using > ipa-replica-parepare to generate the file and set it up from there. > > > in server A B and C, if I do ipa-replica-manage list > > serverA lists A B and C as master > serverB lists A B and C as master > serverC lists only A and C as master .. B is missing. > > trying the command ipa-replica-manage connect B from serverC > gives: You cannot connect to a previously deleted master > > > now how do I add trust relationship between C and B ? I changed the subject as this isn't trust, it's replication. I don't want to be pedantic but there is a significant difference. What I'd do, on each master, is this: ipa-replica-manage list -v `hostname` I think you'll find that C isn't getting updates. The masters list is stored in LDAP so if C doesn't know that B exists it likely means that its data is stale. rob From lucas.diedrich at gmail.com Thu Oct 30 16:45:40 2014 From: lucas.diedrich at gmail.com (Lucas Diedrich) Date: Thu, 30 Oct 2014 14:45:40 -0200 Subject: [Freeipa-users] IPA Server 4.* error on Centos7 Message-ID: Hello for all, I'm trying to install the IPA Server version 4.* on CentOS 7 using the EPEL 7 and the MKOSEK FreeIPA Repo (for 4.* version). But this is giving me a package dependency error. After a search i found this Thread ( https://www.redhat.com/archives/freeipa-users/2014-October/msg00200.html) wit the same error but without a good fix i think, it is possible that we contact someone to fix this issue? I really apreciate installing the 4.* version instead of 3.* of FreeIPA on my production environment if there is a way to fix this. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlasevich at gmail.com Thu Oct 30 17:22:42 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Thu, 30 Oct 2014 10:22:42 -0700 Subject: [Freeipa-users] F20 Problem upgrading to 4.1 In-Reply-To: <5451FA74.7070401@redhat.com> References: <544E2A5C.50209@redhat.com> <544E897F.4050801@redhat.com> <544E9864.9060804@redhat.com> <544E9FC3.6020809@redhat.com> <544EA28B.5050402@redhat.com> <544F262E.1050400@gmail.com> <544F6E3C.3050000@redhat.com> <544FF486.1090905@gmail.com> <5450BB76.8050300@redhat.com> <5451C81A.6070800@gmail.com> <5451FA74.7070401@redhat.com> Message-ID: <545273E2.6010001@gmail.com> *sigh* Feel like I am going around in circles "ipa-ldap-updater --upgrade" failed with: "Upgrade failed with attribute "allowWeakCipher" not allowed" I am running 1.3.3 from mkosek-freeipa copr: 389-ds-base-libs-1.3.3.5-1.fc20.x86_64 389-ds-base-1.3.3.5-1.fc20.x86_64 yum info 389-ds-base Loaded plugins: copr Installed Packages Name : 389-ds-base Arch : x86_64 Version : 1.3.3.5 Release : 1.fc20 Size : 5.2 M Repo : installed >From repo : mkosek-freeipa Summary : 389 Directory Server (base) URL : http://port389.org/ License : GPLv2 with exceptions Description : 389 Directory Server is an LDAPv3 compliant server. The base package includes : the LDAP server and command line utilities for server administration. -M On 10/30/14, 1:44 AM, Martin Basti wrote: > On 30/10/14 06:09, Michael Lasevich wrote: >> Maybe I should not be doing this late at night, but I cannot find >> "cn=IPK11 Unique IDs,cn=IPA UUID,cn=plugins,cn=config " anywhere. >> >> -M > > IMO something bad happens during the ipa upgrade, > > can you remove > > ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com > > entry, and run ipa-ldap-updater --upgrade, then reinstall DNS (rerun > ipa-dns-install) > > Let me know if it works. > >> >> On 10/29/14, 3:03 AM, Martin Basti wrote: >>> On 28/10/14 20:54, Michael Lasevich wrote: >>>> I have a pair of servers that were both installed on clean Fedora20 >>>> 4.0.1 from pviktori copr repo and then upgraded from mkosek to 4.1 >>>> >>>> During update, secondary was done first and worked but primary run >>>> into >>>> trouble as described >>>> >>>> Looking under cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com I get one >>>> entry with dn: >>>> >>>> ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com >>>> >>>> >>>> Not sure what of that you need there, but for ipk11Label it has: >>>> dnssec-replica:infra-dc-02.my.domain.com. (which is the replica >>>> that IS >>>> working) >>>> >>>> Thanks, >>>> >>>> -M >>>> >>>> On 10/28/14, 3:21 AM, Martin Basti wrote: >>>>> On 28/10/14 06:14, Michael Lasevich wrote: >>>>>> Running into same thing, but running ipa-dnsinstall does not >>>>>> complete: >>>>>> >>>>>> ============================= >>>>>> Configuring DNS (named) >>>>>> [1/8]: generating rndc key file >>>>>> WARNING: Your system is running out of entropy, you may experience >>>>>> long delays >>>>>> [2/8]: setting up our own record >>>>>> [3/8]: adding NS record to the zones >>>>>> [4/8]: setting up CA record >>>>>> [5/8]: setting up kerberos principal >>>>>> [6/8]: setting up named.conf >>>>>> [7/8]: configuring named to start on boot >>>>>> [8/8]: changing resolv.conf to point to ourselves >>>>>> Done configuring DNS (named). >>>>>> Configuring DNS key synchronization service (ipa-dnskeysyncd) >>>>>> [1/6]: checking status >>>>>> [2/6]: setting up kerberos principal >>>>>> [3/6]: setting up SoftHSM >>>>>> [4/6]: adding DNSSEC containers >>>>>> [5/6]: creating replica keys >>>>>> [error] DuplicateEntry: This entry already exists >>>>>> Unexpected error - see /var/log/ipaserver-install.log for details: >>>>>> DuplicateEntry: This entry already exists >>>>>> ============================= >>>>>> >>>>>> Looking into the /var/log/ipaserver-install.log gets: >>>>>> ============================= >>>>>> 2014-10-28T05:01:24Z DEBUG Storing replica public key to LDAP, >>>>>> ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com >>>>>> >>>>>> >>>>>> 2014-10-28T05:01:24Z DEBUG flushing >>>>>> ldap://infra-dc-01.my.domain.com:389 from SchemaCache >>>>>> 2014-10-28T05:01:24Z DEBUG retrieving schema for SchemaCache >>>>>> url=ldap://infra-dc-01.my.domain.com:389 >>>>>> conn= >>>>>> 2014-10-28T05:01:24Z DEBUG Traceback (most recent call last): >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>>>> line >>>>>> 382, in start_creation run_step(full_msg, method) >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>>>> line >>>>>> 372, in run_step method() >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", >>>>>> >>>>>> >>>>>> line 340, in __setup_replica_keys ldap.add_entry(entry) >>>>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>>>>> line >>>>>> 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) >>>>>> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ >>>>>> self.gen.throw(type, value, traceback) >>>>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>>>>> line >>>>>> 1169, in error_handler raise errors.DuplicateEntry() >>>>>> DuplicateEntry: This entry already exists >>>>>> >>>>>> 2014-10-28T05:01:24Z DEBUG [error] DuplicateEntry: This entry >>>>>> already exists >>>>>> 2014-10-28T05:01:24Z DEBUG File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>>> >>>>>> line 646, in run_script >>>>>> return_value = main_function() >>>>>> File "/sbin/ipa-dns-install", line 218, in main >>>>>> dnskeysyncd.create_instance(api.env.host, api.env.realm) >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", >>>>>> >>>>>> >>>>>> line 128, in create_instance self.start_creation() >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>>>> line >>>>>> 382, in start_creation run_step(full_msg, method) >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>>>> line >>>>>> 372, in run_step method() >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", >>>>>> >>>>>> >>>>>> line 340, in __setup_replica_keys ldap.add_entry(entry) >>>>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>>>>> line >>>>>> 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) >>>>>> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ >>>>>> self.gen.throw(type, value, traceback) >>>>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>>>>> line >>>>>> 1169, in error_handler raise errors.DuplicateEntry() >>>>>> 2014-10-28T05:01:24Z DEBUG The ipa-dns-install command failed, >>>>>> exception: DuplicateEntry: This entry already exists >>>>> Hello Michael, >>>>> >>>>> can you send me which entries do you have in >>>>> cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com, it looks like directory >>>>> server doesn't generate uniqueID for keys. >>>>> >>>>> Do you have upgraded IPA or fresh installed? >>>>> >>>>> Martin^2 >>>>> >>> Can you send me content of cn=IPK11 Unique IDs,cn=IPA >>> UUID,cn=plugins,cn=config entry? (If exists) >>> It looks like DS doesn't generate unique IDs >>> >>> Martin^2 >>> >>> > > From mbasti at redhat.com Thu Oct 30 18:12:32 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 30 Oct 2014 19:12:32 +0100 Subject: [Freeipa-users] Errors upgrading 4.0.1 to 4.1 In-Reply-To: References: Message-ID: <54527F90.3000407@redhat.com> On 24/10/14 05:17, Michael Lasevich wrote: > While upgrading from 4.0.1. to 4.1 on fedora 20 got following on one > of the two boxes: > > Upgrade failed with attribute "allowWeakCipher" not allowed > IPA upgrade failed. > Unexpected error > DuplicateEntry: This entry already exists > Named errors are caused by cascade effect, if ldap schema and entry updates failed, there is misconfigured DS plugin which is responsible to keep DNSSEC keys DN unique, what causes duplication errors. DuplicateEntry exception is fatal, so dnskeysyncd installation will not continue, what causes there are not appropriate permissions for token database, and named-pkcs11 can't read tokens. > > > It seems the ipa no longer starts up after this. The replica server > seems to have had same error,but it runs just fine. > > From digging around, it appears that there are a number of GSS errors > in dirsrv and bind fails with something like: > > named-pkcs11[2212]: ObjectStore.cpp(74): Failed to open token > e919db16-6329-406c-6ae4-120ad68508c4 > named-pkcs11[2212]: sha1.c:92: fatal error: > named-pkcs11[2212]: RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, > isc_boolean_true, isc_boolean_false, isc_boolean_false, ((void *)0), > 0) == 0) failed > > Any help would be appreciated > > > -M > > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlasevich at gmail.com Thu Oct 30 18:18:18 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Thu, 30 Oct 2014 11:18:18 -0700 Subject: [Freeipa-users] Errors upgrading 4.0.1 to 4.1 In-Reply-To: <54527F90.3000407@redhat.com> References: <54527F90.3000407@redhat.com> Message-ID: <545280EA.40604@gmail.com> Makes sense. What is the solution here? I have the latest 389-ds installed but still getting "allowWeakCipher" error - how to I get around that? -M On 10/30/14, 11:12 AM, Martin Basti wrote: > On 24/10/14 05:17, Michael Lasevich wrote: >> While upgrading from 4.0.1. to 4.1 on fedora 20 got following on one >> of the two boxes: >> >> Upgrade failed with attribute "allowWeakCipher" not allowed >> IPA upgrade failed. >> Unexpected error >> DuplicateEntry: This entry already exists >> > > Named errors are caused by cascade effect, if ldap schema and entry > updates failed, there is misconfigured DS plugin which is responsible > to keep DNSSEC keys DN unique, what causes duplication errors. > DuplicateEntry exception is fatal, so dnskeysyncd installation will > not continue, > what causes there are not appropriate permissions for token database, > and named-pkcs11 can't read tokens. >> >> >> It seems the ipa no longer starts up after this. The replica server >> seems to have had same error,but it runs just fine. >> >> From digging around, it appears that there are a number of GSS errors >> in dirsrv and bind fails with something like: >> >> named-pkcs11[2212]: ObjectStore.cpp(74): Failed to open token >> e919db16-6329-406c-6ae4-120ad68508c4 >> named-pkcs11[2212]: sha1.c:92: fatal error: >> named-pkcs11[2212]: RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, >> isc_boolean_true, isc_boolean_false, isc_boolean_false, ((void *)0), >> 0) == 0) failed >> >> Any help would be appreciated >> >> >> -M >> >> >> > > > -- > Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Oct 30 18:35:57 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 30 Oct 2014 14:35:57 -0400 Subject: [Freeipa-users] Woes adding a samba server to the ipa domain In-Reply-To: <1414640322.3112.30.camel@toron.pzo.lgs.com.ve> References: <1413810952.3012.22.camel@toron.pzo.lgs.com.ve> <5445B498.9090608@redhat.com> <1413893951.3184.15.camel@toron.pzo.lgs.com.ve> <20141023103255.GA2826@localhost.localdomain> <1414612459.3112.22.camel@toron.pzo.lgs.com.ve> <1414616519.3112.28.camel@toron.pzo.lgs.com.ve> <54518B01.3050405@redhat.com> <1414640322.3112.30.camel@toron.pzo.lgs.com.ve> Message-ID: <5452850D.2040003@redhat.com> On 10/29/2014 11:38 PM, Loris Santamaria wrote: > El mi?, 29-10-2014 a las 20:49 -0400, Dmitri Pal escribi?: >> On 10/29/2014 05:01 PM, Loris Santamaria wrote: >> >>> El mi?, 29-10-2014 a las 21:40 +0100, John Obaterspok escribi?: >>>> Hello, >>>> >>>> >>>> I've tried this as well. My IPA is not connected to an AD. My smb.conf >>>> looks almost the same. The differences are: >>>> - I got the default workgroup set (MY or something) >>>> - No FILE:/ prefix for keytab file >>>> >>>> >>>> I had the samba and ipserver on the same box so I just had to add the >>>> cifs server and get keytab file in the same way. >>>> I was a bit surprised to see that accessing samba using "smbclient -k >>>> \\..." worked right away from a linux box. Then stopped working if I >>>> did kdestroy. >>>> >>>> >>>> But, I never got it to work from Windows. The Windows PC is not joined >>>> to any AD, it uses MIT Kerb client 4.0.1 and I successfully get tickes >>>> and can sshlogin via putty without password. >>>> >>>> >>>> Any ideas on how to get this going from Windows as well? >>> I guess you should prepare the ipa server for a windows domain trust >>> (even if you won't setup any trust with an ad domain), with >>> ipa-adtrust-install. Beware that it will overwrite your smb.conf. >>> >>> With that configuration and the steps described in >>> http://www.redhat.com/archives/freeipa-users/2013-September/msg00226.html you will be able to use the native windows kerberos libraries and you should be able to open a samba share with your kerberos credentials. >>> >>> Best regards >>> >>> >>> >>> >> Would by any chance you be able to create a HowTo solution on the >> FreeIPA wiki? >> Seems like it would be a simple cut&paste from couple mails. Thanks in >> advance! > Here it is: > > http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA > > Best regards > > Thanks! -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Oct 30 18:36:22 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 30 Oct 2014 19:36:22 +0100 Subject: [Freeipa-users] Errors upgrading 4.0.1 to 4.1 In-Reply-To: <545280EA.40604@gmail.com> References: <54527F90.3000407@redhat.com> <545280EA.40604@gmail.com> Message-ID: <54528526.4040500@redhat.com> On 30/10/14 19:18, Michael Lasevich wrote: > Makes sense. What is the solution here? > > I have the latest 389-ds installed but still getting "allowWeakCipher" > error - how to I get around that? > > -M > Sorry I don't know, I CCied Ludwig, he is DS guru. Martin^2 > > On 10/30/14, 11:12 AM, Martin Basti wrote: >> On 24/10/14 05:17, Michael Lasevich wrote: >>> While upgrading from 4.0.1. to 4.1 on fedora 20 got following on one >>> of the two boxes: >>> >>> Upgrade failed with attribute "allowWeakCipher" not allowed >>> IPA upgrade failed. >>> Unexpected error >>> DuplicateEntry: This entry already exists >>> >> >> Named errors are caused by cascade effect, if ldap schema and entry >> updates failed, there is misconfigured DS plugin which is responsible >> to keep DNSSEC keys DN unique, what causes duplication errors. >> DuplicateEntry exception is fatal, so dnskeysyncd installation will >> not continue, >> what causes there are not appropriate permissions for token database, >> and named-pkcs11 can't read tokens. >>> >>> >>> It seems the ipa no longer starts up after this. The replica server >>> seems to have had same error,but it runs just fine. >>> >>> From digging around, it appears that there are a number of GSS >>> errors in dirsrv and bind fails with something like: >>> >>> named-pkcs11[2212]: ObjectStore.cpp(74): Failed to open token >>> e919db16-6329-406c-6ae4-120ad68508c4 >>> named-pkcs11[2212]: sha1.c:92: fatal error: >>> named-pkcs11[2212]: RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, >>> isc_boolean_true, isc_boolean_false, isc_boolean_false, ((void *)0), >>> 0) == 0) failed >>> >>> Any help would be appreciated >>> >>> >>> -M >>> >>> >>> >> >> >> -- >> Martin Basti > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Oct 30 18:39:23 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 30 Oct 2014 14:39:23 -0400 Subject: [Freeipa-users] IPA Server 4.* error on Centos7 In-Reply-To: References: Message-ID: <545285DB.9000605@redhat.com> On 10/30/2014 12:45 PM, Lucas Diedrich wrote: > Hello for all, > > I'm trying to install the IPA Server version 4.* on CentOS 7 using the > EPEL 7 and the MKOSEK FreeIPA Repo (for 4.* version). But this is > giving me a package dependency error. > > After a search i found this Thread > (https://www.redhat.com/archives/freeipa-users/2014-October/msg00200.html) > wit the same error but without a good fix i think, it is possible that > we contact someone to fix this issue? > > I really apreciate installing the 4.* version instead of 3.* of > FreeIPA on my production environment if there is a way to fix this. > > Thanks. > > There are plans to fix this soon. We want to have 4.1 work on CentOS but we need to do some heavy lifting first. Please stay tuned. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.taylor at speedcast.com Fri Oct 31 01:23:29 2014 From: david.taylor at speedcast.com (David Taylor) Date: Fri, 31 Oct 2014 01:23:29 +0000 Subject: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 Message-ID: <5A645F9F0CA5764F8D1F624A2C5429EA0E4BE7FD@SC-EXCHANGE.speedcast.com> I just recently updated one of our test servers from CentOS 6.5 to CentOS 6.6, after which I noticed that IPA logons were no longer available. From what I can see the upgrade includes quite a few changes with regard to sssd. - NTP is up and synced on the Auth servers and the client. - DNS is working to the IPA servers - I can do a kinit for users with no problem - I have uninstalled the ipa client, deleted the host profile on the IPA server and one a rejoin. The rejoin worked but the problem is the same. Software versions using - rpm -qa | grep -i ipa - rpm -qa | grep -i sssd Software versions before: libipa_hbac-1.9.2-129.el6_5.4.x86_64 device-mapper-multipath-0.4.9-72.el6_5.4.x86_64 libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 ipa-python-3.0.0-37.el6.x86_64 ipa-client-3.0.0-37.el6.x86_64 device-mapper-multipath-libs-0.4.9-72.el6_5.4.x86_64 sssd-1.9.2-129.el6_5.4.x86_64 sssd-client-1.9.2-129.el6_5.4.x86_64 Software version after: sssd-ipa-1.11.6-30.el6.x86_64 libipa_hbac-1.11.6-30.el6.x86_64 device-mapper-multipath-libs-0.4.9-80.el6.x86_64 ipa-client-3.0.0-42.el6.centos.x86_64 libipa_hbac-python-1.11.6-30.el6.x86_64 ipa-python-3.0.0-42.el6.centos.x86_64 device-mapper-multipath-0.4.9-80.el6.x86_64 sssd-ldap-1.11.6-30.el6.x86_64 sssd-ad-1.11.6-30.el6.x86_64 python-sssdconfig-1.11.6-30.el6.noarch sssd-client-1.11.6-30.el6.x86_64 sssd-krb5-common-1.11.6-30.el6.x86_64 sssd-ipa-1.11.6-30.el6.x86_64 sssd-common-1.11.6-30.el6.x86_64 sssd-proxy-1.11.6-30.el6.x86_64 sssd-common-pac-1.11.6-30.el6.x86_64 sssd-krb5-1.11.6-30.el6.x86_64 sssd-1.11.6-30.el6.x86_64 The /var/log/secure logs show the following Oct 31 10:38:30 test01 sshd[2790]: Invalid user dtaylor from Oct 31 10:38:30 test01 sshd[2791]: input_userauth_request: invalid user dtaylor Oct 31 10:38:30 test01 sshd[2790]: pam_unix(sshd:auth): check pass; user unknown Oct 31 10:38:30 test01 sshd[2790]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost= Oct 31 10:38:30 test01 sshd[2790]: pam_succeed_if(sshd:auth): error retrieving information about user dtaylor The /var/log/audit/audit.log logs show the following type=CRYPTO_KEY_USER msg=audit(1414715857.270:107): user pid=5831 uid=0 auid=0 ses=1 msg='op=destroy kind=server fp=5e:ee:58:a2:25:ec:16:3e:8c:61:01:e6:de:76:3d:32 direction=? spid=5831 suid=0 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' type=CRYPTO_KEY_USER msg=audit(1414715857.270:108): user pid=5831 uid=0 auid=0 ses=1 msg='op=destroy kind=server fp=d0:6f:2f:5f:49:44:94:f2:b2:4e:15:43:69:89:9c:1d direction=? spid=5831 suid=0 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' type=CRYPTO_SESSION msg=audit(1414715857.272:109): user pid=5830 uid=0 auid=0 ses=1 msg='op=start direction=from-client cipher=aes256-ctr ksize=256 spid=5831 suid=74 rport=44361 laddr= lport=22 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' type=CRYPTO_SESSION msg=audit(1414715857.272:110): user pid=5830 uid=0 auid=0 ses=1 msg='op=start direction=from-server cipher=aes256-ctr ksize=256 spid=5831 suid=74 rport=44361 laddr= lport=22 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' type=USER_LOGIN msg=audit(1414715857.310:111): user pid=5830 uid=0 auid=0 ses=1 msg='op=login acct=28756E6B6E6F776E207573657229 exe="/usr/sbin/sshd" hostname=? addr= terminal=ssh res=failed' type=USER_AUTH msg=audit(1414715859.211:112): user pid=5830 uid=0 auid=0 ses=1 msg='op=PAM:authentication acct="?" exe="/usr/sbin/sshd" hostname= addr= terminal=ssh res=failed' type=USER_AUTH msg=audit(1414715859.212:113): user pid=5830 uid=0 auid=0 ses=1 msg='op=password acct=28696E76616C6964207573657229 exe="/usr/sbin/sshd" hostname=? addr= terminal=ssh res=failed' type=CRYPTO_KEY_USER msg=audit(1414715862.076:114): user pid=5830 uid=0 auid=0 ses=1 msg='op=destroy kind=session fp=? direction=both spid=5831 suid=74 rport=44361 laddr= lport=22 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' type=CRYPTO_KEY_USER msg=audit(1414715862.078:115): user pid=5830 uid=0 auid=0 ses=1 msg='op=destroy kind=server fp=5e:ee:58:a2:25:ec:16:3e:8c:61:01:e6:de:76:3d:32 direction=? spid=5830 suid=0 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' type=CRYPTO_KEY_USER msg=audit(1414715862.079:116): user pid=5830 uid=0 auid=0 ses=1 msg='op=destroy kind=server fp=d0:6f:2f:5f:49:44:94:f2:b2:4e:15:43:69:89:9c:1d direction=? spid=5830 suid=0 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' type=USER_LOGIN msg=audit(1414715862.079:117): user pid=5830 uid=0 auid=0 ses=1 msg='op=login acct=28696E76616C6964207573657229 exe="/usr/sbin/sshd" hostname=? addr= terminal=ssh res=failed' The /var/log/sssd/sssd_.log logs show the following ==> /var/log/sssd/sssd_.log <== (Fri Oct 31 12:13:39 2014) [sssd[be[]]] [sbus_dispatch] (0x4000): dbus conn: 0x16699b0 (Fri Oct 31 12:13:39 2014) [sssd[be[]]] [sbus_dispatch] (0x4000): Dispatching. (Fri Oct 31 12:13:39 2014) [sssd[be[]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Fri Oct 31 12:13:39 2014) [sssd[be[]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Fri Oct 31 12:13:39 2014) [sssd[be[]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping] -------------- next part -------------- An HTML attachment was scrubbed... URL: From tlau at tetrioncapital.com Fri Oct 31 04:19:56 2014 From: tlau at tetrioncapital.com (Thomas Lau) Date: Fri, 31 Oct 2014 12:19:56 +0800 Subject: [Freeipa-users] vsftpd PAM setup problem Message-ID: Hi All, I am using vsftpd and auth against PAM (eventually to sss), but I can't login even using admin account, anyone could provide some hints on how to make it work? here is the detail log on sssd_us.domain.com.log: (Fri Oct 31 12:00:36 2014) [sssd[be[us.domain.com]]] [sbus_dispatch] (0x4000): dbus conn: 0xfb8b20 (Fri Oct 31 12:00:36 2014) [sssd[be[us.domain.com]]] [sbus_dispatch] (0x4000): Dispatching. (Fri Oct 31 12:00:36 2014) [sssd[be[us.domain.com]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sbus_dispatch] (0x4000): dbus conn: 0x1001350 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sbus_dispatch] (0x4000): Dispatching. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [be_get_account_info] (0x0100): Got request for [3][1][name=user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [be_req_set_domain] (0x0400): Changing request domain from [us.domain.com] to [us.domain.com] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xffc1d0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xffe330 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0xffc1d0 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0xffe330 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0xffc1d0 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xffc1d0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x10033c0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0xffc1d0 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x100a640 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x101e160 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x10033c0 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0xffc1d0 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x100a640 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x101e160 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x100a640 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_initgr_send] (0x4000): Retrieving info for initgroups call (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_initgr_next_base] (0x0400): Searching for users with base [cn=accounts,dc=hk,dc=tetrioncapital,dc=com] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=user1)(objectclass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))][cn=accounts,dc=hk,dc=tetrioncapital,dc=com]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [homeDirectory] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPrincipalName] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTSecurityIdentifier] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 24 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_process_result] (0x2000): Trace: sh[0xfeddd0], connected[1], ops[0xffb2d0], ldap[0xfeb760] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_entry] (0x4000): OriginalDN: [uid=user1,cn=users,cn=accounts,dc=hk,dc=tetrioncapital,dc=com]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [uid] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [uidNumber] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [gidNumber] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [gecos] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [homeDirectory] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [loginShell] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [krbPrincipalName] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberOf] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [nsUniqueId] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [modifyTimestamp] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [entryUSN] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [krbLastPwdChange] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [krbPasswordExpiration] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_process_result] (0x2000): Trace: sh[0xfeddd0], connected[1], ops[0xffb2d0], ldap[0xfeb760] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_initgr_user] (0x4000): Receiving info for the user (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_initgr_user] (0x4000): Storing the user (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_save_user] (0x0400): Save user (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_save_user] (0x4000): objectSID: not available for group [(null)]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_primary_name] (0x0400): Processing object user1 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_save_user] (0x0400): Processing user user1 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_save_user] (0x2000): Adding originalDN [uid=user1,cn=users,cn=accounts,dc=hk,dc=tetrioncapital,dc=com] to attributes of [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_save_user] (0x0400): Adding original memberOf attributes to [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original mod-Timestamp [20141031034112Z] to attributes of [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_save_user] (0x0400): Adding user principal [user1 at us.domain.com] to attributes of [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowLastChange is not available for [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowMin is not available for [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowMax is not available for [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowWarning is not available for [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowInactive is not available for [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowExpire is not available for [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowFlag is not available for [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding krbLastPwdChange [20141014112721Z] to attributes of [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding krbPasswordExpiration [20150112112721Z] to attributes of [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): pwdAttribute is not available for [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): authorizedService is not available for [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): adAccountExpires is not available for [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): adUserAccountControl is not available for [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): nsAccountLock is not available for [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): authorizedHost is not available for [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginDisabled is not available for [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginExpirationTime is not available for [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginAllowedTimeMap is not available for [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_attrs_add_ldap_attr] (0x2000): sshPublicKey is not available for [user1]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_save_user] (0x0400): Storing info for user user1 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 1) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1008580 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x10086b0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1008580 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x10086b0 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1008580 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 2) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1014920 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x10149e0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1014920 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x10149e0 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1014920 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 2) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_remove_attrs] (0x2000): Removing attribute [userPassword] from [user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1008240 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x10086b0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1008240 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x10086b0 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1008240 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_remove_attrs] (0x2000): Removing attribute [objectSIDString] from [user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x10086b0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1008240 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x10086b0 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x1008240 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x10086b0 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowLastChange] from [user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1008240 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x10086b0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1008240 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x10086b0 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1008240 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowMin] from [user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1008240 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1035140 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1008240 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x1035140 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1008240 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowMax] from [user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1008240 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x10086b0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1008240 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x10086b0 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1008240 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowWarning] from [user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1008240 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1035140 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1008240 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x1035140 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1008240 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowInactive] from [user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1008240 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x10086b0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1008240 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x10086b0 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1008240 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowExpire] from [user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1008240 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1016320 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1008240 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x1016320 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1008240 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowFlag] from [user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1008240 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x10086b0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1008240 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x10086b0 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1008240 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_remove_attrs] (0x2000): Removing attribute [pwdAttribute] from [user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1035140 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1008240 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1035140 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x1008240 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1035140 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_remove_attrs] (0x2000): Removing attribute [authorizedService] from [user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1035140 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x10086b0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1035140 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x10086b0 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1035140 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_remove_attrs] (0x2000): Removing attribute [adAccountExpires] from [user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1035140 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1008240 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1035140 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x1008240 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1035140 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_remove_attrs] (0x2000): Removing attribute [adUserAccountControl] from [user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1035140 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x10086b0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1035140 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x10086b0 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1035140 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_remove_attrs] (0x2000): Removing attribute [nsAccountLock] from [user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x10086b0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1035140 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x10086b0 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x1035140 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x10086b0 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_remove_attrs] (0x2000): Removing attribute [authorizedHost] from [user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1035140 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x10086b0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1035140 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x10086b0 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1035140 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_remove_attrs] (0x2000): Removing attribute [ndsLoginDisabled] from [user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1035140 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1008240 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1035140 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x1008240 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1035140 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_remove_attrs] (0x2000): Removing attribute [ndsLoginExpirationTime] from [user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1035140 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x10086b0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1035140 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x10086b0 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1035140 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_remove_attrs] (0x2000): Removing attribute [ndsLoginAllowedTimeMap] from [user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1035140 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1008240 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1035140 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x1008240 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1035140 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_remove_attrs] (0x2000): Removing attribute [sshPublicKey] from [user1] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1035140 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x10086b0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1035140 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x10086b0 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1035140 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_initgr_user] (0x4000): Commit change (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x10083f0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1008520 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x10083f0 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x1008520 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x10083f0 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_initgr_user] (0x4000): Process user's groups (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_primary_name] (0x0400): Processing object user1 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_has_deref_support] (0x0400): The server supports deref method OpenLDAP (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_deref_search_send] (0x2000): Server supports OpenLDAP deref (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_x_deref_search_send] (0x0400): Dereferencing entry [uid=user1,cn=users,cn=accounts,dc=hk,dc=tetrioncapital,dc=com] using OpenLDAP deref (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [no filter][uid=user1,cn=users,cn=accounts,dc=hk,dc=tetrioncapital,dc=com]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTSecurityIdentifier] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 25 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_process_result] (0x2000): Trace: sh[0xfeddd0], connected[1], ops[0x10008a0], ldap[0xfeb760] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_process_result] (0x2000): Trace: sh[0xfeddd0], connected[1], ops[0x10008a0], ldap[0xfeb760] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_x_deref_parse_entry] (0x0400): Got deref control (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x1000): Dereferenced DN: cn=admins,cn=groups,cn=accounts,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: top (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: groupofnames (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: posixgroup (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipausergroup (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipaobject (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: nestedGroup (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Found map for objectclass 'posixgroup' (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x2000): Dereferenced attribute: objectClass (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x2000): Dereferenced attribute: cn (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced attribute value: admins (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x2000): Dereferenced attribute: gidNumber (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced attribute value: 1218400000 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x2000): Dereferenced attribute: member (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced attribute value: uid=admin,cn=users,cn=accounts,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced attribute value: uid=user1,cn=users,cn=accounts,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced attribute value: uid=kchang,cn=users,cn=accounts,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced attribute value: uid=rzhou,cn=users,cn=accounts,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced attribute value: uid=ftpuser1,cn=users,cn=accounts,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x2000): Dereferenced attribute: nsUniqueId (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced attribute value: 7935eea2-444411e4-ab0bc4d5-2327aad8 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x2000): Dereferenced attribute: modifyTimestamp (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced attribute value: 20141031034112Z (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x2000): Dereferenced attribute: entryUSN (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced attribute value: 144246 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x1000): Dereferenced DN: cn=replication administrators,cn=privileges,cn=pbac,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: top (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: groupofnames (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: nestedgroup (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x1000): Dereferenced DN: cn=add replication agreements,cn=permissions,cn=pbac,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: top (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: groupofnames (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipapermission (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x1000): Dereferenced DN: cn=modify replication agreements,cn=permissions,cn=pbac,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: top (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: groupofnames (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipapermission (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x1000): Dereferenced DN: cn=remove replication agreements,cn=permissions,cn=pbac,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: top (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: groupofnames (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipapermission (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x1000): Dereferenced DN: cn=modify dna range,cn=permissions,cn=pbac,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: top (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: groupofnames (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipapermission (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x1000): Dereferenced DN: cn=host enrollment,cn=privileges,cn=pbac,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: top (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: groupofnames (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: nestedgroup (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x1000): Dereferenced DN: cn=manage host keytab,cn=permissions,cn=pbac,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: top (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: groupofnames (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipapermission (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x1000): Dereferenced DN: cn=enroll a host,cn=permissions,cn=pbac,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: top (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: groupofnames (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipapermission (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x1000): Dereferenced DN: cn=add krbprincipalname to a host,cn=permissions,cn=pbac,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: top (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: groupofnames (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipapermission (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x1000): Dereferenced DN: cn=unlock user accounts,cn=permissions,cn=pbac,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: top (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: groupofnames (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipapermission (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x1000): Dereferenced DN: cn=manage service keytab,cn=permissions,cn=pbac,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: top (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: groupofnames (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipapermission (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x1000): Dereferenced DN: ipauniqueid=7a56467a-4444-11e4-8012-000c298bb2ca,cn=hbac,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipaassociation (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipahbacrule (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x1000): Dereferenced DN: ipauniqueid=73b86006-44ac-11e4-9c4a-000c298bb2ca,cn=sudorules,cn=sudo,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipaassociation (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipasudorule (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x1000): Dereferenced DN: ipauniqueid=3b7d04fc-4629-11e4-88d5-000c298bb2ca,cn=hbac,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipaassociation (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipahbacrule (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x1000): Dereferenced DN: cn=ipausers,cn=groups,cn=accounts,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: top (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: groupofnames (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: nestedgroup (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipausergroup (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipaobject (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x1000): Dereferenced DN: ipauniqueid=3c9d5d6c-60a7-11e4-9138-000c298bb2ca,cn=hbac,dc=hk,dc=tetrioncapital,dc=com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipaassociation (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_parse_deref] (0x4000): Dereferenced objectClass value: ipahbacrule (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_x_deref_parse_entry] (0x0400): All deref results from a single control parsed (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_process_result] (0x2000): Trace: sh[0xfeddd0], connected[1], ops[0x10008a0], ldap[0xfeb760] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_done] (0x2000): Total count [0] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 1) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x10097e0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x10085e0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x10097e0 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x10085e0 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x10097e0 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_primary_name] (0x0400): Processing object admins (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_get_direct_parents] (0x2000): searching sysdb with filter [(&(objectClass=group)(member=name=admins,cn=groups,cn=us.domain.com ,cn=sysdb))] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1009730 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1007b70 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1009730 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x1007b70 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1009730 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_get_direct_parents] (0x1000): admins is a member of 0 sysdb groups (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_initgr_nested_get_direct_parents] (0x4000): Looking up direct parents for group [cn=admins,cn=groups,cn=accounts,dc=hk,dc=tetrioncapital,dc=com] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_initgr_nested_get_direct_parents] (0x4000): The group [cn=admins,cn=groups,cn=accounts,dc=hk,dc=tetrioncapital,dc=com] has 0 direct parents (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_initgr_nested_get_membership_diff] (0x1000): The group admins is a direct member of 0 LDAP groups (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 1) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 2) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_initgr_store_user_memberships] (0x1000): The user user1 is a direct member of 1 LDAP groups (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_get_direct_parents] (0x2000): searching sysdb with filter [(&(objectClass=group)(member=name=user1,cn=users,cn=us.domain.com ,cn=sysdb))] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1009730 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1007b70 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0x1009730 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0x1007b70 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0x1009730 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sysdb_get_direct_parents] (0x1000): user1 is a member of 1 sysdb groups (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 1) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_initgr_store_user_memberships] (0x2000): Updating memberships for user1 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): start ldb transaction (nesting: 2) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_get_initgr_done] (0x4000): Initgroups done (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_id_op_done] (0x4000): releasing operation connection (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sbus_add_timeout] (0x2000): 0xfff5f0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_process_result] (0x2000): Trace: sh[0xfeddd0], connected[1], ops[(nil)], ldap[0xfeb760] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sbus_remove_timeout] (0x2000): 0xfff5f0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sbus_dispatch] (0x4000): dbus conn: 0xff9ba0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sbus_dispatch] (0x4000): Dispatching. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sbus_dispatch] (0x4000): dbus conn: 0x1001350 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sbus_dispatch] (0x4000): Dispatching. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [be_req_set_domain] (0x0400): Changing request domain from [us.domain.com] to [us.domain.com] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [be_pam_handler] (0x0100): Got request with the following data (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [pam_print_data] (0x0100): domain: us.domain.com (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [pam_print_data] (0x0100): user: user1 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [pam_print_data] (0x0100): service: vsftpd (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [pam_print_data] (0x0100): tty: ftp (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [pam_print_data] (0x0100): ruser: user1 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [pam_print_data] (0x0100): rhost: 10.0.0.102 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [pam_print_data] (0x0100): authtok type: 1 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [pam_print_data] (0x0100): newauthtok type: 0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [pam_print_data] (0x0100): priv: 1 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [pam_print_data] (0x0100): cli_pid: 20732 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xffeed0 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xfff830 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0xffeed0 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0xfff830 "ltdb_timeout" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0xffeed0 "ltdb_callback" (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [switch_creds] (0x0200): Switch user to [1218400003][1218400003]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [switch_creds] (0x0200): Switch user to [0][0]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [krb5_auth_send] (0x4000): Ccache_file is [FILE:/tmp/krb5cc_1218400003_TBYVAQ] and is not active and TGT is valid. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [get_server_status] (0x1000): Status of server 'kerberos2.us.domain.com' is 'working' (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [get_port_status] (0x1000): Port status of port 389 for server 'kerberos2.us.domain.com' is 'working' (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [get_server_status] (0x1000): Status of server 'kerberos2.us.domain.com' is 'working' (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [be_resolve_server_process] (0x0200): Found address for server kerberos2.us.domain.com: [10.0.0.9] TTL 1200 (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [krb5_auth_prepare_ccache_name] (0x4000): Recreating ccache file. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [check_parent_stat] (0x0020): Private directory can only be created below a directory belonging to root or to [1218400003][1218400003]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [create_ccache_dir] (0x0080): check_parent_stat failed for directory [/tmp]. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [krb5_auth_prepare_ccache_name] (0x0040): ccache creation failed. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed. (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 4, ) [Success] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [be_pam_handler_callback] (0x0100): Sending result [4][us.domain.com] (Fri Oct 31 12:00:39 2014) [sssd[be[us.domain.com]]] [be_pam_handler_callback] (0x0100): Sent result [4][us.domain.com] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sbus_dispatch] (0x4000): dbus conn: 0xff9ba0 (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sbus_dispatch] (0x4000): Dispatching. (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=*] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [be_req_set_domain] (0x0400): Changing request domain from [us.domain.com] to [us.domain.com] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_search_user_next_base] (0x0400): Searching for users with base [cn=accounts,dc=hk,dc=tetrioncapital,dc=com] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=\2a)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))][cn=accounts,dc=hk,dc=tetrioncapital,dc=com]. (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [homeDirectory] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPrincipalName] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTSecurityIdentifier] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 26 (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_process_result] (0x2000): Trace: sh[0xfeddd0], connected[1], ops[0x1003e00], ldap[0xfeb760] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_search_user_process] (0x0400): Search for users, returned 0 results. (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_get_users_done] (0x0040): Failed to retrieve users (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_id_op_done] (0x4000): releasing operation connection (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xffaca0 (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xffadd0 (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0xffaca0 "ltdb_callback" (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0xffadd0 "ltdb_timeout" (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0xffaca0 "ltdb_callback" (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sysdb_search_user_by_name] (0x0400): No such entry (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sysdb_search_groups] (0x2000): Search groups with filter: (&(objectclass=group)(ghost=\2a)) (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xffaca0 (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xffaad0 (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Running timer event 0xffaca0 "ltdb_callback" (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Destroying timer event 0xffaad0 "ltdb_timeout" (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [ldb] (0x4000): Ending timer event 0xffaca0 "ltdb_callback" (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sysdb_search_groups] (0x2000): No such entry (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sysdb_delete_user] (0x0400): Error: 2 (No such file or directory) (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_process_result] (0x2000): Trace: sh[0xfeddd0], connected[1], ops[(nil)], ldap[0xfeb760] (Fri Oct 31 12:00:41 2014) [sssd[be[us.domain.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Oct 31 05:40:01 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 31 Oct 2014 07:40:01 +0200 Subject: [Freeipa-users] vsftpd PAM setup problem In-Reply-To: References: Message-ID: <20141031054001.GA4107@redhat.com> On Fri, 31 Oct 2014, Thomas Lau wrote: >Hi All, > >I am using vsftpd and auth against PAM (eventually to sss), but I can't >login even using admin account, anyone could provide some hints on how to >make it work? here is the detail log on sssd_us.domain.com.log: You need to fix permissions of /tmp: >[krb5_auth_prepare_ccache_name] (0x4000): Recreating ccache file. >[check_parent_stat] (0x0020): Private directory can only be created below a directory belonging to root or to [1218400003][1218400003]. >[create_ccache_dir] (0x0080): check_parent_stat failed for directory [/tmp]. >[krb5_auth_prepare_ccache_name] (0x0040): ccache creation failed. >[ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed. >[be_pam_handler_callback] (0x0100): Backend returned: (0, 4, ) [Success] -- / Alexander Bokovoy From tlau at tetrioncapital.com Fri Oct 31 06:53:19 2014 From: tlau at tetrioncapital.com (Thomas Lau) Date: Fri, 31 Oct 2014 14:53:19 +0800 Subject: [Freeipa-users] vsftpd PAM setup problem In-Reply-To: <20141031054001.GA4107@redhat.com> References: <20141031054001.GA4107@redhat.com> Message-ID: Thanks, all good now. On Fri, Oct 31, 2014 at 1:40 PM, Alexander Bokovoy wrote: > On Fri, 31 Oct 2014, Thomas Lau wrote: > >> Hi All, >> >> I am using vsftpd and auth against PAM (eventually to sss), but I can't >> login even using admin account, anyone could provide some hints on how to >> make it work? here is the detail log on sssd_us.domain.com.log: >> > > You need to fix permissions of /tmp: > >> [krb5_auth_prepare_ccache_name] (0x4000): Recreating ccache file. >> [check_parent_stat] (0x0020): Private directory can only be created below >> a directory belonging to root or to [1218400003][1218400003]. >> [create_ccache_dir] (0x0080): check_parent_stat failed for directory >> [/tmp]. >> [krb5_auth_prepare_ccache_name] (0x0040): ccache creation failed. >> [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed. >> [be_pam_handler_callback] (0x0100): Backend returned: (0, 4, ) >> [Success] >> > > > -- > / Alexander Bokovoy > -- Thomas Lau Director of Infrastructure Tetrion Capital Limited Mobile: +852-9323-9670 Address: 20/F, IFC 1, Central district, Hong Kong -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Fri Oct 31 08:30:45 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 31 Oct 2014 09:30:45 +0100 Subject: [Freeipa-users] Errors upgrading 4.0.1 to 4.1 In-Reply-To: <54528526.4040500@redhat.com> References: <54527F90.3000407@redhat.com> <545280EA.40604@gmail.com> <54528526.4040500@redhat.com> Message-ID: <545348B5.1090904@redhat.com> On 10/30/2014 07:36 PM, Martin Basti wrote: > On 30/10/14 19:18, Michael Lasevich wrote: >> Makes sense. What is the solution here? >> >> I have the latest 389-ds installed but still getting >> "allowWeakCipher" error - how to I get around that? >> >> -M >> > Sorry I don't know, I CCied Ludwig, he is DS guru. I already asked to verify the schema files: can you check your schema files for the definition of the nsEncryptionConfig objectclass, it should be only in 01core389.ldif and contain allowWeakCipher, but it could have been added also to 99user.ldif during replication when schema changes have been consolidated and what is the latest ds version you are using: rpm -q 389-ds-base > Martin^2 > >> >> On 10/30/14, 11:12 AM, Martin Basti wrote: >>> On 24/10/14 05:17, Michael Lasevich wrote: >>>> While upgrading from 4.0.1. to 4.1 on fedora 20 got following on >>>> one of the two boxes: >>>> >>>> Upgrade failed with attribute "allowWeakCipher" not allowed >>>> IPA upgrade failed. >>>> Unexpected error >>>> DuplicateEntry: This entry already exists >>>> >>> >>> Named errors are caused by cascade effect, if ldap schema and entry >>> updates failed, there is misconfigured DS plugin which is >>> responsible to keep DNSSEC keys DN unique, what causes duplication >>> errors. DuplicateEntry exception is fatal, so dnskeysyncd >>> installation will not continue, >>> what causes there are not appropriate permissions for token >>> database, and named-pkcs11 can't read tokens. >>>> >>>> >>>> It seems the ipa no longer starts up after this. The replica server >>>> seems to have had same error,but it runs just fine. >>>> >>>> From digging around, it appears that there are a number of GSS >>>> errors in dirsrv and bind fails with something like: >>>> >>>> named-pkcs11[2212]: ObjectStore.cpp(74): Failed to open token >>>> e919db16-6329-406c-6ae4-120ad68508c4 >>>> named-pkcs11[2212]: sha1.c:92: fatal error: >>>> named-pkcs11[2212]: RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, >>>> isc_boolean_true, isc_boolean_false, isc_boolean_false, ((void >>>> *)0), 0) == 0) failed >>>> >>>> Any help would be appreciated >>>> >>>> >>>> -M >>>> >>>> >>>> >>> >>> >>> -- >>> Martin Basti >> > > > -- > Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Fri Oct 31 08:35:18 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 31 Oct 2014 09:35:18 +0100 Subject: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 In-Reply-To: <5A645F9F0CA5764F8D1F624A2C5429EA0E4BE7FD@SC-EXCHANGE.speedcast.com> References: <5A645F9F0CA5764F8D1F624A2C5429EA0E4BE7FD@SC-EXCHANGE.speedcast.com> Message-ID: > On 31 Oct 2014, at 02:23, David Taylor wrote: > > I just recently updated one of our test servers from CentOS 6.5 to CentOS 6.6, after which I noticed that IPA logons were no longer available. From what I can see the upgrade includes quite a few changes with regard to sssd. > > - NTP is up and synced on the Auth servers and the client. > - DNS is working to the IPA servers > - I can do a kinit for users with no problem > - I have uninstalled the ipa client, deleted the host profile on the IPA server and one a rejoin. The rejoin worked but the problem is the same. > > Software versions using > - rpm -qa | grep -i ipa > - rpm -qa | grep -i sssd > > Software versions before: > libipa_hbac-1.9.2-129.el6_5.4.x86_64 > device-mapper-multipath-0.4.9-72.el6_5.4.x86_64 > libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 > ipa-python-3.0.0-37.el6.x86_64 > ipa-client-3.0.0-37.el6.x86_64 > device-mapper-multipath-libs-0.4.9-72.el6_5.4.x86_64 > sssd-1.9.2-129.el6_5.4.x86_64 > sssd-client-1.9.2-129.el6_5.4.x86_64 > > Software version after: > sssd-ipa-1.11.6-30.el6.x86_64 > libipa_hbac-1.11.6-30.el6.x86_64 > device-mapper-multipath-libs-0.4.9-80.el6.x86_64 > ipa-client-3.0.0-42.el6.centos.x86_64 > libipa_hbac-python-1.11.6-30.el6.x86_64 > ipa-python-3.0.0-42.el6.centos.x86_64 > device-mapper-multipath-0.4.9-80.el6.x86_64 > sssd-ldap-1.11.6-30.el6.x86_64 > sssd-ad-1.11.6-30.el6.x86_64 > python-sssdconfig-1.11.6-30.el6.noarch > sssd-client-1.11.6-30.el6.x86_64 > sssd-krb5-common-1.11.6-30.el6.x86_64 > sssd-ipa-1.11.6-30.el6.x86_64 > sssd-common-1.11.6-30.el6.x86_64 > sssd-proxy-1.11.6-30.el6.x86_64 > sssd-common-pac-1.11.6-30.el6.x86_64 > sssd-krb5-1.11.6-30.el6.x86_64 > sssd-1.11.6-30.el6.x86_64 > The /var/log/secure logs show the following > > Oct 31 10:38:30 test01 sshd[2790]: Invalid user dtaylor from > Oct 31 10:38:30 test01 sshd[2791]: input_userauth_request: invalid user dtaylor > Oct 31 10:38:30 test01 sshd[2790]: pam_unix(sshd:auth): check pass; user unknown > Oct 31 10:38:30 test01 sshd[2790]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost= > Oct 31 10:38:30 test01 sshd[2790]: pam_succeed_if(sshd:auth): error retrieving information about user dtaylor > Do you also see pam_sss being mentioned at all in your /var/log/secure at all? Can you paste your PAM configuration? It?s expected that pam_unix fails to find the IPA user, but I would also expect the PAM stack to ask pam_sss next... > The /var/log/audit/audit.log logs show the following > > type=CRYPTO_KEY_USER msg=audit(1414715857.270:107): user pid=5831 uid=0 auid=0 ses=1 msg='op=destroy kind=server fp=5e:ee:58:a2:25:ec:16:3e:8c:61:01:e6:de:76:3d:32 direction=? spid=5831 suid=0 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' > type=CRYPTO_KEY_USER msg=audit(1414715857.270:108): user pid=5831 uid=0 auid=0 ses=1 msg='op=destroy kind=server fp=d0:6f:2f:5f:49:44:94:f2:b2:4e:15:43:69:89:9c:1d direction=? spid=5831 suid=0 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' > type=CRYPTO_SESSION msg=audit(1414715857.272:109): user pid=5830 uid=0 auid=0 ses=1 msg='op=start direction=from-client cipher=aes256-ctr ksize=256 spid=5831 suid=74 rport=44361 laddr= lport=22 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' > type=CRYPTO_SESSION msg=audit(1414715857.272:110): user pid=5830 uid=0 auid=0 ses=1 msg='op=start direction=from-server cipher=aes256-ctr ksize=256 spid=5831 suid=74 rport=44361 laddr= lport=22 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' > type=USER_LOGIN msg=audit(1414715857.310:111): user pid=5830 uid=0 auid=0 ses=1 msg='op=login acct=28756E6B6E6F776E207573657229 exe="/usr/sbin/sshd" hostname=? addr= terminal=ssh res=failed' > type=USER_AUTH msg=audit(1414715859.211:112): user pid=5830 uid=0 auid=0 ses=1 msg='op=PAM:authentication acct="?" exe="/usr/sbin/sshd" hostname= addr= terminal=ssh res=failed' > type=USER_AUTH msg=audit(1414715859.212:113): user pid=5830 uid=0 auid=0 ses=1 msg='op=password acct=28696E76616C6964207573657229 exe="/usr/sbin/sshd" hostname=? addr= terminal=ssh res=failed' > type=CRYPTO_KEY_USER msg=audit(1414715862.076:114): user pid=5830 uid=0 auid=0 ses=1 msg='op=destroy kind=session fp=? direction=both spid=5831 suid=74 rport=44361 laddr= lport=22 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' > type=CRYPTO_KEY_USER msg=audit(1414715862.078:115): user pid=5830 uid=0 auid=0 ses=1 msg='op=destroy kind=server fp=5e:ee:58:a2:25:ec:16:3e:8c:61:01:e6:de:76:3d:32 direction=? spid=5830 suid=0 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' > type=CRYPTO_KEY_USER msg=audit(1414715862.079:116): user pid=5830 uid=0 auid=0 ses=1 msg='op=destroy kind=server fp=d0:6f:2f:5f:49:44:94:f2:b2:4e:15:43:69:89:9c:1d direction=? spid=5830 suid=0 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' > type=USER_LOGIN msg=audit(1414715862.079:117): user pid=5830 uid=0 auid=0 ses=1 msg='op=login acct=28696E76616C6964207573657229 exe="/usr/sbin/sshd" hostname=? addr= terminal=ssh res=failed' > > The /var/log/sssd/sssd_.log logs show the following > > ==> /var/log/sssd/sssd_.log <== > (Fri Oct 31 12:13:39 2014) [sssd[be[]]] [sbus_dispatch] (0x4000): dbus conn: 0x16699b0 > (Fri Oct 31 12:13:39 2014) [sssd[be[]]] [sbus_dispatch] (0x4000): Dispatching. > (Fri Oct 31 12:13:39 2014) [sssd[be[]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] > (Fri Oct 31 12:13:39 2014) [sssd[be[]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit > (Fri Oct 31 12:13:39 2014) [sssd[be[]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping] These are just heartbeats between sssd_be and the main sssd process, not a real activity. > -- > 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 From pspacek at redhat.com Fri Oct 31 13:44:31 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 31 Oct 2014 14:44:31 +0100 Subject: [Freeipa-users] [SOLVED] IPA DNS response issue In-Reply-To: <20140319141227.GI23332@coolhack.net> References: <20140318142635.GH23332@coolhack.net> <53299434.9010409@redhat.com> <20140319141227.GI23332@coolhack.net> Message-ID: <5453923F.5080709@redhat.com> On 19.3.2014 15:12, David wrote: > On Wed, Mar 19, 2014 at 01:57:24PM +0100, Petr Spacek wrote: >> On 18.3.2014 15:26, David wrote: >>> We have an installation of FreeIPA (through CentOS 6.5) that's exhibiting some >>> odd behavior with respect to serving DNS. Periodically (interval at random) >>> named running on a replica will stop serving requests from the LDAP server but >>> continue to respond with recursive requests. This type of failure causes us >>> problems, as you could imagine. (It doesn't fail cleanly so it won't request >>> from another server.) We've adjusted the amount of connections each named >>> makes to 389, but it doesn't seem to make a difference. We're not seeing >>> anything in the logs so troubleshooting this is becoming a bit of a >>> (high-visibility) puzzle to us. >>> >>> I do happen to have a core file that I grabbed last night before sending a >>> SIGKILL to named and restarting. (A SIGTERM has no effect.) >>> >>> Hopefully there's an easy answer here that we can get rolled into the >>> environment quickly. FreeIPA has treated us extraordinarily well so far! > > > >> Note that David (I guess :-) added logs to the ticket >> https://fedorahosted.org/bind-dyndb-ldap/ticket/131 >> and I'm looking into it. > > Actually, that's not me! I don't have anywhere near as much logging... > At least I'm not alone... > > Our failures also seem to happen around log rotation time. > > The Kerberos ticket expiring is interesting. I'll poke around on my > installation and see what I see on this side. > > If you need any other information, please let me know. FYI the problem was discovered & fixed a while ago but I did not sent reply to you. It was fixed in all maintained branches (v2+) of bind-dyndb-ldap. All supported versions of Fedora were patched so it should not happen again. You can watch RHEL status on: RHEL 6.y: https://bugzilla.redhat.com/show_bug.cgi?id=1142176 https://bugzilla.redhat.com/show_bug.cgi?id=1142152 RHEL 7.y: https://bugzilla.redhat.com/show_bug.cgi?id=1142150 Have a nice day! -- Petr^2 Spacek From rolf_16_nufable at yahoo.com Fri Oct 31 03:38:53 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Thu, 30 Oct 2014 20:38:53 -0700 Subject: [Freeipa-users] DNS forwarders in 4.1.0 Message-ID: <1414726733.87057.YahooMailNeo@web161603.mail.bf1.yahoo.com> Hello , I've been trying to install freeipa server v 4.1.0 on my fedora 20 machine and I can't complete the installation because of hte DNS forwarders my machine's IP is 192.168.254.7 and I'm using the same IP for DNS forwarders, this is what I did when I was installing 4.0.3 and 3.3.5 and it installed smoothly , so my question is why won't it work in 4.1.0 ? is there something new when configuring DNS forwarders? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Oct 31 14:42:06 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 31 Oct 2014 15:42:06 +0100 Subject: [Freeipa-users] DNS forwarders in 4.1.0 In-Reply-To: <1414726733.87057.YahooMailNeo@web161603.mail.bf1.yahoo.com> References: <1414726733.87057.YahooMailNeo@web161603.mail.bf1.yahoo.com> Message-ID: <54539FBE.5050904@redhat.com> On 31.10.2014 04:38, Rolf Nufable wrote: > Hello , > > I've been trying to install freeipa server v 4.1.0 on my fedora 20 machine and I can't complete the installation because of hte DNS forwarders What exactly is the problem/symptom? Are you receiving an error? Or something else? We need to see exact package versions, parameters you have used, messages, logs etc. > my machine's IP is 192.168.254.7 and I'm using the same IP for DNS forwarders, this is what I did when I was installing 4.0.3 and 3.3.5 and it installed smoothly , so my question is why won't it work in 4.1.0 ? is there something new when configuring DNS forwarders? I'm not sure I understand you. What do you mean with 'my machine'? Is it the (to-be-installed) IPA server? Or some other machine? Are you installing IPA with or without DNS? There is no point in configuring IPA to use itself as forwarder. Please tell us what exactly doesn't work for you :-) -- Petr^2 Spacek From guigne at lms.polytechnique.fr Fri Oct 31 14:58:48 2014 From: guigne at lms.polytechnique.fr (=?UTF-8?B?RWRvdWFyZCBHdWlnbsOp?=) Date: Fri, 31 Oct 2014 15:58:48 +0100 Subject: [Freeipa-users] Extra attributes for sync agreement AD to FreeIPA Message-ID: <5453A3A8.9090302@lms.polytechnique.fr> Hello freeipa Users, I am working on a sync agreement between AD server -> FreeIPA server (fedora 20) I follow the documentation, my sync works beetwen AD -> FreeIPA with "ipa-replica-manage connect --winsync ..." However, I would like to extract attributes from my AD like : - uidNumber - gidNumber - unixHomeDirectory - loginShell - msSFU30NisDomain My AD server is 2008 R2 with with Subsystem for UNIX-based Applications. I would like rerieve these attributes in my freeipa server after sync. I had a look on google, and find informations like this : https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/managing-sync-agmt.html#tab.sync-agmt-attrs But I did not succeed with it. May someone help me ? From rcritten at redhat.com Fri Oct 31 15:04:09 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 31 Oct 2014 11:04:09 -0400 Subject: [Freeipa-users] Extra attributes for sync agreement AD to FreeIPA In-Reply-To: <5453A3A8.9090302@lms.polytechnique.fr> References: <5453A3A8.9090302@lms.polytechnique.fr> Message-ID: <5453A4E9.6080302@redhat.com> Edouard Guign? wrote: > Hello freeipa Users, > > I am working on a sync agreement between AD server -> FreeIPA server > (fedora 20) > > I follow the documentation, my sync works beetwen AD -> FreeIPA with > "ipa-replica-manage connect --winsync ..." > > However, I would like to extract attributes from my AD like : > - uidNumber > - gidNumber > - unixHomeDirectory > - loginShell > - msSFU30NisDomain > My AD server is 2008 R2 with with Subsystem for UNIX-based Applications. > > I would like rerieve these attributes in my freeipa server after sync. > > I had a look on google, and find informations like this : > https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/managing-sync-agmt.html#tab.sync-agmt-attrs > > But I did not succeed with it. > > May someone help me ? > It should already work: http://www.port389.org/docs/389ds/design/winsync-posix.html rob From mmercier at gmail.com Fri Oct 31 15:11:31 2014 From: mmercier at gmail.com (Michael Mercier) Date: Fri, 31 Oct 2014 11:11:31 -0400 Subject: [Freeipa-users] Replication fails after CentOS 6.5 -> 6.6 Upgrade - sasl_io_recv failed to decode packet for connection xxxx Message-ID: <5453A6A3.2080409@gmail.com> Hello, I just did a 'yum update' from CentOS 6.5 -> 6.6 on my freeipa system (master and 2 replicas) and I seen to have run into the following bug, https://bugzilla.redhat.com/show_bug.cgi?id=953653 On Master: [root at srv-1 slapd-CN-LOCAL]# rpm -qa|grep ipa ipa-client-3.0.0-42.el6.centos.x86_64 libipa_hbac-python-1.11.6-30.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-python-3.0.0-42.el6.centos.x86_64 sssd-ipa-1.11.6-30.el6.x86_64 ipa-server-3.0.0-42.el6.centos.x86_64 ipa-server-selinux-3.0.0-42.el6.centos.x86_64 libipa_hbac-1.11.6-30.el6.x86_64 ipa-admintools-3.0.0-42.el6.centos.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-pki-ca-theme-9.0.3-7.el6.noarch [root at srv-1 slapd-CN-LOCAL]# rpm -qa|grep 389 389-ds-base-1.2.11.15-47.el6.x86_64 389-ds-base-libs-1.2.11.15-47.el6.x86_64 ldapsearch -b cn=config -D "cn=Directory Manager" -W | grep nsslapd-sasl-max-buffer-size nsslapd-sasl-max-buffer-size: 65536 [root at srv-1]tail /etc/dirsrv/slapd-xxxx/errors [31/Oct/2014:10:59:51 -0400] - sasl_io_recv failed to decode packet for connection 2313 [31/Oct/2014:10:59:55 -0400] - sasl_io_recv failed to decode packet for connection 2314 [31/Oct/2014:11:00:00 -0400] - sasl_io_recv failed to decode packet for connection 2316 [31/Oct/2014:11:00:01 -0400] - sasl_io_recv failed to decode packet for connection 2315 On Replica: [root at srv-2 slapd-CN-LOCAL]# rpm -qa|grep ipa ipa-server-selinux-3.0.0-42.el6.centos.x86_64 libipa_hbac-1.11.6-30.el6.x86_64 ipa-admintools-3.0.0-42.el6.centos.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-server-3.0.0-42.el6.centos.x86_64 ipa-client-3.0.0-42.el6.centos.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch libipa_hbac-python-1.11.6-30.el6.x86_64 ipa-python-3.0.0-42.el6.centos.x86_64 sssd-ipa-1.11.6-30.el6.x86_64 [root at srv-2 slapd-CN-LOCAL]# rpm -qa|grep 389 389-ds-base-1.2.11.15-47.el6.x86_64 389-ds-base-libs-1.2.11.15-47.el6.x86_64 [root at srv-2 slapd-CN-LOCAL]# ldapsearch -b cn=config -D "cn=Directory Manager" -W | grep nsslapd-sasl-max-buffer-size Enter LDAP Password: nsslapd-sasl-max-buffer-size: 65536 [root at svr-2]tail -f /etc/dirsrv/slapd-xxxx/errors [31/Oct/2014:11:01:11 -0400] NSMMReplicationPlugin - agmt="cn=meTosrv-1.xxxx" (srv-1:389): Replication bind with GSSAPI auth resumed [31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt="cn=meTosrv-1.xxxx" (srv-1:389): Warning: unable to replicate schema: rc=2 [31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt="cn=meTosrv-1.xxxx" (srv-1:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. [31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt="cn=meTosrv-1.xxxx" (srv-1:389): Failed to send update operation to consumer (uniqueid 515cdb0f-24fa11e2-816add07-a91dabe7, CSN 5453fc26000900030000): Can't contact LDAP server. Will retry later. [31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt="cn=meTosrv-1.xxxx" (srv-1:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) In the ticket, Scott Poore says he increased the nsslapd-sasl-max-buffer-size to work around the problem. Is this the correct course of action, or should I be trying something else? Thanks, Mike From Christoph.Maser at globalways.net Fri Oct 31 15:44:51 2014 From: Christoph.Maser at globalways.net (Christoph Maser) Date: Fri, 31 Oct 2014 15:44:51 +0000 Subject: [Freeipa-users] strange error from EL 7 install? Message-ID: <1414770290.2828.16.camel@meier.intern.gw> On Mon, Oct 13, 2014 at 10:08:55PM -0700, Janelle wrote: > Actually, I did find a fix and forgot to post. > > I was able to mirror the COPR repo, and after reviewing it, found that > simply removing the pki-base...fc21 directory, and regenning the repo data > with createrepo, fixed the problem. It drops the version of PKI back to the > 10.1 branch and that resolved the dependencies. > > Hope this helps, > Janelle > You don't need to mirror the repo for that simply using yum-plugin-versionlock would be sufficient, unfortunatly now that solution does not work any more since the freeipa-server package depends on "pki-ca >= 10.2.0-3" wich in turn depends on the 10.2.x pki-server and pki-base packages. I checked out what it would take to backport jackson-jaxrs-json-provider to CentOS 7 and this is quite a task. The fedora 21 packages build up a dependency chain wich includes aspectjweaver, eclipselink, springframework and some more stuff Does mkosek offer a repo with older builds wich are considered working? Chris From rcritten at redhat.com Fri Oct 31 15:49:03 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 31 Oct 2014 11:49:03 -0400 Subject: [Freeipa-users] Extra attributes for sync agreement AD to FreeIPA In-Reply-To: <5453ADD3.8070403@lms.polytechnique.fr> References: <5453A3A8.9090302@lms.polytechnique.fr> <5453A4E9.6080302@redhat.com> <5453ADD3.8070403@lms.polytechnique.fr> Message-ID: <5453AF6F.6060708@redhat.com> Edouard Guign? wrote: > Hello Rob, > > Thank you for your answer. > Do you mean it should already work ? > Or I have to do this on the FreeIPA server : > > |rm /etc/dirsrv/slapd-INSTNAME/schema/10rfc2307.ldif > cp /usr/share/dirsrv/data/10rfc2307bis.ldif /etc/dirsrv/slapd-INSTNAME/schema Sorry, I guess I was a little terse. The nisDomain is already defined for IPA so you can skip that bit. The Posix Winsync Plugin is disabled by default. You'll need to enable it and configure it to match your environment. See the wiki page for configuration details. You can either enable and configure it online by using ldapmodify and binding as the Directory Manager or by shutting down 389-ds and modifying dse.ldif, then restarting it (or use a tool like Apache Directory Studio). rob > > > | > > Best Regards, have a nice we. > Ed > > Le 31/10/2014 16:04, Rob Crittenden a ?crit : >> Edouard Guign? wrote: >>> Hello freeipa Users, >>> >>> I am working on a sync agreement between AD server -> FreeIPA server >>> (fedora 20) >>> >>> I follow the documentation, my sync works beetwen AD -> FreeIPA with >>> "ipa-replica-manage connect --winsync ..." >>> >>> However, I would like to extract attributes from my AD like : >>> - uidNumber >>> - gidNumber >>> - unixHomeDirectory >>> - loginShell >>> - msSFU30NisDomain >>> My AD server is 2008 R2 with with Subsystem for UNIX-based Applications. >>> >>> I would like rerieve these attributes in my freeipa server after sync. >>> >>> I had a look on google, and find informations like this : >>> https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/managing-sync-agmt.html#tab.sync-agmt-attrs >>> >>> But I did not succeed with it. >>> >>> May someone help me ? >>> >> It should already work: >> >> http://www.port389.org/docs/389ds/design/winsync-posix.html >> >> rob >> >> >> > From CWhite at skytouchtechnology.com Fri Oct 31 15:58:38 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Fri, 31 Oct 2014 15:58:38 +0000 Subject: [Freeipa-users] Replication fails after CentOS 6.5 -> 6.6 Upgrade - sasl_io_recv failed to decode packet for connection xxxx In-Reply-To: <5453A6A3.2080409@gmail.com> References: <5453A6A3.2080409@gmail.com> Message-ID: <734aee56215047ef98ace7c3dd3ad93f@BLUPR08MB488.namprd08.prod.outlook.com> Craig White System Administrator O 623-201-8179?? M 602-377-9752 SkyTouch Technology???? 4225 E. Windrose Dr. ????Phoenix, AZ 85032 -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Michael Mercier Sent: Friday, October 31, 2014 8:12 AM To: freeipa-users at redhat.com Subject: [Freeipa-users] Replication fails after CentOS 6.5 -> 6.6 Upgrade - sasl_io_recv failed to decode packet for connection xxxx Hello, I just did a 'yum update' from CentOS 6.5 -> 6.6 on my freeipa system (master and 2 replicas) and I seen to have run into the following bug, https://bugzilla.redhat.com/show_bug.cgi?id=953653 On Master: [root at srv-1 slapd-CN-LOCAL]# rpm -qa|grep ipa ipa-client-3.0.0-42.el6.centos.x86_64 libipa_hbac-python-1.11.6-30.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-python-3.0.0-42.el6.centos.x86_64 sssd-ipa-1.11.6-30.el6.x86_64 ipa-server-3.0.0-42.el6.centos.x86_64 ipa-server-selinux-3.0.0-42.el6.centos.x86_64 libipa_hbac-1.11.6-30.el6.x86_64 ipa-admintools-3.0.0-42.el6.centos.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-pki-ca-theme-9.0.3-7.el6.noarch [root at srv-1 slapd-CN-LOCAL]# rpm -qa|grep 389 389-ds-base-1.2.11.15-47.el6.x86_64 389-ds-base-libs-1.2.11.15-47.el6.x86_64 ldapsearch -b cn=config -D "cn=Directory Manager" -W | grep nsslapd-sasl-max-buffer-size nsslapd-sasl-max-buffer-size: 65536 [root at srv-1]tail /etc/dirsrv/slapd-xxxx/errors [31/Oct/2014:10:59:51 -0400] - sasl_io_recv failed to decode packet for connection 2313 [31/Oct/2014:10:59:55 -0400] - sasl_io_recv failed to decode packet for connection 2314 [31/Oct/2014:11:00:00 -0400] - sasl_io_recv failed to decode packet for connection 2316 [31/Oct/2014:11:00:01 -0400] - sasl_io_recv failed to decode packet for connection 2315 On Replica: [root at srv-2 slapd-CN-LOCAL]# rpm -qa|grep ipa ipa-server-selinux-3.0.0-42.el6.centos.x86_64 libipa_hbac-1.11.6-30.el6.x86_64 ipa-admintools-3.0.0-42.el6.centos.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-server-3.0.0-42.el6.centos.x86_64 ipa-client-3.0.0-42.el6.centos.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch libipa_hbac-python-1.11.6-30.el6.x86_64 ipa-python-3.0.0-42.el6.centos.x86_64 sssd-ipa-1.11.6-30.el6.x86_64 [root at srv-2 slapd-CN-LOCAL]# rpm -qa|grep 389 389-ds-base-1.2.11.15-47.el6.x86_64 389-ds-base-libs-1.2.11.15-47.el6.x86_64 [root at srv-2 slapd-CN-LOCAL]# ldapsearch -b cn=config -D "cn=Directory Manager" -W | grep nsslapd-sasl-max-buffer-size Enter LDAP Password: nsslapd-sasl-max-buffer-size: 65536 [root at svr-2]tail -f /etc/dirsrv/slapd-xxxx/errors [31/Oct/2014:11:01:11 -0400] NSMMReplicationPlugin - agmt="cn=meTosrv-1.xxxx" (srv-1:389): Replication bind with GSSAPI auth resumed [31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt="cn=meTosrv-1.xxxx" (srv-1:389): Warning: unable to replicate schema: rc=2 [31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt="cn=meTosrv-1.xxxx" (srv-1:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. [31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt="cn=meTosrv-1.xxxx" (srv-1:389): Failed to send update operation to consumer (uniqueid 515cdb0f-24fa11e2-816add07-a91dabe7, CSN 5453fc26000900030000): Can't contact LDAP server. Will retry later. [31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt="cn=meTosrv-1.xxxx" (srv-1:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) In the ticket, Scott Poore says he increased the nsslapd-sasl-max-buffer-size to work around the problem. Is this the correct course of action, or should I be trying something else? ---- I can't speak with certainty but I can tell you that increasing the buffer solved my replication problem immediately. Craig From CWhite at skytouchtechnology.com Fri Oct 31 18:05:39 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Fri, 31 Oct 2014 18:05:39 +0000 Subject: [Freeipa-users] stacktrace from crash Message-ID: <79cff3e4fcd14a0fba641bb844e5268b@BLUPR08MB488.namprd08.prod.outlook.com> OK ? and thanks to help in getting the debug-info packages installed by Rich, I crashed IPA when trying to do an edit and have a stacktrace from gdb. I?ll post it here unless someone thinks it would be better in a bug report. 389-ds-base-1.2.11.15-47.el6.x86_64 openldap-2.4.39-8.el6.x86_64 db4-4.7.25-18.el6_4.x86_64 nss-3.16.1-14.el6.x86_64 nspr-4.10.6-1.el6_5.x86_64 ipa-server-3.0.0-42.el6.x86_64 slapi-nis-0.40-6.el6.x86_64 trying to only include relevant stuff ? just the threads that had an errorbuf, let me know if I was trimmed too much. Core was generated by `/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-STT-LOCAL -i /var/run/dirsrv/s'. Program terminated with signal 11, Segmentation fault. #0 comp_cmp (s1=0xec60c0 "objectClass", s2=0x0) at ldap/servers/slapd/attr.c:98 98 while ( *s1 && *s1 != ';' && tolower( *s1 ) == tolower( *s2 ) ) { Thread 44 (Thread 0x7f15df3f8700 (LWP 7490)): #0 0x00007f15feafb5bc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f15ff14e863 in PR_EnterMonitor (mon=0xac6de0) at ../../../nspr/pr/src/pthreads/ptsynch.c:592 self = 139731916523264 #2 0x00007f15f64ec2a4 in ldbm_back_modify (pb=0x7f15b4033920) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:444 be = 0xb895b0 inst = 0xb82d10 li = 0xa65920 e = 0x0 ec = 0x0 original_entry = 0x0 tmpentry = 0x0 postentry = 0x0 mods = 0x7f15b403d6e0 mods_original = 0x0 smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator = 0, free_mods = 0} txn = {back_txn_txn = 0x0} parent_txn = 0x0 ruv_c = {old_entry = 0x0, new_entry = 0x0, smods = 0x0, attr_encrypt = 0} ruv_c_init = 0 retval = -1 msg = errbuf = 0x0 retry_count = 0 disk_full = 0 ldap_result_code = 0 ldap_result_message = 0x0 rc = 0 operation = 0x7f15b4038650 dblock_acquired = 0 addr = 0x7f15b4038728 is_fixup_operation = 0 is_ruv = 0 opcsn = 0x0 repl_op = 0 opreturn = 0 mod_count = 0 #3 0x00007f1600d20251 in op_shared_modify (pb=, pw_change=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1061 rc = be = 0xb895b0 pse = referral = 0x0 e = dn = 0x7f15b403bc40 "uid= SOME_NAME,cn=users,cn=accounts,dc=stt,dc=local" normdn = sdn = 0x7f15b4035480 passin_sdn = 1 mods = 0x7f15b403d6e0 pw_mod = tmpmods = 0x7f15b4014df0 smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator = 0, free_mods = 0} repl_op = 0 internal_op = 32 lastmod = 1 skip_modified_attrs = 0 unhashed_pw_attr = 0x0 operation = 0x7f15b4038650 errorbuf = "\000fff\000\177\000\000\320$\001\264\025\177\000\000\270\025?\337\025\177\000\000d\303\324\000\026\177\000\000\060\277\216\000\000\000\000\000 \026?\337\025\177\000\000\001\000\000\000\000\000\000\000\350\357\000\264\025\177\000\000 at Q\001\264\025\177\000\000\247\303\324\000\026\177\000\000\240$\001\264\025\177\000\000\001\000\000\000\000\000\000\000 \026?\337\025\177\000\000\261*\316\000\026\177\000\000` \221\000\000\000\000\000\230\027?\337\025\177\000\000\000\000\000\000\000\000\000\000j,\316\000\026\177\000\000\300c\000\264\025\177\000\000\000\000\000\000\000\000\000\000entryusn\000estamp\000\340^\003\264\025\177\000\000\300c\000\264\025\177\000\000\340+\003\264\025\177\000\000\370\066?\337\025\177\000\000\000\000\000\000\ 000\000\000\000\005\t\316\000\026\177\000\000\060\277\216\000\000\000\000\000\340\026?\337\025\177\000\000"... err = lc_mod = p = i = proxydn = 0x0 proxy_err = errtext = 0x0 #4 0x00007f1600d20b31 in modify_internal_pb (pb=0x7f15b4033920) at ldap/servers/slapd/modify.c:620 controls = 0x0 pwpolicy_ctrl = 0 op = 0x7f15b4038650 opresult = 0 normalized_mods = 0x7f15b4014df0 mods = 0x7f15b400f990 mod = smods = {mods = 0x1, num_elements = 13839236, num_mods = 32534, iterator = 10968576, free_mods = 0} pw_change = old_pw = 0x0 #5 0x00007f15f5be133c in memberof_fix_memberof_callback (e=, callback_data=) at ldap/servers/plugins/memberof/memberof.c:2502 val = 0x0 mod_pb = 0x7f15b4033920 smod = 0x7f15b4037a20 mods = 0x7f15b400f990 hint = -1 rc = 0 sdn = 0x7f15b4035480 config = del_data = {dn = 0x0, type = 0x7f15b400f9d0 "memberOf"} groups = 0x7f15b400f920 #6 0x00007f15f5be1e20 in memberof_modop_one_replace_r (pb=0xc256b0, config=0x7f15df3f3900, mod_op=1, group_sdn=0x7f15b400ce90, op_this_sdn=, replace_with_sdn=0x0, op_to_sdn=0x7f15b403b7e0, stack=0x0) at ldap/servers/plugins/memberof/memberof.c:1340 rc = 0 mod = {mod_op = 9, mod_type = 0x2
, mod_vals = {modv_strvals = 0x0, modv_bvals = 0x0}} replace_mod = {mod_op = -549505016, mod_type = 0x1000000b0
, mod_vals = {modv_strvals = 0x0, modv_bvals = 0x0}} mods = {0x0, 0xa76818, 0x7f15df3f37f0} val = {0x7c0000005b
, 0x6e00000077
} replace_val = {0x0, 0x3200000009
} mod_pb = 0x0 e = 0x7f15b4035480 ll = 0x0 op_str = op_to = 0x7f15b403bb90 "uid=SOME_NAME,cn=users,cn=accounts,dc=stt,dc=local" op_this = to_dn_val = 0x7f15b4035b00 this_dn_val = 0x7f15b403b790 #7 0x00007f15f5be2f19 in memberof_modop_one_r (pb=0xc256b0, config=0x7f15df3f3900, mod=1, group_sdn=0x7f15b400ce90, smod=0x7f15b400faf0) at ldap/servers/plugins/memberof/memberof.c:1081 No locals. #8 memberof_modop_one (pb=0xc256b0, config=0x7f15df3f3900, mod=1, group_sdn=0x7f15b400ce90, smod=0x7f15b400faf0) at ldap/servers/plugins/memberof/memberof.c:1068 No locals. #9 memberof_mod_smod_list (pb=0xc256b0, config=0x7f15df3f3900, mod=1, group_sdn=0x7f15b400ce90, smod=0x7f15b400faf0) at ldap/servers/plugins/memberof/memberof.c:1462 dn_str = 0x7f15b4031660 "uid=SOME_NAME,cn=users,cn=accounts,dc=stt,dc=local" bv = 0x7f15b4003820 last_size = 127 last_str = 0x7f15b4031660 "uid=SOME_NAME,cn=users,cn=accounts,dc=stt,dc=local" sdn = 0x7f15b403b7e0 #10 0x00007f15f5be36a4 in memberof_del_smod_list (pb=0xc256b0) at ldap/servers/plugins/memberof/memberof.c:1496 No locals. #11 memberof_postop_modify (pb=0xc256b0) at ldap/servers/plugins/memberof/memberof.c:884 op = interested = type = 0x7f15b4016b20 "member" config_copied = mainConfig = configCopy = {groupattrs = 0x7f15b403d420, memberof_attr = 0x7f15b400f9d0 "memberOf", allBackends = 0, group_filter = 0x7f15b403d2a0, group_slapiattrs = 0x7f15b403b940} sdn = 0x7f15b400ce90 smods = 0x7f15b400fb10 smod = 0x7f15b400faf0 mods = 0x7f15b400efd0 next_mod = 0x7f15b400faf0 caller_id = 0x0 #12 0x00007f1600d2fb82 in plugin_call_func (list=0xa76220, operation=505, pb=0xc256b0, call_one=0) at ldap/servers/slapd/plugin.c:1453 n = func = 0x7f15f5be33b0 rc = return_value = count = #13 0x00007f1600d2fdcf in plugin_call_list (pb=0xc256b0, whichfunction=505) at ldap/servers/slapd/plugin.c:1415 No locals. #14 plugin_call_plugins (pb=0xc256b0, whichfunction=505) at ldap/servers/slapd/plugin.c:398 p = plugin_list_number = rc = 0 do_op = #15 0x00007f1600d202ec in op_shared_modify (pb=, pw_change=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1098 rc = 0 be = 0xb895b0 pse = 0x7f15b4038ef0 referral = 0x0 e = dn = 0x7f15b4012160 "cn=Join Systems to Domain and DNS,cn=roles,cn=accounts,dc=stt,dc=local" normdn = sdn = 0x7f15b400ce90 passin_sdn = 0 mods = 0x7f15b4002470 pw_mod = tmpmods = 0x7f15b4016c30 smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator = 0, free_mods = 0} repl_op = 0 internal_op = 0 lastmod = 1 skip_modified_attrs = 0 unhashed_pw_attr = 0x0 operation = 0xf66430 errorbuf = '\000' , "h\304\023\377\025\177\000\000\000\000\000\000\377\377\377\377\023H?\337\025\177", '\000' "\323, \313B", '\000' "\260, Y?\337\025\177\000\000\000\000\000\000\000\000\000\000\200H?\337\025\177\000\000\333\313\023\377\025\177", '\000' , " H?\337\025\177\000\000\023H?\337\025\177\000\000\024H?\337\025\177\000\000\257G?\337\025\177\000\000\240G?\337\025\177\000\000!H?\337\025\177\000\000\000\000\000\000\006", '\000' "\320, .\000\264\025\177\000\000\000\000\000\000\000\000\000 ", '\000' , "?\000\264\025\177\000\000\240\344\237\000\000\000\000\000 \307\372\000\026\177", '\000' , "103", '\000' , "?\000\264\025\177"... err = lc_mod = p = i = proxydn = 0x0 proxy_err = errtext = 0x0 #16 0x00007f1600d2150e in do_modify (pb=0xc256b0) at ldap/servers/slapd/modify.c:408 operation = 0xf66430 ber = last = 0x7f15b400d60b "" type = 0x0 tag = len = 18446744073709551615 mod = 0x0 mods = 0x7f15b400ce90 smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator = 0, free_mods = 0} err = pw_change = 0 ignored_some_mods = has_password_mod = old_pw = 0x0 rawdn = 0x7f15b4012160 "cn=Join Systems to Domain and DNS,cn=roles,cn=accounts,dc=stt,dc=local" minssf_exclude_rootdse = normalized_mods = 0x7f15b4016c30 #17 0x0000000000414344 in connection_dispatch_operation () at ldap/servers/slapd/connection.c:594 minssf = minssf_exclude_rootdse = #18 connection_threadmain () at ldap/servers/slapd/connection.c:2360 is_timedout = 0 curtime = pb = 0xc256b0 interval = 10000 conn = 0x7f15ec10d790 op = 0xf66430 tag = 102 need_wakeup = thread_turbo_flag = 0 ret = more_data = 0 replication_connection = doshutdown = 0 #19 0x00007f15ff154c93 in _pt_root (arg=0xf56ab0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0xf56ab0 detached = 1 id = 139731916523264 tid = 7490 #20 0x00007f15feaf79d1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #21 0x00007f15fe8449dd in clone () from /lib64/libc.so.6 No symbol table info available. Thread 32 (Thread 0x7f15d6bfd700 (LWP 7497)): #0 0x00007f15feafb5bc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f15ff14e863 in PR_EnterMonitor (mon=0xac6de0) at ../../../nspr/pr/src/pthreads/ptsynch.c:592 self = 139731773937408 #2 0x00007f15f64ec2a4 in ldbm_back_modify (pb=0x7f15c0042160) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:444 be = 0xb895b0 inst = 0xb82d10 li = 0xa65920 e = 0x0 ec = 0x0 original_entry = 0x0 tmpentry = 0x0 postentry = 0x0 mods = 0x7f15c004ef80 mods_original = 0x0 smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator = 0, free_mods = 0} txn = {back_txn_txn = 0x0} parent_txn = 0x0 ruv_c = {old_entry = 0x0, new_entry = 0x0, smods = 0x0, attr_encrypt = 0} ruv_c_init = 0 retval = -1 msg = errbuf = 0x0 retry_count = 0 disk_full = 0 ldap_result_code = 0 ldap_result_message = 0x0 rc = 0 operation = 0x7f15c0016da0 dblock_acquired = 0 addr = 0x7f15c0016e78 is_fixup_operation = 0 is_ruv = 0 opcsn = 0x0 repl_op = 0 opreturn = 0 mod_count = 0 #3 0x00007f1600d20251 in op_shared_modify (pb=, pw_change=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1061 rc = be = 0xb895b0 pse = referral = 0x0 e = dn = 0x7f15c000f990 "uid=admin,cn=users,cn=accounts,dc=stt,dc=local" normdn = sdn = 0x7f15c004e360 passin_sdn = 0 mods = 0x7f15c004ef80 pw_mod = tmpmods = 0x7f15c004ef10 smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator = 0, free_mods = 0} repl_op = 0 internal_op = 32 lastmod = 1 skip_modified_attrs = 0 unhashed_pw_attr = 0x0 operation = 0x7f15c0016da0 errorbuf = "\000\000\000\000\000\000\000\000\235\001\324\000\026\177\000\000\060\000\005\300\025\177\000\000\256\000\000\000\000\000\000\000\251\000\000\000\000\000\000\000M&\323\352\257\006\024 8\000\000\000\000\000\000\000\016\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000`x\270\000\000\000\000\000\251\000\000\000\000\000\000\000\016\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000z\f\324\000\026\177\000\000@\351\326\000\026\177\000\000\021\377\323\000\026\177\000\000\300\364\244\000\000\000\000\000`x\270\000\000\000\000\000\300\364\244\000\000\000\000\000a", '\000' , "\001h\210\277\326", '\000' "\360, \225\310\000\000\000\000\000`x\270\000\000\000\000\000`x\270", '\000' "\360, E\311\000\000\000\000\000\060\253\277\326\025\177\000\000p\253\277\326\025\177\000\000`x\270", '\000' "\360"... err = lc_mod = p = i = proxydn = 0x0 proxy_err = errtext = 0x0 #4 0x00007f1600d20b31 in modify_internal_pb (pb=0x7f15c0042160) at ldap/servers/slapd/modify.c:620 controls = 0x0 pwpolicy_ctrl = 0 op = 0x7f15c0016da0 opresult = 0 normalized_mods = 0x7f15c004ef10 mods = 0x7f15c001dc40 mod = smods = {mods = 0x1, num_elements = 13839236, num_mods = 32534, iterator = 10729216, free_mods = 0} pw_change = old_pw = 0x0 #5 0x00007f15f775fca7 in ipalockout_postop (pb=0xb87860) at ipa_lockout.c:634 dn = 0x7f15c001f5a0 "uid=admin,cn=users,cn=accounts,dc=stt,dc=local" policy_dn = 0xecc0c0 "cn=global_policy,cn=STT.LOCAL,cn=kerberos,dc=stt,dc=local" target_entry = 0x7f15c000a040 policy_entry = 0x7f15c001db80 sdn = 0x7f15c0048440 pbtm = 0x7f15c0042160 smods = 0x7f15c0057db0 objectclass = 0x0 errstr = 0x0 ldrc = rc = 0 ret = 0 failedcount = 0 old_failedcount = 0 failedcountstr = "p\253\277\326\025\177\000\000\315o\321\000\026\177\000\000\001\000\000\000\000\000\000\000po\001\300\025\177\000" failedstr = 0x7f15c0017bc0 "0" failed_bind = lockout_duration = max_fail = 3602884968 utctime = {tm_sec = 59, tm_min = 45, tm_hour = 17, tm_mday = 31, tm_mon = 9, tm_year = 114, tm_wday = 5, tm_yday = 303, tm_isdst = 0, tm_gmtoff = 0, tm_zone = 0x7f15fe8b2c07 "GMT"} time_now = 1414777559 timestr = "20141031174559Z" failcnt_interval = 3602884992 lastfail = 0x7f15c002e5e0 "20141031174346Z" tries = failure = 1 actual_type_name = 0x0 attr_free_flags = 0 values = 0x0 __func__ = "ipalockout_postop" #6 0x00007f1600d2fb82 in plugin_call_func (list=0xa3c4f0, operation=501, pb=0xb87860, call_one=0) at ldap/servers/slapd/plugin.c:1453 n = func = 0x7f15f775f5b0 rc = return_value = count = #7 0x00007f1600d2fdcf in plugin_call_list (pb=0xb87860, whichfunction=501) at ldap/servers/slapd/plugin.c:1415 No locals. #8 plugin_call_plugins (pb=0xb87860, whichfunction=501) at ldap/servers/slapd/plugin.c:398 p = plugin_list_number = rc = 0 do_op = #9 0x000000000040f41b in do_bind (pb=0xb87860) at ldap/servers/slapd/bind.c:857 ber = err = isroot = 0 method = 163 version = 3 auth_response_requested = 0 pw_response_requested = 0 rawdn = 0x7f15c0017c60 "" dn = 0x7f15c0025cc0 "" saslmech = 0x7f15c005c790 "GSSAPI" cred = {bv_len = 618, bv_val = 0x7f15c002f430 "`\202\002f\006\t*\206H\206\367\022\001\002\002\001"} be = 0x0 ber_rc = rc = 0 sdn = 0x7f15c005c760 bind_sdn_in_pb = 1 referral = 0xc000e690 errorbuf = "\000\000\000\000\000\000\000\000@\337\000\300\000\000\000\000@\337\000\300\025\177\000\000 \337\000\300\000\000\000\000\001\000\000\000\000\000\000\000`\254\277\326\025\177\000\000\000\000\000\000\000\000\000\000 [\000\300\025\177\000\000C\021\326\000\026\177", '\000' "\366, h\316\000\026\177\000\000\340R\366\000\000\000\000\000l\022\322\000\026\177\000\000\000\000\000\000\000\000\000\000\360o\000\300\025\177\000\000@\254\277\326\025\177\000\000`\254\277\326\025\177\000\000p\254\277\326\025\177", '\000' , " \337\000\300\025\177", '\000' "\377, \377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\067\000\300\025\177\000\000\220U\366\000\000\000\000\000\000\000\000\000\002", '\000' , "h\304\023\377\025\177\000\000\000\000\000\000\377\377\377\377\023\260\277\326\025\177", '\000' "\351, \177\327\000"... supported = pmech = authtypebuf = "X\356\360\000\000\000\000\000g\356\360\000\000\000\000\000\340?\326\025\177\000\000`\356\360\000\000\000\000\000\070?\326\025\177\000\000\004\000\000\000\000\000\000\000a\356\360\000\000\000\000\000g\356\360\000\000\000\000\000\002\001\001`\000\000\000\000M&\323\352\257\006\024 h?\326\025\177\000\000\220\327\020\354\025\177\000\000X\315\277\326\025\177\000\000R8\317\377\025\177\000\000P\356\360\000\000\000\000\000\311\071\317\377\000\000\000\000\200\200\321", '\000' , "w\250\257\376\025\177\000\000\210?\326\025\177\000\000\b\000\000\000\000\000\000\000\360\225\310", '\000' "\366, h\316\000\026\177\000\000@\177\365\000\000\000\000\000\343`\325\000\026\177\000\000\060J\310", '\000' , "\001\000\000\000\000\000\000\000\202\366\023\377\025\177\000" bind_target_entry = 0x0 auto_bind = minssf = minssf_exclude_rootdse = #10 0x0000000000414453 in connection_dispatch_operation () at ldap/servers/slapd/connection.c:569 minssf = minssf_exclude_rootdse = #11 connection_threadmain () at ldap/servers/slapd/connection.c:2360 is_timedout = 0 curtime = pb = 0xb87860 interval = 10000 conn = 0x7f15ec10d790 op = 0xc895f0 tag = 96 need_wakeup = thread_turbo_flag = 0 ret = more_data = 0 replication_connection = doshutdown = 0 #12 0x00007f15ff154c93 in _pt_root (arg=0xf57f40) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0xf57f40 detached = 1 id = 139731773937408 tid = 7497 #13 0x00007f15feaf79d1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #14 0x00007f15fe8449dd in clone () from /lib64/libc.so.6 No symbol table info available. Thread 11 (Thread 0x7f15ca3e9700 (LWP 7517)): #0 0x00007f15feafb5bc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f15ff14e863 in PR_EnterMonitor (mon=0xc5ddc0) at ../../../nspr/pr/src/pthreads/ptsynch.c:592 self = 139731564140288 #2 0x00007f15f5be3565 in memberof_postop_modify (pb=0xf6ab10) at ldap/servers/plugins/memberof/memberof.c:859 op = interested = type = 0x7f15c0047790 "member" config_copied = mainConfig = configCopy = {groupattrs = 0x7f15c00429e0, memberof_attr = 0x7f15c005bee0 "memberOf", allBackends = 0, group_filter = 0x7f15c004cfb0, group_sla piattrs = 0x7f15c00429b0} sdn = 0x7f15c0047980 smods = 0x7f15c005b9a0 smod = 0x7f15c005bba0 mods = 0x7f15c00424e0 next_mod = 0x7f15c005bba0 caller_id = 0x0 #3 0x00007f1600d2fb82 in plugin_call_func (list=0xa76220, operation=505, pb=0xf6ab10, call_one=0) at ldap/servers/slapd/plugin.c:1453 n = func = 0x7f15f5be33b0 rc = return_value = count = #4 0x00007f1600d2fdcf in plugin_call_list (pb=0xf6ab10, whichfunction=505) at ldap/servers/slapd/plugin.c:1415 No locals. #5 plugin_call_plugins (pb=0xf6ab10, whichfunction=505) at ldap/servers/slapd/plugin.c:398 p = plugin_list_number = rc = 0 do_op = #6 0x00007f1600d202ec in op_shared_modify (pb=, pw_change=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1098 rc = 0 be = 0xb895b0 pse = 0x7f15c00242d0 referral = 0x0 e = dn = 0x7f15c004ea00 "cn=Join Systems to Domain and DNS,cn=roles,cn=accounts,dc=stt,dc=local" normdn = sdn = 0x7f15c0047980 passin_sdn = 0 mods = 0x7f15c0047cb0 pw_mod = tmpmods = 0x7f15c002dd70 smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator = 0, free_mods = 0} repl_op = 0 internal_op = 0 lastmod = 1 skip_modified_attrs = 0 unhashed_pw_attr = 0x0 operation = 0xf5ea80 errorbuf = '\000' , "h\304\023\377\025\177\000\000\000\000\000\000\377\377\377\377CU>\312\025\177", '\000' , "Y\177\327\000\026\177", '\000' "\340, f>\312\025\177\000\000\000\000\000\000\000\000\000\000\260U>\312\025\177\000\000\333\313\023\377\025\177", '\000' , "PU>\312\025\177\000\000CU>\312\025\177\000\000DU>\312\025\177\000\000\337T>\312\025\177\000\000\320T>\312\025\177\000\000QU>\312\025\177\000\000\000\000\000\000\024", '\000' , "0\033\001\300\025\177\000\000\000\000\000\000\000\000\000 ", '\000' , "h\304\023\377\025\177\000\000\000\000\000\000\377\377\377\377\242W>\312\025\177", '\000' , "90\000\000\000\000b\372B", '\000' ... err = lc_mod = p = i = proxydn = 0x0 proxy_err = errtext = 0x0 #7 0x00007f1600d2150e in do_modify (pb=0xf6ab10) at ldap/servers/slapd/modify.c:408 operation = 0xf5ea80 ber = last = 0x7f15c00255a9 "" type = 0x0 tag = len = 18446744073709551615 mod = 0x0 mods = 0x7f15c0047980 smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator = 0, free_mods = 0} err = pw_change = 0 ignored_some_mods = has_password_mod = old_pw = 0x0 rawdn = 0x7f15c004ea00 "cn=Join Systems to Domain and DNS,cn=roles,cn=accounts,dc=stt,dc=local" minssf_exclude_rootdse = normalized_mods = 0x7f15c002dd70 #8 0x0000000000414344 in connection_dispatch_operation () at ldap/servers/slapd/connection.c:594 minssf = minssf_exclude_rootdse = #9 connection_threadmain () at ldap/servers/slapd/connection.c:2360 is_timedout = 0 curtime = pb = 0xf6ab10 interval = 10000 conn = 0x7f15ec10d790 op = 0xf5ea80 tag = 102 need_wakeup = thread_turbo_flag = 0 ret = more_data = 0 replication_connection = doshutdown = 0 #10 0x00007f15ff154c93 in _pt_root (arg=0xf5ba00) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0xf5ba00 detached = 1 id = 139731564140288 tid = 7517 #11 0x00007f15feaf79d1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #12 0x00007f15fe8449dd in clone () from /lib64/libc.so.6 No symbol table info available. Thread 1 (Thread 0x7f15d07f3700 (LWP 7507)): #0 comp_cmp (s1=0xec60c0 "objectClass", s2=0x0) at ldap/servers/slapd/attr.c:98 No locals. #1 0x00007f1600ce1675 in slapi_attr_type_cmp (a1=0xec60c0 "objectClass", a2=0x0, opt=) at ldap/servers/slapd/attr.c:131 rc = 0 #2 0x00007f1600d00dd2 in test_ava_filter (pb=0x0, e=0x7f15bc02ab20, a=0x7f15bc0c31e0, ava=0xee8590, ftype=163, verify_access=0, only_check_access=0, a ccess_check_done=0x7f15d07ee4e8) at ldap/servers/slapd/filterentry.c:342 rc = #3 0x00007f1600d5ff2d in vattr_test_filter (pb=0xf6a230, e=0x7f15bc02ab20, f=0xee8570, filter_type=, type=0xec60c0 "objectClass") at ldap/servers/slapd/vattr.c:605 acl_test_done = 0 rc = -1 sp_bit = 0 list = sdn = be = namespace_dn = #4 0x00007f1600d013fe in slapi_vattr_filter_test_ext_internal (pb=0xf6a230, e=0x7f15bc02ab20, f=0xee8570, verify_access=0, only_check_access=0, access_check_done=0x7f15d07ee64c) at ldap/servers/slapd/filterentry.c:897 rc = #5 0x00007f1600d018e5 in vattr_test_filter_list (pb=0xf6a230, e=0x7f15bc02ab20, flist=, ftype=161, verify_access=0, only_check_access=0, access_check_done=0x7f15d07ee64c) at ldap/servers/slapd/filterentry.c:1038 nomatch = f = 0xee8570 #6 0x00007f1600d0153d in slapi_vattr_filter_test_ext_internal (pb=0xf6a230, e=0x7f15bc02ab20, f=0xee2500, verify_access=0, only_check_access=0, access_check_done=0x7f15d07ee64c) at ldap/servers/slapd/filterentry.c:965 rc = 0 #7 0x00007f1600d0181c in slapi_vattr_filter_test_ext (pb=0xf6a230, e=0x7f15bc02ab20, f=0xee2500, verify_access=0, only_check_access=) at ldap/servers/slapd/filterentry.c:827 rc = 0 access_check_done = 0 #8 0x00007f15f7b6ecb5 in dna_be_txn_pre_op (pb=0xf6a230, modtype=) at ldap/servers/plugins/dna/dna.c:3478 config_entry = 0xef0ff0 e = 0x7f15bc02ab20 smods = 0x7f15bc009a60 smod = next_mod = 0x0 attr = 0x0 mods = 0x7f15bc0af2b0 bv = list = value = 0x0 types_to_generate = 0x0 generated_types = 0x0 new_value = 0x0 errstr = 0x0 dn = 0x7f15bc0c22f0 "cn=Join Systems to Domain and DNS,cn=roles,cn=accounts,dc=stt,dc=local" type = numvals = e_numvals = 0 i = len = ret = 0 #9 0x00007f1600d2fb82 in plugin_call_func (list=0xa2fe00, operation=461, pb=0xf6a230, call_one=0) at ldap/servers/slapd/plugin.c:1453 n = func = 0x7f15f7b6f680 rc = return_value = count = #10 0x00007f1600d2fdcf in plugin_call_list (pb=0xf6a230, whichfunction=461) at ldap/servers/slapd/plugin.c:1415 No locals. #11 plugin_call_plugins (pb=0xf6a230, whichfunction=461) at ldap/servers/slapd/plugin.c:398 p = plugin_list_number = rc = 0 do_op = #12 0x00007f15f64ecd27 in ldbm_back_modify (pb=0xf6a230) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:599 cache_rc = 0 new_mod_count = 0 be = 0xb895b0 inst = 0xb82d10 li = 0xa65920 e = 0x7f15c004be40 ec = 0x7f15bc01ef10 original_entry = 0x7f15bc0c3d90 tmpentry = 0x0 postentry = 0x0 mods = 0x7f15bc026930 mods_original = 0x7f15bc021c20 smods = {mods = 0x7f15bc026930, num_elements = 5, num_mods = 4, iterator = 0, free_mods = 0} txn = {back_txn_txn = 0x7f15bc0b4290} parent_txn = 0x0 ruv_c = {old_entry = 0x0, new_entry = 0x0, smods = 0x0, attr_encrypt = 0} ruv_c_init = 0 retval = 0 msg = errbuf = 0x0 retry_count = disk_full = 0 ldap_result_code = 0 ldap_result_message = 0x0 rc = 0 operation = 0xc707a0 dblock_acquired = 1 addr = 0xc70878 is_fixup_operation = 0 is_ruv = 0 opcsn = repl_op = 0 opreturn = 0 mod_count = 4 #13 0x00007f1600d20251 in op_shared_modify (pb=, pw_change=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1061 rc = be = 0xb895b0 pse = referral = 0x0 e = dn = 0x7f15bc0c2940 "cn=Join Systems to Domain and DNS,cn=roles,cn=accounts,dc=stt,dc=local" normdn = sdn = 0x7f15bc0af3b0 passin_sdn = 0 mods = 0x7f15bc0c35c0 pw_mod = tmpmods = 0x7f15bc0c38c0 smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator = 0, free_mods = 0} repl_op = 0 internal_op = 0 lastmod = 1 skip_modified_attrs = 0 unhashed_pw_attr = 0x0 operation = 0xc707a0 errorbuf = '\000' , "h\304\023\377\025\177\000\000\000\000\000\000\377\377\377\377C\365~\320\025\177", '\000' , "Y\177\327\000\026\177", '\000' "\340, \006\177\320\025\177\000\000\000\000\000\000\000\000\000\000\260\365~\320\025\177\000\000\333\313\023\377\025\177", '\000' , "P\365~\320\025\177\000\000C\365~\320\025\177\000\000D\365~\320\025\177\000\000\337\364~\320\025\177\000\000\320\364~\320\025\177\000\000Q\365~\320\025\177\000\000\000\000\000\000\024", '\000' "\200, \262\000\274\025\177\000\000\000\000\000\000\000\000\000 ", '\000' , "h\304\023\377\025\177\000\000\000\000\000\000\377\377\377\377\242\367~\320\025\177", '\000' , "90\000\000\000\000b\372B", '\000' , "@\t\177\320\025\177\000\000"... err = lc_mod = p = i = proxydn = 0x0 proxy_err = errtext = 0x0 #14 0x00007f1600d2150e in do_modify (pb=0xf6a230) at ldap/servers/slapd/modify.c:408 operation = 0xc707a0 ber = last = 0x7f15bc0bb197 "" type = 0x0 tag = len = 18446744073709551615 mod = 0x0 mods = 0x7f15bc0af3b0 smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator = 0, free_mods = 0} err = pw_change = 0 ignored_some_mods = has_password_mod = old_pw = 0x0 rawdn = 0x7f15bc0c2940 "cn=Join Systems to Domain and DNS,cn=roles,cn=accounts,dc=stt,dc=local" minssf_exclude_rootdse = normalized_mods = 0x7f15bc0c38c0 #15 0x0000000000414344 in connection_dispatch_operation () at ldap/servers/slapd/connection.c:594 minssf = minssf_exclude_rootdse = #16 connection_threadmain () at ldap/servers/slapd/connection.c:2360 is_timedout = 0 curtime = pb = 0xf6a230 interval = 10000 conn = 0x7f15ec10d790 op = 0xc707a0 tag = 102 need_wakeup = thread_turbo_flag = 0 ret = more_data = 0 replication_connection = doshutdown = 0 #17 0x00007f15ff154c93 in _pt_root (arg=0xf59ca0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0xf59ca0 detached = 1 id = 139731669038848 tid = 7507 #18 0x00007f15feaf79d1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #19 0x00007f15fe8449dd in clone () from /lib64/libc.so.6 No symbol table info available. Craig White System Administrator O 623-201-8179 M 602-377-9752 [cid:image001.png at 01CF86FE.42D51630] SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7660 bytes Desc: image001.png URL: From dpal at redhat.com Fri Oct 31 18:17:08 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 31 Oct 2014 14:17:08 -0400 Subject: [Freeipa-users] DNS forwarders in 4.1.0 In-Reply-To: <54539FBE.5050904@redhat.com> References: <1414726733.87057.YahooMailNeo@web161603.mail.bf1.yahoo.com> <54539FBE.5050904@redhat.com> Message-ID: <5453D224.5090205@redhat.com> On 10/31/2014 10:42 AM, Petr Spacek wrote: > On 31.10.2014 04:38, Rolf Nufable wrote: >> Hello , >> >> I've been trying to install freeipa server v 4.1.0 on my fedora 20 >> machine and I can't complete the installation because of hte DNS >> forwarders > > What exactly is the problem/symptom? Are you receiving an error? Or > something else? > > We need to see exact package versions, parameters you have used, > messages, logs etc. > >> my machine's IP is 192.168.254.7 and I'm using the same IP for DNS >> forwarders, this is what I did when I was installing 4.0.3 and 3.3.5 >> and it installed smoothly , so my question is why won't it work in >> 4.1.0 ? is there something new when configuring DNS forwarders? > > I'm not sure I understand you. > > What do you mean with 'my machine'? Is it the (to-be-installed) IPA > server? Or some other machine? > > Are you installing IPA with or without DNS? > > There is no point in configuring IPA to use itself as forwarder. > > Please tell us what exactly doesn't work for you :-) > And back to your original question: 4.1 has a lot of changes related to DNSSEC work so something might be broken and we like to understand what and why. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Fri Oct 31 18:24:19 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 31 Oct 2014 14:24:19 -0400 Subject: [Freeipa-users] Extra attributes for sync agreement AD to FreeIPA In-Reply-To: <5453AF6F.6060708@redhat.com> References: <5453A3A8.9090302@lms.polytechnique.fr> <5453A4E9.6080302@redhat.com> <5453ADD3.8070403@lms.polytechnique.fr> <5453AF6F.6060708@redhat.com> Message-ID: <5453D3D3.6070908@redhat.com> On 10/31/2014 11:49 AM, Rob Crittenden wrote: > Edouard Guign? wrote: >> Hello Rob, >> >> Thank you for your answer. >> Do you mean it should already work ? >> Or I have to do this on the FreeIPA server : >> >> |rm /etc/dirsrv/slapd-INSTNAME/schema/10rfc2307.ldif >> cp /usr/share/dirsrv/data/10rfc2307bis.ldif /etc/dirsrv/slapd-INSTNAME/schema > Sorry, I guess I was a little terse. > > The nisDomain is already defined for IPA so you can skip that bit. > > The Posix Winsync Plugin is disabled by default. You'll need to enable > it and configure it to match your environment. See the wiki page for > configuration details. > > You can either enable and configure it online by using ldapmodify and > binding as the Directory Manager or by shutting down 389-ds and > modifying dse.ldif, then restarting it (or use a tool like Apache > Directory Studio). > > rob > >> >> | >> >> Best Regards, have a nice we. >> Ed >> >> Le 31/10/2014 16:04, Rob Crittenden a ?crit : >>> Edouard Guign? wrote: >>>> Hello freeipa Users, >>>> >>>> I am working on a sync agreement between AD server -> FreeIPA server >>>> (fedora 20) >>>> >>>> I follow the documentation, my sync works beetwen AD -> FreeIPA with >>>> "ipa-replica-manage connect --winsync ..." >>>> >>>> However, I would like to extract attributes from my AD like : >>>> - uidNumber >>>> - gidNumber >>>> - unixHomeDirectory >>>> - loginShell >>>> - msSFU30NisDomain >>>> My AD server is 2008 R2 with with Subsystem for UNIX-based Applications. >>>> >>>> I would like rerieve these attributes in my freeipa server after sync. >>>> >>>> I had a look on google, and find informations like this : >>>> https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/managing-sync-agmt.html#tab.sync-agmt-attrs >>>> >>>> But I did not succeed with it. >>>> >>>> May someone help me ? >>>> >>> It should already work: >>> >>> http://www.port389.org/docs/389ds/design/winsync-posix.html >>> >>> rob >>> >>> >>> I just want to mention that this is not a recommended approach. While the plugin exists in DS it is not enabled or supported for IPA. The supported way to deal with POSIX attribute in AD is to use trust with AD rather than sync. Is this a one time move of the accounts from AD to IPA and you plan to turn the plugin off after initial sync? If not it will be a configuration we would recommend. If you just want to copy attributes using ipa migrate-ds or dumping accounts into LDIF and then loading LDIF would be a better option. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From mlasevich at gmail.com Fri Oct 31 21:34:46 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Fri, 31 Oct 2014 14:34:46 -0700 Subject: [Freeipa-users] Errors upgrading 4.0.1 to 4.1 In-Reply-To: <545348B5.1090904@redhat.com> References: <54527F90.3000407@redhat.com> <545280EA.40604@gmail.com> <54528526.4040500@redhat.com> <545348B5.1090904@redhat.com> Message-ID: <54540076.2040801@gmail.com> Thank you!!! That was exactly it. * Removed the "nsEncryptionConfig" entry from 99user.ldif * Re-run the "ipa-ldap-update --upgrade" * Then "ipa-dns-install" and things are looking much better - both servers are now back up and running. What is the lesson here (besides "have good backups")? Should we be turning off ALL servers before upgrading to prevent replication? I did notice that the 99user entry was made it to BOTH servers, which makes me think that replication is not exactly the culprit. -M On 10/31/14, 1:30 AM, Ludwig Krispenz wrote: > > On 10/30/2014 07:36 PM, Martin Basti wrote: >> On 30/10/14 19:18, Michael Lasevich wrote: >>> Makes sense. What is the solution here? >>> >>> I have the latest 389-ds installed but still getting >>> "allowWeakCipher" error - how to I get around that? >>> >>> -M >>> >> Sorry I don't know, I CCied Ludwig, he is DS guru. > I already asked to verify the schema files: > can you check your schema files for the definition of the > nsEncryptionConfig objectclass, it should be only in 01core389.ldif > and contain allowWeakCipher, but it could have been added also to > 99user.ldif during replication when schema changes have been consolidated > > and what is the latest ds version you are using: rpm -q 389-ds-base > > >> Martin^2 >> >>> >>> On 10/30/14, 11:12 AM, Martin Basti wrote: >>>> On 24/10/14 05:17, Michael Lasevich wrote: >>>>> While upgrading from 4.0.1. to 4.1 on fedora 20 got following on >>>>> one of the two boxes: >>>>> >>>>> Upgrade failed with attribute "allowWeakCipher" not allowed >>>>> IPA upgrade failed. >>>>> Unexpected error >>>>> DuplicateEntry: This entry already exists >>>>> >>>> >>>> Named errors are caused by cascade effect, if ldap schema and entry >>>> updates failed, there is misconfigured DS plugin which is >>>> responsible to keep DNSSEC keys DN unique, what causes duplication >>>> errors. DuplicateEntry exception is fatal, so dnskeysyncd >>>> installation will not continue, >>>> what causes there are not appropriate permissions for token >>>> database, and named-pkcs11 can't read tokens. >>>>> >>>>> >>>>> It seems the ipa no longer starts up after this. The replica >>>>> server seems to have had same error,but it runs just fine. >>>>> >>>>> From digging around, it appears that there are a number of GSS >>>>> errors in dirsrv and bind fails with something like: >>>>> >>>>> named-pkcs11[2212]: ObjectStore.cpp(74): Failed to open token >>>>> e919db16-6329-406c-6ae4-120ad68508c4 >>>>> named-pkcs11[2212]: sha1.c:92: fatal error: >>>>> named-pkcs11[2212]: RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, >>>>> isc_boolean_true, isc_boolean_false, isc_boolean_false, ((void >>>>> *)0), 0) == 0) failed >>>>> >>>>> Any help would be appreciated >>>>> >>>>> >>>>> -M >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Martin Basti >>> >> >> >> -- >> Martin Basti > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlasevich at gmail.com Fri Oct 31 21:42:49 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Fri, 31 Oct 2014 14:42:49 -0700 Subject: [Freeipa-users] IPA Backup in AWS - best practices? Message-ID: <54540259.4010809@gmail.com> What is the current best practice for backing up IPA servers? Especially in AWS? Given AWS strengths and weaknesses, I would love to be able to move all of IPA data/state onto a separate drive and just snapshot it on regular basis - but it seems that IPA data is all over the place, so it is hard to separate it from the rest of the OS. Snapshotting entire root drive is another option, but restoring from that is a bit of a pain, so it may not be optimal. There is always also the plain old "tar it all up" approach. What do people use? What works, what does not? Thanks, -M From dpal at redhat.com Fri Oct 31 22:27:02 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 31 Oct 2014 18:27:02 -0400 Subject: [Freeipa-users] IPA Backup in AWS - best practices? In-Reply-To: <54540259.4010809@gmail.com> References: <54540259.4010809@gmail.com> Message-ID: <54540CB6.5080402@redhat.com> On 10/31/2014 05:42 PM, Michael Lasevich wrote: > What is the current best practice for backing up IPA servers? Especially > in AWS? > > Given AWS strengths and weaknesses, I would love to be able to move all > of IPA data/state onto a separate drive and just snapshot it on regular > basis - but it seems that IPA data is all over the place, so it is hard > to separate it from the rest of the OS. Snapshotting entire root drive > is another option, but restoring from that is a bit of a pain, so it may > not be optimal. There is always also the plain old "tar it all up" http://www.freeipa.org/page/Backup_and_Restore This is pretty much what we recommended for some time until we built: http://www.freeipa.org/page/V3/Backup_and_Restore > approach. > > What do people use? What works, what does not? > > Thanks, > > -M > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc.