From rajnesh.siwal at gmail.com Wed Jan 1 18:01:19 2014 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Wed, 1 Jan 2014 23:31:19 +0530 Subject: [Freeipa-users] FreeIPA Security issue : Anonymous user can fetch user details from IPA without authenticating Message-ID: Hi, IPA has really been a great Project. But, I was really concerned about the security of IPA I have been testing it on RHEL 7 Beta for some time. ldapsearch is able to fetch the details from the IPA Server without Authentication. I would appreciate if IPA team could work on securing the IPA Server as it the most critical server if installed in an infrastructure. It exposes the details of all the users/admins in the environment. There should be a user that the IPA should use to fetch the details from the IPA Servers. Without Authentication , no one should be able to fetch any information from the IPA Server. -- Regards, Rajnesh Kumar Siwal -------------- next part -------------- An HTML attachment was scrubbed... URL: From jitseklomp at gmail.com Wed Jan 1 18:41:58 2014 From: jitseklomp at gmail.com (Jitse Klomp) Date: Wed, 01 Jan 2014 19:41:58 +0100 Subject: [Freeipa-users] FreeIPA Security issue : Anonymous user can fetch user details from IPA without authenticating In-Reply-To: References: Message-ID: <52C46176.5010100@gmail.com> It is possible to disable anonymous binds to the directory server. Take a look at https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html - Jitse On 01/01/2014 07:01 PM, Rajnesh Kumar Siwal wrote: > It exposes the details of all the users/admins in the environment. > There should be a user that the IPA should use to fetch the details from > the IPA Servers. Without Authentication , no one should be able to fetch > any information from the IPA Server. From andrew.holway at gmail.com Wed Jan 1 22:27:57 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Wed, 1 Jan 2014 22:27:57 +0000 Subject: [Freeipa-users] AD - Freeipa trust confusion Message-ID: Hello, I am attempting to set up trust between my test freeipa server at ipa.wibble.com. and my test AD server at win-5uglhak7rin.prattle.com. In the GUI I can see the following in "Trusts ? prattle.com". Realm name: prattle.com Domain NetBIOS name: PRATTLE Domain Security Identifier: S-1-5-21-2812083513-4116408788-3699662436 Trust direction: Two-way trust Trust type: Active Directory domain However I cant see any of the AD users that I have created nor can I log on to any of the systems under my freeipa realm. Jan 1 20:50:30 host002 sshd[9959]: Failed password for invalid user bob from 10.51.120.1 port 55101 ssh2 I haven't actually done anything to AD to facilitate this trust. Its not particularly clear what should be done. Many thanks, Andrew From andrew.holway at gmail.com Thu Jan 2 12:38:34 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 2 Jan 2014 12:38:34 +0000 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: References: Message-ID: I have gotten a little further along with this but am having problems connecting to the AD LDAP. [root at ipa.wibble.com cacerts]# ipa-replica-manage connect --winsync --binddn cn=administrator,cn=users,dc=prattle,dc=com --bindpw X9deiX9dei --passsync X9deiX9dei --cacert /etc/openldap/cacerts/prattle.crt win-5uglhak7rin.prattle.com. -vvv Directory Manager password: Added CA certificate /etc/openldap/cacerts/prattle.crt to certificate database for ipa.wibble.com ipa: INFO: Failed to connect to AD server win-5uglhak7rin.prattle.com. ipa: INFO: The error was: {'info': '00000000: LdapErr: DSID-0C090E17, comment: Error initializing SSL/TLS, data 0, v1db1', 'desc': 'Server is unavailable'} Failed to setup winsync replication On 1 January 2014 22:27, Andrew Holway wrote: > Hello, > > I am attempting to set up trust between my test freeipa server at > ipa.wibble.com. and my test AD server at win-5uglhak7rin.prattle.com. > > In the GUI I can see the following in "Trusts ? prattle.com". > > Realm name: prattle.com > Domain NetBIOS name: PRATTLE > Domain Security Identifier: S-1-5-21-2812083513-4116408788-3699662436 > Trust direction: Two-way trust > Trust type: Active Directory domain > > However I cant see any of the AD users that I have created nor can I > log on to any of the systems under my freeipa realm. > > Jan 1 20:50:30 host002 sshd[9959]: Failed password for invalid user > bob from 10.51.120.1 port 55101 ssh2 > > I haven't actually done anything to AD to facilitate this trust. Its > not particularly clear what should be done. > > Many thanks, > > Andrew From dpal at redhat.com Thu Jan 2 13:41:05 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 02 Jan 2014 08:41:05 -0500 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: References: Message-ID: <52C56C71.5050703@redhat.com> On 01/02/2014 07:38 AM, Andrew Holway wrote: > I have gotten a little further along with this but am having problems > connecting to the AD LDAP. > > [root at ipa.wibble.com cacerts]# ipa-replica-manage connect --winsync > --binddn cn=administrator,cn=users,dc=prattle,dc=com --bindpw > X9deiX9dei --passsync X9deiX9dei --cacert > /etc/openldap/cacerts/prattle.crt win-5uglhak7rin.prattle.com. -vvv > > Directory Manager password: > > Added CA certificate /etc/openldap/cacerts/prattle.crt to certificate > database for ipa.wibble.com > > ipa: INFO: Failed to connect to AD server win-5uglhak7rin.prattle.com. > > ipa: INFO: The error was: {'info': '00000000: LdapErr: DSID-0C090E17, > comment: Error initializing SSL/TLS, data 0, v1db1', 'desc': 'Server > is unavailable'} > > Failed to setup winsync replication Hello, Trusts and winsync are mutually exclusive. You either do one or another. We do not have a way to move from one configuration to another yet and the decision should be made at the deployment time. Which one do you prefer? If you prefer trusts please follow the instructions on the wiki. The guide is not updated yet, sorry. http://www.freeipa.org/page/Trusts http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup It seems that after the trust is established you try to login and fail. Can you provide more details about those attempts? http://www.freeipa.org/page/Troubleshooting#Reporting_bugs also see other sections on the same page. HTH Thanks Dmitri > > On 1 January 2014 22:27, Andrew Holway wrote: >> Hello, >> >> I am attempting to set up trust between my test freeipa server at >> ipa.wibble.com. and my test AD server at win-5uglhak7rin.prattle.com. >> >> In the GUI I can see the following in "Trusts ? prattle.com". >> >> Realm name: prattle.com >> Domain NetBIOS name: PRATTLE >> Domain Security Identifier: S-1-5-21-2812083513-4116408788-3699662436 >> Trust direction: Two-way trust >> Trust type: Active Directory domain >> >> However I cant see any of the AD users that I have created nor can I >> log on to any of the systems under my freeipa realm. >> >> Jan 1 20:50:30 host002 sshd[9959]: Failed password for invalid user >> bob from 10.51.120.1 port 55101 ssh2 >> >> I haven't actually done anything to AD to facilitate this trust. Its >> not particularly clear what should be done. >> >> Many thanks, >> >> Andrew > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From matthew.joseph at lmco.com Thu Jan 2 16:05:30 2014 From: matthew.joseph at lmco.com (Joseph, Matthew (EXP)) Date: Thu, 2 Jan 2014 11:05:30 -0500 Subject: [Freeipa-users] NIS Compat issues Message-ID: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> Hello, I've recently had to restart my IPA servers and my NIS compatibility mode has stopped working. I've configured my IPA server to run in NIS compatibility mode by doing the following. [root at ipaserver ~]# ipa-nis-manage enable [root at ipaserver ~]# ipa-compat-manage enable Restart the DNS and Directory Server service: [root at server ~]# service restart rpcbind [root at server ~]# service restart dirsrv On my NIS clients I have the following setup in the yp.conf file. domain domainname.ca server ipaservername.domainname.ca I tried just running the broadcast option but with no luck. When I try to do a service ypbind start on my NIS clients it takes a few minutes to finally fail. When I tried an yptest says "Can't communicate with ypbind" which makes sense since ypbind will not start. On the NIS client in the messages file it says the following; Ypbind: broadcast: RPC: Timed Out Cannot bind UDP: Address already in use Nothing has changed on my IPA server/configuration so I have no idea why this stopped working. Any suggestions? Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Jan 2 16:12:46 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 02 Jan 2014 11:12:46 -0500 Subject: [Freeipa-users] NIS Compat issues In-Reply-To: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> Message-ID: <52C58FFE.9010704@redhat.com> On 01/02/2014 11:05 AM, Joseph, Matthew (EXP) wrote: > > Hello, > > > > I've recently had to restart my IPA servers and my NIS compatibility > mode has stopped working. > > I've configured my IPA server to run in NIS compatibility mode by > doing the following. > > [root at ipaserver ~]# ipa-nis-manage enable > > [root at ipaserver ~]# ipa-compat-manage enable > > Restart the DNS and Directory Server service: > > [root at server ~]# service restart rpcbind > > [root at server ~]# service restart dirsrv > > On my NIS clients I have the following setup in the yp.conf file. > > domain domainname.ca > server ipaservername.domainname.ca > > > > I tried just running the broadcast option but with no luck. > > > > > > When I try to do a service ypbind start on my NIS clients it takes a > few minutes to finally fail. > > When I tried an yptest says "Can't communicate with ypbind" which > makes sense since ypbind will not start. > > > > On the NIS client in the messages file it says the following; > > Ypbind: broadcast: RPC: Timed Out > > Cannot bind UDP: Address already in use > > > > Nothing has changed on my IPA server/configuration so I have no idea > why this stopped working. > > Any suggestions? > Please check if the IPA is running, the DS is running. Check the logs that the compat plugin is loaded and working. You can also try looking at the compat tree from the server itself to verify that the plugin, at least the DS part is functional. This generally smells as a firewall issue but I have not way to prove or disprove the theory. > > > Matt > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Jan 2 16:46:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 02 Jan 2014 17:46:55 +0100 Subject: [Freeipa-users] Trouble with replica install In-Reply-To: <4ED173A868981548967B4FCA2707222602A98F@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222602A807@AACMBXP04.exchserver.com> <4ED173A868981548967B4FCA2707222602A835@AACMBXP04.exchserver.com>, <52AEE632.6000705@redhat.com> <4ED173A868981548967B4FCA2707222602A98F@AACMBXP04.exchserver.com> Message-ID: <52C597FF.8030904@redhat.com> Hello Les, Did you manage to resolve the issue? I just got to it after the Christmas break. Reading few resources online, this error seems to come of a misconfigured httpd when for example mod_authz_groupfile.so or mod_authz_user.so Apache modules are not loaded (I have them loaded in /etc/httpd/conf.modules.d/00-base.conf). Did you modify httpd configuration before you run ipa-replica-install in any way? Martin On 12/16/2013 01:44 PM, Les Stott wrote: > Petr, > > The below was the error from apache error logs.... > >> Apache logs the following error at the same time... >> >> [Mon Dec 16 04:26:50 2013] [crit] [client 192.168.0.13] configuration error: couldn't check access. No groups file?: /ipa/xml, referer: https://replica.mydomain.com/ipa/xml > > Other lines in the /var/log/httpd/error log at the same time... > > [Mon Dec 16 04:26:49 2013] [error] ipa: INFO: *** PROCESS START *** > [Mon Dec 16 04:26:49 2013] [error] ipa: INFO: *** PROCESS START *** > [Mon Dec 16 04:26:50 2013] [crit] [client 192.168.0.13] configuration error: couldn't check access. No groups file?: /ipa/xml, referer: https://replica.mydomain.com/ipa/xml > [Mon Dec 16 04:29:01 2013] [notice] caught SIGTERM, shutting down > [Mon Dec 16 04:29:02 2013] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 > > Regards, > > Les > > ________________________________________ > From: Petr Spacek [pspacek at redhat.com] > Sent: Monday, December 16, 2013 10:38 PM > To: Les Stott; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Trouble with replica install > > On 16.12.2013 10:55, Les Stott wrote: >> Sorry, when I said "selinux is in permissive mode, but it's the same as on the master server, so it should be the issue." It should have read as "selinux is in permissive mode, but it's the same as on the master server, so it should NOT be the issue." >> >> Les >> >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Les Stott >> Sent: Monday, 16 December 2013 8:47 PM >> To: freeipa-users at redhat.com >> Subject: [Freeipa-users] Trouble with replica install >> >> Hi, >> >> Running ipa-server-3.0.0-37.el6.x86_64 on rhel6. >> Already setup master server, now trying to install replica (which I've done before and its worked fine). >> >> The replica install gets all the way to the end but errors out. For the most part, it looks like it is complete, but I want to be sure there are no lingering issues. >> >> The error I see in the log is...(domain and ip's changed) >> >> ------------------------ >> 2013-12-16T09:26:50Z DEBUG stderr=Hostname: replica.mydomain.com >> Realm: MYDOMAIN.COM >> DNS Domain: mydomain.com >> IPA Server: replica.mydomain.com >> BaseDN: dc=mydomain,dc=com >> Domain mydomain.com is already configured in existing SSSD config, creating a new one. >> The old /etc/sssd/sssd.conf is backed up and will be restored during uninstall. >> Configured /etc/sssd/sssd.conf >> trying https://replica.mydomain.com/ipa/xml >> Forwarding 'env' to server u'https://replica.mydomain.com/ipa/xml' >> Traceback (most recent call last): >> File "/usr/sbin/ipa-client-install", line 2377, in >> sys.exit(main()) >> File "/usr/sbin/ipa-client-install", line 2363, in main >> rval = install(options, env, fstore, statestore) >> File "/usr/sbin/ipa-client-install", line 2167, in install >> remote_env = api.Command['env'](server=True)['result'] >> File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 435, in __call__ >> ret = self.run(*args, **options) >> File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 1073, in run >> return self.forward(*args, **options) >> File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 769, in forward >> return self.Backend.xmlclient.forward(self.name, *args, **kw) >> File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 776, in forward >> raise NetworkError(uri=server, error=e.errmsg) > >> ipalib.errors.NetworkError: cannot connect to u'https://replica.mydomain.com/ipa/xml': Internal Server Error > > Please look into /var/log/httpd/errors.log on server replica.mydomain.com and > check error messages there. > > Petr^2 Spacek > >> >> 2013-12-16T09:26:50Z INFO File "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", line 614, in run_script >> return_value = main_function() >> >> File "/usr/sbin/ipa-replica-install", line 527, in main >> raise RuntimeError("Failed to configure the client") >> >> 2013-12-16T09:26:50Z INFO The ipa-replica-install command failed, exception: RuntimeError: Failed to configure the client >> ------------------- >> >> Apache logs the following error at the same time... >> >> [Mon Dec 16 04:26:50 2013] [crit] [client 192.168.0.13] configuration error: couldn't check access. No groups file?: /ipa/xml, referer: https://replica.mydomain.com/ipa/xml >> >> I can login to the gui and it seems ok, but I'm rolling this into production so I've got to get it right. >> >> I'm hoping this is just some bug because its an older freeipa on redhat (minimal install) etc. selinux is in permissive mode, but it's the same as on the master server, so it should be the issue. >> >> Is this error critical? How can I fix it? >> >> Thanks in advance, >> >> Les > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From mkosek at redhat.com Thu Jan 2 16:52:22 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 02 Jan 2014 17:52:22 +0100 Subject: [Freeipa-users] Trouble with replica install In-Reply-To: <52C597FF.8030904@redhat.com> References: <4ED173A868981548967B4FCA2707222602A807@AACMBXP04.exchserver.com> <4ED173A868981548967B4FCA2707222602A835@AACMBXP04.exchserver.com>, <52AEE632.6000705@redhat.com> <4ED173A868981548967B4FCA2707222602A98F@AACMBXP04.exchserver.com> <52C597FF.8030904@redhat.com> Message-ID: <52C59946.50107@redhat.com> Ah, I see this thread was resolved already, my MUA just failed to properly attach it to the thread. Please disregard this mail then (but I was right with the root cause though :) Martin On 01/02/2014 05:46 PM, Martin Kosek wrote: > Hello Les, > > Did you manage to resolve the issue? I just got to it after the Christmas > break. Reading few resources online, this error seems to come of a > misconfigured httpd when for example mod_authz_groupfile.so or > mod_authz_user.so Apache modules are not loaded (I have them loaded in > /etc/httpd/conf.modules.d/00-base.conf). > > Did you modify httpd configuration before you run ipa-replica-install in any way? > > Martin > > On 12/16/2013 01:44 PM, Les Stott wrote: >> Petr, >> >> The below was the error from apache error logs.... >> >>> Apache logs the following error at the same time... >>> >>> [Mon Dec 16 04:26:50 2013] [crit] [client 192.168.0.13] configuration error: couldn't check access. No groups file?: /ipa/xml, referer: https://replica.mydomain.com/ipa/xml >> >> Other lines in the /var/log/httpd/error log at the same time... >> >> [Mon Dec 16 04:26:49 2013] [error] ipa: INFO: *** PROCESS START *** >> [Mon Dec 16 04:26:49 2013] [error] ipa: INFO: *** PROCESS START *** >> [Mon Dec 16 04:26:50 2013] [crit] [client 192.168.0.13] configuration error: couldn't check access. No groups file?: /ipa/xml, referer: https://replica.mydomain.com/ipa/xml >> [Mon Dec 16 04:29:01 2013] [notice] caught SIGTERM, shutting down >> [Mon Dec 16 04:29:02 2013] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 >> >> Regards, >> >> Les >> >> ________________________________________ >> From: Petr Spacek [pspacek at redhat.com] >> Sent: Monday, December 16, 2013 10:38 PM >> To: Les Stott; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Trouble with replica install >> >> On 16.12.2013 10:55, Les Stott wrote: >>> Sorry, when I said "selinux is in permissive mode, but it's the same as on the master server, so it should be the issue." It should have read as "selinux is in permissive mode, but it's the same as on the master server, so it should NOT be the issue." >>> >>> Les >>> >>> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Les Stott >>> Sent: Monday, 16 December 2013 8:47 PM >>> To: freeipa-users at redhat.com >>> Subject: [Freeipa-users] Trouble with replica install >>> >>> Hi, >>> >>> Running ipa-server-3.0.0-37.el6.x86_64 on rhel6. >>> Already setup master server, now trying to install replica (which I've done before and its worked fine). >>> >>> The replica install gets all the way to the end but errors out. For the most part, it looks like it is complete, but I want to be sure there are no lingering issues. >>> >>> The error I see in the log is...(domain and ip's changed) >>> >>> ------------------------ >>> 2013-12-16T09:26:50Z DEBUG stderr=Hostname: replica.mydomain.com >>> Realm: MYDOMAIN.COM >>> DNS Domain: mydomain.com >>> IPA Server: replica.mydomain.com >>> BaseDN: dc=mydomain,dc=com >>> Domain mydomain.com is already configured in existing SSSD config, creating a new one. >>> The old /etc/sssd/sssd.conf is backed up and will be restored during uninstall. >>> Configured /etc/sssd/sssd.conf >>> trying https://replica.mydomain.com/ipa/xml >>> Forwarding 'env' to server u'https://replica.mydomain.com/ipa/xml' >>> Traceback (most recent call last): >>> File "/usr/sbin/ipa-client-install", line 2377, in >>> sys.exit(main()) >>> File "/usr/sbin/ipa-client-install", line 2363, in main >>> rval = install(options, env, fstore, statestore) >>> File "/usr/sbin/ipa-client-install", line 2167, in install >>> remote_env = api.Command['env'](server=True)['result'] >>> File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 435, in __call__ >>> ret = self.run(*args, **options) >>> File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 1073, in run >>> return self.forward(*args, **options) >>> File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 769, in forward >>> return self.Backend.xmlclient.forward(self.name, *args, **kw) >>> File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 776, in forward >>> raise NetworkError(uri=server, error=e.errmsg) >> >>> ipalib.errors.NetworkError: cannot connect to u'https://replica.mydomain.com/ipa/xml': Internal Server Error >> >> Please look into /var/log/httpd/errors.log on server replica.mydomain.com and >> check error messages there. >> >> Petr^2 Spacek >> >>> >>> 2013-12-16T09:26:50Z INFO File "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", line 614, in run_script >>> return_value = main_function() >>> >>> File "/usr/sbin/ipa-replica-install", line 527, in main >>> raise RuntimeError("Failed to configure the client") >>> >>> 2013-12-16T09:26:50Z INFO The ipa-replica-install command failed, exception: RuntimeError: Failed to configure the client >>> ------------------- >>> >>> Apache logs the following error at the same time... >>> >>> [Mon Dec 16 04:26:50 2013] [crit] [client 192.168.0.13] configuration error: couldn't check access. No groups file?: /ipa/xml, referer: https://replica.mydomain.com/ipa/xml >>> >>> I can login to the gui and it seems ok, but I'm rolling this into production so I've got to get it right. >>> >>> I'm hoping this is just some bug because its an older freeipa on redhat (minimal install) etc. selinux is in permissive mode, but it's the same as on the master server, so it should be the issue. >>> >>> Is this error critical? How can I fix it? >>> >>> Thanks in advance, >>> >>> Les >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From mkosek at redhat.com Thu Jan 2 17:06:49 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 02 Jan 2014 18:06:49 +0100 Subject: [Freeipa-users] ipa-client-install 2.58 client incompatible with 2.49 server In-Reply-To: <52BF0F69.6010502@redhat.com> References: <52BF0F69.6010502@redhat.com> Message-ID: <52C59CA9.9020203@redhat.com> On 12/28/2013 06:50 PM, Rob Crittenden wrote: > Will Sheldon wrote: >> >> Hello :) >> >> I'm trying to setup a ubuntu 12.04.3 client running freeipa-client >> 3.2.0-0ubuntu1~precise1 form the apt repo at >> http://ppa.launchpad.net/freeipa/ppa/ubuntu >> The server is a (fully updated) centos 6.5 box running ipa-server.x86_64 >> 3.0.0-37.el6 >> >> The script mostly works on a stock install, but there is an error >> uploading SSH keys, This appears to be called from the >> ipa-client-install script line 1436: >> >> result = api.Command['host_mod'](unicode(hostname), >> >> Which generates the following output when run: >> >> stderr= >> Caught fault 901 from server https://ipa.[domain].com/ipa/xml: 2.58 >> client incompatible with 2.49 server at u'https://ipa.[domain].com/ipa/xml' >> host_mod: 2.58 client incompatible with 2.49 server at >> u'https://ipa.[domain].com/ipa/xml' >> Failed to upload host SSH public keys. >> >> I understand that this is not a critical failure and that I can manually >> upload the host keys if needed but the bit I don't understand is where >> the version numbers come from. > > The API version is baked into the client and server. We generally provide a > backwards compatible server, but right now not the client (so a new client > can't always have 100% success talking to an old server). We are actually > working on this, especially for client enrollment, to make things work more > smoothly. > >> How do I revert the api to version 2.49 to match the server? > > You'd have to modify ipapython/version.py on each client before enrollment. For > enrollment I can't think of any side-effects, but if you ever tried the IPA > admin tool on such a client then some odd things could happen. > >> What is best practice here, should I be using a different source for the >> client install script? > > I don't know what is available for Debian/Ubuntu clients these days. It is > being worked on very hard though I think the focus is on the latest source > which explains the mismatch. > >> Is there a copy of the correct client files stashed on the server somewhere? >> Would anyone be interested in helping with development of a yum and apt >> repo on the server to make all this easier? > > The server being the IPA server, so it can distribute the client bits? An > interesting idea. > > rob > Note that this issue was fixed in FreeIPA version 3.3.2 (upstream ticket https://fedorahosted.org/freeipa/ticket/3931). Thus, when using FreeIPA client 3.3.2 and later, ipa-client-install will upload the SSH keys even to the older SSH server. No other changes required. HTH, Martin From andrew.holway at gmail.com Thu Jan 2 17:07:27 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 2 Jan 2014 17:07:27 +0000 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: <52C56C71.5050703@redhat.com> References: <52C56C71.5050703@redhat.com> Message-ID: I have taken out the winsync. [root at ipa.wibble.com ~]# ipa-replica-manage connect --binddn cn=administrator,cn=users,dc=prattle,dc=com --bindpw pa$$ --passsync pa$$ --cacert /etc/openldap/cacerts/prattle.crt win-5uglhak7rin.prattle.com. -vvv Added CA certificate /etc/openldap/cacerts/prattle.crt to certificate database for ipa.wibble.com You cannot connect to a previously deleted master I cant find anything useful in the server2008 AD logs....I am seeing If I can make them more sensitive. /var/log/messages Jan 2 16:53:43 ipa smbd[12033]: [2014/01/02 16:53:43.904045, 0] ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) Jan 2 16:53:43 ipa smbd[12033]: dcesrv_interface_register: interface 'lsarpc' already registered on endpoint Jan 2 16:53:43 ipa smbd[12033]: [2014/01/02 16:53:43.904642, 0] ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) Jan 2 16:53:43 ipa smbd[12033]: dcesrv_interface_register: interface 'samr' already registered on endpoint Jan 2 16:53:43 ipa smbd[12033]: [2014/01/02 16:53:43.905147, 0] ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) Jan 2 16:53:43 ipa smbd[12033]: dcesrv_interface_register: interface 'netlogon' already registered on endpoint Jan 2 16:53:47 ipa named[11459]: LDAP error: Can't contact LDAP server Jan 2 16:53:47 ipa named[11459]: connection to the LDAP server was lost Jan 2 16:53:47 ipa named[11459]: bind to LDAP server failed: Can't contact LDAP server Jan 2 16:53:47 ipa named[11459]: ldap_psearch_watcher failed to handle LDAP connection error. Reconnection in 60s Jan 2 16:53:49 ipa winbindd[12071]: [2014/01/02 16:53:49.299083, 0] ipa_sam.c:3689(bind_callback_cleanup) Jan 2 16:53:49 ipa winbindd[12071]: kerberos error: code=-1765328324, message=Generic error (see e-text) Jan 2 16:53:49 ipa winbindd[12071]: [2014/01/02 16:53:49.299320, 0] ../source3/lib/smbldap.c:998(smbldap_connect_system) Jan 2 16:53:49 ipa winbindd[12071]: failed to bind to server ldapi://%2fvar%2frun%2fslapd-WIBBLE-COM.socket with dn="[Anonymous bind]" Error: Local error Jan 2 16:53:49 ipa winbindd[12071]: #011(unknown) Jan 2 16:54:13 ipa smbd[12033]: [2014/01/02 16:54:13.909746, 0] ../source3/rpc_server/rpc_handles.c:261(create_rpc_handle_internal) Jan 2 16:54:13 ipa smbd[12033]: create_policy_hnd: ERROR: too many handles (2049) on this pipe. Jan 2 16:54:13 ipa smbd[12033]: [2014/01/02 16:54:13.910126, 0] ../source3/rpc_server/rpc_handles.c:261(create_rpc_handle_internal) Jan 2 16:54:13 ipa smbd[12033]: create_policy_hnd: ERROR: too many handles (2049) on this pipe. Jan 2 16:54:13 ipa smbd[12033]: [2014/01/02 16:54:13.910427, 0] ../source3/rpc_server/rpc_handles.c:261(create_rpc_handle_internal) Jan 2 16:54:13 ipa smbd[12033]: create_policy_hnd: ERROR: too many handles (2049) on this pipe. On 2 January 2014 13:41, Dmitri Pal wrote: > On 01/02/2014 07:38 AM, Andrew Holway wrote: >> I have gotten a little further along with this but am having problems >> connecting to the AD LDAP. >> >> [root at ipa.wibble.com cacerts]# ipa-replica-manage connect --winsync >> --binddn cn=administrator,cn=users,dc=prattle,dc=com --bindpw >> X9deiX9dei --passsync X9deiX9dei --cacert >> /etc/openldap/cacerts/prattle.crt win-5uglhak7rin.prattle.com. -vvv >> >> Directory Manager password: >> >> Added CA certificate /etc/openldap/cacerts/prattle.crt to certificate >> database for ipa.wibble.com >> >> ipa: INFO: Failed to connect to AD server win-5uglhak7rin.prattle.com. >> >> ipa: INFO: The error was: {'info': '00000000: LdapErr: DSID-0C090E17, >> comment: Error initializing SSL/TLS, data 0, v1db1', 'desc': 'Server >> is unavailable'} >> >> Failed to setup winsync replication > > Hello, > > Trusts and winsync are mutually exclusive. > You either do one or another. We do not have a way to move from one > configuration to another yet and the decision should be made at the > deployment time. > > Which one do you prefer? > If you prefer trusts please follow the instructions on the wiki. The > guide is not updated yet, sorry. > http://www.freeipa.org/page/Trusts > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup > > It seems that after the trust is established you try to login and fail. > Can you provide more details about those attempts? > http://www.freeipa.org/page/Troubleshooting#Reporting_bugs > also see other sections on the same page. > > HTH > Thanks > Dmitri > > >> >> On 1 January 2014 22:27, Andrew Holway wrote: >>> Hello, >>> >>> I am attempting to set up trust between my test freeipa server at >>> ipa.wibble.com. and my test AD server at win-5uglhak7rin.prattle.com. >>> >>> In the GUI I can see the following in "Trusts ? prattle.com". >>> >>> Realm name: prattle.com >>> Domain NetBIOS name: PRATTLE >>> Domain Security Identifier: S-1-5-21-2812083513-4116408788-3699662436 >>> Trust direction: Two-way trust >>> Trust type: Active Directory domain >>> >>> However I cant see any of the AD users that I have created nor can I >>> log on to any of the systems under my freeipa realm. >>> >>> Jan 1 20:50:30 host002 sshd[9959]: Failed password for invalid user >>> bob from 10.51.120.1 port 55101 ssh2 >>> >>> I haven't actually done anything to AD to facilitate this trust. Its >>> not particularly clear what should be done. >>> >>> Many thanks, >>> >>> Andrew >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From andrew.holway at gmail.com Thu Jan 2 17:25:22 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 2 Jan 2014 17:25:22 +0000 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: References: <52C56C71.5050703@redhat.com> Message-ID: I turned off all the AD processed on my windows domain controller. The error did not change. On 2 January 2014 17:07, Andrew Holway wrote: > I have taken out the winsync. > > [root at ipa.wibble.com ~]# ipa-replica-manage connect --binddn > cn=administrator,cn=users,dc=prattle,dc=com --bindpw pa$$ --passsync > pa$$ --cacert /etc/openldap/cacerts/prattle.crt > win-5uglhak7rin.prattle.com. -vvv > Added CA certificate /etc/openldap/cacerts/prattle.crt to certificate > database for ipa.wibble.com > You cannot connect to a previously deleted master > > I cant find anything useful in the server2008 AD logs....I am seeing > If I can make them more sensitive. > > /var/log/messages > > Jan 2 16:53:43 ipa smbd[12033]: [2014/01/02 16:53:43.904045, 0] > ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) > Jan 2 16:53:43 ipa smbd[12033]: dcesrv_interface_register: > interface 'lsarpc' already registered on endpoint > Jan 2 16:53:43 ipa smbd[12033]: [2014/01/02 16:53:43.904642, 0] > ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) > Jan 2 16:53:43 ipa smbd[12033]: dcesrv_interface_register: > interface 'samr' already registered on endpoint > Jan 2 16:53:43 ipa smbd[12033]: [2014/01/02 16:53:43.905147, 0] > ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) > Jan 2 16:53:43 ipa smbd[12033]: dcesrv_interface_register: > interface 'netlogon' already registered on endpoint > Jan 2 16:53:47 ipa named[11459]: LDAP error: Can't contact LDAP server > Jan 2 16:53:47 ipa named[11459]: connection to the LDAP server was lost > Jan 2 16:53:47 ipa named[11459]: bind to LDAP server failed: Can't > contact LDAP server > Jan 2 16:53:47 ipa named[11459]: ldap_psearch_watcher failed to > handle LDAP connection error. Reconnection in 60s > Jan 2 16:53:49 ipa winbindd[12071]: [2014/01/02 16:53:49.299083, 0] > ipa_sam.c:3689(bind_callback_cleanup) > Jan 2 16:53:49 ipa winbindd[12071]: kerberos error: > code=-1765328324, message=Generic error (see e-text) > Jan 2 16:53:49 ipa winbindd[12071]: [2014/01/02 16:53:49.299320, 0] > ../source3/lib/smbldap.c:998(smbldap_connect_system) > Jan 2 16:53:49 ipa winbindd[12071]: failed to bind to server > ldapi://%2fvar%2frun%2fslapd-WIBBLE-COM.socket with dn="[Anonymous > bind]" Error: Local error > Jan 2 16:53:49 ipa winbindd[12071]: #011(unknown) > Jan 2 16:54:13 ipa smbd[12033]: [2014/01/02 16:54:13.909746, 0] > ../source3/rpc_server/rpc_handles.c:261(create_rpc_handle_internal) > Jan 2 16:54:13 ipa smbd[12033]: create_policy_hnd: ERROR: too many > handles (2049) on this pipe. > Jan 2 16:54:13 ipa smbd[12033]: [2014/01/02 16:54:13.910126, 0] > ../source3/rpc_server/rpc_handles.c:261(create_rpc_handle_internal) > Jan 2 16:54:13 ipa smbd[12033]: create_policy_hnd: ERROR: too many > handles (2049) on this pipe. > Jan 2 16:54:13 ipa smbd[12033]: [2014/01/02 16:54:13.910427, 0] > ../source3/rpc_server/rpc_handles.c:261(create_rpc_handle_internal) > Jan 2 16:54:13 ipa smbd[12033]: create_policy_hnd: ERROR: too many > handles (2049) on this pipe. > > > On 2 January 2014 13:41, Dmitri Pal wrote: >> On 01/02/2014 07:38 AM, Andrew Holway wrote: >>> I have gotten a little further along with this but am having problems >>> connecting to the AD LDAP. >>> >>> [root at ipa.wibble.com cacerts]# ipa-replica-manage connect --winsync >>> --binddn cn=administrator,cn=users,dc=prattle,dc=com --bindpw >>> X9deiX9dei --passsync X9deiX9dei --cacert >>> /etc/openldap/cacerts/prattle.crt win-5uglhak7rin.prattle.com. -vvv >>> >>> Directory Manager password: >>> >>> Added CA certificate /etc/openldap/cacerts/prattle.crt to certificate >>> database for ipa.wibble.com >>> >>> ipa: INFO: Failed to connect to AD server win-5uglhak7rin.prattle.com. >>> >>> ipa: INFO: The error was: {'info': '00000000: LdapErr: DSID-0C090E17, >>> comment: Error initializing SSL/TLS, data 0, v1db1', 'desc': 'Server >>> is unavailable'} >>> >>> Failed to setup winsync replication >> >> Hello, >> >> Trusts and winsync are mutually exclusive. >> You either do one or another. We do not have a way to move from one >> configuration to another yet and the decision should be made at the >> deployment time. >> >> Which one do you prefer? >> If you prefer trusts please follow the instructions on the wiki. The >> guide is not updated yet, sorry. >> http://www.freeipa.org/page/Trusts >> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup >> >> It seems that after the trust is established you try to login and fail. >> Can you provide more details about those attempts? >> http://www.freeipa.org/page/Troubleshooting#Reporting_bugs >> also see other sections on the same page. >> >> HTH >> Thanks >> Dmitri >> >> >>> >>> On 1 January 2014 22:27, Andrew Holway wrote: >>>> Hello, >>>> >>>> I am attempting to set up trust between my test freeipa server at >>>> ipa.wibble.com. and my test AD server at win-5uglhak7rin.prattle.com. >>>> >>>> In the GUI I can see the following in "Trusts ? prattle.com". >>>> >>>> Realm name: prattle.com >>>> Domain NetBIOS name: PRATTLE >>>> Domain Security Identifier: S-1-5-21-2812083513-4116408788-3699662436 >>>> Trust direction: Two-way trust >>>> Trust type: Active Directory domain >>>> >>>> However I cant see any of the AD users that I have created nor can I >>>> log on to any of the systems under my freeipa realm. >>>> >>>> Jan 1 20:50:30 host002 sshd[9959]: Failed password for invalid user >>>> bob from 10.51.120.1 port 55101 ssh2 >>>> >>>> I haven't actually done anything to AD to facilitate this trust. Its >>>> not particularly clear what should be done. >>>> >>>> Many thanks, >>>> >>>> Andrew >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Thu Jan 2 17:25:48 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 02 Jan 2014 12:25:48 -0500 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: References: <52C56C71.5050703@redhat.com> Message-ID: <52C5A11C.2080408@redhat.com> On 01/02/2014 12:07 PM, Andrew Holway wrote: > I have taken out the winsync. > > [root at ipa.wibble.com ~]# ipa-replica-manage connect --binddn > cn=administrator,cn=users,dc=prattle,dc=com --bindpw pa$$ --passsync > pa$$ --cacert /etc/openldap/cacerts/prattle.crt > win-5uglhak7rin.prattle.com. -vvv > Added CA certificate /etc/openldap/cacerts/prattle.crt to certificate > database for ipa.wibble.com You are still setting up a replication agreement not a trust. > You cannot connect to a previously deleted master I think it confuses your AD for a replica that does not exist. > > I cant find anything useful in the server2008 AD logs....I am seeing > If I can make them more sensitive. > > /var/log/messages > > Jan 2 16:53:43 ipa smbd[12033]: [2014/01/02 16:53:43.904045, 0] > ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) > Jan 2 16:53:43 ipa smbd[12033]: dcesrv_interface_register: > interface 'lsarpc' already registered on endpoint > Jan 2 16:53:43 ipa smbd[12033]: [2014/01/02 16:53:43.904642, 0] > ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) > Jan 2 16:53:43 ipa smbd[12033]: dcesrv_interface_register: > interface 'samr' already registered on endpoint > Jan 2 16:53:43 ipa smbd[12033]: [2014/01/02 16:53:43.905147, 0] > ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) > Jan 2 16:53:43 ipa smbd[12033]: dcesrv_interface_register: > interface 'netlogon' already registered on endpoint > Jan 2 16:53:47 ipa named[11459]: LDAP error: Can't contact LDAP server > Jan 2 16:53:47 ipa named[11459]: connection to the LDAP server was lost > Jan 2 16:53:47 ipa named[11459]: bind to LDAP server failed: Can't > contact LDAP server This seems to indicate that the directory server is not running. Can you check that the dirsrv is running? > Jan 2 16:53:47 ipa named[11459]: ldap_psearch_watcher failed to > handle LDAP connection error. Reconnection in 60s > Jan 2 16:53:49 ipa winbindd[12071]: [2014/01/02 16:53:49.299083, 0] > ipa_sam.c:3689(bind_callback_cleanup) > Jan 2 16:53:49 ipa winbindd[12071]: kerberos error: > code=-1765328324, message=Generic error (see e-text) > Jan 2 16:53:49 ipa winbindd[12071]: [2014/01/02 16:53:49.299320, 0] > ../source3/lib/smbldap.c:998(smbldap_connect_system) > Jan 2 16:53:49 ipa winbindd[12071]: failed to bind to server > ldapi://%2fvar%2frun%2fslapd-WIBBLE-COM.socket with dn="[Anonymous > bind]" Error: Local error > Jan 2 16:53:49 ipa winbindd[12071]: #011(unknown) > Jan 2 16:54:13 ipa smbd[12033]: [2014/01/02 16:54:13.909746, 0] > ../source3/rpc_server/rpc_handles.c:261(create_rpc_handle_internal) > Jan 2 16:54:13 ipa smbd[12033]: create_policy_hnd: ERROR: too many > handles (2049) on this pipe. > Jan 2 16:54:13 ipa smbd[12033]: [2014/01/02 16:54:13.910126, 0] > ../source3/rpc_server/rpc_handles.c:261(create_rpc_handle_internal) > Jan 2 16:54:13 ipa smbd[12033]: create_policy_hnd: ERROR: too many > handles (2049) on this pipe. > Jan 2 16:54:13 ipa smbd[12033]: [2014/01/02 16:54:13.910427, 0] > ../source3/rpc_server/rpc_handles.c:261(create_rpc_handle_internal) > Jan 2 16:54:13 ipa smbd[12033]: create_policy_hnd: ERROR: too many > handles (2049) on this pipe. > > > On 2 January 2014 13:41, Dmitri Pal wrote: >> On 01/02/2014 07:38 AM, Andrew Holway wrote: >>> I have gotten a little further along with this but am having problems >>> connecting to the AD LDAP. >>> >>> [root at ipa.wibble.com cacerts]# ipa-replica-manage connect --winsync >>> --binddn cn=administrator,cn=users,dc=prattle,dc=com --bindpw >>> X9deiX9dei --passsync X9deiX9dei --cacert >>> /etc/openldap/cacerts/prattle.crt win-5uglhak7rin.prattle.com. -vvv >>> >>> Directory Manager password: >>> >>> Added CA certificate /etc/openldap/cacerts/prattle.crt to certificate >>> database for ipa.wibble.com >>> >>> ipa: INFO: Failed to connect to AD server win-5uglhak7rin.prattle.com. >>> >>> ipa: INFO: The error was: {'info': '00000000: LdapErr: DSID-0C090E17, >>> comment: Error initializing SSL/TLS, data 0, v1db1', 'desc': 'Server >>> is unavailable'} >>> >>> Failed to setup winsync replication >> Hello, >> >> Trusts and winsync are mutually exclusive. >> You either do one or another. We do not have a way to move from one >> configuration to another yet and the decision should be made at the >> deployment time. >> >> Which one do you prefer? >> If you prefer trusts please follow the instructions on the wiki. The >> guide is not updated yet, sorry. >> http://www.freeipa.org/page/Trusts >> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup >> >> It seems that after the trust is established you try to login and fail. >> Can you provide more details about those attempts? >> http://www.freeipa.org/page/Troubleshooting#Reporting_bugs >> also see other sections on the same page. >> >> HTH >> Thanks >> Dmitri >> >> >>> On 1 January 2014 22:27, Andrew Holway wrote: >>>> Hello, >>>> >>>> I am attempting to set up trust between my test freeipa server at >>>> ipa.wibble.com. and my test AD server at win-5uglhak7rin.prattle.com. >>>> >>>> In the GUI I can see the following in "Trusts ? prattle.com". >>>> >>>> Realm name: prattle.com >>>> Domain NetBIOS name: PRATTLE >>>> Domain Security Identifier: S-1-5-21-2812083513-4116408788-3699662436 >>>> Trust direction: Two-way trust >>>> Trust type: Active Directory domain >>>> >>>> However I cant see any of the AD users that I have created nor can I >>>> log on to any of the systems under my freeipa realm. >>>> >>>> Jan 1 20:50:30 host002 sshd[9959]: Failed password for invalid user >>>> bob from 10.51.120.1 port 55101 ssh2 >>>> >>>> I haven't actually done anything to AD to facilitate this trust. Its >>>> not particularly clear what should be done. >>>> >>>> Many thanks, >>>> >>>> Andrew >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From matthew.joseph at lmco.com Thu Jan 2 17:30:16 2014 From: matthew.joseph at lmco.com (Joseph, Matthew (EXP)) Date: Thu, 2 Jan 2014 12:30:16 -0500 Subject: [Freeipa-users] EXTERNAL: Re: NIS Compat issues In-Reply-To: <52C58FFE.9010704@redhat.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> <52C58FFE.9010704@redhat.com> Message-ID: <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> Hello, All of the IPA services are running. When I tried running the ipa-compat-manage enable and ipa-nis-manage enable they are both loaded and running. The firewall is not the issue, I am positive about that. What do you mean by looking at the compat tree from the IPA server? Matt From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Thursday, January 02, 2014 12:13 PM To: freeipa-users at redhat.com Subject: EXTERNAL: Re: [Freeipa-users] NIS Compat issues On 01/02/2014 11:05 AM, Joseph, Matthew (EXP) wrote: Hello, I've recently had to restart my IPA servers and my NIS compatibility mode has stopped working. I've configured my IPA server to run in NIS compatibility mode by doing the following. [root at ipaserver ~]# ipa-nis-manage enable [root at ipaserver ~]# ipa-compat-manage enable Restart the DNS and Directory Server service: [root at server ~]# service restart rpcbind [root at server ~]# service restart dirsrv On my NIS clients I have the following setup in the yp.conf file. domain domainname.ca server ipaservername.domainname.ca I tried just running the broadcast option but with no luck. When I try to do a service ypbind start on my NIS clients it takes a few minutes to finally fail. When I tried an yptest says "Can't communicate with ypbind" which makes sense since ypbind will not start. On the NIS client in the messages file it says the following; Ypbind: broadcast: RPC: Timed Out Cannot bind UDP: Address already in use Nothing has changed on my IPA server/configuration so I have no idea why this stopped working. Any suggestions? Please check if the IPA is running, the DS is running. Check the logs that the compat plugin is loaded and working. You can also try looking at the compat tree from the server itself to verify that the plugin, at least the DS part is functional. This generally smells as a firewall issue but I have not way to prove or disprove the theory. Matt _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Jan 2 17:37:43 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 02 Jan 2014 12:37:43 -0500 Subject: [Freeipa-users] EXTERNAL: Re: NIS Compat issues In-Reply-To: <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> <52C58FFE.9010704@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> Message-ID: <52C5A3E7.20902@redhat.com> On 01/02/2014 12:30 PM, Joseph, Matthew (EXP) wrote: > > Hello, > > > > All of the IPA services are running. > > When I tried running the ipa-compat-manage enable and ipa-nis-manage > enable they are both loaded and running. > Have you checked the logs to confirm that the DS server actually loaded the plugins? > The firewall is not the issue, I am positive about that. > > > > What do you mean by looking at the compat tree from the IPA server? > I mean doing an ldapsearch operation against cn=compat,... sub tree by running it on the server. Just to see if it returns any data. If it does then the server is probably OK and this is the client that can't connect due to FW or DNS. > > > > Matt > > > > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* Thursday, January 02, 2014 12:13 PM > *To:* freeipa-users at redhat.com > *Subject:* EXTERNAL: Re: [Freeipa-users] NIS Compat issues > > > > On 01/02/2014 11:05 AM, Joseph, Matthew (EXP) wrote: > > Hello, > > > > I've recently had to restart my IPA servers and my NIS compatibility > mode has stopped working. > > I've configured my IPA server to run in NIS compatibility mode by > doing the following. > > [root at ipaserver ~]# ipa-nis-manage enable > > [root at ipaserver ~]# ipa-compat-manage enable > > Restart the DNS and Directory Server service: > > [root at server ~]# service restart rpcbind > > [root at server ~]# service restart dirsrv > > On my NIS clients I have the following setup in the yp.conf file. > > domain domainname.ca > server ipaservername.domainname.ca > > > > I tried just running the broadcast option but with no luck. > > > > > > When I try to do a service ypbind start on my NIS clients it takes a > few minutes to finally fail. > > When I tried an yptest says "Can't communicate with ypbind" which > makes sense since ypbind will not start. > > > > On the NIS client in the messages file it says the following; > > Ypbind: broadcast: RPC: Timed Out > > Cannot bind UDP: Address already in use > > > > Nothing has changed on my IPA server/configuration so I have no idea > why this stopped working. > > Any suggestions? > > > Please check if the IPA is running, the DS is running. Check the logs > that the compat plugin is loaded and working. > You can also try looking at the compat tree from the server itself to > verify that the plugin, at least the DS part is functional. > > This generally smells as a firewall issue but I have not way to prove > or disprove the theory. > > > > > Matt > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Jan 2 18:58:09 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 Jan 2014 13:58:09 -0500 Subject: [Freeipa-users] EXTERNAL: Re: NIS Compat issues In-Reply-To: <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> <52C58FFE.9010704@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> Message-ID: <52C5B6C1.3030607@redhat.com> Joseph, Matthew (EXP) wrote: > Hello, > > All of the IPA services are running. > > When I tried running the ipa-compat-manage enable and ipa-nis-manage > enable they are both loaded and running. On the IPA master you should be able to run something like: $ ypcat -h `hostname` -d passwd This will confirm basic operation on the server. If you can run the same on a client it will rule out firewall issues. Is a ypbind process already running on these clients? That might explain the 'address in use' error. rob > > The firewall is not the issue, I am positive about that. > > What do you mean by looking at the compat tree from the IPA server? > > Matt > > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* Thursday, January 02, 2014 12:13 PM > *To:* freeipa-users at redhat.com > *Subject:* EXTERNAL: Re: [Freeipa-users] NIS Compat issues > > On 01/02/2014 11:05 AM, Joseph, Matthew (EXP) wrote: > > Hello, > > I?ve recently had to restart my IPA servers and my NIS compatibility > mode has stopped working. > > I?ve configured my IPA server to run in NIS compatibility mode by doing > the following. > > [root at ipaserver ~]# ipa-nis-manage enable > > [root at ipaserver ~]# ipa-compat-manage enable > > Restart the DNS and Directory Server service: > > [root at server ~]# service restart rpcbind > > [root at server ~]# service restart dirsrv > > On my NIS clients I have the following setup in the yp.conf file. > > domain domainname.ca > server ipaservername.domainname.ca > > I tried just running the broadcast option but with no luck. > > When I try to do a service ypbind start on my NIS clients it takes a few > minutes to finally fail. > > When I tried an yptest says ?Can?t communicate with ypbind? which makes > sense since ypbind will not start. > > On the NIS client in the messages file it says the following; > > Ypbind: broadcast: RPC: Timed Out > > Cannot bind UDP: Address already in use > > Nothing has changed on my IPA server/configuration so I have no idea why > this stopped working. > > Any suggestions? > > > Please check if the IPA is running, the DS is running. Check the logs > that the compat plugin is loaded and working. > You can also try looking at the compat tree from the server itself to > verify that the plugin, at least the DS part is functional. > > This generally smells as a firewall issue but I have not way to prove or > disprove the theory. > > > Matt > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager for IdM portfolio > > Red Hat Inc. > > > > > > ------------------------------- > > Looking to carve out IT costs? > > www.redhat.com/carveoutcosts/ > > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From andrew.holway at gmail.com Thu Jan 2 19:12:22 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 2 Jan 2014 19:12:22 +0000 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: <52C5A11C.2080408@redhat.com> References: <52C56C71.5050703@redhat.com> <52C5A11C.2080408@redhat.com> Message-ID: > You are still setting up a replication agreement not a trust. Oh, I am following the redhat documentation here: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/managing-sync-agmt.html > This seems to indicate that the directory server is not running. > Can you check that the dirsrv is running? [root at ipa.wibble.com log]# /etc/init.d/dirsrv status dirsrv PKI-IPA (pid 7394) is running... dirsrv WIBBLE-COM (pid 7463) is running... [root at ipa.wibble.com log]# ipa trust-add --type=ad prattle.com --admin Administrator --password Active directory domain administrator's password: ---------------------------------------------------- Added Active Directory trust for realm "prattle.com" ---------------------------------------------------- Realm name: prattle.com Domain NetBIOS name: PRATTLE Domain Security Identifier: S-1-5-21-2812083513-4116408788-3699662436 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified However I cannot log into the windows domain with my linux users nor the linux domain with my linux users..... Ta, Andrew From simo at redhat.com Thu Jan 2 19:16:41 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 02 Jan 2014 14:16:41 -0500 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: References: <52C56C71.5050703@redhat.com> <52C5A11C.2080408@redhat.com> Message-ID: <1388690201.26102.28.camel@willson.li.ssimo.org> On Thu, 2014-01-02 at 19:12 +0000, Andrew Holway wrote: > > You are still setting up a replication agreement not a trust. > > Oh, I am following the redhat documentation here: > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/managing-sync-agmt.html > > > This seems to indicate that the directory server is not running. > > Can you check that the dirsrv is running? > > [root at ipa.wibble.com log]# /etc/init.d/dirsrv status > dirsrv PKI-IPA (pid 7394) is running... > dirsrv WIBBLE-COM (pid 7463) is running... > > > [root at ipa.wibble.com log]# ipa trust-add --type=ad prattle.com --admin > Administrator --password > Active directory domain administrator's password: > ---------------------------------------------------- > Added Active Directory trust for realm "prattle.com" > ---------------------------------------------------- > Realm name: prattle.com > Domain NetBIOS name: PRATTLE > Domain Security Identifier: S-1-5-21-2812083513-4116408788-3699662436 > Trust direction: Two-way trust > Trust type: Active Directory domain > Trust status: Established and verified > > However I cannot log into the windows domain with my linux users nor > the linux domain with my linux users..... At this time loggin in with linux iusers into the Windows domain is not supported and does not work. However loggin with Windows user into a linux machine joined to the ipa realm should work, a slong as you use sssd on the linux machine. What error do you see on the linux machine whe you try to log in with a windows user ? Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Thu Jan 2 19:18:35 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 02 Jan 2014 14:18:35 -0500 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: References: <52C56C71.5050703@redhat.com> <52C5A11C.2080408@redhat.com> Message-ID: <52C5BB8B.6090905@redhat.com> On 01/02/2014 02:12 PM, Andrew Holway wrote: >> You are still setting up a replication agreement not a trust. > Oh, I am following the redhat documentation here: > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/managing-sync-agmt.html This is sync not trust as I mentioned in my first reply. > >> This seems to indicate that the directory server is not running. >> Can you check that the dirsrv is running? > [root at ipa.wibble.com log]# /etc/init.d/dirsrv status > dirsrv PKI-IPA (pid 7394) is running... > dirsrv WIBBLE-COM (pid 7463) is running... > > > [root at ipa.wibble.com log]# ipa trust-add --type=ad prattle.com --admin > Administrator --password > Active directory domain administrator's password: > ---------------------------------------------------- > Added Active Directory trust for realm "prattle.com" > ---------------------------------------------------- > Realm name: prattle.com > Domain NetBIOS name: PRATTLE > Domain Security Identifier: S-1-5-21-2812083513-4116408788-3699662436 > Trust direction: Two-way trust > Trust type: Active Directory domain > Trust status: Established and verified This is the right step. > However I cannot log into the windows domain with my linux users nor > the linux domain with my linux users..... You should not expect logging into AD domain with Linux users. This functionality is not implemented yet. As for AD users we need to look at the client and see what is going on there. What is your client? Version and component? Is it using latest SSSD? If not additional steps might be needed. Please provide the details about the clients. Please start with trying AD users on the IPA server itself, looking at the logs and seeing what is going on. Thanks Dmitri > > Ta, > > Andrew -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From andrew.holway at gmail.com Thu Jan 2 20:06:31 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 2 Jan 2014 20:06:31 +0000 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: <52C5BB8B.6090905@redhat.com> References: <52C56C71.5050703@redhat.com> <52C5A11C.2080408@redhat.com> <52C5BB8B.6090905@redhat.com> Message-ID: > As for AD users we need to look at the client and see what is going on > there. What is your client? Version and component? Is it using latest SSSD? > If not additional steps might be needed. Please provide the details > about the clients. Please start with trying AD users on the IPA server > itself, looking at the logs and seeing what is going on. /var/log/secure Jan 2 19:27:46 ipa sshd[8252]: pam_unix(sshd:auth): check pass; user unknown Jan 2 19:27:46 ipa sshd[8252]: pam_succeed_if(sshd:auth): error retrieving information about user bob at prattle.com Jan 2 19:27:49 ipa sshd[8252]: Failed password for invalid user bob at prattle.com from 192.168.202.12 port 51537 ssh2 /var/log/messages (not sure if related. this error is going off every 20s) Jan 2 19:52:18 ipa smbd[7279]: [2014/01/02 19:52:18.895536, 0] ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) Jan 2 19:52:18 ipa smbd[7279]: dcesrv_interface_register: interface 'lsarpc' already registered on endpoint Jan 2 19:52:18 ipa smbd[7279]: [2014/01/02 19:52:18.896121, 0] ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) Jan 2 19:52:18 ipa smbd[7279]: dcesrv_interface_register: interface 'samr' already registered on endpoint Jan 2 19:52:18 ipa smbd[7279]: [2014/01/02 19:52:18.896616, 0] ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) Jan 2 19:52:18 ipa smbd[7279]: dcesrv_interface_register: interface 'netlogon' already registered on endpoint Jan 2 19:53:18 ipa smbd[7279]: [2014/01/02 19:53:18.913794, 0] ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) Jan 2 19:53:18 ipa smbd[7279]: dcesrv_interface_register: interface 'lsarpc' already registered on endpoint Jan 2 19:53:18 ipa smbd[7279]: [2014/01/02 19:53:18.914377, 0] ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) Jan 2 19:53:18 ipa smbd[7279]: dcesrv_interface_register: interface 'samr' already registered on endpoint Jan 2 19:53:18 ipa smbd[7279]: [2014/01/02 19:53:18.914853, 0] ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) Jan 2 19:53:18 ipa smbd[7279]: dcesrv_interface_register: interface 'netlogon' already registered on endpoint /var/log/krb5kdc.log Jan 02 19:27:37 ipa.wibble.com krb5kdc[6611](info): AS_REQ (4 etypes {18 17 16 23}) 10.51.120.1: NEEDED_PREAUTH: host/ipa.wibble.com at WIBBLE.COM for krbtgt/WIBBLE.COM at WIBBLE.COM, Additional pre-authentication required Jan 02 19:27:37 ipa.wibble.com krb5kdc[6611](info): AS_REQ (4 etypes {18 17 16 23}) 10.51.120.1: ISSUE: authtime 1388690857, etypes {rep=18 tkt=18 ses=18}, host/ipa.wibble.com at WIBBLE.COM for krbtgt/WIBBLE.COM at WIBBLE.COM Jan 02 19:27:37 ipa.wibble.com krb5kdc[6611](info): TGS_REQ (4 etypes {18 17 16 23}) 10.51.120.1: ISSUE: authtime 1388690857, etypes {rep=18 tkt=18 ses=18}, host/ipa.wibble.com at WIBBLE.COM for ldap/ipa.wibble.com at WIBBLE.COM /var/log/sssd/* this is using bob at host (prattle.com is the windows domain) https://gist.github.com/anonymous/ff817a251948ff58bdb1 this is using bob at prattle.com@host (prattle.com is the windows domain) https://gist.github.com/anonymous/885d8bfd6cf7d224de93 > > Thanks > Dmitri > >> >> Ta, >> >> Andrew > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > From andrew.holway at gmail.com Thu Jan 2 20:10:14 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 2 Jan 2014 20:10:14 +0000 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: References: <52C56C71.5050703@redhat.com> <52C5A11C.2080408@redhat.com> <52C5BB8B.6090905@redhat.com> Message-ID: Sorry, I forgot this. It works fine for the wibble.com linux domain. [root at ipa.wibble.com log]# ldapsearch -x -ZZ -H ldap://localhost -b dc=prattle,dc=com # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 3 result: 32 No such object # numResponses: 1 On 2 January 2014 20:06, Andrew Holway wrote: >> As for AD users we need to look at the client and see what is going on >> there. What is your client? Version and component? Is it using latest SSSD? >> If not additional steps might be needed. Please provide the details >> about the clients. Please start with trying AD users on the IPA server >> itself, looking at the logs and seeing what is going on. > > /var/log/secure > Jan 2 19:27:46 ipa sshd[8252]: pam_unix(sshd:auth): check pass; user unknown > Jan 2 19:27:46 ipa sshd[8252]: pam_succeed_if(sshd:auth): error > retrieving information about user bob at prattle.com > Jan 2 19:27:49 ipa sshd[8252]: Failed password for invalid user > bob at prattle.com from 192.168.202.12 port 51537 ssh2 > > /var/log/messages (not sure if related. this error is going off every 20s) > Jan 2 19:52:18 ipa smbd[7279]: [2014/01/02 19:52:18.895536, 0] > ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) > Jan 2 19:52:18 ipa smbd[7279]: dcesrv_interface_register: interface > 'lsarpc' already registered on endpoint > Jan 2 19:52:18 ipa smbd[7279]: [2014/01/02 19:52:18.896121, 0] > ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) > Jan 2 19:52:18 ipa smbd[7279]: dcesrv_interface_register: interface > 'samr' already registered on endpoint > Jan 2 19:52:18 ipa smbd[7279]: [2014/01/02 19:52:18.896616, 0] > ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) > Jan 2 19:52:18 ipa smbd[7279]: dcesrv_interface_register: interface > 'netlogon' already registered on endpoint > Jan 2 19:53:18 ipa smbd[7279]: [2014/01/02 19:53:18.913794, 0] > ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) > Jan 2 19:53:18 ipa smbd[7279]: dcesrv_interface_register: interface > 'lsarpc' already registered on endpoint > Jan 2 19:53:18 ipa smbd[7279]: [2014/01/02 19:53:18.914377, 0] > ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) > Jan 2 19:53:18 ipa smbd[7279]: dcesrv_interface_register: interface > 'samr' already registered on endpoint > Jan 2 19:53:18 ipa smbd[7279]: [2014/01/02 19:53:18.914853, 0] > ../source3/rpc_server/epmapper/srv_epmapper.c:378(_epm_Insert) > Jan 2 19:53:18 ipa smbd[7279]: dcesrv_interface_register: interface > 'netlogon' already registered on endpoint > > /var/log/krb5kdc.log > Jan 02 19:27:37 ipa.wibble.com krb5kdc[6611](info): AS_REQ (4 etypes > {18 17 16 23}) 10.51.120.1: NEEDED_PREAUTH: > host/ipa.wibble.com at WIBBLE.COM for krbtgt/WIBBLE.COM at WIBBLE.COM, > Additional pre-authentication required > Jan 02 19:27:37 ipa.wibble.com krb5kdc[6611](info): AS_REQ (4 etypes > {18 17 16 23}) 10.51.120.1: ISSUE: authtime 1388690857, etypes {rep=18 > tkt=18 ses=18}, host/ipa.wibble.com at WIBBLE.COM for > krbtgt/WIBBLE.COM at WIBBLE.COM > Jan 02 19:27:37 ipa.wibble.com krb5kdc[6611](info): TGS_REQ (4 etypes > {18 17 16 23}) 10.51.120.1: ISSUE: authtime 1388690857, etypes {rep=18 > tkt=18 ses=18}, host/ipa.wibble.com at WIBBLE.COM for > ldap/ipa.wibble.com at WIBBLE.COM > > /var/log/sssd/* > this is using bob at host (prattle.com is the windows domain) > https://gist.github.com/anonymous/ff817a251948ff58bdb1 > > this is using bob at prattle.com@host (prattle.com is the windows domain) > https://gist.github.com/anonymous/885d8bfd6cf7d224de93 > > >> >> Thanks >> Dmitri >> >>> >>> Ta, >>> >>> Andrew >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> From genadipost at gmail.com Thu Jan 2 20:37:14 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Thu, 2 Jan 2014 22:37:14 +0200 Subject: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain. Message-ID: Hi all. I have a running IPA Server (3.0.0-37) on RHEL 6.2. I'm trying to create Trust between IPA server and AD (In different DNS domains). I followed the red hat guide https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/pdf/Identity_Management_Guide/Red_Hat_Enterprise_Linux-6-Identity_Management_Guide-en-US.pdf . When i completed the needed step to create the trust and retrieved a krb ticket from the AD server: [root at ipaserver ~]# kinit Administrator at ADDC.COM Password for Administrator at ADDC.COM: [root at ipaserver ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: Administrator at ADDC.COM Valid starting Expires Service principal 01/02/14 12:20:30 01/02/14 22:20:34 krbtgt/ADDC.COM at ADDC.COM renew until 01/03/14 12:20:30 But when i try to connect to the IPA server via SHH (Putty) i get "Access denied" message: login as: Administrator at ADDC.COM Administrator at ADDC.COM@192.168.227.128's password: Access denied Any ideas on what i could have done wrong in the process of creating the trust? Thank you in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Jan 2 21:30:59 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 Jan 2014 16:30:59 -0500 Subject: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain. In-Reply-To: References: Message-ID: <52C5DA93.8080601@redhat.com> Genadi Postrilko wrote: > Hi all. > > I have a running IPA Server (3.0.0-37) on RHEL 6.2. > I'm trying to create Trust between IPA server and AD (In different DNS > domains). I followed the red hat guide > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/pdf/Identity_Management_Guide/Red_Hat_Enterprise_Linux-6-Identity_Management_Guide-en-US.pdf. > > When i completed the needed step to create the trust and retrieved a krb > ticket from the AD server: > > [root at ipaserver ~]# kinit Administrator at ADDC.COM > > Password for Administrator at ADDC.COM : > [root at ipaserver ~]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: Administrator at ADDC.COM > > Valid starting Expires Service principal > 01/02/14 12:20:30 01/02/14 22:20:34 krbtgt/ADDC.COM at ADDC.COM > > renew until 01/03/14 12:20:30 > > But when i try to connect to the IPA server via SHH (Putty) i get > "Access denied" message: > > login as: Administrator at ADDC.COM > Administrator at ADDC.COM@192.168.227.128 's password: > Access denied > > Any ideas on what i could have done wrong in the process of creating the > trust? I'd check the sssd logs and /var/log/secure. Do you have any HBAC rules? rob From genadipost at gmail.com Thu Jan 2 21:45:40 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Thu, 2 Jan 2014 23:45:40 +0200 Subject: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain. In-Reply-To: <52C5DA93.8080601@redhat.com> References: <52C5DA93.8080601@redhat.com> Message-ID: Its a newly installed IPA Server, haven't added any Rules. The relevant output from /var/log/secure : Jan 2 13:36:24 ipaserver sshd[4864]: Invalid user from 192.168.227.100 Jan 2 13:36:24 ipaserver sshd[4865]: input_userauth_request: invalid user Jan 2 13:36:26 ipaserver sshd[4865]: Connection closed by 192.168.227.100 Jan 2 13:36:35 ipaserver sshd[4868]: Invalid user Administrator at ADDC.COMfrom 192.168.227.100 Jan 2 13:36:35 ipaserver sshd[4869]: input_userauth_request: invalid user Administrator at ADDC.COM Jan 2 13:36:44 ipaserver sshd[4868]: pam_unix(sshd:auth): check pass; user unknown Jan 2 13:36:44 ipaserver sshd[4868]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.227.100 Jan 2 13:36:44 ipaserver sshd[4868]: pam_succeed_if(sshd:auth): error retrieving information about user Administrator at ADDC.COM Jan 2 13:36:46 ipaserver sshd[4868]: Failed password for invalid user Administrator at ADDC.COM from 192.168.227.100 port 62484 ssh2 2014/1/2 Rob Crittenden > Genadi Postrilko wrote: > >> Hi all. >> >> I have a running IPA Server (3.0.0-37) on RHEL 6.2. >> I'm trying to create Trust between IPA server and AD (In different DNS >> domains). I followed the red hat guide >> https://access.redhat.com/site/documentation/en-US/Red_ >> Hat_Enterprise_Linux/6/pdf/Identity_Management_Guide/Red_ >> Hat_Enterprise_Linux-6-Identity_Management_Guide-en-US.pdf. >> >> When i completed the needed step to create the trust and retrieved a krb >> ticket from the AD server: >> >> [root at ipaserver ~]# kinit Administrator at ADDC.COM >> >> Password for Administrator at ADDC.COM : >> >> [root at ipaserver ~]# klist >> Ticket cache: FILE:/tmp/krb5cc_0 >> Default principal: Administrator at ADDC.COM >> >> >> Valid starting Expires Service principal >> 01/02/14 12:20:30 01/02/14 22:20:34 krbtgt/ADDC.COM at ADDC.COM >> >> >> renew until 01/03/14 12:20:30 >> >> But when i try to connect to the IPA server via SHH (Putty) i get >> "Access denied" message: >> >> login as: Administrator at ADDC.COM >> Administrator at ADDC.COM@192.168.227.128 's >> password: >> >> Access denied >> >> Any ideas on what i could have done wrong in the process of creating the >> trust? >> > > I'd check the sssd logs and /var/log/secure. > > Do you have any HBAC rules? > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Jan 2 21:51:14 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 02 Jan 2014 16:51:14 -0500 Subject: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain. In-Reply-To: References: <52C5DA93.8080601@redhat.com> Message-ID: <52C5DF52.1010901@redhat.com> On 01/02/2014 04:45 PM, Genadi Postrilko wrote: > Its a newly installed IPA Server, haven't added any Rules. > > The relevant output from /var/log/secure : > > Jan 2 13:36:24 ipaserver sshd[4864]: Invalid user from 192.168.227.100 > Jan 2 13:36:24 ipaserver sshd[4865]: input_userauth_request: invalid user > Jan 2 13:36:26 ipaserver sshd[4865]: Connection closed by 192.168.227.100 > Jan 2 13:36:35 ipaserver sshd[4868]: Invalid user > Administrator at ADDC.COM from > 192.168.227.100 > Jan 2 13:36:35 ipaserver sshd[4869]: input_userauth_request: invalid > user Administrator at ADDC.COM > Jan 2 13:36:44 ipaserver sshd[4868]: pam_unix(sshd:auth): check pass; > user unknown > Jan 2 13:36:44 ipaserver sshd[4868]: pam_unix(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=192.168.227.100 > Jan 2 13:36:44 ipaserver sshd[4868]: pam_succeed_if(sshd:auth): error > retrieving information about user Administrator at ADDC.COM > > Jan 2 13:36:46 ipaserver sshd[4868]: Failed password for invalid user > Administrator at ADDC.COM from > 192.168.227.100 port 62484 ssh2 > > > > 2014/1/2 Rob Crittenden > > > Genadi Postrilko wrote: > > Hi all. > > I have a running IPA Server (3.0.0-37) on RHEL 6.2. > I'm trying to create Trust between IPA server and AD (In > different DNS > domains). I followed the red hat guide > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/pdf/Identity_Management_Guide/Red_Hat_Enterprise_Linux-6-Identity_Management_Guide-en-US.pdf. > > When i completed the needed step to create the trust and > retrieved a krb > ticket from the AD server: > > [root at ipaserver ~]# kinit Administrator at ADDC.COM > > > > Password for Administrator at ADDC.COM > >: > > [root at ipaserver ~]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: Administrator at ADDC.COM > > > > > Valid starting Expires Service principal > 01/02/14 12:20:30 01/02/14 22:20:34 krbtgt/ADDC.COM at ADDC.COM > > > > > renew until 01/03/14 12:20:30 > > But when i try to connect to the IPA server via SHH (Putty) i get > "Access denied" message: > > login as: Administrator at ADDC.COM > > > Administrator at ADDC.COM@192.168.227.128 > 's password: > > Access denied > > Any ideas on what i could have done wrong in the process of > creating the > trust? > > > I'd check the sssd logs and /var/log/secure. > > Do you have any HBAC rules? > > rob > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Looks an error similar to what I see in the other thread. Unfortunately be might need to wait till Monday for Alexander, Sumit and Jakub to come back and provide help. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.holway at gmail.com Thu Jan 2 21:51:29 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 2 Jan 2014 21:51:29 +0000 Subject: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain. In-Reply-To: References: <52C5DA93.8080601@redhat.com> Message-ID: If you add "debug_level = 5" into every section of "/etc/sssd/sssd.conf" Restart sssd Try and log in again cat /var/log/sssd/* And paste that somewhere. On 2 January 2014 21:45, Genadi Postrilko wrote: > Its a newly installed IPA Server, haven't added any Rules. > > The relevant output from /var/log/secure : > > Jan 2 13:36:24 ipaserver sshd[4864]: Invalid user from 192.168.227.100 > Jan 2 13:36:24 ipaserver sshd[4865]: input_userauth_request: invalid user > Jan 2 13:36:26 ipaserver sshd[4865]: Connection closed by 192.168.227.100 > Jan 2 13:36:35 ipaserver sshd[4868]: Invalid user Administrator at ADDC.COM > from 192.168.227.100 > Jan 2 13:36:35 ipaserver sshd[4869]: input_userauth_request: invalid user > Administrator at ADDC.COM > Jan 2 13:36:44 ipaserver sshd[4868]: pam_unix(sshd:auth): check pass; user > unknown > Jan 2 13:36:44 ipaserver sshd[4868]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.227.100 > Jan 2 13:36:44 ipaserver sshd[4868]: pam_succeed_if(sshd:auth): error > retrieving information about user Administrator at ADDC.COM > Jan 2 13:36:46 ipaserver sshd[4868]: Failed password for invalid user > Administrator at ADDC.COM from 192.168.227.100 port 62484 ssh2 > > > > 2014/1/2 Rob Crittenden >> >> Genadi Postrilko wrote: >>> >>> Hi all. >>> >>> I have a running IPA Server (3.0.0-37) on RHEL 6.2. >>> I'm trying to create Trust between IPA server and AD (In different DNS >>> domains). I followed the red hat guide >>> >>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/pdf/Identity_Management_Guide/Red_Hat_Enterprise_Linux-6-Identity_Management_Guide-en-US.pdf. >>> >>> When i completed the needed step to create the trust and retrieved a krb >>> ticket from the AD server: >>> >>> [root at ipaserver ~]# kinit Administrator at ADDC.COM >>> >>> Password for Administrator at ADDC.COM : >>> >>> [root at ipaserver ~]# klist >>> Ticket cache: FILE:/tmp/krb5cc_0 >>> Default principal: Administrator at ADDC.COM >>> >>> >>> Valid starting Expires Service principal >>> 01/02/14 12:20:30 01/02/14 22:20:34 krbtgt/ADDC.COM at ADDC.COM >>> >>> >>> renew until 01/03/14 12:20:30 >>> >>> But when i try to connect to the IPA server via SHH (Putty) i get >>> "Access denied" message: >>> >>> login as: Administrator at ADDC.COM >>> Administrator at ADDC.COM@192.168.227.128 's >>> password: >>> >>> Access denied >>> >>> Any ideas on what i could have done wrong in the process of creating the >>> trust? >> >> >> I'd check the sssd logs and /var/log/secure. >> >> Do you have any HBAC rules? >> >> rob > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From genadipost at gmail.com Thu Jan 2 22:33:16 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Fri, 3 Jan 2014 00:33:16 +0200 Subject: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain. In-Reply-To: <52C5DF52.1010901@redhat.com> References: <52C5DA93.8080601@redhat.com> <52C5DF52.1010901@redhat.com> Message-ID: Here are the *sssd.log, **sssd_nss.log. *Other logs where empty of did not contain the output for the relevant log in. https://gist.github.com/anonymous/8228284 2014/1/2 Dmitri Pal > On 01/02/2014 04:45 PM, Genadi Postrilko wrote: > > Its a newly installed IPA Server, haven't added any Rules. > > The relevant output from /var/log/secure : > > Jan 2 13:36:24 ipaserver sshd[4864]: Invalid user from 192.168.227.100 > Jan 2 13:36:24 ipaserver sshd[4865]: input_userauth_request: invalid user > Jan 2 13:36:26 ipaserver sshd[4865]: Connection closed by 192.168.227.100 > Jan 2 13:36:35 ipaserver sshd[4868]: Invalid user Administrator at ADDC.COMfrom 192.168.227.100 > Jan 2 13:36:35 ipaserver sshd[4869]: input_userauth_request: invalid user > Administrator at ADDC.COM > Jan 2 13:36:44 ipaserver sshd[4868]: pam_unix(sshd:auth): check pass; > user unknown > Jan 2 13:36:44 ipaserver sshd[4868]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.227.100 > Jan 2 13:36:44 ipaserver sshd[4868]: pam_succeed_if(sshd:auth): error > retrieving information about user Administrator at ADDC.COM > Jan 2 13:36:46 ipaserver sshd[4868]: Failed password for invalid user > Administrator at ADDC.COM from 192.168.227.100 port 62484 ssh2 > > > > 2014/1/2 Rob Crittenden > >> Genadi Postrilko wrote: >> >>> Hi all. >>> >>> I have a running IPA Server (3.0.0-37) on RHEL 6.2. >>> I'm trying to create Trust between IPA server and AD (In different DNS >>> domains). I followed the red hat guide >>> >>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/pdf/Identity_Management_Guide/Red_Hat_Enterprise_Linux-6-Identity_Management_Guide-en-US.pdf >>> . >>> >>> When i completed the needed step to create the trust and retrieved a krb >>> ticket from the AD server: >>> >>> [root at ipaserver ~]# kinit Administrator at ADDC.COM >>> >>> Password for Administrator at ADDC.COM : >>> >>> [root at ipaserver ~]# klist >>> Ticket cache: FILE:/tmp/krb5cc_0 >>> Default principal: Administrator at ADDC.COM >> Administrator at ADDC.COM> >>> >>> >>> Valid starting Expires Service principal >>> 01/02/14 12:20:30 01/02/14 22:20:34 krbtgt/ADDC.COM at ADDC.COM >>> >>> >>> renew until 01/03/14 12:20:30 >>> >>> But when i try to connect to the IPA server via SHH (Putty) i get >>> "Access denied" message: >>> >>> login as: Administrator at ADDC.COM >>> Administrator at ADDC.COM@192.168.227.128 's >>> password: >>> >>> Access denied >>> >>> Any ideas on what i could have done wrong in the process of creating the >>> trust? >>> >> >> I'd check the sssd logs and /var/log/secure. >> >> Do you have any HBAC rules? >> >> rob >> > > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > Looks an error similar to what I see in the other thread. > Unfortunately be might need to wait till Monday for Alexander, Sumit and > Jakub to come back and provide help. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at willsheldon.com Fri Jan 3 01:04:40 2014 From: mail at willsheldon.com (Will Sheldon) Date: Thu, 2 Jan 2014 17:04:40 -0800 Subject: [Freeipa-users] ipa-client-install 2.58 client incompatible with 2.49 server In-Reply-To: <52C59CA9.9020203@redhat.com> References: <52BF0F69.6010502@redhat.com> <52C59CA9.9020203@redhat.com> Message-ID: Thanks guys. For now I've just reverted the reported version while the install script runs. It seems to work OK. On Thu, Jan 2, 2014 at 9:06 AM, Martin Kosek wrote: > On 12/28/2013 06:50 PM, Rob Crittenden wrote: > > Will Sheldon wrote: > >> > >> Hello :) > >> > >> I'm trying to setup a ubuntu 12.04.3 client running freeipa-client > >> 3.2.0-0ubuntu1~precise1 form the apt repo at > >> http://ppa.launchpad.net/freeipa/ppa/ubuntu > >> The server is a (fully updated) centos 6.5 box running ipa-server.x86_64 > >> 3.0.0-37.el6 > >> > >> The script mostly works on a stock install, but there is an error > >> uploading SSH keys, This appears to be called from the > >> ipa-client-install script line 1436: > >> > >> result = api.Command['host_mod'](unicode(hostname), > >> > >> Which generates the following output when run: > >> > >> stderr= > >> Caught fault 901 from server https://ipa.[domain].com/ipa/xml: 2.58 > >> client incompatible with 2.49 server at u'https://ipa. > [domain].com/ipa/xml' > >> host_mod: 2.58 client incompatible with 2.49 server at > >> u'https://ipa.[domain].com/ipa/xml' > >> Failed to upload host SSH public keys. > >> > >> I understand that this is not a critical failure and that I can manually > >> upload the host keys if needed but the bit I don't understand is where > >> the version numbers come from. > > > > The API version is baked into the client and server. We generally > provide a > > backwards compatible server, but right now not the client (so a new > client > > can't always have 100% success talking to an old server). We are actually > > working on this, especially for client enrollment, to make things work > more > > smoothly. > > > >> How do I revert the api to version 2.49 to match the server? > > > > You'd have to modify ipapython/version.py on each client before > enrollment. For > > enrollment I can't think of any side-effects, but if you ever tried the > IPA > > admin tool on such a client then some odd things could happen. > > > >> What is best practice here, should I be using a different source for the > >> client install script? > > > > I don't know what is available for Debian/Ubuntu clients these days. It > is > > being worked on very hard though I think the focus is on the latest > source > > which explains the mismatch. > > > >> Is there a copy of the correct client files stashed on the server > somewhere? > >> Would anyone be interested in helping with development of a yum and apt > >> repo on the server to make all this easier? > > > > The server being the IPA server, so it can distribute the client bits? An > > interesting idea. > > > > rob > > > > Note that this issue was fixed in FreeIPA version 3.3.2 (upstream ticket > https://fedorahosted.org/freeipa/ticket/3931). > > Thus, when using FreeIPA client 3.3.2 and later, ipa-client-install will > upload > the SSH keys even to the older SSH server. No other changes required. > > HTH, > Martin > -- Kind regards, Will Sheldon +1.(778)-689-4144 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at willsheldon.com Fri Jan 3 01:23:58 2014 From: mail at willsheldon.com (Will Sheldon) Date: Thu, 2 Jan 2014 17:23:58 -0800 Subject: [Freeipa-users] FreeIPA Security issue : Anonymous user can fetch user details from IPA without authenticating In-Reply-To: <52C46176.5010100@gmail.com> References: <52C46176.5010100@gmail.com> Message-ID: This is cause for concern. Is there a hardening / best practices for production guide anywhere, did I miss a section of the documentation? What else do I need to secure? I understand that there is a tradeoff between security and compatibility, but maybe there should be a ipa-secure script somewhere? On Wed, Jan 1, 2014 at 10:41 AM, Jitse Klomp wrote: > It is possible to disable anonymous binds to the directory server. Take a > look at https://docs.fedoraproject.org/en-US/Fedora/18/html/ > FreeIPA_Guide/disabling-anon-binds.html > > - Jitse > > > > On 01/01/2014 07:01 PM, Rajnesh Kumar Siwal wrote: > >> It exposes the details of all the users/admins in the environment. >> There should be a user that the IPA should use to fetch the details from >> the IPA Servers. Without Authentication , no one should be able to fetch >> any information from the IPA Server. >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- Kind regards, Will Sheldon +1.(778)-689-4144 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Jan 3 09:29:40 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 Jan 2014 10:29:40 +0100 Subject: [Freeipa-users] [SOLVED] Do not upgrade FreeIPA deployments to Fedora 20 final (yet) In-Reply-To: <81614488.131679.1387708947601.JavaMail.root@redhat.com> References: <20131217091434.GW21264@redhat.com> <81614488.131679.1387708947601.JavaMail.root@redhat.com> Message-ID: <52C68304.2000309@redhat.com> Hello, We have good news for you. Both 389-ds-base-1.3.2.9-1.fc20 and slapi-nis-0.52-1.fc20 are now in Fedora 20 stable repository. The only remaining issue in 389-ds-base is https://fedorahosted.org/389/ticket/47656, but this sahould not be a show stopper for upgrading to Fedora 20. I lifted the warning from FreeIPA.org wiki. Martin On 12/22/2013 11:42 AM, Alexander Bokovoy wrote: > Hi, > > an update on the issue of upgrading Fedora 19 to Fedora 20 for FreeIPA deployments. > > An updated 389-ds-base package, 1.3.2.9-1.fc20 is in updates-testing repository. > Updated slapi-nis package, 0.52-1.fc20, is in updates-testing as well. > > I've tested that using fedora-upgrade tool to upgrade from Fedora 19 to Fedora 20 does work > if you have updates-testing repository enabled and that FreeIPA is continuing to work afterwards. > > I've initiated move of 389-ds-base to updates stable repository. Once it reach out there, > I'll lift a warning on freeipa.org and publish a final update. > > Happy holidays! > > ----- Original Message ----- >> From: "Alexander Bokovoy" >> To: freeipa-users at redhat.com >> Sent: Tuesday, December 17, 2013 11:14:34 AM >> Subject: [Freeipa-users] WARNING: Do not upgrade FreeIPA deployments to Fedora 20 final (yet) >> >> Greetings! >> >> As many of you are aware, Fedora Project releases Fedora 20 today, >> Tuesday, December 17th. This post serves as a warning against upgrading >> your FreeIPA deployments to Fedora 20 using release images. Please check >> Fedora 20 Common Bugs page https://fedoraproject.org/wiki/Common_F20_bugs >> for the complete list of issues. >> >> FreeIPA relies heavily on 389-ds Directory Server. Fedora 20 introduces >> new version series of 389-ds, 1.3.2.x. Along with multiple enhancements, >> unfortunately, few bugs went into the version currently available in >> Fedora 20 stable tree. These bugs are causing crashes under certain >> conditions and we don't recommend updating your existing configurations >> due to these consequences. >> >> As an update to the Fedora 20 Common Bugs page, over last night fellow >> developers from 389-ds and slapi-nis projects have fixed >> https://bugzilla.redhat.com/show_bug.cgi?id=1043546 and >> https://bugzilla.redhat.com/show_bug.cgi?id=1041732 but there will be >> some delay before the builds featuring the fixes will appear in Fedora >> 20 updates repository. Remaining bugs are under investigation. >> >> I'll post an update note once we'll get remaining issues fixed and packages >> pushed to Fedora 20 updates repository. >> >> -- >> / Alexander Bokovoy From jhrozek at redhat.com Fri Jan 3 11:20:56 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 3 Jan 2014 12:20:56 +0100 Subject: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain. In-Reply-To: References: <52C5DA93.8080601@redhat.com> <52C5DF52.1010901@redhat.com> Message-ID: <20140103112056.GE26958@hendrix.brq.redhat.com> On Fri, Jan 03, 2014 at 12:33:16AM +0200, Genadi Postrilko wrote: > Here are the *sssd.log, **sssd_nss.log. *Other logs where empty of did not > contain the output for the relevant log in. > > https://gist.github.com/anonymous/8228284 According to gist, you only provided the debug logs from the [sssd] and [nss] sections. Can you also paste the logs from the [domain/xxx] section ? From jhrozek at redhat.com Fri Jan 3 11:29:11 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 3 Jan 2014 12:29:11 +0100 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: References: <52C56C71.5050703@redhat.com> <52C5A11C.2080408@redhat.com> <52C5BB8B.6090905@redhat.com> Message-ID: <20140103112911.GF26958@hendrix.brq.redhat.com> On Thu, Jan 02, 2014 at 08:06:31PM +0000, Andrew Holway wrote: > /var/log/sssd/* > this is using bob at host (prattle.com is the windows domain) > https://gist.github.com/anonymous/ff817a251948ff58bdb1 > > this is using bob at prattle.com@host (prattle.com is the windows domain) Thanks, these logs have somewhat more info than those in the other thread. It seems that Winbind on the IPA server has trouble talking to the AD server: (Thu Jan 2 19:27:41 2014) [sssd[be[wibble.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'ipa.wibble.com' as 'working' (Thu Jan 2 19:27:41 2014) [sssd[be[wibble.com]]] [set_server_common_status] (0x0100): Marking server 'ipa.wibble.com' as 'working' (Thu Jan 2 19:27:41 2014) [sssd[be[wibble.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. (The s2n exop does a special LDAP call to IPA which in turn calls winbind on the server). To generate the winbind logs on the server, can you do 'smbcontrol winbindd debug 100', then request the trusted user. The winbind logs would be at /var/log/samba/log.w* I'd advise to restart SSSD on the client before the test to get rid of the negative cache and make sure the request actually hits the server. From jhrozek at redhat.com Fri Jan 3 11:32:07 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 3 Jan 2014 12:32:07 +0100 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: <20140103112911.GF26958@hendrix.brq.redhat.com> References: <52C56C71.5050703@redhat.com> <52C5A11C.2080408@redhat.com> <52C5BB8B.6090905@redhat.com> <20140103112911.GF26958@hendrix.brq.redhat.com> Message-ID: <20140103113207.GG26958@hendrix.brq.redhat.com> On Fri, Jan 03, 2014 at 12:29:11PM +0100, Jakub Hrozek wrote: > On Thu, Jan 02, 2014 at 08:06:31PM +0000, Andrew Holway wrote: > > /var/log/sssd/* > > this is using bob at host (prattle.com is the windows domain) > > https://gist.github.com/anonymous/ff817a251948ff58bdb1 > > > > this is using bob at prattle.com@host (prattle.com is the windows domain) > > Thanks, these logs have somewhat more info than those in the other > thread. > > It seems that Winbind on the IPA server has trouble talking to the AD > server: > > (Thu Jan 2 19:27:41 2014) [sssd[be[wibble.com]]] [fo_set_port_status] > (0x0100): Marking port 0 of server 'ipa.wibble.com' as 'working' > (Thu Jan 2 19:27:41 2014) [sssd[be[wibble.com]]] > [set_server_common_status] (0x0100): Marking server 'ipa.wibble.com' as > 'working' > (Thu Jan 2 19:27:41 2014) [sssd[be[wibble.com]]] [ipa_s2n_get_user_done] > (0x0040): s2n exop request failed. > > (The s2n exop does a special LDAP call to IPA which in turn calls > winbind on the server). > > To generate the winbind logs on the server, can you do 'smbcontrol winbindd > debug 100', then request the trusted user. The winbind logs would be at > /var/log/samba/log.w* > > I'd advise to restart SSSD on the client before the test to get rid of > the negative cache and make sure the request actually hits the server. > Oh and after you gather the info, you should also re-set the debug logs back: smbcontrol winbindd debug 1 Running with a verbose log level would flood your disk soon. From pviktori at redhat.com Fri Jan 3 12:53:13 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 03 Jan 2014 13:53:13 +0100 Subject: [Freeipa-users] FreeIPA Security issue : Anonymous user can fetch user details from IPA without authenticating In-Reply-To: References: <52C46176.5010100@gmail.com> Message-ID: <52C6B2B9.8010300@redhat.com> On 01/03/2014 02:23 AM, Will Sheldon wrote: > > This is cause for concern. Is there a hardening / best practices for > production guide anywhere, did I miss a section of the documentation? > > What else do I need to secure? > > I understand that there is a tradeoff between security and > compatibility, but maybe there should be a ipa-secure script somewhere? We are working on making the read permissions granular, so you can make your own tradeoffs if IPA defaults aren't appropriate for your use. The work is tracked in https://fedorahosted.org/freeipa/ticket/3566 and linked tickets 4032-4034. > On Wed, Jan 1, 2014 at 10:41 AM, Jitse Klomp > wrote: > > It is possible to disable anonymous binds to the directory server. > Take a look at > https://docs.fedoraproject.__org/en-US/Fedora/18/html/__FreeIPA_Guide/disabling-anon-__binds.html > > > - Jitse > > > > On 01/01/2014 07:01 PM, Rajnesh Kumar Siwal wrote: > > It exposes the details of all the users/admins in the environment. > There should be a user that the IPA should use to fetch the > details from > the IPA Servers. Without Authentication , no one should be able > to fetch > any information from the IPA Server. -- Petr? From simo at redhat.com Fri Jan 3 13:47:34 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 03 Jan 2014 08:47:34 -0500 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: <20140103112911.GF26958@hendrix.brq.redhat.com> References: <52C56C71.5050703@redhat.com> <52C5A11C.2080408@redhat.com> <52C5BB8B.6090905@redhat.com> <20140103112911.GF26958@hendrix.brq.redhat.com> Message-ID: <1388756854.26102.35.camel@willson.li.ssimo.org> On Fri, 2014-01-03 at 12:29 +0100, Jakub Hrozek wrote: > On Thu, Jan 02, 2014 at 08:06:31PM +0000, Andrew Holway wrote: > > /var/log/sssd/* > > this is using bob at host (prattle.com is the windows domain) > > https://gist.github.com/anonymous/ff817a251948ff58bdb1 > > > > this is using bob at prattle.com@host (prattle.com is the windows domain) > > Thanks, these logs have somewhat more info than those in the other > thread. > > It seems that Winbind on the IPA server has trouble talking to the AD > server: > > (Thu Jan 2 19:27:41 2014) [sssd[be[wibble.com]]] [fo_set_port_status] > (0x0100): Marking port 0 of server 'ipa.wibble.com' as 'working' > (Thu Jan 2 19:27:41 2014) [sssd[be[wibble.com]]] > [set_server_common_status] (0x0100): Marking server 'ipa.wibble.com' as > 'working' > (Thu Jan 2 19:27:41 2014) [sssd[be[wibble.com]]] [ipa_s2n_get_user_done] > (0x0040): s2n exop request failed. > > (The s2n exop does a special LDAP call to IPA which in turn calls > winbind on the server). > > To generate the winbind logs on the server, can you do 'smbcontrol winbindd > debug 100', then request the trusted user. The winbind logs would be at > /var/log/samba/log.w* Don't use debug level 100, it will litter the tmp with packet dumps and [possibly fill the disk. Log level 10 is the max that is ever useful. > I'd advise to restart SSSD on the client before the test to get rid of > the negative cache and make sure the request actually hits the server. or simply run wbinfo on the server to check winbindd can properly retrieve users before moving back to testing on client. Simo. -- Simo Sorce * Red Hat, Inc * New York From andrew.holway at gmail.com Fri Jan 3 14:05:58 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Fri, 3 Jan 2014 14:05:58 +0000 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: <20140103113207.GG26958@hendrix.brq.redhat.com> References: <52C56C71.5050703@redhat.com> <52C5A11C.2080408@redhat.com> <52C5BB8B.6090905@redhat.com> <20140103112911.GF26958@hendrix.brq.redhat.com> <20140103113207.GG26958@hendrix.brq.redhat.com> Message-ID: >> To generate the winbind logs on the server, can you do 'smbcontrol winbindd >> debug 100', then request the trusted user. The winbind logs would be at >> /var/log/samba/log.w* I truncated all of the files in /var/log/samba and then make a single login attempt. These are the files that were non zero after the event. log.smbd.epmd - https://gist.github.com/anonymous/663be9204d24bf3e915c log.wb-PRATTLE - https://gist.github.com/anonymous/069c9931b1c66a2da85e log.wb-WIBBLE - https://gist.github.com/anonymous/c60754ec956df30f2c60 log.winbindd - https://gist.github.com/anonymous/25995d07c20ef5f3926a log.winbindd-dc-connect - https://gist.github.com/anonymous/9b6a1b736f1266ddc37f From andrew.holway at gmail.com Fri Jan 3 15:06:51 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Fri, 3 Jan 2014 15:06:51 +0000 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: <1388756854.26102.35.camel@willson.li.ssimo.org> References: <52C56C71.5050703@redhat.com> <52C5A11C.2080408@redhat.com> <52C5BB8B.6090905@redhat.com> <20140103112911.GF26958@hendrix.brq.redhat.com> <1388756854.26102.35.camel@willson.li.ssimo.org> Message-ID: > or simply run wbinfo on the server to check winbindd can properly > retrieve users before moving back to testing on client. [root at ipa.wibble.com ~]# wbinfo -i bob at prattle.com failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND Could not get info for user bob at prattle.com Would this be an appropriate wbinfo command? > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From genadipost at gmail.com Fri Jan 3 17:29:54 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Fri, 3 Jan 2014 19:29:54 +0200 Subject: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain. In-Reply-To: <20140103112056.GE26958@hendrix.brq.redhat.com> References: <52C5DA93.8080601@redhat.com> <52C5DF52.1010901@redhat.com> <20140103112056.GE26958@hendrix.brq.redhat.com> Message-ID: Here are the other logs as well (ldap_child.log, sssd_pac.log, sssd_ssh.log). https://gist.github.com/anonymous/8242061 I attempted to log in (as Administrator at ADDC.COM) at 9:04. Thanks for the help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at willsheldon.com Fri Jan 3 17:50:04 2014 From: mail at willsheldon.com (Will Sheldon) Date: Fri, 3 Jan 2014 09:50:04 -0800 Subject: [Freeipa-users] FreeIPA Security issue : Anonymous user can fetch user details from IPA without authenticating In-Reply-To: <52C6B2B9.8010300@redhat.com> References: <52C46176.5010100@gmail.com> <52C6B2B9.8010300@redhat.com> Message-ID: Thanks Petr, that certainly makes sense from the point of view of functionality. I do think the default is sane, but there are a lot of possible deployment scenarios and my concern is that a junior or time poor admin looking to implement a trusted, secure solution should be made aware of any potential data leakage during configuration, (preferably in big red letters in the documentation, or better still, the install script). Though I am reluctant to draw comparisons between IPA and MS AD they do seem inevitable. AD restricts anonymous binds to the rootDSE entry by default and as such this may be considered by many to be the expected default. Extra care should therefore be made to point out this difference. To do otherwise risks undermining the confidence of users in the security of the solution. On Fri, Jan 3, 2014 at 4:53 AM, Petr Viktorin wrote: > On 01/03/2014 02:23 AM, Will Sheldon wrote: > >> >> This is cause for concern. Is there a hardening / best practices for >> production guide anywhere, did I miss a section of the documentation? >> >> What else do I need to secure? >> >> I understand that there is a tradeoff between security and >> compatibility, but maybe there should be a ipa-secure script somewhere? >> > > We are working on making the read permissions granular, so you can make > your own tradeoffs if IPA defaults aren't appropriate for your use. > > The work is tracked in https://fedorahosted.org/freeipa/ticket/3566 and > linked tickets 4032-4034. > > On Wed, Jan 1, 2014 at 10:41 AM, Jitse Klomp > > wrote: >> >> It is possible to disable anonymous binds to the directory server. >> Take a look at >> https://docs.fedoraproject.__org/en-US/Fedora/18/html/__ >> FreeIPA_Guide/disabling-anon-__binds.html >> >> > FreeIPA_Guide/disabling-anon-binds.html> >> >> - Jitse >> >> >> >> On 01/01/2014 07:01 PM, Rajnesh Kumar Siwal wrote: >> >> It exposes the details of all the users/admins in the environment. >> There should be a user that the IPA should use to fetch the >> details from >> the IPA Servers. Without Authentication , no one should be able >> to fetch >> any information from the IPA Server. >> > > > -- > Petr? > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- Kind regards, Will Sheldon +1.(778)-689-4144 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.holway at gmail.com Fri Jan 3 18:17:06 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Fri, 3 Jan 2014 18:17:06 +0000 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: References: <52C56C71.5050703@redhat.com> <52C5A11C.2080408@redhat.com> <52C5BB8B.6090905@redhat.com> <20140103112911.GF26958@hendrix.brq.redhat.com> <1388756854.26102.35.camel@willson.li.ssimo.org> Message-ID: [root at ipa.wibble.com ~]# wbinfo --all-domains BUILTIN WIBBLE PRATTLE [root at ipa.wibble.com ~]# wbinfo --own-domain WIBBLE On 3 January 2014 15:06, Andrew Holway wrote: >> or simply run wbinfo on the server to check winbindd can properly >> retrieve users before moving back to testing on client. > > > [root at ipa.wibble.com ~]# wbinfo -i bob at prattle.com > failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND > Could not get info for user bob at prattle.com > > Would this be an appropriate wbinfo command? > > > > >> >> Simo. >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Fri Jan 3 18:29:02 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 03 Jan 2014 13:29:02 -0500 Subject: [Freeipa-users] FreeIPA Security issue : Anonymous user can fetch user details from IPA without authenticating In-Reply-To: References: <52C46176.5010100@gmail.com> <52C6B2B9.8010300@redhat.com> Message-ID: <52C7016E.8020004@redhat.com> On 01/03/2014 12:50 PM, Will Sheldon wrote: > Thanks Petr, that certainly makes sense from the point of view of > functionality. > > I do think the default is sane, but there are a lot of possible > deployment scenarios and my concern is that a junior or time poor > admin looking to implement a trusted, secure solution should be made > aware of any potential data leakage during configuration, (preferably > in big red letters in the documentation, or better still, the install > script). > > Though I am reluctant to draw comparisons between IPA and MS AD they > do seem inevitable. AD restricts anonymous binds to the rootDSE entry > by default and as such this may be considered by many to be the > expected default. Extra care should therefore be made to point out > this difference. To do otherwise risks undermining the confidence of > users in the security of the solution. It is a double edge sword. We compared IPA to LDAP based solutions and with those you have (had) anonymous bind enabled by default. IMO it is the question of a migration. The field of centralized authentication is crowded with all sorts of different solutions, though not that integrated as AD or IdM. It seems that migrating and then tightening security to the level you need is the way to go. The default you suggest might be a barrier to migration as people usually tackle problems one step at a time. I am not against changing the default eventually but I am not sure it is the time to. But may be I am wrong. Are there any opinions on the matter? > > > > On Fri, Jan 3, 2014 at 4:53 AM, Petr Viktorin > wrote: > > On 01/03/2014 02:23 AM, Will Sheldon wrote: > > > This is cause for concern. Is there a hardening / best > practices for > production guide anywhere, did I miss a section of the > documentation? > > What else do I need to secure? > > I understand that there is a tradeoff between security and > compatibility, but maybe there should be a ipa-secure script > somewhere? > > > We are working on making the read permissions granular, so you can > make your own tradeoffs if IPA defaults aren't appropriate for > your use. > > The work is tracked in > https://fedorahosted.org/freeipa/ticket/3566 and linked tickets > 4032-4034. > > On Wed, Jan 1, 2014 at 10:41 AM, Jitse Klomp > > >> > wrote: > > It is possible to disable anonymous binds to the directory > server. > Take a look at > > https://docs.fedoraproject.__org/en-US/Fedora/18/html/__FreeIPA_Guide/disabling-anon-__binds.html > > > > > > - Jitse > > > > On 01/01/2014 07:01 PM, Rajnesh Kumar Siwal wrote: > > It exposes the details of all the users/admins in the > environment. > There should be a user that the IPA should use to > fetch the > details from > the IPA Servers. Without Authentication , no one > should be able > to fetch > any information from the IPA Server. > > > > -- > Petr? > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > > Kind regards, > > Will Sheldon > +1.(778)-689-4144 > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbingram at gmail.com Fri Jan 3 19:33:50 2014 From: sbingram at gmail.com (Stephen Ingram) Date: Fri, 3 Jan 2014 11:33:50 -0800 Subject: [Freeipa-users] FreeIPA Security issue : Anonymous user can fetch user details from IPA without authenticating In-Reply-To: <52C7016E.8020004@redhat.com> References: <52C46176.5010100@gmail.com> <52C6B2B9.8010300@redhat.com> <52C7016E.8020004@redhat.com> Message-ID: On Fri, Jan 3, 2014 at 10:29 AM, Dmitri Pal wrote: > On 01/03/2014 12:50 PM, Will Sheldon wrote: > > Thanks Petr, that certainly makes sense from the point of view of > functionality. > > I do think the default is sane, but there are a lot of possible deployment > scenarios and my concern is that a junior or time poor admin looking to > implement a trusted, secure solution should be made aware of any potential > data leakage during configuration, (preferably in big red letters in the > documentation, or better still, the install script). > > Though I am reluctant to draw comparisons between IPA and MS AD they do > seem inevitable. AD restricts anonymous binds to the rootDSE entry by > default and as such this may be considered by many to be the expected > default. Extra care should therefore be made to point out this difference. > To do otherwise risks undermining the confidence of users in the security > of the solution. > > > It is a double edge sword. We compared IPA to LDAP based solutions and > with those you have (had) anonymous bind enabled by default. > IMO it is the question of a migration. The field of centralized > authentication is crowded with all sorts of different solutions, though not > that integrated as AD or IdM. > It seems that migrating and then tightening security to the level you need > is the way to go. The default you suggest might be a barrier to migration > as people usually tackle problems one step at a time. > I am not against changing the default eventually but I am not sure it is > the time to. > > But may be I am wrong. Are there any opinions on the matter? > I think traditionally LDAP-based solutions have been used as true directories where one might be able to search for people through say a Web-based interface, for example at a university. Whereas AD can also be deployed as a directory, but more often than not though say an email Interface (e.g. Outlook) where the user has already gained access via their own credentials so there was not a need to allow anonymous binds. I like following the tradition of LDAP-based directories where anonymous access is allowed by default, however, it would be really nice as the OP requested to have controls available via the WebUI where the admin could apply ACLs to the directory to restrict access to various areas. As changing the overall access scheme requires a directory restart, I'm not too sure how easy it would be to incorporate that into the WebUI, but maybe a notice somewhere to re-enforce the "open" nature of the directory if the default is retained. Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Jan 3 19:37:55 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 03 Jan 2014 14:37:55 -0500 Subject: [Freeipa-users] FreeIPA Security issue : Anonymous user can fetch user details from IPA without authenticating In-Reply-To: References: <52C46176.5010100@gmail.com> <52C6B2B9.8010300@redhat.com> <52C7016E.8020004@redhat.com> Message-ID: <52C71193.70507@redhat.com> On 01/03/2014 02:33 PM, Stephen Ingram wrote: > On Fri, Jan 3, 2014 at 10:29 AM, Dmitri Pal > wrote: > > On 01/03/2014 12:50 PM, Will Sheldon wrote: >> Thanks Petr, that certainly makes sense from the point of view of >> functionality. >> >> I do think the default is sane, but there are a lot of possible >> deployment scenarios and my concern is that a junior or time poor >> admin looking to implement a trusted, secure solution should be >> made aware of any potential data leakage during configuration, >> (preferably in big red letters in the documentation, or better >> still, the install script). >> >> Though I am reluctant to draw comparisons between IPA and MS AD >> they do seem inevitable. AD restricts anonymous binds to the >> rootDSE entry by default and as such this may be considered by >> many to be the expected default. Extra care should therefore be >> made to point out this difference. To do otherwise risks >> undermining the confidence of users in the security of the solution. > > It is a double edge sword. We compared IPA to LDAP based solutions > and with those you have (had) anonymous bind enabled by default. > IMO it is the question of a migration. The field of centralized > authentication is crowded with all sorts of different solutions, > though not that integrated as AD or IdM. > It seems that migrating and then tightening security to the level > you need is the way to go. The default you suggest might be a > barrier to migration as people usually tackle problems one step at > a time. > I am not against changing the default eventually but I am not sure > it is the time to. > > But may be I am wrong. Are there any opinions on the matter? > > > I think traditionally LDAP-based solutions have been used as true > directories where one might be able to search for people through say a > Web-based interface, for example at a university. Whereas AD can also > be deployed as a directory, but more often than not though say an > email Interface (e.g. Outlook) where the user has already gained > access via their own credentials so there was not a need to allow > anonymous binds. I like following the tradition of LDAP-based > directories where anonymous access is allowed by default, however, it > would be really nice as the OP requested to have controls available > via the WebUI where the admin could apply ACLs to the directory to > restrict access to various areas. As changing the overall access > scheme requires a directory restart, I'm not too sure how easy it > would be to incorporate that into the WebUI, but maybe a notice > somewhere to re-enforce the "open" nature of the directory if the > default is retained. > > Steve As it was mentioned there are two options. The anonymous bind can be globally disabled. IMO it is not a UI option it is a deployment option. The ability to create fine grain access control rules including read access are in works as Petr mentioned in the earlier email. Seems like we are covered or I am missing something? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbingram at gmail.com Fri Jan 3 19:43:04 2014 From: sbingram at gmail.com (Stephen Ingram) Date: Fri, 3 Jan 2014 11:43:04 -0800 Subject: [Freeipa-users] FreeIPA Security issue : Anonymous user can fetch user details from IPA without authenticating In-Reply-To: <52C71193.70507@redhat.com> References: <52C46176.5010100@gmail.com> <52C6B2B9.8010300@redhat.com> <52C7016E.8020004@redhat.com> <52C71193.70507@redhat.com> Message-ID: On Fri, Jan 3, 2014 at 11:37 AM, Dmitri Pal wrote: > On 01/03/2014 02:33 PM, Stephen Ingram wrote: > > On Fri, Jan 3, 2014 at 10:29 AM, Dmitri Pal wrote: > >> On 01/03/2014 12:50 PM, Will Sheldon wrote: >> >> Thanks Petr, that certainly makes sense from the point of view of >> functionality. >> >> I do think the default is sane, but there are a lot of possible >> deployment scenarios and my concern is that a junior or time poor admin >> looking to implement a trusted, secure solution should be made aware of any >> potential data leakage during configuration, (preferably in big red letters >> in the documentation, or better still, the install script). >> >> Though I am reluctant to draw comparisons between IPA and MS AD they do >> seem inevitable. AD restricts anonymous binds to the rootDSE entry by >> default and as such this may be considered by many to be the expected >> default. Extra care should therefore be made to point out this difference. >> To do otherwise risks undermining the confidence of users in the >> security of the solution. >> >> >> It is a double edge sword. We compared IPA to LDAP based solutions and >> with those you have (had) anonymous bind enabled by default. >> IMO it is the question of a migration. The field of centralized >> authentication is crowded with all sorts of different solutions, though not >> that integrated as AD or IdM. >> It seems that migrating and then tightening security to the level you >> need is the way to go. The default you suggest might be a barrier to >> migration as people usually tackle problems one step at a time. >> I am not against changing the default eventually but I am not sure it is >> the time to. >> >> But may be I am wrong. Are there any opinions on the matter? >> > > I think traditionally LDAP-based solutions have been used as true > directories where one might be able to search for people through say a > Web-based interface, for example at a university. Whereas AD can also be > deployed as a directory, but more often than not though say an email > Interface (e.g. Outlook) where the user has already gained access via their > own credentials so there was not a need to allow anonymous binds. I like > following the tradition of LDAP-based directories where anonymous access is > allowed by default, however, it would be really nice as the OP requested to > have controls available via the WebUI where the admin could apply ACLs to > the directory to restrict access to various areas. As changing the overall > access scheme requires a directory restart, I'm not too sure how easy it > would be to incorporate that into the WebUI, but maybe a notice somewhere > to re-enforce the "open" nature of the directory if the default is retained. > > Steve > > As it was mentioned there are two options. The anonymous bind can be > globally disabled. IMO it is not a UI option it is a deployment option. > The ability to create fine grain access control rules including read > access are in works as Petr mentioned in the earlier email. Seems like we > are covered or I am missing something? > Sounds good to me. I was just throwing in a comment on why I thought anonymous bind is and should be the default behavior. Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.scollard at weather.com Fri Jan 3 20:31:27 2014 From: james.scollard at weather.com (James Scollard) Date: Fri, 03 Jan 2014 15:31:27 -0500 Subject: [Freeipa-users] Globalsign External CA Certificate Import Failure Message-ID: <52C71E1F.3010807@weather.com> When attempting to run the second part of the installation with an external CA (Globalsign) using my signed certificate and CA certificate chain I get the following; [root at ldapm6x00 ~]# ipa-server-install --external_cert_file=/root/ldapm6x00.sun.weather.com.crt --external_ca_file=/root/sun.weather.com.crt The log file for this installation can be found in /var/log/ipaserver-install.log Directory Manager password: Subject of the external certificate is not correct (got CN=*.sun.weather.com,O=The Weather Channel Interactive\, Inc,L=Atlanta,ST=Georgia,C=US, expected CN=Certificate Authority,O=SUN.WEATHER.COM). CN= and O= are correct, so why is IPA refusing to use the certificate? It appears to be expecting bogus data instead of using the provided identity. This doesnt appear to be an issue with the certificate, although I have never installed FreeIPA with a Globalsign certificate. I did nto see this problem with Network Solutions wildcard certificates though. Any suggestions would be appreciated. Thanks. -- James E. Scollard III Senior Cloud Systems Architect c: 615.730.4387 www.weather.com View my profile on LinkedIn From kifal75 at hotmail.com Fri Jan 3 20:52:30 2014 From: kifal75 at hotmail.com (Zulkifal Ahmad) Date: Fri, 3 Jan 2014 20:52:30 +0000 Subject: [Freeipa-users] freeipa remote commands Message-ID: Hi Experts , I am trying to run a script from a remote server which creates user principals and generate keytabs on my ipa server installed on CentOS6.5 ipav3 . The issue that I am getting is that when i run the same script from the terminal of the remote server it runs fine and retrieves the keytabs but when it is ran from a webUI of the remote server it gives me an error. " ipa: Error: did not receive kerberos credentials " . FYI my client/remote server is a part of the ipa domain and has the same version of ipa client installed i.e v3. This procedure was tested on an ordinary MIT Kerberos server and runs with no issues. Any help regarding this matter will highly be appreciated. Thanks Best Regards Sahibzada .Z. Ahmad System Administrator -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Jan 3 20:58:21 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 03 Jan 2014 15:58:21 -0500 Subject: [Freeipa-users] Globalsign External CA Certificate Import Failure In-Reply-To: <52C71E1F.3010807@weather.com> References: <52C71E1F.3010807@weather.com> Message-ID: <52C7246D.7060407@redhat.com> James Scollard wrote: > When attempting to run the second part of the installation with an > external CA (Globalsign) using my signed certificate and CA certificate > chain I get the following; > > [root at ldapm6x00 ~]# ipa-server-install > --external_cert_file=/root/ldapm6x00.sun.weather.com.crt > --external_ca_file=/root/sun.weather.com.crt > > The log file for this installation can be found in > /var/log/ipaserver-install.log > Directory Manager password: > > Subject of the external certificate is not correct (got > CN=*.sun.weather.com,O=The Weather Channel Interactive\, > Inc,L=Atlanta,ST=Georgia,C=US, expected CN=Certificate > Authority,O=SUN.WEATHER.COM). > > CN= and O= are correct, so why is IPA refusing to use the certificate? > It appears to be expecting bogus data instead of using the provided > identity. This doesnt appear to be an issue with the certificate, > although I have never installed FreeIPA with a Globalsign certificate. I > did nto see this problem with Network Solutions wildcard certificates > though. Any suggestions would be appreciated. This isn't related to the external CA, it just can't modify the subject of the IPA CA, which it did in this case. I'm not even entirely sure what it would mean to have the CA certificate itself be a wildcard cert. Doesn't seem to be a valid use-case though. Looks like this validation was added in in v3. rob From rcritten at redhat.com Fri Jan 3 21:01:32 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 03 Jan 2014 16:01:32 -0500 Subject: [Freeipa-users] freeipa remote commands In-Reply-To: References: Message-ID: <52C7252C.6070009@redhat.com> Zulkifal Ahmad wrote: > Hi Experts , > I am trying to run a script from a remote server which creates user > principals and generate keytabs on my ipa server installed on CentOS6.5 > ipav3 . The issue that I am getting is that when i run the same script > from the terminal of the remote server it runs fine and retrieves the > keytabs but when it is ran from a webUI of the remote server it gives me > an error. > " ipa: Error: did not receive kerberos credentials " . > FYI my client/remote server is a part of the ipa domain and has the > same version of ipa client installed i.e v3. Because on your local terminal you have a valid ticket when you run it, but running within the web server it doesn't unless you explicitly do a kinit (or delegate the TGT from the requesting web browser). > This procedure was tested on an ordinary MIT Kerberos server and runs > with no issues. Using what tool? I'm guessing you used kadmin or kadmin.local which is an apples to orange comparison. rob From james.scollard at weather.com Fri Jan 3 21:13:04 2014 From: james.scollard at weather.com (James Scollard) Date: Fri, 03 Jan 2014 16:13:04 -0500 Subject: [Freeipa-users] Globalsign External CA Certificate Import Failure In-Reply-To: <52C7246D.7060407@redhat.com> References: <52C71E1F.3010807@weather.com> <52C7246D.7060407@redhat.com> Message-ID: <52C727E0.4070208@weather.com> Thanks for the reply, Version: Package freeipa-server-3.3.3-2.fc19.x86_64 already installed and latest version... I'm not sure I understand the answer. I created the CSR and they signed it using their automation, and returned the new ones to me for installation, which failed. SUN.WEATHER.COM is a valid Kerberos domain name, but not a valid O=. The node itself is xxxxx.sun.weather.com, we have a wildcard certificate for sun.weather.com, and this domain controller needs the certificate for the domain for setup to complete. What am I doing wrong here? On 1/3/14 3:58 PM, Rob Crittenden wrote: > James Scollard wrote: >> When attempting to run the second part of the installation with an >> external CA (Globalsign) using my signed certificate and CA certificate >> chain I get the following; >> >> [root at ldapm6x00 ~]# ipa-server-install >> --external_cert_file=/root/ldapm6x00.sun.weather.com.crt >> --external_ca_file=/root/sun.weather.com.crt >> >> The log file for this installation can be found in >> /var/log/ipaserver-install.log >> Directory Manager password: >> >> Subject of the external certificate is not correct (got >> CN=*.sun.weather.com,O=The Weather Channel Interactive\, >> Inc,L=Atlanta,ST=Georgia,C=US, expected CN=Certificate >> Authority,O=SUN.WEATHER.COM). >> >> CN= and O= are correct, so why is IPA refusing to use the certificate? >> It appears to be expecting bogus data instead of using the provided >> identity. This doesnt appear to be an issue with the certificate, >> although I have never installed FreeIPA with a Globalsign certificate. I >> did nto see this problem with Network Solutions wildcard certificates >> though. Any suggestions would be appreciated. > > This isn't related to the external CA, it just can't modify the > subject of the IPA CA, which it did in this case. I'm not even > entirely sure what it would mean to have the CA certificate itself be > a wildcard cert. Doesn't seem to be a valid use-case though. > > Looks like this validation was added in in v3. > > rob > -- James E. Scollard III Senior Cloud Systems Architect c: 615.730.4387 www.weather.com View my profile on LinkedIn From dpal at redhat.com Fri Jan 3 21:26:21 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 03 Jan 2014 16:26:21 -0500 Subject: [Freeipa-users] Globalsign External CA Certificate Import Failure In-Reply-To: <52C727E0.4070208@weather.com> References: <52C71E1F.3010807@weather.com> <52C7246D.7060407@redhat.com> <52C727E0.4070208@weather.com> Message-ID: <52C72AFD.50101@redhat.com> On 01/03/2014 04:13 PM, James Scollard wrote: > Thanks for the reply, > > Version: > > Package freeipa-server-3.3.3-2.fc19.x86_64 already installed and > latest version... > > I'm not sure I understand the answer. > > I created the CSR and they signed it using their automation, and > returned the new ones to me for installation, which failed. > SUN.WEATHER.COM is a valid Kerberos domain name, but not a valid O=. > The node itself is xxxxx.sun.weather.com, we have a wildcard > certificate for sun.weather.com, and this domain controller needs the > certificate for the domain for setup to complete. I think what Rob was trying to say is that a wild card certificate does not make sense for IPA as a server. AFAIU you are trying to chain to an external CA to become a sub CA. I would leave to the European team to reply on Monday morning in more details. In 3.3 a new feature was added to allow installing IPA using a cert provided by external CA may be this is what you are looking for instead of a sub CA? But again I would leave it till Monday for the European team to provide more tech details on what is going wrong here. Thanks Dmitri > > What am I doing wrong here? > > On 1/3/14 3:58 PM, Rob Crittenden wrote: >> James Scollard wrote: >>> When attempting to run the second part of the installation with an >>> external CA (Globalsign) using my signed certificate and CA certificate >>> chain I get the following; >>> >>> [root at ldapm6x00 ~]# ipa-server-install >>> --external_cert_file=/root/ldapm6x00.sun.weather.com.crt >>> --external_ca_file=/root/sun.weather.com.crt >>> >>> The log file for this installation can be found in >>> /var/log/ipaserver-install.log >>> Directory Manager password: >>> >>> Subject of the external certificate is not correct (got >>> CN=*.sun.weather.com,O=The Weather Channel Interactive\, >>> Inc,L=Atlanta,ST=Georgia,C=US, expected CN=Certificate >>> Authority,O=SUN.WEATHER.COM). >>> >>> CN= and O= are correct, so why is IPA refusing to use the certificate? >>> It appears to be expecting bogus data instead of using the provided >>> identity. This doesnt appear to be an issue with the certificate, >>> although I have never installed FreeIPA with a Globalsign >>> certificate. I >>> did nto see this problem with Network Solutions wildcard certificates >>> though. Any suggestions would be appreciated. >> >> This isn't related to the external CA, it just can't modify the >> subject of the IPA CA, which it did in this case. I'm not even >> entirely sure what it would mean to have the CA certificate itself be >> a wildcard cert. Doesn't seem to be a valid use-case though. >> >> Looks like this validation was added in in v3. >> >> rob >> > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Jan 3 21:32:17 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 03 Jan 2014 16:32:17 -0500 Subject: [Freeipa-users] freeipa remote commands In-Reply-To: <52C7252C.6070009@redhat.com> References: <52C7252C.6070009@redhat.com> Message-ID: <52C72C61.9010601@redhat.com> On 01/03/2014 04:01 PM, Rob Crittenden wrote: > Zulkifal Ahmad wrote: >> Hi Experts , >> I am trying to run a script from a remote server which creates user >> principals and generate keytabs on my ipa server installed on CentOS6.5 >> ipav3 . The issue that I am getting is that when i run the same script >> from the terminal of the remote server it runs fine and retrieves the >> keytabs but when it is ran from a webUI of the remote server it gives me >> an error. What are you using as a web server? You need to give web server privileges to perform the operation on behalf of the user or delegate user tickets to web server to act as user. Both need some advanced knowledge about kerberos. Gssproxy project was created to help with that a bit but it is not in 6.x so you would have to build it yourself. With it you might be able to allow web server to perform GSSAPI operations on behalf of the users via Gss proxy. >> " ipa: Error: did not receive kerberos credentials " . >> FYI my client/remote server is a part of the ipa domain and has the >> same version of ipa client installed i.e v3. > > Because on your local terminal you have a valid ticket when you run > it, but running within the web server it doesn't unless you explicitly > do a kinit (or delegate the TGT from the requesting web browser). > >> This procedure was tested on an ordinary MIT Kerberos server and runs >> with no issues. > > Using what tool? I'm guessing you used kadmin or kadmin.local which is > an apples to orange comparison. > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From genadipost at gmail.com Sat Jan 4 23:13:10 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Sun, 5 Jan 2014 01:13:10 +0200 Subject: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain. In-Reply-To: References: <52C5DA93.8080601@redhat.com> <52C5DF52.1010901@redhat.com> <20140103112056.GE26958@hendrix.brq.redhat.com> Message-ID: Output from /var/log/secure: Jan 4 15:03:02 ipaserver sshd[5958]: Invalid user Administrator at ADDC.COMfrom 192.168.227.1 Jan 4 15:03:02 ipaserver sshd[5959]: input_userauth_request: invalid user Administrator at ADDC.COM Jan 4 15:03:06 ipaserver sshd[5958]: pam_unix(sshd:auth): check pass; user unknown Jan 4 15:03:06 ipaserver sshd[5958]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.227.1 Jan 4 15:03:06 ipaserver sshd[5958]: pam_succeed_if(sshd:auth): error retrieving information about user Administrator at ADDC.COM Jan 4 15:03:08 ipaserver sshd[5958]: Failed password for invalid user Administrator at ADDC.COM from 192.168.227.1 port 53125 ssh2 2014/1/3 Genadi Postrilko > Here are the other logs as well (ldap_child.log, sssd_pac.log, > sssd_ssh.log). > > https://gist.github.com/anonymous/8242061 > > I attempted to log in (as Administrator at ADDC.COM) at 9:04. > > Thanks for the help. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sun Jan 5 00:21:21 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 04 Jan 2014 19:21:21 -0500 Subject: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain. In-Reply-To: References: <52C5DA93.8080601@redhat.com> <52C5DF52.1010901@redhat.com> <20140103112056.GE26958@hendrix.brq.redhat.com> Message-ID: <52C8A581.3070005@redhat.com> On 01/04/2014 06:13 PM, Genadi Postrilko wrote: > Output from /var/log/secure: > > Jan 4 15:03:02 ipaserver sshd[5958]: Invalid user > Administrator at ADDC.COM from 192.168.227.1 > Jan 4 15:03:02 ipaserver sshd[5959]: input_userauth_request: invalid > user Administrator at ADDC.COM > Jan 4 15:03:06 ipaserver sshd[5958]: pam_unix(sshd:auth): check pass; > user unknown > Jan 4 15:03:06 ipaserver sshd[5958]: pam_unix(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=192.168.227.1 > Jan 4 15:03:06 ipaserver sshd[5958]: pam_succeed_if(sshd:auth): error > retrieving information about user Administrator at ADDC.COM > > Jan 4 15:03:08 ipaserver sshd[5958]: Failed password for invalid user > Administrator at ADDC.COM from > 192.168.227.1 port 53125 ssh2 I do not see SSSD doing auth. Is pam_sss configured for PAM for SSH? See more details here: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#installing-host-keys http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf I do not see simple HowTo to configure SSH to use SSSD for cases when ipa-client-install is not used. May be we should provide one. The expectation is: You install IPA, create trust, join client to IPA using ipa-client-install and it configures everything you need. The order of last two steps can be reversed but the result should be the same. > > > > 2014/1/3 Genadi Postrilko > > > Here are the other logs as well (ldap_child.log, sssd_pac.log, > sssd_ssh.log). > > https://gist.github.com/anonymous/8242061 > > I attempted to log in (as Administrator at ADDC.COM > ) at 9:04. > > Thanks for the help. > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From genadipost at gmail.com Sun Jan 5 20:58:49 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Sun, 5 Jan 2014 22:58:49 +0200 Subject: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain. In-Reply-To: <52C8A581.3070005@redhat.com> References: <52C5DA93.8080601@redhat.com> <52C5DF52.1010901@redhat.com> <20140103112056.GE26958@hendrix.brq.redhat.com> <52C8A581.3070005@redhat.com> Message-ID: What is content of the log when SSSD is doing auth? When i log in with IPA domain client, the output of the log is (anything non standard?): Jan 5 12:08:37 ipaserver sshd[24434]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.227.1 user= ron at EXAMPLE.COM Jan 5 12:08:37 ipaserver sshd[24434]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.227.1 user= ron at EXAMPLE.COM Jan 5 12:08:37 ipaserver sshd[24434]: Accepted password for ron at EXAMPLE.COMfrom 192.168.227.1 port 57144 ssh2 Jan 5 12:08:37 ipaserver sshd[24434]: pam_unix(sshd:session): session opened for user ron at EXAMPLE.COM by (uid=0) Here is the /etc/pam.d/system-auth file : https://gist.github.com/anonymous/8273507 it does contains pam_sss.so module. When i created the the environment, first i installed the IPA server, then joined the IPA clients and finally created the trust. 2014/1/5 Dmitri Pal > On 01/04/2014 06:13 PM, Genadi Postrilko wrote: > > Output from /var/log/secure: > > Jan 4 15:03:02 ipaserver sshd[5958]: Invalid user Administrator at ADDC.COMfrom 192.168.227.1 > Jan 4 15:03:02 ipaserver sshd[5959]: input_userauth_request: invalid user > Administrator at ADDC.COM > Jan 4 15:03:06 ipaserver sshd[5958]: pam_unix(sshd:auth): check pass; > user unknown > Jan 4 15:03:06 ipaserver sshd[5958]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.227.1 > Jan 4 15:03:06 ipaserver sshd[5958]: pam_succeed_if(sshd:auth): error > retrieving information about user Administrator at ADDC.COM > Jan 4 15:03:08 ipaserver sshd[5958]: Failed password for invalid user > Administrator at ADDC.COM from 192.168.227.1 port 53125 ssh2 > > > I do not see SSSD doing auth. > Is pam_sss configured for PAM for SSH? > See more details here: > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#installing-host-keys > http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf > > I do not see simple HowTo to configure SSH to use SSSD for cases when > ipa-client-install is not used. May be we should provide one. > The expectation is: > You install IPA, create trust, join client to IPA using ipa-client-install > and it configures everything you need. > The order of last two steps can be reversed but the result should be the > same. > > > > > 2014/1/3 Genadi Postrilko > >> Here are the other logs as well (ldap_child.log, sssd_pac.log, >> sssd_ssh.log). >> >> https://gist.github.com/anonymous/8242061 >> >> I attempted to log in (as Administrator at ADDC.COM) at 9:04. >> >> Thanks for the help. >> > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Less at imagine-sw.com Mon Jan 6 03:12:46 2014 From: Less at imagine-sw.com (Les Stott) Date: Mon, 6 Jan 2014 03:12:46 +0000 Subject: [Freeipa-users] Service Accounts - non expiry of passwords Message-ID: <4ED173A868981548967B4FCA2707222604FAAA@AACMBXP04.exchserver.com> Hi, I've seen a few references to this when searching the lists and mention of enhancements to later versions of freeipa to allow setting certain users to have passwords that don't expire. I'm on rhel6, which has an older freeipa, and I cant see it being updated anytime soon. So I thought I'd share what I did to work around this. Scenario: setup a user account with a password that doesn't expire. Example: an account with credentials to bind to ldap to do searches. Created a user "ldapbind" in freeipa. Created a user group in freeipa: service_accounts Added ldapbind as a member of service_accounts Created a new password policy in freeipa: service_accounts Replicated the same settings in the service_accounts password policy as per the default global_policy with the exception of "Max Lifetime", which, instead of 90 days, I set to 7300 days. The service_accounts policy was created with priority 0 (same as global_policy). All users who don't belong to the service_accounts group will get the standard 90 day expiry from the global_policy. Users who do belong to the service_accounts group get the service_accounts password policy. This seems to be a valid workaround for me. Hope it helps others. Regards, Les -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Jan 6 08:08:58 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 06 Jan 2014 09:08:58 +0100 Subject: [Freeipa-users] FreeIPA Server Install - Why --no-ntp? In-Reply-To: <1387832225.19564.403.camel@willson.li.ssimo.org> References: <1387832225.19564.403.camel@willson.li.ssimo.org> Message-ID: <52CA649A.4010506@redhat.com> On 23.12.2013 21:57, Simo Sorce wrote: > On Mon, 2013-12-23 at 12:57 -0700, Jason Becker wrote: >> Section 2.1.4.5. NTP in the Fedora 18 / 3.1.5 Guide states: >> >> "If a server is being installed on a virtual machine, that server *should >> not* run an NTP server. To disable NTP for FreeIPA, use the *--no-ntp*option." >> >> There is no further explanation. >> >> I would like to install FreeIPA Server on a vSphere VM where NTP is >> recommended as part of their timekeeping best practices for Linux guests. > > Often happens that VMs do not do very good time keeping, so using a VM > as the central NTP server is not really advised, you should instead get > a good source for NTP external to the virtualized environment and you > that one as the time source for your network. > > Of course if your virtualization environment guarantees a good clock, go > for it. > > The recommendation is in the spirit of avoiding issues in the common > case, that up to the time of the writing was not very good :) Would the option --no-ntp-server be better? -- Petr^2 Spacek From jhrozek at redhat.com Mon Jan 6 08:32:24 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 6 Jan 2014 09:32:24 +0100 Subject: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain. In-Reply-To: References: <52C5DA93.8080601@redhat.com> <52C5DF52.1010901@redhat.com> <20140103112056.GE26958@hendrix.brq.redhat.com> Message-ID: <20140106083224.GD3455@hendrix.redhat.com> On Fri, Jan 03, 2014 at 07:29:54PM +0200, Genadi Postrilko wrote: > Here are the other logs as well (ldap_child.log, sssd_pac.log, > sssd_ssh.log). > > https://gist.github.com/anonymous/8242061 > > I attempted to log in (as Administrator at ADDC.COM) at 9:04. > > Thanks for the help. > You need the *domain* log. According to the logs, your domain is called example.com, do you need to put debug_level=6 (or higher, but 6 should be enough) to the section called [domain/example.com] in sssd.conf, restart sssd, attempt the login and then attach /var/log/sssd/sssd_example.com.log Given that SSSD is complaining about not being able to find the user, I suspect a similar problem as in the other thread, that is, Winbind on the server not being able to talk to the AD. Does "wbinfo -u $user" work on the server? From jcholast at redhat.com Mon Jan 6 09:09:38 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 06 Jan 2014 10:09:38 +0100 Subject: [Freeipa-users] Globalsign External CA Certificate Import Failure In-Reply-To: <52C727E0.4070208@weather.com> References: <52C71E1F.3010807@weather.com> <52C7246D.7060407@redhat.com> <52C727E0.4070208@weather.com> Message-ID: <52CA72D2.8090201@redhat.com> Hi, On 3.1.2014 22:13, James Scollard wrote: > Thanks for the reply, > > Version: > > Package freeipa-server-3.3.3-2.fc19.x86_64 already installed and latest > version... > > I'm not sure I understand the answer. > > I created the CSR and they signed it using their automation, and > returned the new ones to me for installation, which failed. > SUN.WEATHER.COM is a valid Kerberos domain name, but not a valid O=. The > node itself is xxxxx.sun.weather.com, we have a wildcard certificate for > sun.weather.com, and this domain controller needs the certificate for > the domain for setup to complete. > > What am I doing wrong here? I sense some confusion about ipa-server-install options here. You use a wildcard server certificate as IPA's CA certificate, which is obviously not correct. It seems to me you are trying to do one of the following: a) Set up IPA using your own server certificate. This is achieved using the --*_pkcs12 options. You must create a PKCS#12 file with the certificate and its private key in order to do this. Assuming you save the PKCS#12 file to /root/ldapm6x00.sun.weather.com.p12, the command line should look something like: # ipa-server-install --dirsrv_pkcs12=/root/ldapm6x00.sun.weather.com.p12 --http_pkcs12=/root/ldapm6x00.sun.weather.com.p12 --root-ca-file=/root/sun.weather.com.crt b) Set up IPA including a IPA-managed CA, with the CA being a subordinate of some external CA. This is where you should use the --external* options. First run ipa-server-install with --external-ca, which will create a CSR for IPA CA certificate in /root/ipa.csr. Then sign the CSR with the external CA to get the IPA CA certificate. Finally, run ipa-server-install with --external_cert_file pointing to the IPA CA certificate and --external_ca_file pointing to CA certificate of the external CA. > > On 1/3/14 3:58 PM, Rob Crittenden wrote: >> James Scollard wrote: >>> When attempting to run the second part of the installation with an >>> external CA (Globalsign) using my signed certificate and CA certificate >>> chain I get the following; >>> >>> [root at ldapm6x00 ~]# ipa-server-install >>> --external_cert_file=/root/ldapm6x00.sun.weather.com.crt >>> --external_ca_file=/root/sun.weather.com.crt >>> >>> The log file for this installation can be found in >>> /var/log/ipaserver-install.log >>> Directory Manager password: >>> >>> Subject of the external certificate is not correct (got >>> CN=*.sun.weather.com,O=The Weather Channel Interactive\, >>> Inc,L=Atlanta,ST=Georgia,C=US, expected CN=Certificate >>> Authority,O=SUN.WEATHER.COM). >>> >>> CN= and O= are correct, so why is IPA refusing to use the certificate? >>> It appears to be expecting bogus data instead of using the provided >>> identity. This doesnt appear to be an issue with the certificate, >>> although I have never installed FreeIPA with a Globalsign certificate. I >>> did nto see this problem with Network Solutions wildcard certificates >>> though. Any suggestions would be appreciated. >> >> This isn't related to the external CA, it just can't modify the >> subject of the IPA CA, which it did in this case. I'm not even >> entirely sure what it would mean to have the CA certificate itself be >> a wildcard cert. Doesn't seem to be a valid use-case though. >> >> Looks like this validation was added in in v3. >> >> rob >> > Honza -- Jan Cholasta From jhrozek at redhat.com Mon Jan 6 13:20:25 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 6 Jan 2014 14:20:25 +0100 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: References: <52C56C71.5050703@redhat.com> <52C5A11C.2080408@redhat.com> <52C5BB8B.6090905@redhat.com> <20140103112911.GF26958@hendrix.brq.redhat.com> <20140103113207.GG26958@hendrix.brq.redhat.com> Message-ID: <20140106132025.GH3455@hendrix.redhat.com> On Fri, Jan 03, 2014 at 02:05:58PM +0000, Andrew Holway wrote: > >> To generate the winbind logs on the server, can you do 'smbcontrol winbindd > >> debug 100', then request the trusted user. The winbind logs would be at > >> /var/log/samba/log.w* > > I truncated all of the files in /var/log/samba and then make a single > login attempt. These are the files that were non zero after the event. > > log.smbd.epmd - https://gist.github.com/anonymous/663be9204d24bf3e915c > log.wb-PRATTLE - https://gist.github.com/anonymous/069c9931b1c66a2da85e > log.wb-WIBBLE - https://gist.github.com/anonymous/c60754ec956df30f2c60 > log.winbindd - https://gist.github.com/anonymous/25995d07c20ef5f3926a > log.winbindd-dc-connect - https://gist.github.com/anonymous/9b6a1b736f1266ddc37f Thank you, I can see some errors in the winbind log and the fact you can't resolve users with wbinfo -u confirms there is an issue, but I'not really a winbind expert. I'm sure Alexander will chime in once he's done with his post-holiday travelling :-) From pspacek at redhat.com Mon Jan 6 13:21:51 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 06 Jan 2014 14:21:51 +0100 Subject: [Freeipa-users] named failure: REQUIRE(pthread_kill(ldap_inst->watcher...) failed In-Reply-To: <52C35721.50401@redhat.com> References: <23ABE75B-1C04-48F6-8D78-F5A179E65B22@numeezy.com> <52C35721.50401@redhat.com> Message-ID: <52CAADEF.2010500@redhat.com> Hello! On 1.1.2014 00:45, Dmitri Pal wrote: > On 12/30/2013 04:48 AM, Alexandre Ellert wrote: >> This night, named crashed on my IPA server (Centos 6.5) : >> >> Dec 29 02:27:02 ipa-master named[1537]: received control channel >> command 'reload' >> Dec 29 02:27:03 ipa-master named[1537]: ldap_helper.c:640: >> REQUIRE(pthread_kill(ldap_inst->watcher, 10) == 0) failed, back trace >> Dec 29 02:27:03 ipa-master named[1537]: #0 0x7f6f443a0eff in ?? >> Dec 29 02:27:03 ipa-master named[1537]: #1 0x7f6f42d0c89a in ?? >> Dec 29 02:27:03 ipa-master named[1537]: #2 0x7f6f3e48acbf in ?? >> Dec 29 02:27:03 ipa-master named[1537]: #3 0x7f6f3e48efd6 in ?? >> Dec 29 02:27:03 ipa-master named[1537]: #4 0x7f6f3e48f591 in ?? >> Dec 29 02:27:03 ipa-master named[1537]: #5 0x7f6f43bfca54 in ?? >> Dec 29 02:27:03 ipa-master named[1537]: #6 0x7f6f443c1b87 in ?? >> Dec 29 02:27:03 ipa-master named[1537]: #7 0x7f6f443c4726 in ?? >> Dec 29 02:27:03 ipa-master named[1537]: #8 0x7f6f443c4b36 in ?? >> Dec 29 02:27:03 ipa-master named[1537]: #9 0x7f6f443c4cf8 in ?? >> Dec 29 02:27:03 ipa-master named[1537]: #10 0x7f6f44399f55 in ?? >> Dec 29 02:27:03 ipa-master named[1537]: #11 0x7f6f4439d616 in ?? >> Dec 29 02:27:03 ipa-master named[1537]: #12 0x7f6f42d2b2f8 in ?? >> Dec 29 02:27:03 ipa-master named[1537]: #13 0x7f6f426e09d1 in ?? >> Dec 29 02:27:03 ipa-master named[1537]: #14 0x7f6f41c41b6d in ?? >> Dec 29 02:27:03 ipa-master named[1537]: exiting (due to assertion failure) >> >> DNS was setup during installation time and didn't notify any problem >> since this server is in production (several months). >> >> Can you please advice about how to investigate to find the root cause >> of this crash ? >> Should I worry about that or is this just a isolated case ? This crash happens if something goes seriously wrong with the LDAP connection between named and LDAP server. (It should not crash but I feel that this part of code is not bullet-proof.) Do you see any messages complaining about broken connection or something like that? Did the server worked fine before the reload? We need more information about your configuration. Please add details mentioned at https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting#Aboutyouroperatingsystemdistribution and https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting#Abouttheplugin Have a nice day! -- Petr^2 Spacek From simo at redhat.com Mon Jan 6 14:03:54 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 06 Jan 2014 09:03:54 -0500 Subject: [Freeipa-users] FreeIPA Server Install - Why --no-ntp? In-Reply-To: <52CA649A.4010506@redhat.com> References: <1387832225.19564.403.camel@willson.li.ssimo.org> <52CA649A.4010506@redhat.com> Message-ID: <1389017034.26102.70.camel@willson.li.ssimo.org> On Mon, 2014-01-06 at 09:08 +0100, Petr Spacek wrote: > On 23.12.2013 21:57, Simo Sorce wrote: > > On Mon, 2013-12-23 at 12:57 -0700, Jason Becker wrote: > >> Section 2.1.4.5. NTP in the Fedora 18 / 3.1.5 Guide states: > >> > >> "If a server is being installed on a virtual machine, that server *should > >> not* run an NTP server. To disable NTP for FreeIPA, use the *--no-ntp*option." > >> > >> There is no further explanation. > >> > >> I would like to install FreeIPA Server on a vSphere VM where NTP is > >> recommended as part of their timekeeping best practices for Linux guests. > > > > Often happens that VMs do not do very good time keeping, so using a VM > > as the central NTP server is not really advised, you should instead get > > a good source for NTP external to the virtualized environment and you > > that one as the time source for your network. > > > > Of course if your virtualization environment guarantees a good clock, go > > for it. > > > > The recommendation is in the spirit of avoiding issues in the common > > case, that up to the time of the writing was not very good :) > > Would the option --no-ntp-server be better? I think just the Docs need to be clearer on the VM thing. Simo. -- Simo Sorce * Red Hat, Inc * New York From james.scollard at weather.com Mon Jan 6 15:43:14 2014 From: james.scollard at weather.com (James Scollard) Date: Mon, 06 Jan 2014 10:43:14 -0500 Subject: [Freeipa-users] Globalsign External CA Certificate Import Failure In-Reply-To: <52CA72D2.8090201@redhat.com> References: <52C71E1F.3010807@weather.com> <52C7246D.7060407@redhat.com> <52C727E0.4070208@weather.com> <52CA72D2.8090201@redhat.com> Message-ID: <52CACF12.6080506@weather.com> That makes absolute perfect sense. Thanks for the clarification. Unfortunately I have an new issue now. Globalsign has issued me a pkcs7 certificate. FreeIPA does not recognize the format: [root at ldapm6x00 ~]# ipa-server-install --dirsrv_pkcs7=/root/ldapm6x00.sun.weather.com.pkcs7 --http_pkcs7=/root/ldapm6x00.sun.weather.com.pkcs7 --root-ca-file=/root/STAR_CA-2048.crt Usage: ipa-server-install [options] ipa-server-install: error: no such option: --dirsrv_pkcs7 I need to convert it to pkcs12 using the converter here (awesome free tool): https://www.sslshopper.com/ssl-converter.html I need the server's private key file to convert from pkcs7 to pkcs12, but cant find it anywhere. Is there a command to export it or does it live in /var/lib or /etc somewhere? Thanks. On 1/6/14 4:09 AM, Jan Cholasta wrote: > ipa-server-install --dirsrv_pkcs -- James E. Scollard III Senior Cloud Systems Architect c: 615.730.4387 www.weather.com View my profile on LinkedIn From rcritten at redhat.com Mon Jan 6 16:01:09 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 06 Jan 2014 11:01:09 -0500 Subject: [Freeipa-users] Globalsign External CA Certificate Import Failure In-Reply-To: <52CACF12.6080506@weather.com> References: <52C71E1F.3010807@weather.com> <52C7246D.7060407@redhat.com> <52C727E0.4070208@weather.com> <52CA72D2.8090201@redhat.com> <52CACF12.6080506@weather.com> Message-ID: <52CAD345.3020405@redhat.com> James Scollard wrote: > That makes absolute perfect sense. Thanks for the clarification. > Unfortunately I have an new issue now. Globalsign has issued me a pkcs7 > certificate. FreeIPA does not recognize the format: > > [root at ldapm6x00 ~]# ipa-server-install > --dirsrv_pkcs7=/root/ldapm6x00.sun.weather.com.pkcs7 > --http_pkcs7=/root/ldapm6x00.sun.weather.com.pkcs7 > --root-ca-file=/root/STAR_CA-2048.crt > Usage: ipa-server-install [options] > > ipa-server-install: error: no such option: --dirsrv_pkcs7 > > I need to convert it to pkcs12 using the converter here (awesome free > tool): > > https://www.sslshopper.com/ssl-converter.html > > I need the server's private key file to convert from pkcs7 to pkcs12, > but cant find it anywhere. Is there a command to export it or does it > live in /var/lib or /etc somewhere? The private exists wherever you generated the CSR. If you used openssl then it would be in a flat file somewhere. If you used NSS then it would be in that database. rob From james.scollard at weather.com Mon Jan 6 17:25:28 2014 From: james.scollard at weather.com (James Scollard) Date: Mon, 06 Jan 2014 12:25:28 -0500 Subject: [Freeipa-users] Globalsign External CA Certificate Import Failure In-Reply-To: <52CAD345.3020405@redhat.com> References: <52C71E1F.3010807@weather.com> <52C7246D.7060407@redhat.com> <52C727E0.4070208@weather.com> <52CA72D2.8090201@redhat.com> <52CACF12.6080506@weather.com> <52CAD345.3020405@redhat.com> Message-ID: <52CAE708.5080105@weather.com> I have it now. The --dirsrv_pkcs12 option seems to like pkcs7 formatted certificates, but the person who issued it did not set a password, so FreeIPA will not let me install it to know if it works for sure. I am having the certificate reissued again with a password in pkcs12 format and all should be well with the world again. Thanks for your help and guidance on this. Your level of support is better than I could have expected. On 1/6/14 11:01 AM, Rob Crittenden wrote: > James Scollard wrote: >> That makes absolute perfect sense. Thanks for the clarification. >> Unfortunately I have an new issue now. Globalsign has issued me a pkcs7 >> certificate. FreeIPA does not recognize the format: >> >> [root at ldapm6x00 ~]# ipa-server-install >> --dirsrv_pkcs7=/root/ldapm6x00.sun.weather.com.pkcs7 >> --http_pkcs7=/root/ldapm6x00.sun.weather.com.pkcs7 >> --root-ca-file=/root/STAR_CA-2048.crt >> Usage: ipa-server-install [options] >> >> ipa-server-install: error: no such option: --dirsrv_pkcs7 >> >> I need to convert it to pkcs12 using the converter here (awesome free >> tool): >> >> https://www.sslshopper.com/ssl-converter.html >> >> I need the server's private key file to convert from pkcs7 to pkcs12, >> but cant find it anywhere. Is there a command to export it or does it >> live in /var/lib or /etc somewhere? > > The private exists wherever you generated the CSR. If you used openssl > then it would be in a flat file somewhere. If you used NSS then it > would be in that database. > > rob -- James E. Scollard III Senior Cloud Systems Architect c: 615.730.4387 www.weather.com View my profile on LinkedIn From dpal at redhat.com Mon Jan 6 18:39:07 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 06 Jan 2014 13:39:07 -0500 Subject: [Freeipa-users] Globalsign External CA Certificate Import Failure In-Reply-To: <52CAE708.5080105@weather.com> References: <52C71E1F.3010807@weather.com> <52C7246D.7060407@redhat.com> <52C727E0.4070208@weather.com> <52CA72D2.8090201@redhat.com> <52CACF12.6080506@weather.com> <52CAD345.3020405@redhat.com> <52CAE708.5080105@weather.com> Message-ID: <52CAF84B.60105@redhat.com> On 01/06/2014 12:25 PM, James Scollard wrote: > I have it now. The --dirsrv_pkcs12 option seems to like pkcs7 > formatted certificates, but the person who issued it did not set a > password, so FreeIPA will not let me install it to know if it works > for sure. I am having the certificate reissued again with a password > in pkcs12 format and all should be well with the world again. > > Thanks for your help and guidance on this. Your level of support is > better than I could have expected. This is not support ;-) We are just a friendly community of developers taking pride in what we do and making sure it works for people who want to use the software we create. Thanks Dmitri > > On 1/6/14 11:01 AM, Rob Crittenden wrote: >> James Scollard wrote: >>> That makes absolute perfect sense. Thanks for the clarification. >>> Unfortunately I have an new issue now. Globalsign has issued me a >>> pkcs7 >>> certificate. FreeIPA does not recognize the format: >>> >>> [root at ldapm6x00 ~]# ipa-server-install >>> --dirsrv_pkcs7=/root/ldapm6x00.sun.weather.com.pkcs7 >>> --http_pkcs7=/root/ldapm6x00.sun.weather.com.pkcs7 >>> --root-ca-file=/root/STAR_CA-2048.crt >>> Usage: ipa-server-install [options] >>> >>> ipa-server-install: error: no such option: --dirsrv_pkcs7 >>> >>> I need to convert it to pkcs12 using the converter here (awesome free >>> tool): >>> >>> https://www.sslshopper.com/ssl-converter.html >>> >>> I need the server's private key file to convert from pkcs7 to pkcs12, >>> but cant find it anywhere. Is there a command to export it or does it >>> live in /var/lib or /etc somewhere? >> >> The private exists wherever you generated the CSR. If you used >> openssl then it would be in a flat file somewhere. If you used NSS >> then it would be in that database. >> >> rob > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From matthew.joseph at lmco.com Mon Jan 6 19:43:17 2014 From: matthew.joseph at lmco.com (Joseph, Matthew (EXP)) Date: Mon, 6 Jan 2014 14:43:17 -0500 Subject: [Freeipa-users] EXTERNAL: Re: NIS Compat issues In-Reply-To: <52C5B6C1.3030607@redhat.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> <52C58FFE.9010704@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> <52C5B6C1.3030607@redhat.com> Message-ID: <543FB8F8BFD9A74298A96670DA2F2E7F0F85308606@HCXMSP1.ca.lmco.com> Hello, I can add the old UNIX servers using NIS to the secondary IPA server but not the primary. The servers can ping the primary with no issues. I didn't think the IPA servers could run ypcat? Either way neither of the servers can run the ypcat commands. Nope, ypbind was stopped when those errors came up. Matt -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Thursday, January 02, 2014 2:58 PM To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues Joseph, Matthew (EXP) wrote: > Hello, > > All of the IPA services are running. > > When I tried running the ipa-compat-manage enable and ipa-nis-manage > enable they are both loaded and running. On the IPA master you should be able to run something like: $ ypcat -h `hostname` -d passwd This will confirm basic operation on the server. If you can run the same on a client it will rule out firewall issues. Is a ypbind process already running on these clients? That might explain the 'address in use' error. rob > > The firewall is not the issue, I am positive about that. > > What do you mean by looking at the compat tree from the IPA server? > > Matt > > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* Thursday, January 02, 2014 12:13 PM > *To:* freeipa-users at redhat.com > *Subject:* EXTERNAL: Re: [Freeipa-users] NIS Compat issues > > On 01/02/2014 11:05 AM, Joseph, Matthew (EXP) wrote: > > Hello, > > I've recently had to restart my IPA servers and my NIS compatibility > mode has stopped working. > > I've configured my IPA server to run in NIS compatibility mode by doing > the following. > > [root at ipaserver ~]# ipa-nis-manage enable > > [root at ipaserver ~]# ipa-compat-manage enable > > Restart the DNS and Directory Server service: > > [root at server ~]# service restart rpcbind > > [root at server ~]# service restart dirsrv > > On my NIS clients I have the following setup in the yp.conf file. > > domain domainname.ca > server ipaservername.domainname.ca > > I tried just running the broadcast option but with no luck. > > When I try to do a service ypbind start on my NIS clients it takes a few > minutes to finally fail. > > When I tried an yptest says "Can't communicate with ypbind" which makes > sense since ypbind will not start. > > On the NIS client in the messages file it says the following; > > Ypbind: broadcast: RPC: Timed Out > > Cannot bind UDP: Address already in use > > Nothing has changed on my IPA server/configuration so I have no idea why > this stopped working. > > Any suggestions? > > > Please check if the IPA is running, the DS is running. Check the logs > that the compat plugin is loaded and working. > You can also try looking at the compat tree from the server itself to > verify that the plugin, at least the DS part is functional. > > This generally smells as a firewall issue but I have not way to prove or > disprove the theory. > > > Matt > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager for IdM portfolio > > Red Hat Inc. > > > > > > ------------------------------- > > Looking to carve out IT costs? > > www.redhat.com/carveoutcosts/ > > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From aellert at numeezy.com Mon Jan 6 20:53:45 2014 From: aellert at numeezy.com (Alexandre Ellert) Date: Mon, 6 Jan 2014 21:53:45 +0100 Subject: [Freeipa-users] named failure: REQUIRE(pthread_kill(ldap_inst->watcher...) failed In-Reply-To: <52CAADEF.2010500@redhat.com> References: <23ABE75B-1C04-48F6-8D78-F5A179E65B22@numeezy.com> <52C35721.50401@redhat.com> <52CAADEF.2010500@redhat.com> Message-ID: <1AF6994B-5EF4-4470-961A-720F7575B157@numeezy.com> > We need more information about your configuration. Please add details mentioned at > > https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting#Aboutyouroperatingsystemdistribution > > and > > https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting#Abouttheplugin What distribution/version/architecture you use? Centos 6.5 (2.6.32-431.el6.x86_64) up to date What plugin version you use? bind-dyndb-ldap-2.3-5.el6.x86_64 Do you use bind-dyndb-ldap as part of FreeIPA installation? Yes Which version of BIND you use ? bind-9.8.2-0.17.rc1.el6_4.6.x86_64 Please provide dynamic-db section from configuration file /etc/named.conf : dynamic-db "ipa" { library "ldap.so"; arg "uri ldapi://%2fvar%2frun%2fslapd-IVSCLOUD-LOCAL.socket"; arg "base cn=dns, dc=ivscloud,dc=local"; arg "fake_mname ipa-master.ivscloud.local."; arg "auth_method sasl"; arg "sasl_mech GSSAPI"; arg "sasl_user DNS/ipa-master.ivscloud.local"; arg "zone_refresh 0"; arg "psearch yes"; arg "serial_autoincrement yes"; arg "connections 4"; }; Do you have some other text based or DLZ zones configured? no Do you have some global forwarders configured in BIND configuration file? no options { [?] forward first; forwarders { }; [?] }; Do you have some settings in global configuration object in LDAP? no (not sure) $ ldapsearch -Y GSSAPI -b 'cn=dns,dc=example,dc=com' '(objectClass=idnsConfigObject)' SASL/GSSAPI authentication started SASL username: admin at IVSCLOUD.LOCAL SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectClass=idnsConfigObject) # requesting: ALL # # search result search: 4 result: 32 No such object # numResponses: 1 > Do you see any messages complaining about broken connection or something like that? Did the server worked fine before the reload? The server worked fine before reload (caused by logrotate). I've searched in log file /var/log/dirsrv/*, /var/log/messages but didn't find anything interesting. Thanks for your help -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigbjorn at nixtra.com Mon Jan 6 21:39:03 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 06 Jan 2014 22:39:03 +0100 Subject: [Freeipa-users] named failure: REQUIRE(pthread_kill(ldap_inst->watcher...) failed In-Reply-To: <1AF6994B-5EF4-4470-961A-720F7575B157@numeezy.com> References: <23ABE75B-1C04-48F6-8D78-F5A179E65B22@numeezy.com> <52C35721.50401@redhat.com> <52CAADEF.2010500@redhat.com> <1AF6994B-5EF4-4470-961A-720F7575B157@numeezy.com> Message-ID: <52CB2277.40505@nixtra.com> On 06/01/14 21:53, Alexandre Ellert wrote: > >> Do you see any messages complaining about broken connection or >> something like that? Did the server worked fine before the reload? > The server worked fine before reload (caused by logrotate). > I've searched in log file /var/log/dirsrv/*, /var/log/messages but > didn't find anything interesting. > Some of the named crashes I had at first with bind-dyndb-ldap when I started using IPA in production a few years ago also happened at the exact time logrotate rotated the log files. I've not had any issues with bind-dyndb-ldap for a while now, however the most busy dns servers are still running flat files generated from IPA's LDAP tree, but the similarity was too close not to mention it. :) Regards, Siggi -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigbjorn at nixtra.com Mon Jan 6 21:57:48 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 06 Jan 2014 22:57:48 +0100 Subject: [Freeipa-users] FreeIPA Security issue : Anonymous user can fetch user details from IPA without authenticating In-Reply-To: References: <52C46176.5010100@gmail.com> <52C6B2B9.8010300@redhat.com> <52C7016E.8020004@redhat.com> Message-ID: <52CB26DC.7080607@nixtra.com> On 03/01/14 20:33, Stephen Ingram wrote: > On Fri, Jan 3, 2014 at 10:29 AM, Dmitri Pal > wrote: > > On 01/03/2014 12:50 PM, Will Sheldon wrote: >> Thanks Petr, that certainly makes sense from the point of view of >> functionality. >> >> I do think the default is sane, but there are a lot of possible >> deployment scenarios and my concern is that a junior or time poor >> admin looking to implement a trusted, secure solution should be >> made aware of any potential data leakage during configuration, >> (preferably in big red letters in the documentation, or better >> still, the install script). >> >> Though I am reluctant to draw comparisons between IPA and MS AD >> they do seem inevitable. AD restricts anonymous binds to the >> rootDSE entry by default and as such this may be considered by >> many to be the expected default. Extra care should therefore be >> made to point out this difference. To do otherwise risks >> undermining the confidence of users in the security of the solution. > > It is a double edge sword. We compared IPA to LDAP based solutions > and with those you have (had) anonymous bind enabled by default. > IMO it is the question of a migration. The field of centralized > authentication is crowded with all sorts of different solutions, > though not that integrated as AD or IdM. > It seems that migrating and then tightening security to the level > you need is the way to go. The default you suggest might be a > barrier to migration as people usually tackle problems one step at > a time. > I am not against changing the default eventually but I am not sure > it is the time to. > > But may be I am wrong. Are there any opinions on the matter? > > > I think traditionally LDAP-based solutions have been used as true > directories where one might be able to search for people through say a > Web-based interface, for example at a university. Whereas AD can also > be deployed as a directory, but more often than not though say an > email Interface (e.g. Outlook) where the user has already gained > access via their own credentials so there was not a need to allow > anonymous binds. I like following the tradition of LDAP-based > directories where anonymous access is allowed by default, however, it > would be really nice as the OP requested to have controls available > via the WebUI where the admin could apply ACLs to the directory to > restrict access to various areas. As changing the overall access > scheme requires a directory restart, I'm not too sure how easy it > would be to incorporate that into the WebUI, but maybe a notice > somewhere to re-enforce the "open" nature of the directory if the > default is retained. > > Not to start a flame war here - but I would like to say I disagree with you. :) The traditional LDAP-based solutions you're mentioning keep information that would be open to the public, such as a phone directory. However IPA (like AD) keep sensitive information that should not be open to the public. From a security standpoint it's much easier to forget to secure a piece of information in an open directory, than to simply close the directory off and only open for known entities. In my point of view, it's better to keep these directories closed by default, to anything but authenticated requests. It's a great thing that IPA can easily be configured to either be open or closed to anonymous requests by default. :) Regards, Siggi -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Jan 6 21:59:12 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 6 Jan 2014 23:59:12 +0200 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: References: <52C56C71.5050703@redhat.com> <52C5A11C.2080408@redhat.com> <52C5BB8B.6090905@redhat.com> <20140103112911.GF26958@hendrix.brq.redhat.com> <20140103113207.GG26958@hendrix.brq.redhat.com> Message-ID: <20140106215912.GA12003@redhat.com> On Fri, 03 Jan 2014, Andrew Holway wrote: >>> To generate the winbind logs on the server, can you do 'smbcontrol winbindd >>> debug 100', then request the trusted user. The winbind logs would be at >>> /var/log/samba/log.w* > >I truncated all of the files in /var/log/samba and then make a single >login attempt. These are the files that were non zero after the event. > >log.smbd.epmd - https://gist.github.com/anonymous/663be9204d24bf3e915c >log.wb-PRATTLE - https://gist.github.com/anonymous/069c9931b1c66a2da85e I can see multiples of: [2014/01/03 07:48:08.789374, 10, pid=2662, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cm.c:806(cm_prepare_connection) cm_prepare_connection: connecting to DC WIN-5UGLHAK7RIN for domain PRATTLE [2014/01/03 07:48:08.789437, 1, pid=2662, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cm.c:839(cm_prepare_connection) cli_negprot failed: NT_STATUS_INVALID_PARAMETER_MIX This means some internal mishandling in winbindd, NT_STATUS_INVALID_PARAMETER_MIX can only appear at this path if the connection (which has just been created, few calls before cli_negprot) has outstanding outstanding calls in outgoing queue at the point when cli_negprot is attempted. As result, cli_negprot can't start until they are finished. >log.wb-WIBBLE - https://gist.github.com/anonymous/c60754ec956df30f2c60 >log.winbindd - https://gist.github.com/anonymous/25995d07c20ef5f3926a >log.winbindd-dc-connect - https://gist.github.com/anonymous/9b6a1b736f1266ddc37f At this point I need to know exact version of the samba package (samba4 if this is RHEL 6.x) to continue investigations with the exact source code at hand. -- / Alexander Bokovoy From genadipost at gmail.com Mon Jan 6 22:00:56 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Tue, 7 Jan 2014 00:00:56 +0200 Subject: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain. In-Reply-To: <20140106083224.GD3455@hendrix.redhat.com> References: <52C5DA93.8080601@redhat.com> <52C5DF52.1010901@redhat.com> <20140103112056.GE26958@hendrix.brq.redhat.com> <20140106083224.GD3455@hendrix.redhat.com> Message-ID: sssd_example.com.log after changing the debug level: https://gist.github.com/anonymous/8290381#file-sssd_example-com-log [genadi at ipaserver root]$ wbinfo -u (no output) [genadi at ipaserver root]$ wbinfo -g admins editors default smb group ad_users ad_admins [genadi at ipaserver root]$ wbinfo --trusted-domains BUILTIN EXAMPLE ADDC [genadi at ipaserver root]$ wbinfo -i Administrator failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND Could not get info for user Administrator [genadi at ipaserver root]$ wbinfo --domain-info ADDC.COM Name : ADDC Alt_Name : addc.com SID : S-1-5-21-33789592-1708006097-2663368750 Active Directory : No Native : No Primary : No 2014/1/6 Jakub Hrozek > On Fri, Jan 03, 2014 at 07:29:54PM +0200, Genadi Postrilko wrote: > > Here are the other logs as well (ldap_child.log, sssd_pac.log, > > sssd_ssh.log). > > > > https://gist.github.com/anonymous/8242061 > > > > I attempted to log in (as Administrator at ADDC.COM) at 9:04. > > > > Thanks for the help. > > > > You need the *domain* log. According to the logs, your domain is called > example.com, do you need to put debug_level=6 (or higher, but 6 should > be enough) to the section called [domain/example.com] in sssd.conf, > restart sssd, attempt the login and then attach > /var/log/sssd/sssd_example.com.log > > Given that SSSD is complaining about not being able to find the user, I > suspect a similar problem as in the other thread, that is, Winbind on > the server not being able to talk to the AD. Does "wbinfo -u $user" work > on the server? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Jan 6 22:13:19 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 06 Jan 2014 17:13:19 -0500 Subject: [Freeipa-users] EXTERNAL: Re: NIS Compat issues In-Reply-To: <543FB8F8BFD9A74298A96670DA2F2E7F0F85308606@HCXMSP1.ca.lmco.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> <52C58FFE.9010704@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> <52C5B6C1.3030607@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308606@HCXMSP1.ca.lmco.com> Message-ID: <52CB2A7F.8080300@redhat.com> Joseph, Matthew (EXP) wrote: > Hello, > > I can add the old UNIX servers using NIS to the secondary IPA server but not the primary. > The servers can ping the primary with no issues. > > I didn't think the IPA servers could run ypcat? Either way neither of the servers can run the ypcat commands. Can't run them how? > Nope, ypbind was stopped when those errors came up. Can you confirm that nothing else is bound to the port? rob > > Matt > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Thursday, January 02, 2014 2:58 PM > To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues > > Joseph, Matthew (EXP) wrote: >> Hello, >> >> All of the IPA services are running. >> >> When I tried running the ipa-compat-manage enable and ipa-nis-manage >> enable they are both loaded and running. > > On the IPA master you should be able to run something like: > > $ ypcat -h `hostname` -d passwd > > This will confirm basic operation on the server. > > If you can run the same on a client it will rule out firewall issues. > > Is a ypbind process already running on these clients? That might explain > the 'address in use' error. > > rob > >> >> The firewall is not the issue, I am positive about that. >> >> What do you mean by looking at the compat tree from the IPA server? >> >> Matt >> >> *From:*freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal >> *Sent:* Thursday, January 02, 2014 12:13 PM >> *To:* freeipa-users at redhat.com >> *Subject:* EXTERNAL: Re: [Freeipa-users] NIS Compat issues >> >> On 01/02/2014 11:05 AM, Joseph, Matthew (EXP) wrote: >> >> Hello, >> >> I've recently had to restart my IPA servers and my NIS compatibility >> mode has stopped working. >> >> I've configured my IPA server to run in NIS compatibility mode by doing >> the following. >> >> [root at ipaserver ~]# ipa-nis-manage enable >> >> [root at ipaserver ~]# ipa-compat-manage enable >> >> Restart the DNS and Directory Server service: >> >> [root at server ~]# service restart rpcbind >> >> [root at server ~]# service restart dirsrv >> >> On my NIS clients I have the following setup in the yp.conf file. >> >> domain domainname.ca >> server ipaservername.domainname.ca >> >> I tried just running the broadcast option but with no luck. >> >> When I try to do a service ypbind start on my NIS clients it takes a few >> minutes to finally fail. >> >> When I tried an yptest says "Can't communicate with ypbind" which makes >> sense since ypbind will not start. >> >> On the NIS client in the messages file it says the following; >> >> Ypbind: broadcast: RPC: Timed Out >> >> Cannot bind UDP: Address already in use >> >> Nothing has changed on my IPA server/configuration so I have no idea why >> this stopped working. >> >> Any suggestions? >> >> >> Please check if the IPA is running, the DS is running. Check the logs >> that the compat plugin is loaded and working. >> You can also try looking at the compat tree from the server itself to >> verify that the plugin, at least the DS part is functional. >> >> This generally smells as a firewall issue but I have not way to prove or >> disprove the theory. >> >> >> Matt >> >> >> >> >> _______________________________________________ >> >> Freeipa-users mailing list >> >> Freeipa-users at redhat.com >> >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> >> >> -- >> >> Thank you, >> >> Dmitri Pal >> >> >> >> Sr. Engineering Manager for IdM portfolio >> >> Red Hat Inc. >> >> >> >> >> >> ------------------------------- >> >> Looking to carve out IT costs? >> >> www.redhat.com/carveoutcosts/ >> >> >> >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > From mail at willsheldon.com Tue Jan 7 01:31:56 2014 From: mail at willsheldon.com (Will Sheldon) Date: Mon, 6 Jan 2014 17:31:56 -0800 Subject: [Freeipa-users] FreeIPA Security issue : Anonymous user can fetch user details from IPA without authenticating In-Reply-To: <52CB26DC.7080607@nixtra.com> References: <52C46176.5010100@gmail.com> <52C6B2B9.8010300@redhat.com> <52C7016E.8020004@redhat.com> <52CB26DC.7080607@nixtra.com> Message-ID: <27B0952B268840939959EC562940A339@willsheldon.com> I?m not too concerned on the default as long as the user is warned (or even maybe asked) at install time. Kind regards, Will Sheldon +1.778-689-1244 On Monday, January 6, 2014 at 1:57 PM, Sigbjorn Lie wrote: > On 03/01/14 20:33, Stephen Ingram wrote: > > On Fri, Jan 3, 2014 at 10:29 AM, Dmitri Pal wrote: > > > On 01/03/2014 12:50 PM, Will Sheldon wrote: > > > > Thanks Petr, that certainly makes sense from the point of view of functionality. > > > > > > > > I do think the default is sane, but there are a lot of possible deployment scenarios and my concern is that a junior or time poor admin looking to implement a trusted, secure solution should be made aware of any potential data leakage during configuration, (preferably in big red letters in the documentation, or better still, the install script). > > > > > > > > Though I am reluctant to draw comparisons between IPA and MS AD they do seem inevitable. AD restricts anonymous binds to the rootDSE entry by default and as such this may be considered by many to be the expected default. Extra care should therefore be made to point out this difference. To do otherwise risks undermining the confidence of users in the security of the solution. > > > > > > It is a double edge sword. We compared IPA to LDAP based solutions and with those you have (had) anonymous bind enabled by default. > > > IMO it is the question of a migration. The field of centralized authentication is crowded with all sorts of different solutions, though not that integrated as AD or IdM. > > > It seems that migrating and then tightening security to the level you need is the way to go. The default you suggest might be a barrier to migration as people usually tackle problems one step at a time. > > > I am not against changing the default eventually but I am not sure it is the time to. > > > > > > But may be I am wrong. Are there any opinions on the matter? > > > > I think traditionally LDAP-based solutions have been used as true directories where one might be able to search for people through say a Web-based interface, for example at a university. Whereas AD can also be deployed as a directory, but more often than not though say an email Interface (e.g. Outlook) where the user has already gained access via their own credentials so there was not a need to allow anonymous binds. I like following the tradition of LDAP-based directories where anonymous access is allowed by default, however, it would be really nice as the OP requested to have controls available via the WebUI where the admin could apply ACLs to the directory to restrict access to various areas. As changing the overall access scheme requires a directory restart, I'm not too sure how easy it would be to incorporate that into the WebUI, but maybe a notice somewhere to re-enforce the "open" nature of the directory if the default is retained. > > > > > > Not to start a flame war here - but I would like to say I disagree with you. :) > > The traditional LDAP-based solutions you're mentioning keep information that would be open to the public, such as a phone directory. > > However IPA (like AD) keep sensitive information that should not be open to the public. From a security standpoint it's much easier to forget to secure a piece of information in an open directory, than to simply close the directory off and only open for known entities. In my point of view, it's better to keep these directories closed by default, to anything but authenticated requests. > > It's a great thing that IPA can easily be configured to either be open or closed to anonymous requests by default. :) > > > Regards, > Siggi > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com (mailto:Freeipa-users at redhat.com) > https://www.redhat.com/mailman/listinfo/freeipa-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpazdziora at redhat.com Tue Jan 7 04:02:41 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 7 Jan 2014 12:02:41 +0800 Subject: [Freeipa-users] Enrolling client to second IPA server Message-ID: <20140107040241.GA3901@redhat.com> For testing purposes, I'd like to enroll my already IPA-enrolled client to another IPA server, with different domain. My goal is to then use Kerberos authencation in applications to use the second realm and PAM authentication in applications to go to the second domain in sssd while leaving the first realm/domain solely for OS-level authentication. I was able to copy and tweak /etc/sssd/sssd.conf, add a realm to /etc/krb5.conf, but I'm not sure where my second keytab is supposed to go. Reading http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/enrolling-machines.html suggests having the keytab from the IPA server is essential ... but where do I specify its location? Ideally I'd like to just run ipa-client-install with proper parameters but I always get IPA client is already configured on this system. While that is technically correct, it does not move me forward enrolling the system to another IPA server. Does anyone have example steps that need to be done to have my system enrolled to two IPA servers? Thank you, -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From abokovoy at redhat.com Tue Jan 7 05:48:32 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 7 Jan 2014 07:48:32 +0200 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: <1388756854.26102.35.camel@willson.li.ssimo.org> References: <52C56C71.5050703@redhat.com> <52C5A11C.2080408@redhat.com> <52C5BB8B.6090905@redhat.com> <20140103112911.GF26958@hendrix.brq.redhat.com> <1388756854.26102.35.camel@willson.li.ssimo.org> Message-ID: <20140107054832.GC12003@redhat.com> On Fri, 03 Jan 2014, Simo Sorce wrote: >On Fri, 2014-01-03 at 12:29 +0100, Jakub Hrozek wrote: >> On Thu, Jan 02, 2014 at 08:06:31PM +0000, Andrew Holway wrote: >> > /var/log/sssd/* >> > this is using bob at host (prattle.com is the windows domain) >> > https://gist.github.com/anonymous/ff817a251948ff58bdb1 >> > >> > this is using bob at prattle.com@host (prattle.com is the windows domain) >> >> Thanks, these logs have somewhat more info than those in the other >> thread. >> >> It seems that Winbind on the IPA server has trouble talking to the AD >> server: >> >> (Thu Jan 2 19:27:41 2014) [sssd[be[wibble.com]]] [fo_set_port_status] >> (0x0100): Marking port 0 of server 'ipa.wibble.com' as 'working' >> (Thu Jan 2 19:27:41 2014) [sssd[be[wibble.com]]] >> [set_server_common_status] (0x0100): Marking server 'ipa.wibble.com' as >> 'working' >> (Thu Jan 2 19:27:41 2014) [sssd[be[wibble.com]]] [ipa_s2n_get_user_done] >> (0x0040): s2n exop request failed. >> >> (The s2n exop does a special LDAP call to IPA which in turn calls >> winbind on the server). >> >> To generate the winbind logs on the server, can you do 'smbcontrol winbindd >> debug 100', then request the trusted user. The winbind logs would be at >> /var/log/samba/log.w* > >Don't use debug level 100, it will litter the tmp with packet dumps and >[possibly fill the disk. > >Log level 10 is the max that is ever useful. No, you are not right. It looks in this case that there are some unfinished async tasks associated with the outgoing socket and they prevent cli_negprot from starting. On debug level 100 we see content of the packets sent by smbd/winbindd in the log itself which will help to identify what happens. On debug level 10 we simply have two lines in succession telling that winbindd attempted to start cli_negprot and then failed it. -- / Alexander Bokovoy From abokovoy at redhat.com Tue Jan 7 06:11:12 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 7 Jan 2014 08:11:12 +0200 Subject: [Freeipa-users] Enrolling client to second IPA server In-Reply-To: <20140107040241.GA3901@redhat.com> References: <20140107040241.GA3901@redhat.com> Message-ID: <20140107061112.GD12003@redhat.com> On Tue, 07 Jan 2014, Jan Pazdziora wrote: > >For testing purposes, I'd like to enroll my already IPA-enrolled >client to another IPA server, with different domain. My goal is to >then use Kerberos authencation in applications to use the second >realm and PAM authentication in applications to go to the second >domain in sssd while leaving the first realm/domain solely for OS-level >authentication. > >I was able to copy and tweak /etc/sssd/sssd.conf, add a realm to >/etc/krb5.conf, but I'm not sure where my second keytab is supposed >to go. Reading > > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/enrolling-machines.html > >suggests having the keytab from the IPA server is essential ... but >where do I specify its location? > >Ideally I'd like to just run ipa-client-install with proper parameters >but I always get > > IPA client is already configured on this system. > >While that is technically correct, it does not move me forward >enrolling the system to another IPA server. > >Does anyone have example steps that need to be done to have my system >enrolled to two IPA servers? The problem here is that you would have the same host name assigned to two different realms which means there would be a single principal but two different keys associated with it from different realms. A single keytab could contain only principals from the single realm. Thus, you need to use different keytabs and make sure that access to a non-default KDC is always using non-default keytab. You'd also need to fetch IPA2's CA certificate and trust it. Here might be a problem since it will have the same nickname, 'IPA CA' and thus cannot be placed in the same /etc/pki/nssdb database. You can, however, put the cert file in a separate file somewhere, for example, /etc/ipa/ipa2-ca.crt. Now, suppose you have a non-default keytab set at /etc/krb5.keytab.IPA2. # kinit admin at IPA2 # ipa-getkeytab -s ipaserver.example.com -p host/foo.example.com -k /etc/krb5.keytab.IPA2 would fetch the host keytab there. Then SSSD would need to be configured to use a different location for the keytab for this realm and a different TLS cert. [domain/example.com] ... krb5_keytab = /etc/krb5.keytab.IPA2 ldap_tls_cacert = /etc/ipa/ipa2-ca.crt ... So, off my head (not tested): 1. Set up krb5.conf to have realm and domain_realm mappings for the second realm. You can only have one of the realms as default one. 2. Set up sssd.conf to have a second domain which points krb5_keytab to a different keytab, /etc/krb5.keytab.IPA2, and a different TLS CA certificate. 3. kinit as a principal from the second realm 4. Use ipa-getkeytab to fetch the keytab to /etc/krb5.keytab.IPA2 Finally, for LDAP operations you can't have profiles in ldap.conf, so defaults will only point to the original one. You can create another one in /etc/openldap and then use LDAPCONF environmental variable to point to the second config file for the defaults. -- / Alexander Bokovoy From pspacek at redhat.com Tue Jan 7 09:42:15 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 07 Jan 2014 10:42:15 +0100 Subject: [Freeipa-users] named failure: REQUIRE(pthread_kill(ldap_inst->watcher...) failed In-Reply-To: <1AF6994B-5EF4-4470-961A-720F7575B157@numeezy.com> References: <23ABE75B-1C04-48F6-8D78-F5A179E65B22@numeezy.com> <52C35721.50401@redhat.com> <52CAADEF.2010500@redhat.com> <1AF6994B-5EF4-4470-961A-720F7575B157@numeezy.com> Message-ID: <52CBCBF7.5060103@redhat.com> On 6.1.2014 21:53, Alexandre Ellert wrote: > Do you have some settings in global configuration object in LDAP? You have to adapt the example to your environment: LDAP search base should be "cn=dns, dc=ivscloud, dc=local" > $ ldapsearch -Y GSSAPI -b 'cn=dns,dc=example,dc=com' '(objectClass=idnsConfigObject)' [...] > # search result > search: 4 > result: 32 No such object Anyway, your configuration in /etc/named.conf seems correct. Please let us know if you are able to reproduce the crash, I don't see a way how to fix it without a reproducer. Have a nice day! -- Petr^2 Spacek From pspacek at redhat.com Tue Jan 7 09:50:06 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 07 Jan 2014 10:50:06 +0100 Subject: [Freeipa-users] Enrolling client to second IPA server In-Reply-To: <20140107061112.GD12003@redhat.com> References: <20140107040241.GA3901@redhat.com> <20140107061112.GD12003@redhat.com> Message-ID: <52CBCDCE.2090002@redhat.com> On 7.1.2014 07:11, Alexander Bokovoy wrote: >> Does anyone have example steps that need to be done to have my system >> enrolled to two IPA servers? > The problem here is that you would have the same host name assigned to > two different realms which means there would be a single principal but > two different keys associated with it from different realms. A single > keytab could contain only principals from the single realm. I believe that it is possible to have keys for multiple principals from multiple realms in the same keytab file. This of course doesn't solve other problems. -- Petr^2 Spacek From aellert at numeezy.com Tue Jan 7 10:14:41 2014 From: aellert at numeezy.com (Alexandre Ellert) Date: Tue, 7 Jan 2014 11:14:41 +0100 Subject: [Freeipa-users] named failure: REQUIRE(pthread_kill(ldap_inst->watcher...) failed In-Reply-To: <52CBCBF7.5060103@redhat.com> References: <23ABE75B-1C04-48F6-8D78-F5A179E65B22@numeezy.com> <52C35721.50401@redhat.com> <52CAADEF.2010500@redhat.com> <1AF6994B-5EF4-4470-961A-720F7575B157@numeezy.com> <52CBCBF7.5060103@redhat.com> Message-ID: > You have to adapt the example to your environment: > LDAP search base should be "cn=dns, dc=ivscloud, dc=local" > >> $ ldapsearch -Y GSSAPI -b 'cn=dns,dc=example,dc=com' '(objectClass=idnsConfigObject)' > [...] >> # search result >> search: 4 >> result: 32 No such object My mistake, here is the result : ldapsearch -Y GSSAPI -b 'cn=dns,dc=ivscloud,dc=local' '(objectClass=idnsConfigObject)' SASL/GSSAPI authentication started SASL username: admin at IVSCLOUD.LOCAL SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectClass=idnsConfigObject) # requesting: ALL # # dns, ivscloud.local dn: cn=dns,dc=ivscloud,dc=local objectClass: idnsConfigObject objectClass: nsContainer objectClass: top cn: dns # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1 > > Anyway, your configuration in /etc/named.conf seems correct. > > Please let us know if you are able to reproduce the crash, I don't see a way how to fix it without a reproducer. I don't know how to reproduce. Maybe try to put a cron '/sbin/service named reload' and see if it crash. > > Have a nice day! > > -- > Petr^2 Spacek From matthew.joseph at lmco.com Tue Jan 7 10:22:22 2014 From: matthew.joseph at lmco.com (Joseph, Matthew (EXP)) Date: Tue, 7 Jan 2014 05:22:22 -0500 Subject: [Freeipa-users] EXTERNAL: Re: NIS Compat issues In-Reply-To: <52CB2A7F.8080300@redhat.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> <52C58FFE.9010704@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> <52C5B6C1.3030607@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308606@HCXMSP1.ca.lmco.com> <52CB2A7F.8080300@redhat.com> Message-ID: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530871B@HCXMSP1.ca.lmco.com> When I run ypcat on the IPA servers it states that ypbind can't communicate. I started ypbind on the secondary IPA server so now I can run ypcat. Is running ypbind on the IPA servers necessary? According to all of the documentation I read it doesn't mention anything about ypbind on the servers. Yup, I checked the status of the port to make sure nothing else was using it. I configured it for an empty port below 1024. -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Monday, January 06, 2014 6:13 PM To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues Joseph, Matthew (EXP) wrote: > Hello, > > I can add the old UNIX servers using NIS to the secondary IPA server but not the primary. > The servers can ping the primary with no issues. > > I didn't think the IPA servers could run ypcat? Either way neither of the servers can run the ypcat commands. Can't run them how? > Nope, ypbind was stopped when those errors came up. Can you confirm that nothing else is bound to the port? rob > > Matt > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Thursday, January 02, 2014 2:58 PM > To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues > > Joseph, Matthew (EXP) wrote: >> Hello, >> >> All of the IPA services are running. >> >> When I tried running the ipa-compat-manage enable and ipa-nis-manage >> enable they are both loaded and running. > > On the IPA master you should be able to run something like: > > $ ypcat -h `hostname` -d passwd > > This will confirm basic operation on the server. > > If you can run the same on a client it will rule out firewall issues. > > Is a ypbind process already running on these clients? That might > explain the 'address in use' error. > > rob > >> >> The firewall is not the issue, I am positive about that. >> >> What do you mean by looking at the compat tree from the IPA server? >> >> Matt >> >> *From:*freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal >> *Sent:* Thursday, January 02, 2014 12:13 PM >> *To:* freeipa-users at redhat.com >> *Subject:* EXTERNAL: Re: [Freeipa-users] NIS Compat issues >> >> On 01/02/2014 11:05 AM, Joseph, Matthew (EXP) wrote: >> >> Hello, >> >> I've recently had to restart my IPA servers and my NIS compatibility >> mode has stopped working. >> >> I've configured my IPA server to run in NIS compatibility mode by >> doing the following. >> >> [root at ipaserver ~]# ipa-nis-manage enable >> >> [root at ipaserver ~]# ipa-compat-manage enable >> >> Restart the DNS and Directory Server service: >> >> [root at server ~]# service restart rpcbind >> >> [root at server ~]# service restart dirsrv >> >> On my NIS clients I have the following setup in the yp.conf file. >> >> domain domainname.ca >> server ipaservername.domainname.ca >> >> I tried just running the broadcast option but with no luck. >> >> When I try to do a service ypbind start on my NIS clients it takes a >> few minutes to finally fail. >> >> When I tried an yptest says "Can't communicate with ypbind" which >> makes sense since ypbind will not start. >> >> On the NIS client in the messages file it says the following; >> >> Ypbind: broadcast: RPC: Timed Out >> >> Cannot bind UDP: Address already in use >> >> Nothing has changed on my IPA server/configuration so I have no idea >> why this stopped working. >> >> Any suggestions? >> >> >> Please check if the IPA is running, the DS is running. Check the logs >> that the compat plugin is loaded and working. >> You can also try looking at the compat tree from the server itself to >> verify that the plugin, at least the DS part is functional. >> >> This generally smells as a firewall issue but I have not way to prove >> or disprove the theory. >> >> >> Matt >> >> >> >> >> _______________________________________________ >> >> Freeipa-users mailing list >> >> Freeipa-users at redhat.com >> >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> >> >> -- >> >> Thank you, >> >> Dmitri Pal >> >> >> >> Sr. Engineering Manager for IdM portfolio >> >> Red Hat Inc. >> >> >> >> >> >> ------------------------------- >> >> Looking to carve out IT costs? >> >> www.redhat.com/carveoutcosts/ >> >> >> >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > From pspacek at redhat.com Tue Jan 7 10:57:08 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 07 Jan 2014 11:57:08 +0100 Subject: [Freeipa-users] named failure: REQUIRE(pthread_kill(ldap_inst->watcher...) failed In-Reply-To: References: <23ABE75B-1C04-48F6-8D78-F5A179E65B22@numeezy.com> <52C35721.50401@redhat.com> <52CAADEF.2010500@redhat.com> <1AF6994B-5EF4-4470-961A-720F7575B157@numeezy.com> <52CBCBF7.5060103@redhat.com> Message-ID: <52CBDD84.8030404@redhat.com> On 7.1.2014 11:14, Alexandre Ellert wrote: >> You have to adapt the example to your environment: >> LDAP search base should be "cn=dns, dc=ivscloud, dc=local" >> >>> $ ldapsearch -Y GSSAPI -b 'cn=dns,dc=example,dc=com' '(objectClass=idnsConfigObject)' >> [...] >>> # search result >>> search: 4 >>> result: 32 No such object > > My mistake, here is the result : > > ldapsearch -Y GSSAPI -b 'cn=dns,dc=ivscloud,dc=local' '(objectClass=idnsConfigObject)' > SASL/GSSAPI authentication started > SASL username: admin at IVSCLOUD.LOCAL > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectClass=idnsConfigObject) > # requesting: ALL > # > > # dns, ivscloud.local > dn: cn=dns,dc=ivscloud,dc=local > objectClass: idnsConfigObject > objectClass: nsContainer > objectClass: top > cn: dns > > # search result > search: 4 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > >> >> Anyway, your configuration in /etc/named.conf seems correct. >> >> Please let us know if you are able to reproduce the crash, I don't see a way how to fix it without a reproducer. > > I don't know how to reproduce. Maybe try to put a cron '/sbin/service named reload' and see if it crash. May be, I don't have a better idea. -- Petr^2 Spacek From pspacek at redhat.com Tue Jan 7 10:58:52 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 07 Jan 2014 11:58:52 +0100 Subject: [Freeipa-users] EXTERNAL: Re: NIS Compat issues In-Reply-To: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530871B@HCXMSP1.ca.lmco.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> <52C58FFE.9010704@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> <52C5B6C1.3030607@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308606@HCXMSP1.ca.lmco.com> <52CB2A7F.8080300@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F8530871B@HCXMSP1.ca.lmco.com> Message-ID: <52CBDDEC.7020006@redhat.com> On 7.1.2014 11:22, Joseph, Matthew (EXP) wrote: > When I run ypcat on the IPA servers it states that ypbind can't communicate. > I started ypbind on the secondary IPA server so now I can run ypcat. > Is running ypbind on the IPA servers necessary? According to all of the documentation I read it doesn't mention anything about ypbind on the servers. > > Yup, I checked the status of the port to make sure nothing else was using it. > I configured it for an empty port below 1024. You can use command netstat -lpn (as root) and check if the process is listening on the correct port and interface. Petr^2 Spacek > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Monday, January 06, 2014 6:13 PM > To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues > > Joseph, Matthew (EXP) wrote: >> Hello, >> >> I can add the old UNIX servers using NIS to the secondary IPA server but not the primary. >> The servers can ping the primary with no issues. >> >> I didn't think the IPA servers could run ypcat? Either way neither of the servers can run the ypcat commands. > > Can't run them how? > >> Nope, ypbind was stopped when those errors came up. > > Can you confirm that nothing else is bound to the port? > > rob > >> >> Matt >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Thursday, January 02, 2014 2:58 PM >> To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues >> >> Joseph, Matthew (EXP) wrote: >>> Hello, >>> >>> All of the IPA services are running. >>> >>> When I tried running the ipa-compat-manage enable and ipa-nis-manage >>> enable they are both loaded and running. >> >> On the IPA master you should be able to run something like: >> >> $ ypcat -h `hostname` -d passwd >> >> This will confirm basic operation on the server. >> >> If you can run the same on a client it will rule out firewall issues. >> >> Is a ypbind process already running on these clients? That might >> explain the 'address in use' error. >> >> rob >> >>> >>> The firewall is not the issue, I am positive about that. >>> >>> What do you mean by looking at the compat tree from the IPA server? >>> >>> Matt >>> >>> *From:*freeipa-users-bounces at redhat.com >>> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal >>> *Sent:* Thursday, January 02, 2014 12:13 PM >>> *To:* freeipa-users at redhat.com >>> *Subject:* EXTERNAL: Re: [Freeipa-users] NIS Compat issues >>> >>> On 01/02/2014 11:05 AM, Joseph, Matthew (EXP) wrote: >>> >>> Hello, >>> >>> I've recently had to restart my IPA servers and my NIS compatibility >>> mode has stopped working. >>> >>> I've configured my IPA server to run in NIS compatibility mode by >>> doing the following. >>> >>> [root at ipaserver ~]# ipa-nis-manage enable >>> >>> [root at ipaserver ~]# ipa-compat-manage enable >>> >>> Restart the DNS and Directory Server service: >>> >>> [root at server ~]# service restart rpcbind >>> >>> [root at server ~]# service restart dirsrv >>> >>> On my NIS clients I have the following setup in the yp.conf file. >>> >>> domain domainname.ca >>> server ipaservername.domainname.ca >>> >>> I tried just running the broadcast option but with no luck. >>> >>> When I try to do a service ypbind start on my NIS clients it takes a >>> few minutes to finally fail. >>> >>> When I tried an yptest says "Can't communicate with ypbind" which >>> makes sense since ypbind will not start. >>> >>> On the NIS client in the messages file it says the following; >>> >>> Ypbind: broadcast: RPC: Timed Out >>> >>> Cannot bind UDP: Address already in use >>> >>> Nothing has changed on my IPA server/configuration so I have no idea >>> why this stopped working. >>> >>> Any suggestions? >>> >>> >>> Please check if the IPA is running, the DS is running. Check the logs >>> that the compat plugin is loaded and working. >>> You can also try looking at the compat tree from the server itself to >>> verify that the plugin, at least the DS part is functional. >>> >>> This generally smells as a firewall issue but I have not way to prove >>> or disprove the theory. >>> >>> >>> Matt From andrew.holway at gmail.com Tue Jan 7 10:58:57 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Tue, 7 Jan 2014 10:58:57 +0000 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: <20140106215912.GA12003@redhat.com> References: <52C56C71.5050703@redhat.com> <52C5A11C.2080408@redhat.com> <52C5BB8B.6090905@redhat.com> <20140103112911.GF26958@hendrix.brq.redhat.com> <20140103113207.GG26958@hendrix.brq.redhat.com> <20140106215912.GA12003@redhat.com> Message-ID: > At this point I need to know exact version of the samba package (samba4 > if this is RHEL 6.x) to continue investigations with the exact source > code at hand. [root at ipa ~]# rpm -qa | grep samba samba4-libs-4.0.0-60.el6_5.rc4.x86_64 From abokovoy at redhat.com Tue Jan 7 11:04:28 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 7 Jan 2014 13:04:28 +0200 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: References: <52C5A11C.2080408@redhat.com> <52C5BB8B.6090905@redhat.com> <20140103112911.GF26958@hendrix.brq.redhat.com> <20140103113207.GG26958@hendrix.brq.redhat.com> <20140106215912.GA12003@redhat.com> Message-ID: <20140107110428.GF12003@redhat.com> Andrew, On Tue, 07 Jan 2014, Andrew Holway wrote: >> At this point I need to know exact version of the samba package (samba4 >> if this is RHEL 6.x) to continue investigations with the exact source >> code at hand. > >[root at ipa ~]# rpm -qa | grep samba >samba4-libs-4.0.0-60.el6_5.rc4.x86_64 Thanks. Can you please repeat getting the logs with 'log level = 100'? Don't put them online, just send them to me privately. -- / Alexander Bokovoy From matthew.joseph at lmco.com Tue Jan 7 13:16:03 2014 From: matthew.joseph at lmco.com (Joseph, Matthew (EXP)) Date: Tue, 7 Jan 2014 08:16:03 -0500 Subject: [Freeipa-users] EXTERNAL: Re: NIS Compat issues In-Reply-To: <52CBDDEC.7020006@redhat.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> <52C58FFE.9010704@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> <52C5B6C1.3030607@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308606@HCXMSP1.ca.lmco.com> <52CB2A7F.8080300@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F8530871B@HCXMSP1.ca.lmco.com> <52CBDDEC.7020006@redhat.com> Message-ID: <543FB8F8BFD9A74298A96670DA2F2E7F0F853087A1@HCXMSP1.ca.lmco.com> When I run the netstat command it shows the following Tcp 0 0.0.0.0:1023 0.0.0.0:* LISTEN 10465/ypserv UDP 0 0.0.0.0:1023 0.0.0.0:* 10465/ypserv Like I stated this was working fine until we had our holiday shutdown for 2 weeks and when it came back online this stopped working. I tried restarting ypserv and ypbind on the secondary IPA server and it stopped working..... Does ipa-server-2.2.0-16 have some bug issues with the NIS compatibility mode? -----Original Message----- From: Petr Spacek [mailto:pspacek at redhat.com] Sent: Tuesday, January 07, 2014 6:59 AM To: Joseph, Matthew (EXP); Rob Crittenden; dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues On 7.1.2014 11:22, Joseph, Matthew (EXP) wrote: > When I run ypcat on the IPA servers it states that ypbind can't communicate. > I started ypbind on the secondary IPA server so now I can run ypcat. > Is running ypbind on the IPA servers necessary? According to all of the documentation I read it doesn't mention anything about ypbind on the servers. > > Yup, I checked the status of the port to make sure nothing else was using it. > I configured it for an empty port below 1024. You can use command netstat -lpn (as root) and check if the process is listening on the correct port and interface. Petr^2 Spacek > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Monday, January 06, 2014 6:13 PM > To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues > > Joseph, Matthew (EXP) wrote: >> Hello, >> >> I can add the old UNIX servers using NIS to the secondary IPA server but not the primary. >> The servers can ping the primary with no issues. >> >> I didn't think the IPA servers could run ypcat? Either way neither of the servers can run the ypcat commands. > > Can't run them how? > >> Nope, ypbind was stopped when those errors came up. > > Can you confirm that nothing else is bound to the port? > > rob > >> >> Matt >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Thursday, January 02, 2014 2:58 PM >> To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues >> >> Joseph, Matthew (EXP) wrote: >>> Hello, >>> >>> All of the IPA services are running. >>> >>> When I tried running the ipa-compat-manage enable and ipa-nis-manage >>> enable they are both loaded and running. >> >> On the IPA master you should be able to run something like: >> >> $ ypcat -h `hostname` -d passwd >> >> This will confirm basic operation on the server. >> >> If you can run the same on a client it will rule out firewall issues. >> >> Is a ypbind process already running on these clients? That might >> explain the 'address in use' error. >> >> rob >> >>> >>> The firewall is not the issue, I am positive about that. >>> >>> What do you mean by looking at the compat tree from the IPA server? >>> >>> Matt >>> >>> *From:*freeipa-users-bounces at redhat.com >>> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal >>> *Sent:* Thursday, January 02, 2014 12:13 PM >>> *To:* freeipa-users at redhat.com >>> *Subject:* EXTERNAL: Re: [Freeipa-users] NIS Compat issues >>> >>> On 01/02/2014 11:05 AM, Joseph, Matthew (EXP) wrote: >>> >>> Hello, >>> >>> I've recently had to restart my IPA servers and my NIS compatibility >>> mode has stopped working. >>> >>> I've configured my IPA server to run in NIS compatibility mode by >>> doing the following. >>> >>> [root at ipaserver ~]# ipa-nis-manage enable >>> >>> [root at ipaserver ~]# ipa-compat-manage enable >>> >>> Restart the DNS and Directory Server service: >>> >>> [root at server ~]# service restart rpcbind >>> >>> [root at server ~]# service restart dirsrv >>> >>> On my NIS clients I have the following setup in the yp.conf file. >>> >>> domain domainname.ca >>> server ipaservername.domainname.ca >>> >>> I tried just running the broadcast option but with no luck. >>> >>> When I try to do a service ypbind start on my NIS clients it takes a >>> few minutes to finally fail. >>> >>> When I tried an yptest says "Can't communicate with ypbind" which >>> makes sense since ypbind will not start. >>> >>> On the NIS client in the messages file it says the following; >>> >>> Ypbind: broadcast: RPC: Timed Out >>> >>> Cannot bind UDP: Address already in use >>> >>> Nothing has changed on my IPA server/configuration so I have no idea >>> why this stopped working. >>> >>> Any suggestions? >>> >>> >>> Please check if the IPA is running, the DS is running. Check the logs >>> that the compat plugin is loaded and working. >>> You can also try looking at the compat tree from the server itself to >>> verify that the plugin, at least the DS part is functional. >>> >>> This generally smells as a firewall issue but I have not way to prove >>> or disprove the theory. >>> >>> >>> Matt From matthew.joseph at lmco.com Tue Jan 7 13:22:45 2014 From: matthew.joseph at lmco.com (Joseph, Matthew (EXP)) Date: Tue, 7 Jan 2014 08:22:45 -0500 Subject: [Freeipa-users] EXTERNAL: Re: NIS Compat issues In-Reply-To: <52CBDDEC.7020006@redhat.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> <52C58FFE.9010704@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> <52C5B6C1.3030607@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308606@HCXMSP1.ca.lmco.com> <52CB2A7F.8080300@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F8530871B@HCXMSP1.ca.lmco.com> <52CBDDEC.7020006@redhat.com> Message-ID: <543FB8F8BFD9A74298A96670DA2F2E7F0F853087AF@HCXMSP1.ca.lmco.com> I forgot to show my current configuration. Yp.conf ----------------- Domain mydomain.ca server primaryIPA Domain mydomain.ca server secondaryIPA /etc/sysconfig/network ------------------- NISDOMAIN=mydomain.ca Nsswitch.conf ----------------------- has "nis" added for passwd/group/automount I've been trying different combinations of adding the nsslapd-pluginarg0: 1023 and running ypserv on the same port. Should nsslapd and ypserv be running on the same port when I do the netstat command? -----Original Message----- From: Petr Spacek [mailto:pspacek at redhat.com] Sent: Tuesday, January 07, 2014 6:59 AM To: Joseph, Matthew (EXP); Rob Crittenden; dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues On 7.1.2014 11:22, Joseph, Matthew (EXP) wrote: > When I run ypcat on the IPA servers it states that ypbind can't communicate. > I started ypbind on the secondary IPA server so now I can run ypcat. > Is running ypbind on the IPA servers necessary? According to all of the documentation I read it doesn't mention anything about ypbind on the servers. > > Yup, I checked the status of the port to make sure nothing else was using it. > I configured it for an empty port below 1024. You can use command netstat -lpn (as root) and check if the process is listening on the correct port and interface. Petr^2 Spacek > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Monday, January 06, 2014 6:13 PM > To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues > > Joseph, Matthew (EXP) wrote: >> Hello, >> >> I can add the old UNIX servers using NIS to the secondary IPA server but not the primary. >> The servers can ping the primary with no issues. >> >> I didn't think the IPA servers could run ypcat? Either way neither of the servers can run the ypcat commands. > > Can't run them how? > >> Nope, ypbind was stopped when those errors came up. > > Can you confirm that nothing else is bound to the port? > > rob > >> >> Matt >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Thursday, January 02, 2014 2:58 PM >> To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues >> >> Joseph, Matthew (EXP) wrote: >>> Hello, >>> >>> All of the IPA services are running. >>> >>> When I tried running the ipa-compat-manage enable and ipa-nis-manage >>> enable they are both loaded and running. >> >> On the IPA master you should be able to run something like: >> >> $ ypcat -h `hostname` -d passwd >> >> This will confirm basic operation on the server. >> >> If you can run the same on a client it will rule out firewall issues. >> >> Is a ypbind process already running on these clients? That might >> explain the 'address in use' error. >> >> rob >> >>> >>> The firewall is not the issue, I am positive about that. >>> >>> What do you mean by looking at the compat tree from the IPA server? >>> >>> Matt >>> >>> *From:*freeipa-users-bounces at redhat.com >>> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal >>> *Sent:* Thursday, January 02, 2014 12:13 PM >>> *To:* freeipa-users at redhat.com >>> *Subject:* EXTERNAL: Re: [Freeipa-users] NIS Compat issues >>> >>> On 01/02/2014 11:05 AM, Joseph, Matthew (EXP) wrote: >>> >>> Hello, >>> >>> I've recently had to restart my IPA servers and my NIS compatibility >>> mode has stopped working. >>> >>> I've configured my IPA server to run in NIS compatibility mode by >>> doing the following. >>> >>> [root at ipaserver ~]# ipa-nis-manage enable >>> >>> [root at ipaserver ~]# ipa-compat-manage enable >>> >>> Restart the DNS and Directory Server service: >>> >>> [root at server ~]# service restart rpcbind >>> >>> [root at server ~]# service restart dirsrv >>> >>> On my NIS clients I have the following setup in the yp.conf file. >>> >>> domain domainname.ca >>> server ipaservername.domainname.ca >>> >>> I tried just running the broadcast option but with no luck. >>> >>> When I try to do a service ypbind start on my NIS clients it takes a >>> few minutes to finally fail. >>> >>> When I tried an yptest says "Can't communicate with ypbind" which >>> makes sense since ypbind will not start. >>> >>> On the NIS client in the messages file it says the following; >>> >>> Ypbind: broadcast: RPC: Timed Out >>> >>> Cannot bind UDP: Address already in use >>> >>> Nothing has changed on my IPA server/configuration so I have no idea >>> why this stopped working. >>> >>> Any suggestions? >>> >>> >>> Please check if the IPA is running, the DS is running. Check the logs >>> that the compat plugin is loaded and working. >>> You can also try looking at the compat tree from the server itself to >>> verify that the plugin, at least the DS part is functional. >>> >>> This generally smells as a firewall issue but I have not way to prove >>> or disprove the theory. >>> >>> >>> Matt From simo at redhat.com Tue Jan 7 13:51:49 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 07 Jan 2014 08:51:49 -0500 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: <20140107054832.GC12003@redhat.com> References: <52C56C71.5050703@redhat.com> <52C5A11C.2080408@redhat.com> <52C5BB8B.6090905@redhat.com> <20140103112911.GF26958@hendrix.brq.redhat.com> <1388756854.26102.35.camel@willson.li.ssimo.org> <20140107054832.GC12003@redhat.com> Message-ID: <1389102709.26102.89.camel@willson.li.ssimo.org> On Tue, 2014-01-07 at 07:48 +0200, Alexander Bokovoy wrote: > On Fri, 03 Jan 2014, Simo Sorce wrote: > >On Fri, 2014-01-03 at 12:29 +0100, Jakub Hrozek wrote: > >> On Thu, Jan 02, 2014 at 08:06:31PM +0000, Andrew Holway wrote: > >> > /var/log/sssd/* > >> > this is using bob at host (prattle.com is the windows domain) > >> > https://gist.github.com/anonymous/ff817a251948ff58bdb1 > >> > > >> > this is using bob at prattle.com@host (prattle.com is the windows domain) > >> > >> Thanks, these logs have somewhat more info than those in the other > >> thread. > >> > >> It seems that Winbind on the IPA server has trouble talking to the AD > >> server: > >> > >> (Thu Jan 2 19:27:41 2014) [sssd[be[wibble.com]]] [fo_set_port_status] > >> (0x0100): Marking port 0 of server 'ipa.wibble.com' as 'working' > >> (Thu Jan 2 19:27:41 2014) [sssd[be[wibble.com]]] > >> [set_server_common_status] (0x0100): Marking server 'ipa.wibble.com' as > >> 'working' > >> (Thu Jan 2 19:27:41 2014) [sssd[be[wibble.com]]] [ipa_s2n_get_user_done] > >> (0x0040): s2n exop request failed. > >> > >> (The s2n exop does a special LDAP call to IPA which in turn calls > >> winbind on the server). > >> > >> To generate the winbind logs on the server, can you do 'smbcontrol winbindd > >> debug 100', then request the trusted user. The winbind logs would be at > >> /var/log/samba/log.w* > > > >Don't use debug level 100, it will litter the tmp with packet dumps and > >[possibly fill the disk. > > > >Log level 10 is the max that is ever useful. > No, you are not right. > > It looks in this case that there are some unfinished async tasks > associated with the outgoing socket and they prevent cli_negprot from > starting. On debug level 100 we see content of the packets sent by > smbd/winbindd in the log itself which will help to identify what > happens. On debug level 10 we simply have two lines in succession > telling that winbindd attempted to start cli_negprot and then failed it. Yes it is ok to ask for 100 in specific cases if you find out it is really needed, but shouldn't normally be advised, the starting point is level 10, imo. Simo. -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Tue Jan 7 13:56:04 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 7 Jan 2014 14:56:04 +0100 Subject: [Freeipa-users] AD - Freeipa trust confusion In-Reply-To: <1389102709.26102.89.camel@willson.li.ssimo.org> References: <52C56C71.5050703@redhat.com> <52C5A11C.2080408@redhat.com> <52C5BB8B.6090905@redhat.com> <20140103112911.GF26958@hendrix.brq.redhat.com> <1388756854.26102.35.camel@willson.li.ssimo.org> <20140107054832.GC12003@redhat.com> <1389102709.26102.89.camel@willson.li.ssimo.org> Message-ID: <20140107135604.GB3825@hendrix.brq.redhat.com> On Tue, Jan 07, 2014 at 08:51:49AM -0500, Simo Sorce wrote: > On Tue, 2014-01-07 at 07:48 +0200, Alexander Bokovoy wrote: > > On Fri, 03 Jan 2014, Simo Sorce wrote: > > >On Fri, 2014-01-03 at 12:29 +0100, Jakub Hrozek wrote: > > >> On Thu, Jan 02, 2014 at 08:06:31PM +0000, Andrew Holway wrote: > > >> > /var/log/sssd/* > > >> > this is using bob at host (prattle.com is the windows domain) > > >> > https://gist.github.com/anonymous/ff817a251948ff58bdb1 > > >> > > > >> > this is using bob at prattle.com@host (prattle.com is the windows domain) > > >> > > >> Thanks, these logs have somewhat more info than those in the other > > >> thread. > > >> > > >> It seems that Winbind on the IPA server has trouble talking to the AD > > >> server: > > >> > > >> (Thu Jan 2 19:27:41 2014) [sssd[be[wibble.com]]] [fo_set_port_status] > > >> (0x0100): Marking port 0 of server 'ipa.wibble.com' as 'working' > > >> (Thu Jan 2 19:27:41 2014) [sssd[be[wibble.com]]] > > >> [set_server_common_status] (0x0100): Marking server 'ipa.wibble.com' as > > >> 'working' > > >> (Thu Jan 2 19:27:41 2014) [sssd[be[wibble.com]]] [ipa_s2n_get_user_done] > > >> (0x0040): s2n exop request failed. > > >> > > >> (The s2n exop does a special LDAP call to IPA which in turn calls > > >> winbind on the server). > > >> > > >> To generate the winbind logs on the server, can you do 'smbcontrol winbindd > > >> debug 100', then request the trusted user. The winbind logs would be at > > >> /var/log/samba/log.w* > > > > > >Don't use debug level 100, it will litter the tmp with packet dumps and > > >[possibly fill the disk. > > > > > >Log level 10 is the max that is ever useful. > > No, you are not right. > > > > It looks in this case that there are some unfinished async tasks > > associated with the outgoing socket and they prevent cli_negprot from > > starting. On debug level 100 we see content of the packets sent by > > smbd/winbindd in the log itself which will help to identify what > > happens. On debug level 10 we simply have two lines in succession > > telling that winbindd attempted to start cli_negprot and then failed it. > > Yes it is ok to ask for 100 in specific cases if you find out it is > really needed, but shouldn't normally be advised, the starting point is > level 10, imo. > > Simo. I agree that 10 is a better default value to advice. To be honest, I didn't try the debug level before I adviced it, I just copied what I had in bash history on my IPA server. Sorry. From t.sailer at alumni.ethz.ch Tue Jan 7 13:58:50 2014 From: t.sailer at alumni.ethz.ch (Thomas Sailer) Date: Tue, 07 Jan 2014 14:58:50 +0100 Subject: [Freeipa-users] Upgrading freeipa server from f18 to f20 In-Reply-To: <1388328582.26102.4.camel@willson.li.ssimo.org> References: <52BFFC26.109@alumni.ethz.ch> <1388328582.26102.4.camel@willson.li.ssimo.org> Message-ID: <52CC081A.8030006@alumni.ethz.ch> On 12/29/2013 03:49 PM, Simo Sorce wrote: > Unfortunately you should have created the replica *before* the upgrade. Too bad fedup didn't refuse to update and created this mess... > Have you tried downgrading all dogtag and tomcat packages to the fc18 > ones ? After some trial and error, I downgraded the following RPMs: freeipa-admintools-3.1.5-1.fc18.x86_64 freeipa-client-3.1.5-1.fc18.x86_64 freeipa-python-3.1.5-1.fc18.x86_64 freeipa-server-3.1.5-1.fc18.x86_64 jss-4.2.6-28.fc18.x86_64 pki-ca-10.0.6-1.fc18.noarch pki-server-10.0.6-1.fc18.noarch pki-symkey-10.0.6-1.fc18.x86_64 pki-tools-10.0.6-1.fc18.x86_64 tomcatjss-7.0.0-5.fc18.noarch krb5-workstation-1.10.3-17.fc18 krb5-libs-1.10.3-17.fc18 krb5-server-ldap-1.10.3-17.fc18 krb5-pkinit-1.10.3-17.fc18 krb5-server-1.10.3-17.fc18 A file needed an ownership fix: chown pkiuser.pkiuser /var/lib/pki-ca/profiles/ca/caIPAserviceCert.cfg Now I can prepare the replica without error. However, installing the replica fails: Connection check OK Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/34]: creating directory server user [2/34]: creating directory server instance [3/34]: adding default schema [4/34]: enabling memberof plugin [5/34]: enabling winsync plugin [6/34]: configuring replication version plugin [7/34]: enabling IPA enrollment plugin [8/34]: enabling ldapi [9/34]: configuring uniqueness plugin [10/34]: configuring uuid plugin [11/34]: configuring modrdn plugin [12/34]: configuring DNS plugin [13/34]: enabling entryUSN plugin [14/34]: configuring lockout plugin [15/34]: creating indices [16/34]: enabling referential integrity plugin [17/34]: configuring ssl for ds instance [18/34]: configuring certmap.conf [19/34]: configure autobind for root [20/34]: configure new location for managed entries [21/34]: configure dirsrv ccache [22/34]: enable SASL mapping fallback [23/34]: restarting directory server [24/34]: setting up initial replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Unexpected error - see /var/log/ipareplica-install.log for details: DatabaseError: Constraint violation: pre-hashed passwords are not valid The last few lines from the install log look like: 2014-01-07T13:48:06Z DEBUG wait_for_open_ports: localhost [389] timeout 120 2014-01-07T13:48:07Z DEBUG flushing ldap://server.xxxx.com:389 from SchemaCache 2014-01-07T13:48:07Z DEBUG retrieving schema for SchemaCache url=ldap://server.xxxx.com:389 conn= 2014-01-07T13:48:08Z DEBUG flushing ldaps://replica.xxxx.com:636 from SchemaCache 2014-01-07T13:48:08Z DEBUG retrieving schema for SchemaCache url=ldaps://replica.xxxx.com:636 conn= 2014-01-07T13:48:09Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 622, in run_script return_value = main_function() File "/sbin/ipa-replica-install", line 669, in main ds = install_replica_ds(config) File "/sbin/ipa-replica-install", line 188, in install_replica_ds ca_file=config.dir + "/ca.crt", File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 360, in create_replica self.start_creation(runtime=60) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 364, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 373, in __setup_replica r_bindpw=self.dm_password) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 938, in setup_replication self.repl_man_dn, self.repl_man_passwd) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 909, in basic_replication_setup self.add_replication_manager(conn, repldn, replpw) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 362, in add_replication_manager conn.add_entry(ent) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1527, in add_entry self.conn.add_s(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 928, in error_handler raise errors.DatabaseError(desc=desc, info=info) 2014-01-07T13:48:09Z DEBUG The ipa-replica-install command failed, exception: DatabaseError: Constraint violation: pre-hashed passwords are not valid Any hint on how to fix this? Thanks, Thomas From matthew.joseph at lmco.com Tue Jan 7 14:47:33 2014 From: matthew.joseph at lmco.com (Joseph, Matthew (EXP)) Date: Tue, 7 Jan 2014 09:47:33 -0500 Subject: [Freeipa-users] EXTERNAL: Re: NIS Compat issues In-Reply-To: <543FB8F8BFD9A74298A96670DA2F2E7F0F853087AF@HCXMSP1.ca.lmco.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> <52C58FFE.9010704@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> <52C5B6C1.3030607@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308606@HCXMSP1.ca.lmco.com> <52CB2A7F.8080300@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F8530871B@HCXMSP1.ca.lmco.com> <52CBDDEC.7020006@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F853087AF@HCXMSP1.ca.lmco.com> Message-ID: <543FB8F8BFD9A74298A96670DA2F2E7F0F85308876@HCXMSP1.ca.lmco.com> So looking at NIS documentation I noticed my /var/yp folder did not have the same folders/files as it should. It should have a Makefile, nicknames, binding (folder) and mydomainname (folder) I created a folder which matched my domainname and ypbind was finally able to start. But I can't do a ypcat since it can't find the maps which I would assume live under that domainname folder. Any ideas? -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Joseph, Matthew (EXP) Sent: Tuesday, January 07, 2014 9:23 AM To: Petr Spacek; Rob Crittenden; dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues I forgot to show my current configuration. Yp.conf ----------------- Domain mydomain.ca server primaryIPA Domain mydomain.ca server secondaryIPA /etc/sysconfig/network ------------------- NISDOMAIN=mydomain.ca Nsswitch.conf ----------------------- has "nis" added for passwd/group/automount I've been trying different combinations of adding the nsslapd-pluginarg0: 1023 and running ypserv on the same port. Should nsslapd and ypserv be running on the same port when I do the netstat command? -----Original Message----- From: Petr Spacek [mailto:pspacek at redhat.com] Sent: Tuesday, January 07, 2014 6:59 AM To: Joseph, Matthew (EXP); Rob Crittenden; dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues On 7.1.2014 11:22, Joseph, Matthew (EXP) wrote: > When I run ypcat on the IPA servers it states that ypbind can't communicate. > I started ypbind on the secondary IPA server so now I can run ypcat. > Is running ypbind on the IPA servers necessary? According to all of the documentation I read it doesn't mention anything about ypbind on the servers. > > Yup, I checked the status of the port to make sure nothing else was using it. > I configured it for an empty port below 1024. You can use command netstat -lpn (as root) and check if the process is listening on the correct port and interface. Petr^2 Spacek > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Monday, January 06, 2014 6:13 PM > To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues > > Joseph, Matthew (EXP) wrote: >> Hello, >> >> I can add the old UNIX servers using NIS to the secondary IPA server but not the primary. >> The servers can ping the primary with no issues. >> >> I didn't think the IPA servers could run ypcat? Either way neither of the servers can run the ypcat commands. > > Can't run them how? > >> Nope, ypbind was stopped when those errors came up. > > Can you confirm that nothing else is bound to the port? > > rob > >> >> Matt >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Thursday, January 02, 2014 2:58 PM >> To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues >> >> Joseph, Matthew (EXP) wrote: >>> Hello, >>> >>> All of the IPA services are running. >>> >>> When I tried running the ipa-compat-manage enable and ipa-nis-manage >>> enable they are both loaded and running. >> >> On the IPA master you should be able to run something like: >> >> $ ypcat -h `hostname` -d passwd >> >> This will confirm basic operation on the server. >> >> If you can run the same on a client it will rule out firewall issues. >> >> Is a ypbind process already running on these clients? That might >> explain the 'address in use' error. >> >> rob >> >>> >>> The firewall is not the issue, I am positive about that. >>> >>> What do you mean by looking at the compat tree from the IPA server? >>> >>> Matt >>> >>> *From:*freeipa-users-bounces at redhat.com >>> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal >>> *Sent:* Thursday, January 02, 2014 12:13 PM >>> *To:* freeipa-users at redhat.com >>> *Subject:* EXTERNAL: Re: [Freeipa-users] NIS Compat issues >>> >>> On 01/02/2014 11:05 AM, Joseph, Matthew (EXP) wrote: >>> >>> Hello, >>> >>> I've recently had to restart my IPA servers and my NIS compatibility >>> mode has stopped working. >>> >>> I've configured my IPA server to run in NIS compatibility mode by >>> doing the following. >>> >>> [root at ipaserver ~]# ipa-nis-manage enable >>> >>> [root at ipaserver ~]# ipa-compat-manage enable >>> >>> Restart the DNS and Directory Server service: >>> >>> [root at server ~]# service restart rpcbind >>> >>> [root at server ~]# service restart dirsrv >>> >>> On my NIS clients I have the following setup in the yp.conf file. >>> >>> domain domainname.ca >>> server ipaservername.domainname.ca >>> >>> I tried just running the broadcast option but with no luck. >>> >>> When I try to do a service ypbind start on my NIS clients it takes a >>> few minutes to finally fail. >>> >>> When I tried an yptest says "Can't communicate with ypbind" which >>> makes sense since ypbind will not start. >>> >>> On the NIS client in the messages file it says the following; >>> >>> Ypbind: broadcast: RPC: Timed Out >>> >>> Cannot bind UDP: Address already in use >>> >>> Nothing has changed on my IPA server/configuration so I have no idea >>> why this stopped working. >>> >>> Any suggestions? >>> >>> >>> Please check if the IPA is running, the DS is running. Check the logs >>> that the compat plugin is loaded and working. >>> You can also try looking at the compat tree from the server itself to >>> verify that the plugin, at least the DS part is functional. >>> >>> This generally smells as a firewall issue but I have not way to prove >>> or disprove the theory. >>> >>> >>> Matt _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From ovalousek at vendavo.com Tue Jan 7 15:12:20 2014 From: ovalousek at vendavo.com (Ondrej Valousek) Date: Tue, 7 Jan 2014 15:12:20 +0000 Subject: [Freeipa-users] EXTERNAL: Re: NIS Compat issues In-Reply-To: <543FB8F8BFD9A74298A96670DA2F2E7F0F85308876@HCXMSP1.ca.lmco.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> <52C58FFE.9010704@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> <52C5B6C1.3030607@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308606@HCXMSP1.ca.lmco.com> <52CB2A7F.8080300@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F8530871B@HCXMSP1.ca.lmco.com> <52CBDDEC.7020006@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F853087AF@HCXMSP1.ca.lmco.com>, <543FB8F8BFD9A74298A96670DA2F2E7F0F85308876@HCXMSP1.ca.lmco.com> Message-ID: Did you try tu run ypinit -c ? Not sure now - it might be necessary to initialize the Nis subsystem. O. Odesl?no ze Samsung Mobile -------- P?vodn? zpr?va -------- Od: "Joseph, Matthew (EXP)" Datum:07. 01. 2014 15:52 (GMT+01:00) Komu: Petr Spacek ,Rob Crittenden ,dpal at redhat.com,freeipa-users at redhat.com P?edm?t: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues So looking at NIS documentation I noticed my /var/yp folder did not have the same folders/files as it should. It should have a Makefile, nicknames, binding (folder) and mydomainname (folder) I created a folder which matched my domainname and ypbind was finally able to start. But I can't do a ypcat since it can't find the maps which I would assume live under that domainname folder. Any ideas? -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Joseph, Matthew (EXP) Sent: Tuesday, January 07, 2014 9:23 AM To: Petr Spacek; Rob Crittenden; dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues I forgot to show my current configuration. Yp.conf ----------------- Domain mydomain.ca server primaryIPA Domain mydomain.ca server secondaryIPA /etc/sysconfig/network ------------------- NISDOMAIN=mydomain.ca Nsswitch.conf ----------------------- has "nis" added for passwd/group/automount I've been trying different combinations of adding the nsslapd-pluginarg0: 1023 and running ypserv on the same port. Should nsslapd and ypserv be running on the same port when I do the netstat command? -----Original Message----- From: Petr Spacek [mailto:pspacek at redhat.com] Sent: Tuesday, January 07, 2014 6:59 AM To: Joseph, Matthew (EXP); Rob Crittenden; dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues On 7.1.2014 11:22, Joseph, Matthew (EXP) wrote: > When I run ypcat on the IPA servers it states that ypbind can't communicate. > I started ypbind on the secondary IPA server so now I can run ypcat. > Is running ypbind on the IPA servers necessary? According to all of the documentation I read it doesn't mention anything about ypbind on the servers. > > Yup, I checked the status of the port to make sure nothing else was using it. > I configured it for an empty port below 1024. You can use command netstat -lpn (as root) and check if the process is listening on the correct port and interface. Petr^2 Spacek > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Monday, January 06, 2014 6:13 PM > To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues > > Joseph, Matthew (EXP) wrote: >> Hello, >> >> I can add the old UNIX servers using NIS to the secondary IPA server but not the primary. >> The servers can ping the primary with no issues. >> >> I didn't think the IPA servers could run ypcat? Either way neither of the servers can run the ypcat commands. > > Can't run them how? > >> Nope, ypbind was stopped when those errors came up. > > Can you confirm that nothing else is bound to the port? > > rob > >> >> Matt >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Thursday, January 02, 2014 2:58 PM >> To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues >> >> Joseph, Matthew (EXP) wrote: >>> Hello, >>> >>> All of the IPA services are running. >>> >>> When I tried running the ipa-compat-manage enable and ipa-nis-manage >>> enable they are both loaded and running. >> >> On the IPA master you should be able to run something like: >> >> $ ypcat -h `hostname` -d passwd >> >> This will confirm basic operation on the server. >> >> If you can run the same on a client it will rule out firewall issues. >> >> Is a ypbind process already running on these clients? That might >> explain the 'address in use' error. >> >> rob >> >>> >>> The firewall is not the issue, I am positive about that. >>> >>> What do you mean by looking at the compat tree from the IPA server? >>> >>> Matt >>> >>> *From:*freeipa-users-bounces at redhat.com >>> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal >>> *Sent:* Thursday, January 02, 2014 12:13 PM >>> *To:* freeipa-users at redhat.com >>> *Subject:* EXTERNAL: Re: [Freeipa-users] NIS Compat issues >>> >>> On 01/02/2014 11:05 AM, Joseph, Matthew (EXP) wrote: >>> >>> Hello, >>> >>> I've recently had to restart my IPA servers and my NIS compatibility >>> mode has stopped working. >>> >>> I've configured my IPA server to run in NIS compatibility mode by >>> doing the following. >>> >>> [root at ipaserver ~]# ipa-nis-manage enable >>> >>> [root at ipaserver ~]# ipa-compat-manage enable >>> >>> Restart the DNS and Directory Server service: >>> >>> [root at server ~]# service restart rpcbind >>> >>> [root at server ~]# service restart dirsrv >>> >>> On my NIS clients I have the following setup in the yp.conf file. >>> >>> domain domainname.ca >>> server ipaservername.domainname.ca >>> >>> I tried just running the broadcast option but with no luck. >>> >>> When I try to do a service ypbind start on my NIS clients it takes a >>> few minutes to finally fail. >>> >>> When I tried an yptest says "Can't communicate with ypbind" which >>> makes sense since ypbind will not start. >>> >>> On the NIS client in the messages file it says the following; >>> >>> Ypbind: broadcast: RPC: Timed Out >>> >>> Cannot bind UDP: Address already in use >>> >>> Nothing has changed on my IPA server/configuration so I have no idea >>> why this stopped working. >>> >>> Any suggestions? >>> >>> >>> Please check if the IPA is running, the DS is running. Check the logs >>> that the compat plugin is loaded and working. >>> You can also try looking at the compat tree from the server itself to >>> verify that the plugin, at least the DS part is functional. >>> >>> This generally smells as a firewall issue but I have not way to prove >>> or disprove the theory. >>> >>> >>> Matt _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.joseph at lmco.com Tue Jan 7 15:15:59 2014 From: matthew.joseph at lmco.com (Joseph, Matthew (EXP)) Date: Tue, 7 Jan 2014 10:15:59 -0500 Subject: [Freeipa-users] EXTERNAL: Re: NIS Compat issues In-Reply-To: References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> <52C58FFE.9010704@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> <52C5B6C1.3030607@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308606@HCXMSP1.ca.lmco.com> <52CB2A7F.8080300@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F8530871B@HCXMSP1.ca.lmco.com> <52CBDDEC.7020006@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F853087AF@HCXMSP1.ca.lmco.com>, <543FB8F8BFD9A74298A96670DA2F2E7F0F85308876@HCXMSP1.ca.lmco.com> Message-ID: <543FB8F8BFD9A74298A96670DA2F2E7F0F853088AC@HCXMSP1.ca.lmco.com> Ypinit -c does not exist for Linux. At least from what I can see. It looks like it's a server issue. It seems when I try to initialize NIS (through ypserv and ypbind) on the Primary and Secondary IPA servers it does not know to check IPA for the user information. Maybe I'm wrong but are the ipa-nis-manage and ipa-compat-manage commands not used to enable the NIS compatibility mode? From: Ondrej Valousek [mailto:ovalousek at vendavo.com] Sent: Tuesday, January 07, 2014 11:12 AM To: Joseph, Matthew (EXP); Petr Spacek; Rob Crittenden; dpal at redhat.com; freeipa-users at redhat.com Subject: RE: [Freeipa-users] EXTERNAL: Re: NIS Compat issues Did you try tu run ypinit -c ? Not sure now - it might be necessary to initialize the Nis subsystem. O. Odesl?no ze Samsung Mobile -------- P?vodn? zpr?va -------- Od: "Joseph, Matthew (EXP)" Datum:07. 01. 2014 15:52 (GMT+01:00) Komu: Petr Spacek ,Rob Crittenden ,dpal at redhat.com,freeipa-users at redhat.com P?edm?t: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues So looking at NIS documentation I noticed my /var/yp folder did not have the same folders/files as it should. It should have a Makefile, nicknames, binding (folder) and mydomainname (folder) I created a folder which matched my domainname and ypbind was finally able to start. But I can't do a ypcat since it can't find the maps which I would assume live under that domainname folder. Any ideas? -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Joseph, Matthew (EXP) Sent: Tuesday, January 07, 2014 9:23 AM To: Petr Spacek; Rob Crittenden; dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues I forgot to show my current configuration. Yp.conf ----------------- Domain mydomain.ca server primaryIPA Domain mydomain.ca server secondaryIPA /etc/sysconfig/network ------------------- NISDOMAIN=mydomain.ca Nsswitch.conf ----------------------- has "nis" added for passwd/group/automount I've been trying different combinations of adding the nsslapd-pluginarg0: 1023 and running ypserv on the same port. Should nsslapd and ypserv be running on the same port when I do the netstat command? -----Original Message----- From: Petr Spacek [mailto:pspacek at redhat.com] Sent: Tuesday, January 07, 2014 6:59 AM To: Joseph, Matthew (EXP); Rob Crittenden; dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues On 7.1.2014 11:22, Joseph, Matthew (EXP) wrote: > When I run ypcat on the IPA servers it states that ypbind can't communicate. > I started ypbind on the secondary IPA server so now I can run ypcat. > Is running ypbind on the IPA servers necessary? According to all of the documentation I read it doesn't mention anything about ypbind on the servers. > > Yup, I checked the status of the port to make sure nothing else was using it. > I configured it for an empty port below 1024. You can use command netstat -lpn (as root) and check if the process is listening on the correct port and interface. Petr^2 Spacek > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Monday, January 06, 2014 6:13 PM > To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues > > Joseph, Matthew (EXP) wrote: >> Hello, >> >> I can add the old UNIX servers using NIS to the secondary IPA server but not the primary. >> The servers can ping the primary with no issues. >> >> I didn't think the IPA servers could run ypcat? Either way neither of the servers can run the ypcat commands. > > Can't run them how? > >> Nope, ypbind was stopped when those errors came up. > > Can you confirm that nothing else is bound to the port? > > rob > >> >> Matt >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Thursday, January 02, 2014 2:58 PM >> To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues >> >> Joseph, Matthew (EXP) wrote: >>> Hello, >>> >>> All of the IPA services are running. >>> >>> When I tried running the ipa-compat-manage enable and ipa-nis-manage >>> enable they are both loaded and running. >> >> On the IPA master you should be able to run something like: >> >> $ ypcat -h `hostname` -d passwd >> >> This will confirm basic operation on the server. >> >> If you can run the same on a client it will rule out firewall issues. >> >> Is a ypbind process already running on these clients? That might >> explain the 'address in use' error. >> >> rob >> >>> >>> The firewall is not the issue, I am positive about that. >>> >>> What do you mean by looking at the compat tree from the IPA server? >>> >>> Matt >>> >>> *From:*freeipa-users-bounces at redhat.com >>> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal >>> *Sent:* Thursday, January 02, 2014 12:13 PM >>> *To:* freeipa-users at redhat.com >>> *Subject:* EXTERNAL: Re: [Freeipa-users] NIS Compat issues >>> >>> On 01/02/2014 11:05 AM, Joseph, Matthew (EXP) wrote: >>> >>> Hello, >>> >>> I've recently had to restart my IPA servers and my NIS compatibility >>> mode has stopped working. >>> >>> I've configured my IPA server to run in NIS compatibility mode by >>> doing the following. >>> >>> [root at ipaserver ~]# ipa-nis-manage enable >>> >>> [root at ipaserver ~]# ipa-compat-manage enable >>> >>> Restart the DNS and Directory Server service: >>> >>> [root at server ~]# service restart rpcbind >>> >>> [root at server ~]# service restart dirsrv >>> >>> On my NIS clients I have the following setup in the yp.conf file. >>> >>> domain domainname.ca >>> server ipaservername.domainname.ca >>> >>> I tried just running the broadcast option but with no luck. >>> >>> When I try to do a service ypbind start on my NIS clients it takes a >>> few minutes to finally fail. >>> >>> When I tried an yptest says "Can't communicate with ypbind" which >>> makes sense since ypbind will not start. >>> >>> On the NIS client in the messages file it says the following; >>> >>> Ypbind: broadcast: RPC: Timed Out >>> >>> Cannot bind UDP: Address already in use >>> >>> Nothing has changed on my IPA server/configuration so I have no idea >>> why this stopped working. >>> >>> Any suggestions? >>> >>> >>> Please check if the IPA is running, the DS is running. Check the logs >>> that the compat plugin is loaded and working. >>> You can also try looking at the compat tree from the server itself to >>> verify that the plugin, at least the DS part is functional. >>> >>> This generally smells as a firewall issue but I have not way to prove >>> or disprove the theory. >>> >>> >>> Matt _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nalin at redhat.com Tue Jan 7 15:31:36 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 7 Jan 2014 10:31:36 -0500 Subject: [Freeipa-users] EXTERNAL: Re: NIS Compat issues In-Reply-To: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530871B@HCXMSP1.ca.lmco.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> <52C58FFE.9010704@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> <52C5B6C1.3030607@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308606@HCXMSP1.ca.lmco.com> <52CB2A7F.8080300@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F8530871B@HCXMSP1.ca.lmco.com> Message-ID: <20140107153136.GA29580@redhat.com> On Tue, Jan 07, 2014 at 05:22:22AM -0500, Joseph, Matthew (EXP) wrote: > When I run ypcat on the IPA servers it states that ypbind can't communicate. > I started ypbind on the secondary IPA server so now I can run ypcat. > Is running ypbind on the IPA servers necessary? According to all of the documentation I read it doesn't mention anything about ypbind on the servers. Any system on which you intend to run ypcat, ypmatch, or any of the NIS client commands should run ypbind, whether it's talking to a more traditional NIS server or an IPA server with its NIS service enabled. HTH, Nalin From nalin at redhat.com Tue Jan 7 15:35:17 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 7 Jan 2014 10:35:17 -0500 Subject: [Freeipa-users] EXTERNAL: Re: NIS Compat issues In-Reply-To: <543FB8F8BFD9A74298A96670DA2F2E7F0F853087AF@HCXMSP1.ca.lmco.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> <52C58FFE.9010704@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> <52C5B6C1.3030607@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308606@HCXMSP1.ca.lmco.com> <52CB2A7F.8080300@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F8530871B@HCXMSP1.ca.lmco.com> <52CBDDEC.7020006@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F853087AF@HCXMSP1.ca.lmco.com> Message-ID: <20140107153517.GB29580@redhat.com> On Tue, Jan 07, 2014 at 08:22:45AM -0500, Joseph, Matthew (EXP) wrote: > I've been trying different combinations of adding the nsslapd-pluginarg0: 1023 and running ypserv on the same port. > Should nsslapd and ypserv be running on the same port when I do the netstat command? Only one of those should be (or can be) listening on a given port for a given set of network interfaces. If you're using the service that's enabled by ipa-nis-manage, you should turn off ypserv, though, as the directory server plugin's functions handle the work that ypserv normally does of responding to NIS clients. HTH, Nalin From rcritten at redhat.com Tue Jan 7 15:35:58 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 07 Jan 2014 10:35:58 -0500 Subject: [Freeipa-users] EXTERNAL: Re: NIS Compat issues In-Reply-To: <20140107153136.GA29580@redhat.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> <52C58FFE.9010704@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> <52C5B6C1.3030607@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308606@HCXMSP1.ca.lmco.com> <52CB2A7F.8080300@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F8530871B@HCXMSP1.ca.lmco.com> <20140107153136.GA29580@redhat.com> Message-ID: <52CC1EDE.9070905@redhat.com> Nalin Dahyabhai wrote: > On Tue, Jan 07, 2014 at 05:22:22AM -0500, Joseph, Matthew (EXP) wrote: >> When I run ypcat on the IPA servers it states that ypbind can't communicate. >> I started ypbind on the secondary IPA server so now I can run ypcat. >> Is running ypbind on the IPA servers necessary? According to all of the documentation I read it doesn't mention anything about ypbind on the servers. > > Any system on which you intend to run ypcat, ypmatch, or any of the NIS > client commands should run ypbind, whether it's talking to a more > traditional NIS server or an IPA server with its NIS service enabled. > I run ypcat w/o ypbind all the time for testing. You just need to specify the server and domain on the command-line: $ ypcat -h `hostname` -d example.com passwd rob From ovalousek at vendavo.com Tue Jan 7 15:43:37 2014 From: ovalousek at vendavo.com (Ondrej Valousek) Date: Tue, 7 Jan 2014 15:43:37 +0000 Subject: [Freeipa-users] EXTERNAL: Re: NIS Compat issues In-Reply-To: <543FB8F8BFD9A74298A96670DA2F2E7F0F853088AC@HCXMSP1.ca.lmco.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> <52C58FFE.9010704@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> <52C5B6C1.3030607@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308606@HCXMSP1.ca.lmco.com> <52CB2A7F.8080300@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F8530871B@HCXMSP1.ca.lmco.com> <52CBDDEC.7020006@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F853087AF@HCXMSP1.ca.lmco.com>, <543FB8F8BFD9A74298A96670DA2F2E7F0F85308876@HCXMSP1.ca.lmco.com> , <543FB8F8BFD9A74298A96670DA2F2E7F0F853088AC@HCXMSP1.ca.lmco.com> Message-ID: Ok. Just curious - why are you running Nis on Linux where we have native client available? Sorry for this OT question. O. Odesl?no ze Samsung Mobile -------- P?vodn? zpr?va -------- Od: "Joseph, Matthew (EXP)" Datum:07. 01. 2014 16:17 (GMT+01:00) Komu: Ondrej Valousek ,Petr Spacek ,Rob Crittenden ,dpal at redhat.com,freeipa-users at redhat.com P?edm?t: RE: [Freeipa-users] EXTERNAL: Re: NIS Compat issues Ypinit ?c does not exist for Linux. At least from what I can see. It looks like it?s a server issue. It seems when I try to initialize NIS (through ypserv and ypbind) on the Primary and Secondary IPA servers it does not know to check IPA for the user information. Maybe I?m wrong but are the ipa-nis-manage and ipa-compat-manage commands not used to enable the NIS compatibility mode? From: Ondrej Valousek [mailto:ovalousek at vendavo.com] Sent: Tuesday, January 07, 2014 11:12 AM To: Joseph, Matthew (EXP); Petr Spacek; Rob Crittenden; dpal at redhat.com; freeipa-users at redhat.com Subject: RE: [Freeipa-users] EXTERNAL: Re: NIS Compat issues Did you try tu run ypinit -c ? Not sure now - it might be necessary to initialize the Nis subsystem. O. Odesl?no ze Samsung Mobile -------- P?vodn? zpr?va -------- Od: "Joseph, Matthew (EXP)" Datum:07. 01. 2014 15:52 (GMT+01:00) Komu: Petr Spacek ,Rob Crittenden ,dpal at redhat.com,freeipa-users at redhat.com P?edm?t: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues So looking at NIS documentation I noticed my /var/yp folder did not have the same folders/files as it should. It should have a Makefile, nicknames, binding (folder) and mydomainname (folder) I created a folder which matched my domainname and ypbind was finally able to start. But I can't do a ypcat since it can't find the maps which I would assume live under that domainname folder. Any ideas? -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Joseph, Matthew (EXP) Sent: Tuesday, January 07, 2014 9:23 AM To: Petr Spacek; Rob Crittenden; dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues I forgot to show my current configuration. Yp.conf ----------------- Domain mydomain.ca server primaryIPA Domain mydomain.ca server secondaryIPA /etc/sysconfig/network ------------------- NISDOMAIN=mydomain.ca Nsswitch.conf ----------------------- has "nis" added for passwd/group/automount I've been trying different combinations of adding the nsslapd-pluginarg0: 1023 and running ypserv on the same port. Should nsslapd and ypserv be running on the same port when I do the netstat command? -----Original Message----- From: Petr Spacek [mailto:pspacek at redhat.com] Sent: Tuesday, January 07, 2014 6:59 AM To: Joseph, Matthew (EXP); Rob Crittenden; dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues On 7.1.2014 11:22, Joseph, Matthew (EXP) wrote: > When I run ypcat on the IPA servers it states that ypbind can't communicate. > I started ypbind on the secondary IPA server so now I can run ypcat. > Is running ypbind on the IPA servers necessary? According to all of the documentation I read it doesn't mention anything about ypbind on the servers. > > Yup, I checked the status of the port to make sure nothing else was using it. > I configured it for an empty port below 1024. You can use command netstat -lpn (as root) and check if the process is listening on the correct port and interface. Petr^2 Spacek > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Monday, January 06, 2014 6:13 PM > To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues > > Joseph, Matthew (EXP) wrote: >> Hello, >> >> I can add the old UNIX servers using NIS to the secondary IPA server but not the primary. >> The servers can ping the primary with no issues. >> >> I didn't think the IPA servers could run ypcat? Either way neither of the servers can run the ypcat commands. > > Can't run them how? > >> Nope, ypbind was stopped when those errors came up. > > Can you confirm that nothing else is bound to the port? > > rob > >> >> Matt >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Thursday, January 02, 2014 2:58 PM >> To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues >> >> Joseph, Matthew (EXP) wrote: >>> Hello, >>> >>> All of the IPA services are running. >>> >>> When I tried running the ipa-compat-manage enable and ipa-nis-manage >>> enable they are both loaded and running. >> >> On the IPA master you should be able to run something like: >> >> $ ypcat -h `hostname` -d passwd >> >> This will confirm basic operation on the server. >> >> If you can run the same on a client it will rule out firewall issues. >> >> Is a ypbind process already running on these clients? That might >> explain the 'address in use' error. >> >> rob >> >>> >>> The firewall is not the issue, I am positive about that. >>> >>> What do you mean by looking at the compat tree from the IPA server? >>> >>> Matt >>> >>> *From:*freeipa-users-bounces at redhat.com >>> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal >>> *Sent:* Thursday, January 02, 2014 12:13 PM >>> *To:* freeipa-users at redhat.com >>> *Subject:* EXTERNAL: Re: [Freeipa-users] NIS Compat issues >>> >>> On 01/02/2014 11:05 AM, Joseph, Matthew (EXP) wrote: >>> >>> Hello, >>> >>> I've recently had to restart my IPA servers and my NIS compatibility >>> mode has stopped working. >>> >>> I've configured my IPA server to run in NIS compatibility mode by >>> doing the following. >>> >>> [root at ipaserver ~]# ipa-nis-manage enable >>> >>> [root at ipaserver ~]# ipa-compat-manage enable >>> >>> Restart the DNS and Directory Server service: >>> >>> [root at server ~]# service restart rpcbind >>> >>> [root at server ~]# service restart dirsrv >>> >>> On my NIS clients I have the following setup in the yp.conf file. >>> >>> domain domainname.ca >>> server ipaservername.domainname.ca >>> >>> I tried just running the broadcast option but with no luck. >>> >>> When I try to do a service ypbind start on my NIS clients it takes a >>> few minutes to finally fail. >>> >>> When I tried an yptest says "Can't communicate with ypbind" which >>> makes sense since ypbind will not start. >>> >>> On the NIS client in the messages file it says the following; >>> >>> Ypbind: broadcast: RPC: Timed Out >>> >>> Cannot bind UDP: Address already in use >>> >>> Nothing has changed on my IPA server/configuration so I have no idea >>> why this stopped working. >>> >>> Any suggestions? >>> >>> >>> Please check if the IPA is running, the DS is running. Check the logs >>> that the compat plugin is loaded and working. >>> You can also try looking at the compat tree from the server itself to >>> verify that the plugin, at least the DS part is functional. >>> >>> This generally smells as a firewall issue but I have not way to prove >>> or disprove the theory. >>> >>> >>> Matt _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.joseph at lmco.com Tue Jan 7 15:46:08 2014 From: matthew.joseph at lmco.com (Joseph, Matthew (EXP)) Date: Tue, 7 Jan 2014 10:46:08 -0500 Subject: [Freeipa-users] EXTERNAL: Re: NIS Compat issues In-Reply-To: References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> <52C58FFE.9010704@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> <52C5B6C1.3030607@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308606@HCXMSP1.ca.lmco.com> <52CB2A7F.8080300@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F8530871B@HCXMSP1.ca.lmco.com> <52CBDDEC.7020006@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F853087AF@HCXMSP1.ca.lmco.com>, <543FB8F8BFD9A74298A96670DA2F2E7F0F85308876@HCXMSP1.ca.lmco.com> , <543FB8F8BFD9A74298A96670DA2F2E7F0F853088AC@HCXMSP1.ca.lmco.com> Message-ID: <543FB8F8BFD9A74298A96670DA2F2E7F0F853088E2@HCXMSP1.ca.lmco.com> No worries. We have a couple of older clients on our network that consist of RHEL 4.3, RHEL 5.3, RHEL 5.5, Solaris 7, Solaris 8, and Solaris 10. Unfortunately I won't be able to get rid of those machines for the next year or so. I figured for those older clients it would just be easier to have them all go through NIS. I had it working for a good year and then it just stopped. From: Ondrej Valousek [mailto:ovalousek at vendavo.com] Sent: Tuesday, January 07, 2014 11:44 AM To: Joseph, Matthew (EXP); Petr Spacek; Rob Crittenden; dpal at redhat.com; freeipa-users at redhat.com Subject: RE: [Freeipa-users] EXTERNAL: Re: NIS Compat issues Ok. Just curious - why are you running Nis on Linux where we have native client available? Sorry for this OT question. O. Odesl?no ze Samsung Mobile -------- P?vodn? zpr?va -------- Od: "Joseph, Matthew (EXP)" Datum:07. 01. 2014 16:17 (GMT+01:00) Komu: Ondrej Valousek ,Petr Spacek ,Rob Crittenden ,dpal at redhat.com,freeipa-users at redhat.com P?edm?t: RE: [Freeipa-users] EXTERNAL: Re: NIS Compat issues Ypinit -c does not exist for Linux. At least from what I can see. It looks like it's a server issue. It seems when I try to initialize NIS (through ypserv and ypbind) on the Primary and Secondary IPA servers it does not know to check IPA for the user information. Maybe I'm wrong but are the ipa-nis-manage and ipa-compat-manage commands not used to enable the NIS compatibility mode? From: Ondrej Valousek [mailto:ovalousek at vendavo.com] Sent: Tuesday, January 07, 2014 11:12 AM To: Joseph, Matthew (EXP); Petr Spacek; Rob Crittenden; dpal at redhat.com; freeipa-users at redhat.com Subject: RE: [Freeipa-users] EXTERNAL: Re: NIS Compat issues Did you try tu run ypinit -c ? Not sure now - it might be necessary to initialize the Nis subsystem. O. Odesl?no ze Samsung Mobile -------- P?vodn? zpr?va -------- Od: "Joseph, Matthew (EXP)" Datum:07. 01. 2014 15:52 (GMT+01:00) Komu: Petr Spacek ,Rob Crittenden ,dpal at redhat.com,freeipa-users at redhat.com P?edm?t: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues So looking at NIS documentation I noticed my /var/yp folder did not have the same folders/files as it should. It should have a Makefile, nicknames, binding (folder) and mydomainname (folder) I created a folder which matched my domainname and ypbind was finally able to start. But I can't do a ypcat since it can't find the maps which I would assume live under that domainname folder. Any ideas? -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Joseph, Matthew (EXP) Sent: Tuesday, January 07, 2014 9:23 AM To: Petr Spacek; Rob Crittenden; dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues I forgot to show my current configuration. Yp.conf ----------------- Domain mydomain.ca server primaryIPA Domain mydomain.ca server secondaryIPA /etc/sysconfig/network ------------------- NISDOMAIN=mydomain.ca Nsswitch.conf ----------------------- has "nis" added for passwd/group/automount I've been trying different combinations of adding the nsslapd-pluginarg0: 1023 and running ypserv on the same port. Should nsslapd and ypserv be running on the same port when I do the netstat command? -----Original Message----- From: Petr Spacek [mailto:pspacek at redhat.com] Sent: Tuesday, January 07, 2014 6:59 AM To: Joseph, Matthew (EXP); Rob Crittenden; dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues On 7.1.2014 11:22, Joseph, Matthew (EXP) wrote: > When I run ypcat on the IPA servers it states that ypbind can't communicate. > I started ypbind on the secondary IPA server so now I can run ypcat. > Is running ypbind on the IPA servers necessary? According to all of the documentation I read it doesn't mention anything about ypbind on the servers. > > Yup, I checked the status of the port to make sure nothing else was using it. > I configured it for an empty port below 1024. You can use command netstat -lpn (as root) and check if the process is listening on the correct port and interface. Petr^2 Spacek > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Monday, January 06, 2014 6:13 PM > To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues > > Joseph, Matthew (EXP) wrote: >> Hello, >> >> I can add the old UNIX servers using NIS to the secondary IPA server but not the primary. >> The servers can ping the primary with no issues. >> >> I didn't think the IPA servers could run ypcat? Either way neither of the servers can run the ypcat commands. > > Can't run them how? > >> Nope, ypbind was stopped when those errors came up. > > Can you confirm that nothing else is bound to the port? > > rob > >> >> Matt >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Thursday, January 02, 2014 2:58 PM >> To: Joseph, Matthew (EXP); dpal at redhat.com; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues >> >> Joseph, Matthew (EXP) wrote: >>> Hello, >>> >>> All of the IPA services are running. >>> >>> When I tried running the ipa-compat-manage enable and ipa-nis-manage >>> enable they are both loaded and running. >> >> On the IPA master you should be able to run something like: >> >> $ ypcat -h `hostname` -d passwd >> >> This will confirm basic operation on the server. >> >> If you can run the same on a client it will rule out firewall issues. >> >> Is a ypbind process already running on these clients? That might >> explain the 'address in use' error. >> >> rob >> >>> >>> The firewall is not the issue, I am positive about that. >>> >>> What do you mean by looking at the compat tree from the IPA server? >>> >>> Matt >>> >>> *From:*freeipa-users-bounces at redhat.com >>> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal >>> *Sent:* Thursday, January 02, 2014 12:13 PM >>> *To:* freeipa-users at redhat.com >>> *Subject:* EXTERNAL: Re: [Freeipa-users] NIS Compat issues >>> >>> On 01/02/2014 11:05 AM, Joseph, Matthew (EXP) wrote: >>> >>> Hello, >>> >>> I've recently had to restart my IPA servers and my NIS compatibility >>> mode has stopped working. >>> >>> I've configured my IPA server to run in NIS compatibility mode by >>> doing the following. >>> >>> [root at ipaserver ~]# ipa-nis-manage enable >>> >>> [root at ipaserver ~]# ipa-compat-manage enable >>> >>> Restart the DNS and Directory Server service: >>> >>> [root at server ~]# service restart rpcbind >>> >>> [root at server ~]# service restart dirsrv >>> >>> On my NIS clients I have the following setup in the yp.conf file. >>> >>> domain domainname.ca >>> server ipaservername.domainname.ca >>> >>> I tried just running the broadcast option but with no luck. >>> >>> When I try to do a service ypbind start on my NIS clients it takes a >>> few minutes to finally fail. >>> >>> When I tried an yptest says "Can't communicate with ypbind" which >>> makes sense since ypbind will not start. >>> >>> On the NIS client in the messages file it says the following; >>> >>> Ypbind: broadcast: RPC: Timed Out >>> >>> Cannot bind UDP: Address already in use >>> >>> Nothing has changed on my IPA server/configuration so I have no idea >>> why this stopped working. >>> >>> Any suggestions? >>> >>> >>> Please check if the IPA is running, the DS is running. Check the logs >>> that the compat plugin is loaded and working. >>> You can also try looking at the compat tree from the server itself to >>> verify that the plugin, at least the DS part is functional. >>> >>> This generally smells as a firewall issue but I have not way to prove >>> or disprove the theory. >>> >>> >>> Matt _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nalin at redhat.com Tue Jan 7 15:52:11 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 7 Jan 2014 10:52:11 -0500 Subject: [Freeipa-users] EXTERNAL: Re: NIS Compat issues In-Reply-To: <52CC1EDE.9070905@redhat.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> <52C58FFE.9010704@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> <52C5B6C1.3030607@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308606@HCXMSP1.ca.lmco.com> <52CB2A7F.8080300@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F8530871B@HCXMSP1.ca.lmco.com> <20140107153136.GA29580@redhat.com> <52CC1EDE.9070905@redhat.com> Message-ID: <20140107155211.GC29580@redhat.com> On Tue, Jan 07, 2014 at 10:35:58AM -0500, Rob Crittenden wrote: > Nalin Dahyabhai wrote: > >Any system on which you intend to run ypcat, ypmatch, or any of the NIS > >client commands should run ypbind, whether it's talking to a more > >traditional NIS server or an IPA server with its NIS service enabled. > > I run ypcat w/o ypbind all the time for testing. You just need to > specify the server and domain on the command-line: > > $ ypcat -h `hostname` -d example.com passwd I left that tidbit out, but yeah, I often use it that way as well when troubleshooting. On that topic, 'rpcinfo -p' is handy for checking that the NIS server is properly registered with its local port mapper (as a "ypserv" server), which is necessary for ypbind to find it. Cheers, Nalin From matthew.joseph at lmco.com Tue Jan 7 15:59:19 2014 From: matthew.joseph at lmco.com (Joseph, Matthew (EXP)) Date: Tue, 7 Jan 2014 10:59:19 -0500 Subject: [Freeipa-users] EXTERNAL: Re: NIS Compat issues In-Reply-To: <52CC1EDE.9070905@redhat.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0F8530814C@HCXMSP1.ca.lmco.com> <52C58FFE.9010704@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308164@HCXMSP1.ca.lmco.com> <52C5B6C1.3030607@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F85308606@HCXMSP1.ca.lmco.com> <52CB2A7F.8080300@redhat.com> <543FB8F8BFD9A74298A96670DA2F2E7F0F8530871B@HCXMSP1.ca.lmco.com> <20140107153136.GA29580@redhat.com> <52CC1EDE.9070905@redhat.com> Message-ID: <543FB8F8BFD9A74298A96670DA2F2E7F0F85308905@HCXMSP1.ca.lmco.com> That is right, I forgot about adding those options. So what I did was stopped ypserv (since the IPA plugin functions should handle all incoming NIS requests right?) Restarted the dirsrv and rpcbind. I try running ypbind on both the server and client but it fails with the same error. I tried running ypcat from a client and it gives the following error; No such map passwd.byname: Reason: Can't communicate with portmapper. So I checked port 1023 (ns-slapd is running) and nothing else is using port 1023. I restarted dirsrv and rpcbind 2 times each and then it finally worked. I'm going to try to reboot the server at the earliest time possible to make sure the config sticks. Thank you for the help guys and helping me understand how the NIS module in IPA works. Matt -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Tuesday, January 07, 2014 11:36 AM To: Nalin Dahyabhai; Joseph, Matthew (EXP) Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues Nalin Dahyabhai wrote: > On Tue, Jan 07, 2014 at 05:22:22AM -0500, Joseph, Matthew (EXP) wrote: >> When I run ypcat on the IPA servers it states that ypbind can't communicate. >> I started ypbind on the secondary IPA server so now I can run ypcat. >> Is running ypbind on the IPA servers necessary? According to all of the documentation I read it doesn't mention anything about ypbind on the servers. > > Any system on which you intend to run ypcat, ypmatch, or any of the NIS > client commands should run ypbind, whether it's talking to a more > traditional NIS server or an IPA server with its NIS service enabled. > I run ypcat w/o ypbind all the time for testing. You just need to specify the server and domain on the command-line: $ ypcat -h `hostname` -d example.com passwd rob From benjamin.soriano at lyra-network.com Tue Jan 7 17:56:31 2014 From: benjamin.soriano at lyra-network.com (Benjamin Soriano) Date: Tue, 07 Jan 2014 18:56:31 +0100 Subject: [Freeipa-users] Get certificate for virtual host on many hosts In-Reply-To: <52CC3C51.6070000@lyra-network.com> References: <52CC3C51.6070000@lyra-network.com> Message-ID: <52CC3FCF.9080802@lyra-network.com> Hello all, Here is the situation. I have a web service (reachable via service.example.com) that run on two servers (srv1.example.com and srv2.example.com). The load is distributed on servers by a DNS round robin. And I want the certificate for https://service.example.com be managed by IPA (which is my root CA) and take advantage of certificate monitoring. The two servers are registered in IPA and can request their own certificate. I manage to request the certificate on one of the servers by doing the following : Create fake host on ds.example.com > ipa host-add service.example.com > ipa host-add-managedby service.example.com --hosts=srv1.example.com > ipa service-add HTTP/service.example.com > ipa service-add-hosts HTTP/service.example.com --hosts=srv1.example.com Then request the certificate on srv1 : > ipa-getcert request -r -f /etc/pki/certs/service.example.com.crt -k /etc/pki/private/service.example.com.key -N CN=service.example.com -D service.example.com -K HTTP/service.example.com It work pretty well. But if I add the second server that way : > ... > ipa host-add-managedby service.example.com --hosts=srv1.example.com,srv2.example.com > ... > ipa service-add-hosts HTTP/service.example.com --hosts=srv1.example.com,srv2.example.com I can only resquest the certificate on one of the servers. The first request is going well (no matter on which server I do it) and the second is stuck in this state : Request ID '20140107165415': status: CA_REJECTED ca-error: Server denied our request, giving up: 2100 (RPC failed at server. Insufficient access: not allowed to perform this command). stuck: yes key pair storage: type=FILE,location='/etc/pki/private/service.example.com.key' certificate: type=FILE,location='/etc/pki/certs/service.example.com.crt' CA: IPA ... Is this a normal behavior? If yes, what could be the right way to achieve what I want? Regards, -- Benjamin Soriano From rcritten at redhat.com Tue Jan 7 18:21:07 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 07 Jan 2014 13:21:07 -0500 Subject: [Freeipa-users] Get certificate for virtual host on many hosts In-Reply-To: <52CC3FCF.9080802@lyra-network.com> References: <52CC3C51.6070000@lyra-network.com> <52CC3FCF.9080802@lyra-network.com> Message-ID: <52CC4593.8050802@redhat.com> Benjamin Soriano wrote: > Hello all, > > Here is the situation. I have a web service (reachable via > service.example.com) that run on two servers (srv1.example.com and > srv2.example.com). The load is distributed on servers by a DNS round robin. > And I want the certificate for https://service.example.com be managed by > IPA (which is my root CA) and take advantage of certificate monitoring. > The two servers are registered in IPA and can request their own > certificate. > > I manage to request the certificate on one of the servers by doing the > following : > > Create fake host on ds.example.com > > ipa host-add service.example.com > > ipa host-add-managedby service.example.com --hosts=srv1.example.com > > ipa service-add HTTP/service.example.com > > ipa service-add-hosts HTTP/service.example.com --hosts=srv1.example.com > > Then request the certificate on srv1 : > > ipa-getcert request -r -f /etc/pki/certs/service.example.com.crt -k > /etc/pki/private/service.example.com.key -N CN=service.example.com -D > service.example.com -K HTTP/service.example.com > > It work pretty well. But if I add the second server that way : > > ... > > ipa host-add-managedby service.example.com > --hosts=srv1.example.com,srv2.example.com > > ... > > ipa service-add-hosts HTTP/service.example.com > --hosts=srv1.example.com,srv2.example.com > > I can only resquest the certificate on one of the servers. The first > request is going well (no matter on which server I do it) and the second > is stuck in this state : > > Request ID '20140107165415': > status: CA_REJECTED > ca-error: Server denied our request, giving up: 2100 (RPC > failed at server. Insufficient access: not allowed to perform this > command). > stuck: yes > key pair storage: > type=FILE,location='/etc/pki/private/service.example.com.key' > certificate: > type=FILE,location='/etc/pki/certs/service.example.com.crt' > CA: IPA > ... > > Is this a normal behavior? > > If yes, what could be the right way to achieve what I want? > > Regards, The problem is you would have two separate, valid certificates for the same service and we only store one at a time. The second request is going to try to revoke the original cert in order to issue another one. I'm guessing it is failing on the revocation step. I think you'll need to pick one server to manage it and manually copy it to any other servers. This loses the advantage of certmonger on the other boxes unfortunately. rob From pspacek at redhat.com Tue Jan 7 18:33:05 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 07 Jan 2014 19:33:05 +0100 Subject: [Freeipa-users] Get certificate for virtual host on many hosts In-Reply-To: <52CC4593.8050802@redhat.com> References: <52CC3C51.6070000@lyra-network.com> <52CC3FCF.9080802@lyra-network.com> <52CC4593.8050802@redhat.com> Message-ID: <52CC4861.4090301@redhat.com> On 7.1.2014 19:21, Rob Crittenden wrote: > Benjamin Soriano wrote: >> Hello all, >> >> Here is the situation. I have a web service (reachable via >> service.example.com) that run on two servers (srv1.example.com and >> srv2.example.com). The load is distributed on servers by a DNS round robin. >> And I want the certificate for https://service.example.com be managed by >> IPA (which is my root CA) and take advantage of certificate monitoring. >> The two servers are registered in IPA and can request their own >> certificate. >> >> I manage to request the certificate on one of the servers by doing the >> following : >> >> Create fake host on ds.example.com >> > ipa host-add service.example.com >> > ipa host-add-managedby service.example.com --hosts=srv1.example.com >> > ipa service-add HTTP/service.example.com >> > ipa service-add-hosts HTTP/service.example.com --hosts=srv1.example.com >> >> Then request the certificate on srv1 : >> > ipa-getcert request -r -f /etc/pki/certs/service.example.com.crt -k >> /etc/pki/private/service.example.com.key -N CN=service.example.com -D >> service.example.com -K HTTP/service.example.com >> >> It work pretty well. But if I add the second server that way : >> > ... >> > ipa host-add-managedby service.example.com >> --hosts=srv1.example.com,srv2.example.com >> > ... >> > ipa service-add-hosts HTTP/service.example.com >> --hosts=srv1.example.com,srv2.example.com >> >> I can only resquest the certificate on one of the servers. The first >> request is going well (no matter on which server I do it) and the second >> is stuck in this state : >> >> Request ID '20140107165415': >> status: CA_REJECTED >> ca-error: Server denied our request, giving up: 2100 (RPC >> failed at server. Insufficient access: not allowed to perform this >> command). >> stuck: yes >> key pair storage: >> type=FILE,location='/etc/pki/private/service.example.com.key' >> certificate: >> type=FILE,location='/etc/pki/certs/service.example.com.crt' >> CA: IPA >> ... >> >> Is this a normal behavior? >> >> If yes, what could be the right way to achieve what I want? >> >> Regards, > > The problem is you would have two separate, valid certificates for the same > service and we only store one at a time. The second request is going to try to > revoke the original cert in order to issue another one. I'm guessing it is > failing on the revocation step. > > I think you'll need to pick one server to manage it and manually copy it to > any other servers. This loses the advantage of certmonger on the other boxes > unfortunately. I think that 'the right approach' is to issue separate certificates for srv1.example.com and srv2.example.com and add SAN (Subject Alternative Name) cn=service.example.com to both of them. See http://en.wikipedia.org/wiki/SubjectAltName I'm not sure how to get such certificate from FreeIPA. Rob, could you add some details? -- Petr^2 Spacek From rcritten at redhat.com Tue Jan 7 18:40:03 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 07 Jan 2014 13:40:03 -0500 Subject: [Freeipa-users] Get certificate for virtual host on many hosts In-Reply-To: <52CC4861.4090301@redhat.com> References: <52CC3C51.6070000@lyra-network.com> <52CC3FCF.9080802@lyra-network.com> <52CC4593.8050802@redhat.com> <52CC4861.4090301@redhat.com> Message-ID: <52CC4A03.6080608@redhat.com> Petr Spacek wrote: > On 7.1.2014 19:21, Rob Crittenden wrote: >> Benjamin Soriano wrote: >>> Hello all, >>> >>> Here is the situation. I have a web service (reachable via >>> service.example.com) that run on two servers (srv1.example.com and >>> srv2.example.com). The load is distributed on servers by a DNS round >>> robin. >>> And I want the certificate for https://service.example.com be managed by >>> IPA (which is my root CA) and take advantage of certificate monitoring. >>> The two servers are registered in IPA and can request their own >>> certificate. >>> >>> I manage to request the certificate on one of the servers by doing the >>> following : >>> >>> Create fake host on ds.example.com >>> > ipa host-add service.example.com >>> > ipa host-add-managedby service.example.com --hosts=srv1.example.com >>> > ipa service-add HTTP/service.example.com >>> > ipa service-add-hosts HTTP/service.example.com >>> --hosts=srv1.example.com >>> >>> Then request the certificate on srv1 : >>> > ipa-getcert request -r -f /etc/pki/certs/service.example.com.crt -k >>> /etc/pki/private/service.example.com.key -N CN=service.example.com -D >>> service.example.com -K HTTP/service.example.com >>> >>> It work pretty well. But if I add the second server that way : >>> > ... >>> > ipa host-add-managedby service.example.com >>> --hosts=srv1.example.com,srv2.example.com >>> > ... >>> > ipa service-add-hosts HTTP/service.example.com >>> --hosts=srv1.example.com,srv2.example.com >>> >>> I can only resquest the certificate on one of the servers. The first >>> request is going well (no matter on which server I do it) and the second >>> is stuck in this state : >>> >>> Request ID '20140107165415': >>> status: CA_REJECTED >>> ca-error: Server denied our request, giving up: 2100 (RPC >>> failed at server. Insufficient access: not allowed to perform this >>> command). >>> stuck: yes >>> key pair storage: >>> type=FILE,location='/etc/pki/private/service.example.com.key' >>> certificate: >>> type=FILE,location='/etc/pki/certs/service.example.com.crt' >>> CA: IPA >>> ... >>> >>> Is this a normal behavior? >>> >>> If yes, what could be the right way to achieve what I want? >>> >>> Regards, >> >> The problem is you would have two separate, valid certificates for the >> same >> service and we only store one at a time. The second request is going >> to try to >> revoke the original cert in order to issue another one. I'm guessing >> it is >> failing on the revocation step. >> >> I think you'll need to pick one server to manage it and manually copy >> it to >> any other servers. This loses the advantage of certmonger on the other >> boxes >> unfortunately. > > I think that 'the right approach' is to issue separate certificates for > srv1.example.com and srv2.example.com and add SAN (Subject Alternative > Name) cn=service.example.com to both of them. > > See > http://en.wikipedia.org/wiki/SubjectAltName > > I'm not sure how to get such certificate from FreeIPA. Rob, could you > add some details? > Not currently possible, see https://fedorahosted.org/freeipa/ticket/3977 rob From pspacek at redhat.com Tue Jan 7 18:43:01 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 07 Jan 2014 19:43:01 +0100 Subject: [Freeipa-users] Get certificate for virtual host on many hosts In-Reply-To: <52CC4A03.6080608@redhat.com> References: <52CC3C51.6070000@lyra-network.com> <52CC3FCF.9080802@lyra-network.com> <52CC4593.8050802@redhat.com> <52CC4861.4090301@redhat.com> <52CC4A03.6080608@redhat.com> Message-ID: <52CC4AB5.7070904@redhat.com> On 7.1.2014 19:40, Rob Crittenden wrote: > Petr Spacek wrote: >> On 7.1.2014 19:21, Rob Crittenden wrote: >>> Benjamin Soriano wrote: >>>> Hello all, >>>> >>>> Here is the situation. I have a web service (reachable via >>>> service.example.com) that run on two servers (srv1.example.com and >>>> srv2.example.com). The load is distributed on servers by a DNS round >>>> robin. >>>> And I want the certificate for https://service.example.com be managed by >>>> IPA (which is my root CA) and take advantage of certificate monitoring. >>>> The two servers are registered in IPA and can request their own >>>> certificate. >>>> >>>> I manage to request the certificate on one of the servers by doing the >>>> following : >>>> >>>> Create fake host on ds.example.com >>>> > ipa host-add service.example.com >>>> > ipa host-add-managedby service.example.com --hosts=srv1.example.com >>>> > ipa service-add HTTP/service.example.com >>>> > ipa service-add-hosts HTTP/service.example.com >>>> --hosts=srv1.example.com >>>> >>>> Then request the certificate on srv1 : >>>> > ipa-getcert request -r -f /etc/pki/certs/service.example.com.crt -k >>>> /etc/pki/private/service.example.com.key -N CN=service.example.com -D >>>> service.example.com -K HTTP/service.example.com >>>> >>>> It work pretty well. But if I add the second server that way : >>>> > ... >>>> > ipa host-add-managedby service.example.com >>>> --hosts=srv1.example.com,srv2.example.com >>>> > ... >>>> > ipa service-add-hosts HTTP/service.example.com >>>> --hosts=srv1.example.com,srv2.example.com >>>> >>>> I can only resquest the certificate on one of the servers. The first >>>> request is going well (no matter on which server I do it) and the second >>>> is stuck in this state : >>>> >>>> Request ID '20140107165415': >>>> status: CA_REJECTED >>>> ca-error: Server denied our request, giving up: 2100 (RPC >>>> failed at server. Insufficient access: not allowed to perform this >>>> command). >>>> stuck: yes >>>> key pair storage: >>>> type=FILE,location='/etc/pki/private/service.example.com.key' >>>> certificate: >>>> type=FILE,location='/etc/pki/certs/service.example.com.crt' >>>> CA: IPA >>>> ... >>>> >>>> Is this a normal behavior? >>>> >>>> If yes, what could be the right way to achieve what I want? >>>> >>>> Regards, >>> >>> The problem is you would have two separate, valid certificates for the >>> same >>> service and we only store one at a time. The second request is going >>> to try to >>> revoke the original cert in order to issue another one. I'm guessing >>> it is >>> failing on the revocation step. >>> >>> I think you'll need to pick one server to manage it and manually copy >>> it to >>> any other servers. This loses the advantage of certmonger on the other >>> boxes >>> unfortunately. >> >> I think that 'the right approach' is to issue separate certificates for >> srv1.example.com and srv2.example.com and add SAN (Subject Alternative >> Name) cn=service.example.com to both of them. >> >> See >> http://en.wikipedia.org/wiki/SubjectAltName >> >> I'm not sure how to get such certificate from FreeIPA. Rob, could you >> add some details? >> > > Not currently possible, see https://fedorahosted.org/freeipa/ticket/3977 Benjamin, you are lucky. It is planed for FreeIPA 3.4 and the patch is on review :-) -- Petr^2 Spacek From jhrozek at redhat.com Tue Jan 7 20:14:09 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 7 Jan 2014 21:14:09 +0100 Subject: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain. In-Reply-To: References: <52C5DA93.8080601@redhat.com> <52C5DF52.1010901@redhat.com> <20140103112056.GE26958@hendrix.brq.redhat.com> <20140106083224.GD3455@hendrix.redhat.com> Message-ID: <20140107201409.GB19219@hendrix.redhat.com> On Tue, Jan 07, 2014 at 12:00:56AM +0200, Genadi Postrilko wrote: > sssd_example.com.log after changing the debug level: > https://gist.github.com/anonymous/8290381#file-sssd_example-com-log This info from the log: (Mon Jan 6 13:23:11 2014) [sssd[be[example.com]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Operations error(1), (null) (Mon Jan 6 13:23:11 2014) [sssd[be[example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed Plus the wbinfo output below indicates that you are seeing a similar kind of error as the user in thread called "AD - Freeipa trust confusion". Would you mind getting the same debug information on the IPA server? In short, set "smbcontrol winbindd debug 10", run the testcase, then revert the debug level. Feel free to chek the other thread for some more details on debugging.. > > [genadi at ipaserver root]$ wbinfo -u > (no output) > > [genadi at ipaserver root]$ wbinfo -g > admins > editors > default smb group > ad_users > ad_admins > > [genadi at ipaserver root]$ wbinfo --trusted-domains > BUILTIN > EXAMPLE > ADDC > > [genadi at ipaserver root]$ wbinfo -i Administrator > failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND > Could not get info for user Administrator > > [genadi at ipaserver root]$ wbinfo --domain-info ADDC.COM > Name : ADDC > Alt_Name : addc.com > SID : S-1-5-21-33789592-1708006097-2663368750 > Active Directory : No > Native : No > Primary : No > > > > > > 2014/1/6 Jakub Hrozek > > > On Fri, Jan 03, 2014 at 07:29:54PM +0200, Genadi Postrilko wrote: > > > Here are the other logs as well (ldap_child.log, sssd_pac.log, > > > sssd_ssh.log). > > > > > > https://gist.github.com/anonymous/8242061 > > > > > > I attempted to log in (as Administrator at ADDC.COM) at 9:04. > > > > > > Thanks for the help. > > > > > > > You need the *domain* log. According to the logs, your domain is called > > example.com, do you need to put debug_level=6 (or higher, but 6 should > > be enough) to the section called [domain/example.com] in sssd.conf, > > restart sssd, attempt the login and then attach > > /var/log/sssd/sssd_example.com.log > > > > Given that SSSD is complaining about not being able to find the user, I > > suspect a similar problem as in the other thread, that is, Winbind on > > the server not being able to talk to the AD. Does "wbinfo -u $user" work > > on the server? > > From benjamin.soriano at lyra-network.com Wed Jan 8 08:51:07 2014 From: benjamin.soriano at lyra-network.com (Benjamin Soriano) Date: Wed, 08 Jan 2014 09:51:07 +0100 Subject: [Freeipa-users] Get certificate for virtual host on many hosts In-Reply-To: <52CC4AB5.7070904@redhat.com> References: <52CC3C51.6070000@lyra-network.com> <52CC3FCF.9080802@lyra-network.com> <52CC4593.8050802@redhat.com> <52CC4861.4090301@redhat.com> <52CC4A03.6080608@redhat.com> <52CC4AB5.7070904@redhat.com> Message-ID: <52CD117B.10509@lyra-network.com> Le 07/01/2014 19:43, Petr Spacek a ?crit : > On 7.1.2014 19:40, Rob Crittenden wrote: >> Petr Spacek wrote: >>> On 7.1.2014 19:21, Rob Crittenden wrote: >>>> Benjamin Soriano wrote: >>>>> Hello all, >>>>> >>>>> Here is the situation. I have a web service (reachable via >>>>> service.example.com) that run on two servers (srv1.example.com and >>>>> srv2.example.com). The load is distributed on servers by a DNS round >>>>> robin. >>>>> And I want the certificate for https://service.example.com be >>>>> managed by >>>>> IPA (which is my root CA) and take advantage of certificate >>>>> monitoring. >>>>> The two servers are registered in IPA and can request their own >>>>> certificate. >>>>> >>>>> I manage to request the certificate on one of the servers by doing >>>>> the >>>>> following : >>>>> >>>>> Create fake host on ds.example.com >>>>> > ipa host-add service.example.com >>>>> > ipa host-add-managedby service.example.com >>>>> --hosts=srv1.example.com >>>>> > ipa service-add HTTP/service.example.com >>>>> > ipa service-add-hosts HTTP/service.example.com >>>>> --hosts=srv1.example.com >>>>> >>>>> Then request the certificate on srv1 : >>>>> > ipa-getcert request -r -f >>>>> /etc/pki/certs/service.example.com.crt -k >>>>> /etc/pki/private/service.example.com.key -N CN=service.example.com -D >>>>> service.example.com -K HTTP/service.example.com >>>>> >>>>> It work pretty well. But if I add the second server that way : >>>>> > ... >>>>> > ipa host-add-managedby service.example.com >>>>> --hosts=srv1.example.com,srv2.example.com >>>>> > ... >>>>> > ipa service-add-hosts HTTP/service.example.com >>>>> --hosts=srv1.example.com,srv2.example.com >>>>> >>>>> I can only resquest the certificate on one of the servers. The first >>>>> request is going well (no matter on which server I do it) and the >>>>> second >>>>> is stuck in this state : >>>>> >>>>> Request ID '20140107165415': >>>>> status: CA_REJECTED >>>>> ca-error: Server denied our request, giving up: 2100 (RPC >>>>> failed at server. Insufficient access: not allowed to perform this >>>>> command). >>>>> stuck: yes >>>>> key pair storage: >>>>> type=FILE,location='/etc/pki/private/service.example.com.key' >>>>> certificate: >>>>> type=FILE,location='/etc/pki/certs/service.example.com.crt' >>>>> CA: IPA >>>>> ... >>>>> >>>>> Is this a normal behavior? >>>>> >>>>> If yes, what could be the right way to achieve what I want? >>>>> >>>>> Regards, >>>> >>>> The problem is you would have two separate, valid certificates for the >>>> same >>>> service and we only store one at a time. The second request is going >>>> to try to >>>> revoke the original cert in order to issue another one. I'm guessing >>>> it is >>>> failing on the revocation step. >>>> >>>> I think you'll need to pick one server to manage it and manually copy >>>> it to >>>> any other servers. This loses the advantage of certmonger on the other >>>> boxes >>>> unfortunately. >>> >>> I think that 'the right approach' is to issue separate certificates for >>> srv1.example.com and srv2.example.com and add SAN (Subject Alternative >>> Name) cn=service.example.com to both of them. >>> >>> See >>> http://en.wikipedia.org/wiki/SubjectAltName >>> >>> I'm not sure how to get such certificate from FreeIPA. Rob, could you >>> add some details? >>> >> >> Not currently possible, see https://fedorahosted.org/freeipa/ticket/3977 > > Benjamin, you are lucky. It is planed for FreeIPA 3.4 and the patch is > on review :-) > Indeed, lucky me. Thanks a lot guys! -- Benjamin soriano From simo at redhat.com Wed Jan 8 14:25:53 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 08 Jan 2014 09:25:53 -0500 Subject: [Freeipa-users] Get certificate for virtual host on many hosts In-Reply-To: <52CD117B.10509@lyra-network.com> References: <52CC3C51.6070000@lyra-network.com> <52CC3FCF.9080802@lyra-network.com> <52CC4593.8050802@redhat.com> <52CC4861.4090301@redhat.com> <52CC4A03.6080608@redhat.com> <52CC4AB5.7070904@redhat.com> <52CD117B.10509@lyra-network.com> Message-ID: <1389191153.26102.155.camel@willson.li.ssimo.org> On Wed, 2014-01-08 at 09:51 +0100, Benjamin Soriano wrote: > Le 07/01/2014 19:43, Petr Spacek a ?crit : > > On 7.1.2014 19:40, Rob Crittenden wrote: > >> Petr Spacek wrote: > >>> On 7.1.2014 19:21, Rob Crittenden wrote: > >>>> Benjamin Soriano wrote: > >>>>> Hello all, > >>>>> > >>>>> Here is the situation. I have a web service (reachable via > >>>>> service.example.com) that run on two servers (srv1.example.com and > >>>>> srv2.example.com). The load is distributed on servers by a DNS round > >>>>> robin. > >>>>> And I want the certificate for https://service.example.com be > >>>>> managed by > >>>>> IPA (which is my root CA) and take advantage of certificate > >>>>> monitoring. > >>>>> The two servers are registered in IPA and can request their own > >>>>> certificate. > >>>>> > >>>>> I manage to request the certificate on one of the servers by doing > >>>>> the > >>>>> following : > >>>>> > >>>>> Create fake host on ds.example.com > >>>>> > ipa host-add service.example.com > >>>>> > ipa host-add-managedby service.example.com > >>>>> --hosts=srv1.example.com > >>>>> > ipa service-add HTTP/service.example.com > >>>>> > ipa service-add-hosts HTTP/service.example.com > >>>>> --hosts=srv1.example.com > >>>>> > >>>>> Then request the certificate on srv1 : > >>>>> > ipa-getcert request -r -f > >>>>> /etc/pki/certs/service.example.com.crt -k > >>>>> /etc/pki/private/service.example.com.key -N CN=service.example.com -D > >>>>> service.example.com -K HTTP/service.example.com > >>>>> > >>>>> It work pretty well. But if I add the second server that way : > >>>>> > ... > >>>>> > ipa host-add-managedby service.example.com > >>>>> --hosts=srv1.example.com,srv2.example.com > >>>>> > ... > >>>>> > ipa service-add-hosts HTTP/service.example.com > >>>>> --hosts=srv1.example.com,srv2.example.com > >>>>> > >>>>> I can only resquest the certificate on one of the servers. The first > >>>>> request is going well (no matter on which server I do it) and the > >>>>> second > >>>>> is stuck in this state : > >>>>> > >>>>> Request ID '20140107165415': > >>>>> status: CA_REJECTED > >>>>> ca-error: Server denied our request, giving up: 2100 (RPC > >>>>> failed at server. Insufficient access: not allowed to perform this > >>>>> command). > >>>>> stuck: yes > >>>>> key pair storage: > >>>>> type=FILE,location='/etc/pki/private/service.example.com.key' > >>>>> certificate: > >>>>> type=FILE,location='/etc/pki/certs/service.example.com.crt' > >>>>> CA: IPA > >>>>> ... > >>>>> > >>>>> Is this a normal behavior? > >>>>> > >>>>> If yes, what could be the right way to achieve what I want? > >>>>> > >>>>> Regards, > >>>> > >>>> The problem is you would have two separate, valid certificates for the > >>>> same > >>>> service and we only store one at a time. The second request is going > >>>> to try to > >>>> revoke the original cert in order to issue another one. I'm guessing > >>>> it is > >>>> failing on the revocation step. > >>>> > >>>> I think you'll need to pick one server to manage it and manually copy > >>>> it to > >>>> any other servers. This loses the advantage of certmonger on the other > >>>> boxes > >>>> unfortunately. > >>> > >>> I think that 'the right approach' is to issue separate certificates for > >>> srv1.example.com and srv2.example.com and add SAN (Subject Alternative > >>> Name) cn=service.example.com to both of them. > >>> > >>> See > >>> http://en.wikipedia.org/wiki/SubjectAltName > >>> > >>> I'm not sure how to get such certificate from FreeIPA. Rob, could you > >>> add some details? > >>> > >> > >> Not currently possible, see https://fedorahosted.org/freeipa/ticket/3977 > > > > Benjamin, you are lucky. It is planed for FreeIPA 3.4 and the patch is > > on review :-) > > > Indeed, lucky me. Thanks a lot guys! Benjamin, in the meanwhile, if you can use SNI on your servers, you could simply get an additional certificate for service.example.com for IPA, and copy it on both machines, then configure 2 sites that expose the same data. (easy if you use something like apache or nginx). Once the feature becomes available you can replace all the certs with 2 new certs with common alt name. Simo. -- Simo Sorce * Red Hat, Inc * New York From orion at cora.nwra.com Wed Jan 8 18:16:40 2014 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 08 Jan 2014 11:16:40 -0700 Subject: [Freeipa-users] Updated doc, synchronization question Message-ID: <52CD9608.7090404@cora.nwra.com> Two questions: - Any ETA on an updated 3.3.3 Users Guide? - Is AD/IPA synchronization still supported in 3.3.3? Will it always? Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com/ From t.sailer at alumni.ethz.ch Wed Jan 8 18:31:52 2014 From: t.sailer at alumni.ethz.ch (Thomas Sailer) Date: Wed, 08 Jan 2014 19:31:52 +0100 Subject: [Freeipa-users] Upgrading freeipa server from f18 to f20 In-Reply-To: <52CC081A.8030006@alumni.ethz.ch> References: <52BFFC26.109@alumni.ethz.ch> <1388328582.26102.4.camel@willson.li.ssimo.org> <52CC081A.8030006@alumni.ethz.ch> Message-ID: <52CD9998.7080302@alumni.ethz.ch> Trying to install the replica on a Fedora 18 machine gives me a slightly more verbose error message: Unexpected error - see /var/log/ipareplica-install.log for details: DatabaseError: Constraint violation: pre-hashed passwords are not valid arguments: entry=cn=replication manager,cn=config: [('objectclass', ['top', 'person']), ('userpassword', ['XXXX']), (u'cn', ['replication manager']), ('sn', ['replication manager pseudo user'])] This entry doesn't look wrong to me, the slapd log below seems to indicate that adding this entry worked. Could someone give me a hint how to fix this or where to look at? Thanks, Thomas [08/Jan/2014:17:51:01 +0100] conn=2 op=0 BIND dn="cn=directory manager" method=128 version=3 [08/Jan/2014:17:51:01 +0100] conn=2 op=1 SRCH base="cn=config,cn=ldbm database,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" attrs="nsslapd-directory" [08/Jan/2014:17:51:01 +0100] conn=2 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [08/Jan/2014:17:51:01 +0100] conn=2 op=2 SRCH base="cn=schema" scope=0 filter="(objectClass=*)" attrs="attributeTypes objectClasses" [08/Jan/2014:17:51:01 +0100] conn=2 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [08/Jan/2014:17:51:01 +0100] conn=2 op=2 RESULT err=0 tag=101 nentries=1 etime=0 [08/Jan/2014:17:51:01 +0100] conn=2 op=3 SRCH base="cn=replica,cn=dc\3Dxxxx\2Cdc\3Dcom,cn=mapping tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL [08/Jan/2014:17:51:01 +0100] conn=2 op=3 RESULT err=32 tag=101 nentries=0 etime=0 [08/Jan/2014:17:51:01 +0100] conn=2 op=4 ADD dn="cn=replication manager,cn=config" [08/Jan/2014:17:51:01 +0100] conn=2 op=4 RESULT err=0 tag=105 nentries=0 etime=0 [08/Jan/2014:17:51:01 +0100] conn=2 op=5 SRCH base="cn=replica,cn=dc\3Dxxxx\2Cdc\3Dcom,cn=mapping tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL [08/Jan/2014:17:51:01 +0100] conn=2 op=5 RESULT err=32 tag=101 nentries=0 etime=0 [08/Jan/2014:17:51:01 +0100] conn=2 op=6 ADD dn="cn=replica,cn=dc\3Dxxxx\2Cdc\3Dcom,cn=mapping tree,cn=config" [08/Jan/2014:17:51:02 +0100] conn=2 op=7 ADD dn="cn=changelog5,cn=config" [08/Jan/2014:17:51:02 +0100] conn=2 op=7 RESULT err=0 tag=105 nentries=0 etime=0 [08/Jan/2014:17:51:02 +0100] conn=2 op=6 RESULT err=0 tag=105 nentries=0 etime=1 [08/Jan/2014:17:51:02 +0100] conn=2 op=8 UNBIND [08/Jan/2014:17:51:02 +0100] conn=2 op=8 fd=64 closed - U1 From rchase at cs.vt.edu Wed Jan 8 20:12:35 2014 From: rchase at cs.vt.edu (Ryan Chase) Date: Wed, 08 Jan 2014 15:12:35 -0500 Subject: [Freeipa-users] trouble adding users Message-ID: <52CDB133.8060002@cs.vt.edu> I've added a new user using the command "ipa user-add" from the ipa server. I can see correct user information when I run the commands "ipa user-show" and "ipa user-status". However, I cannot see the user when I run "getent passwd username" or even "id username". When I run "id username" I get, "no such user". I feel this may be an issue with sssd, but I'm not 100% sure. /etc/nsswitch.conf looks correct. Any ideas? --Ryan IPA server is CentOS 6 running freeipa version 3.0.0 From jhrozek at redhat.com Wed Jan 8 22:25:05 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 8 Jan 2014 23:25:05 +0100 Subject: [Freeipa-users] trouble adding users In-Reply-To: <52CDB133.8060002@cs.vt.edu> References: <52CDB133.8060002@cs.vt.edu> Message-ID: <20140108222505.GJ10918@hendrix.brq.redhat.com> On Wed, Jan 08, 2014 at 03:12:35PM -0500, Ryan Chase wrote: > I've added a new user using the command "ipa user-add" from the ipa > server. I can see correct user information when I run the commands > "ipa user-show" and "ipa user-status". However, I cannot see the > user when I run "getent passwd username" or even "id username". When > I run "id username" I get, "no such user". > I feel this may be an issue with sssd, but I'm not 100% sure. > /etc/nsswitch.conf looks correct. > Any ideas? > > --Ryan > > IPA server is CentOS 6 running freeipa version 3.0.0 Hi Ryan, this indeed sounds like an issue with the SSSD. Given that you said nsswitch.conf looks OK, can you raise debug_level (let's start with 5 perhaps) in the [nss] and [domain/] sections, restart the SSSD and inspect the logs in /var/log/sssd/ for any errors? Is there anything in the syslog? Some errors, like invalid keytab are logged to the system logs as well as the SSSD debug logs. From t.sailer at alumni.ethz.ch Thu Jan 9 11:22:47 2014 From: t.sailer at alumni.ethz.ch (Thomas Sailer) Date: Thu, 09 Jan 2014 12:22:47 +0100 Subject: [Freeipa-users] Upgrading freeipa server from f18 to f20 In-Reply-To: <52CD9998.7080302@alumni.ethz.ch> References: <52BFFC26.109@alumni.ethz.ch> <1388328582.26102.4.camel@willson.li.ssimo.org> <52CC081A.8030006@alumni.ethz.ch> <52CD9998.7080302@alumni.ethz.ch> Message-ID: <52CE8687.50505@alumni.ethz.ch> Here's the corresponding log (from another attempt, thus the differing timestamps) of the server slapd: [09/Jan/2014:12:19:35 +0100] conn=375 fd=73 slot=73 connection from a.b.c.d to e.f.g.h [09/Jan/2014:12:19:35 +0100] conn=375 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [09/Jan/2014:12:19:35 +0100] conn=375 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [09/Jan/2014:12:19:35 +0100] conn=375 SSL 256-bit AES [09/Jan/2014:12:19:35 +0100] conn=375 op=1 BIND dn="cn=Directory Manager" method=128 version=3 [09/Jan/2014:12:19:35 +0100] conn=375 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [09/Jan/2014:12:19:35 +0100] conn=375 op=2 SRCH base="cn=config,cn=ldbm database,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" attrs="nsslapd-directory" [09/Jan/2014:12:19:35 +0100] conn=375 op=2 RESULT err=0 tag=101 nentries=1 etime=0 [09/Jan/2014:12:19:35 +0100] conn=375 op=3 SRCH base="cn=schema" scope=0 filter="(objectClass=*)" attrs="attributeTypes objectClasses" [09/Jan/2014:12:19:36 +0100] conn=375 op=3 RESULT err=0 tag=101 nentries=1 etime=1 [09/Jan/2014:12:19:36 +0100] conn=375 op=4 SRCH base="cn=replication,cn=etc,dc=axsem,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [09/Jan/2014:12:19:36 +0100] conn=375 op=4 RESULT err=0 tag=101 nentries=1 etime=0 [09/Jan/2014:12:19:36 +0100] conn=375 op=5 MOD dn="cn=replication,cn=etc,dc=xxxx,dc=com" [09/Jan/2014:12:19:36 +0100] conn=375 op=5 RESULT err=0 tag=103 nentries=0 etime=0 csn=52ce8617000000040000 [09/Jan/2014:12:19:36 +0100] conn=375 op=6 SRCH base="cn=replica,cn=dc\3Dxxxx\2Cdc\3Dcom,cn=mapping tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL [09/Jan/2014:12:19:36 +0100] conn=375 op=6 RESULT err=0 tag=101 nentries=1 etime=0 [09/Jan/2014:12:19:36 +0100] conn=375 op=7 ADD dn="cn=replication manager,cn=config" [09/Jan/2014:12:19:36 +0100] conn=375 op=7 RESULT err=19 tag=105 nentries=0 etime=0 [09/Jan/2014:12:19:36 +0100] conn=375 op=8 UNBIND [09/Jan/2014:12:19:36 +0100] conn=375 op=8 fd=73 closed - U1 I don't have cn=replication manager,cn=config, should I? When I manually try to create this entry like this (ldapvi syntax), I get: add cn=replication manager,cn=config objectClass: inetorgperson objectClass: person objectClass: top cn: replication manager sn: RM userPassword: password passwordExpirationTime: 20380119031407Z ldap_add: Constraint violation (19) additional info: pre-hashed passwords are not valid Why is that? From mkosek at redhat.com Thu Jan 9 13:07:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 Jan 2014 14:07:34 +0100 Subject: [Freeipa-users] Updated doc, synchronization question In-Reply-To: <52CD9608.7090404@cora.nwra.com> References: <52CD9608.7090404@cora.nwra.com> Message-ID: <52CE9F16.4020507@redhat.com> On 01/08/2014 07:16 PM, Orion Poplawski wrote: > Two questions: > > - Any ETA on an updated 3.3.3 Users Guide? Our current plan is to release next documentation release along with FreeIPA 3.4, when more documentation fixes are factored in. Just in case you would like to check the most recent status of the documentation work (or even help us with it), this page describes the details http://www.freeipa.org/page/Contribute/Documentation including instructions how to build HTMLs out of our git tree. > - Is AD/IPA synchronization still supported in 3.3.3? Will it always? The AD/IPA synchronization is supported only in terms in bug fixes. As for the enhancements, the FreeIPA core team is focusing on the AD trusts: http://www.freeipa.org/page/Trusts (That does not mean we are not open to contributions from the community) Martin From mkosek at redhat.com Thu Jan 9 13:55:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 Jan 2014 14:55:04 +0100 Subject: [Freeipa-users] Upgrading freeipa server from f18 to f20 In-Reply-To: <52CE8687.50505@alumni.ethz.ch> References: <52BFFC26.109@alumni.ethz.ch> <1388328582.26102.4.camel@willson.li.ssimo.org> <52CC081A.8030006@alumni.ethz.ch> <52CD9998.7080302@alumni.ethz.ch> <52CE8687.50505@alumni.ethz.ch> Message-ID: <52CEAA38.6000103@redhat.com> On 01/09/2014 12:22 PM, Thomas Sailer wrote: > Here's the corresponding log (from another attempt, thus the differing > timestamps) of the server slapd: > > [09/Jan/2014:12:19:35 +0100] conn=375 fd=73 slot=73 connection from a.b.c.d to > e.f.g.h > [09/Jan/2014:12:19:35 +0100] conn=375 op=0 EXT oid="1.3.6.1.4.1.1466.20037" > name="startTLS" > [09/Jan/2014:12:19:35 +0100] conn=375 op=0 RESULT err=0 tag=120 nentries=0 etime=0 > [09/Jan/2014:12:19:35 +0100] conn=375 SSL 256-bit AES > [09/Jan/2014:12:19:35 +0100] conn=375 op=1 BIND dn="cn=Directory Manager" > method=128 version=3 > [09/Jan/2014:12:19:35 +0100] conn=375 op=1 RESULT err=0 tag=97 nentries=0 > etime=0 dn="cn=directory manager" > [09/Jan/2014:12:19:35 +0100] conn=375 op=2 SRCH base="cn=config,cn=ldbm > database,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" > attrs="nsslapd-directory" > [09/Jan/2014:12:19:35 +0100] conn=375 op=2 RESULT err=0 tag=101 nentries=1 etime=0 > [09/Jan/2014:12:19:35 +0100] conn=375 op=3 SRCH base="cn=schema" scope=0 > filter="(objectClass=*)" attrs="attributeTypes objectClasses" > [09/Jan/2014:12:19:36 +0100] conn=375 op=3 RESULT err=0 tag=101 nentries=1 etime=1 > [09/Jan/2014:12:19:36 +0100] conn=375 op=4 SRCH > base="cn=replication,cn=etc,dc=axsem,dc=com" scope=0 filter="(objectClass=*)" > attrs=ALL > [09/Jan/2014:12:19:36 +0100] conn=375 op=4 RESULT err=0 tag=101 nentries=1 etime=0 > [09/Jan/2014:12:19:36 +0100] conn=375 op=5 MOD > dn="cn=replication,cn=etc,dc=xxxx,dc=com" > [09/Jan/2014:12:19:36 +0100] conn=375 op=5 RESULT err=0 tag=103 nentries=0 > etime=0 csn=52ce8617000000040000 > [09/Jan/2014:12:19:36 +0100] conn=375 op=6 SRCH > base="cn=replica,cn=dc\3Dxxxx\2Cdc\3Dcom,cn=mapping tree,cn=config" scope=0 > filter="(objectClass=*)" attrs=ALL > [09/Jan/2014:12:19:36 +0100] conn=375 op=6 RESULT err=0 tag=101 nentries=1 etime=0 > [09/Jan/2014:12:19:36 +0100] conn=375 op=7 ADD dn="cn=replication > manager,cn=config" > [09/Jan/2014:12:19:36 +0100] conn=375 op=7 RESULT err=19 tag=105 nentries=0 > etime=0 > [09/Jan/2014:12:19:36 +0100] conn=375 op=8 UNBIND > [09/Jan/2014:12:19:36 +0100] conn=375 op=8 fd=73 closed - U1 > > I don't have cn=replication manager,cn=config, should I? You don't. This temporary user is automatically created by ipa-replica-install to bootstrap the replication agreements. It should be deleted afterwards. > > When I manually try to create this entry like this (ldapvi syntax), I get: > > add cn=replication manager,cn=config > objectClass: inetorgperson > objectClass: person > objectClass: top > cn: replication manager > sn: RM > userPassword: password > passwordExpirationTime: 20380119031407Z > > ldap_add: Constraint violation (19) > additional info: pre-hashed passwords are not valid > > Why is that? I really wonder why you get this error (maybe because of the downgrade?), I did not see such case yet. It is hitting a check in our password plugin which needs user passwords in clear text to be able to properly check them. In your case, password should be the DM password and it is given for ipa-replica-install in clear. You could, however, try temporarily switching: ipa config-mod --enable-migration=1 on the master machine to disable this check and see if the installation continues or not. Martin From rchase at cs.vt.edu Thu Jan 9 15:14:20 2014 From: rchase at cs.vt.edu (Ryan Chase) Date: Thu, 09 Jan 2014 10:14:20 -0500 Subject: [Freeipa-users] trouble adding users In-Reply-To: <20140108222505.GJ10918@hendrix.brq.redhat.com> References: <52CDB133.8060002@cs.vt.edu> <20140108222505.GJ10918@hendrix.brq.redhat.com> Message-ID: <52CEBCCC.6000401@cs.vt.edu> On 1/8/14 5:25 PM, Jakub Hrozek wrote: > On Wed, Jan 08, 2014 at 03:12:35PM -0500, Ryan Chase wrote: >> I've added a new user using the command "ipa user-add" from the ipa >> server. I can see correct user information when I run the commands >> "ipa user-show" and "ipa user-status". However, I cannot see the >> user when I run "getent passwd username" or even "id username". When >> I run "id username" I get, "no such user". >> I feel this may be an issue with sssd, but I'm not 100% sure. >> /etc/nsswitch.conf looks correct. >> Any ideas? >> >> --Ryan >> >> IPA server is CentOS 6 running freeipa version 3.0.0 > > Hi Ryan, > > this indeed sounds like an issue with the SSSD. > > Given that you said nsswitch.conf looks OK, can you raise debug_level > (let's start with 5 perhaps) in the [nss] and [domain/] sections, > restart the SSSD and inspect the logs in /var/log/sssd/ for any errors? > > Is there anything in the syslog? Some errors, like invalid keytab are > logged to the system logs as well as the SSSD debug logs. > Below is a snip from the sssd log with debug_level=5 This was an ssh attempt to the server. (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=username] (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [be_get_account_info] (0x0100): Request processed. Returned 1,11,Fast reply - offline (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [get_port_status] (0x0100): Reseting the status of port 0 for server 'server.csl.local' (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [be_resolve_server_process] (0x0200): Found address for server server.csl.local: [10.0.0.1] TTL 7200 (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [be_resolve_server_process] (0x0200): Found address for server server.csl.local: [10.0.0.1] TTL 7200 (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address] (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'server.csl.local' as 'not working' (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [fo_resolve_service_send] (0x0020): No available servers for service 'IPA' (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [child_sig_handler] (0x0100): child [16458] finished successfully. (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error]) (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks. (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [remove_krb5_info_files] (0x0200): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.CSL.LOCAL], [2][No such file or directory] From t.sailer at alumni.ethz.ch Thu Jan 9 15:15:55 2014 From: t.sailer at alumni.ethz.ch (Thomas Sailer) Date: Thu, 09 Jan 2014 16:15:55 +0100 Subject: [Freeipa-users] Upgrading freeipa server from f18 to f20 In-Reply-To: <52CEAA38.6000103@redhat.com> References: <52BFFC26.109@alumni.ethz.ch> <1388328582.26102.4.camel@willson.li.ssimo.org> <52CC081A.8030006@alumni.ethz.ch> <52CD9998.7080302@alumni.ethz.ch> <52CE8687.50505@alumni.ethz.ch> <52CEAA38.6000103@redhat.com> Message-ID: <52CEBD2B.7070705@alumni.ethz.ch> Hi Martin, > ipa config-mod --enable-migration=1 Thanks! I'm getting farther now. It seems to manage setting up the main directory server, but fails configuring the ca system. Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/17]: creating certificate server user [2/17]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpqX0Uul' returned non-zero exit status 1 2014-01-09T14:53:42Z DEBUG Starting external process 2014-01-09T14:53:42Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpqX0Uul 2014-01-09T14:53:55Z DEBUG Process finished, return code=1 2014-01-09T14:53:55Z DEBUG stdout=Loading deployment configuration from /tmp/tmp qX0Uul. Installing CA into /var/lib/pki/pki-tomcat. Storing deployment configuration into /etc/sysconfig/pki/tomcat/pki-tomcat/ca/de ployment.cfg. Installation failed. 2014-01-09T14:53:55Z DEBUG stderr=pkispawn : WARNING ....... unable to valid ate security domain user/password through REST interface. Interface not availabl e mmap: Invalid argument mmap: Invalid argument mmap: Invalid argument pkispawn : ERROR ....... Exception from Java Configuration Servlet: Failed to obtain installation token from security domain: java.lang.NullPointerException 2014-01-09T14:53:55Z CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpqX0Uul' returned non-zero exit status 1 2014-01-09T14:53:55Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 619, in run_script return_value = main_function() File "/usr/sbin/ipa-replica-install", line 652, in main (CA, cs) = cainstance.install_replica_ca(config, dogtag_master_ds_port) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1809, in install_replica_ca subject_base=config.subject_base) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 625, in configure_instance self.start_creation(runtime=210) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 358, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 744, in __spawn_instance raise RuntimeError('Configuration of CA failed') 2014-01-09T14:53:55Z INFO The ipa-replica-install command failed, exception: RuntimeError: Configuration of CA failed /var/log/pki/pki-tomcat/ca/system: 17875.localhost-startStop-1 - [09/Jan/2014:15:53:52 CET] [3] [3] Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate 17875.localhost-startStop-1 - [09/Jan/2014:15:53:52 CET] [13] [3] authz instance DirAclAuthz initialization failed and skipped, error=Property internaldb.ldapconn.port missing value From jhrozek at redhat.com Thu Jan 9 16:15:10 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 9 Jan 2014 17:15:10 +0100 Subject: [Freeipa-users] trouble adding users In-Reply-To: <52CEBCCC.6000401@cs.vt.edu> References: <52CDB133.8060002@cs.vt.edu> <20140108222505.GJ10918@hendrix.brq.redhat.com> <52CEBCCC.6000401@cs.vt.edu> Message-ID: <20140109161510.GO14699@hendrix.brq.redhat.com> On Thu, Jan 09, 2014 at 10:14:20AM -0500, Ryan Chase wrote: > On 1/8/14 5:25 PM, Jakub Hrozek wrote: > >On Wed, Jan 08, 2014 at 03:12:35PM -0500, Ryan Chase wrote: > >>I've added a new user using the command "ipa user-add" from the ipa > >>server. I can see correct user information when I run the commands > >>"ipa user-show" and "ipa user-status". However, I cannot see the > >>user when I run "getent passwd username" or even "id username". When > >>I run "id username" I get, "no such user". > >> I feel this may be an issue with sssd, but I'm not 100% sure. > >>/etc/nsswitch.conf looks correct. > >> Any ideas? > >> > >>--Ryan > >> > >>IPA server is CentOS 6 running freeipa version 3.0.0 > > > >Hi Ryan, > > > >this indeed sounds like an issue with the SSSD. > > > >Given that you said nsswitch.conf looks OK, can you raise debug_level > >(let's start with 5 perhaps) in the [nss] and [domain/] sections, > >restart the SSSD and inspect the logs in /var/log/sssd/ for any errors? > > > >Is there anything in the syslog? Some errors, like invalid keytab are > >logged to the system logs as well as the SSSD debug logs. > > > > Below is a snip from the sssd log with debug_level=5 > This was an ssh attempt to the server. > This log snippet is telling us about problems with keytab: > (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [sdap_kinit_done] > (0x0100): Could not get TGT: 14 [Bad address] Perhaps /var/log/sssd/ldap_child.log would have more info? Can you kinit with your keytab (kinit -k or kinit -k host/$(hostname)) ? From rchase at cs.vt.edu Thu Jan 9 16:41:33 2014 From: rchase at cs.vt.edu (Ryan Chase) Date: Thu, 09 Jan 2014 11:41:33 -0500 Subject: [Freeipa-users] trouble adding users In-Reply-To: <20140109161510.GO14699@hendrix.brq.redhat.com> References: <52CDB133.8060002@cs.vt.edu> <20140108222505.GJ10918@hendrix.brq.redhat.com> <52CEBCCC.6000401@cs.vt.edu> <20140109161510.GO14699@hendrix.brq.redhat.com> Message-ID: <52CED13D.7050201@cs.vt.edu> On 1/9/14 11:15 AM, Jakub Hrozek wrote: > On Thu, Jan 09, 2014 at 10:14:20AM -0500, Ryan Chase wrote: >> On 1/8/14 5:25 PM, Jakub Hrozek wrote: >>> On Wed, Jan 08, 2014 at 03:12:35PM -0500, Ryan Chase wrote: >>>> I've added a new user using the command "ipa user-add" from the ipa >>>> server. I can see correct user information when I run the commands >>>> "ipa user-show" and "ipa user-status". However, I cannot see the >>>> user when I run "getent passwd username" or even "id username". When >>>> I run "id username" I get, "no such user". >>>> I feel this may be an issue with sssd, but I'm not 100% sure. >>>> /etc/nsswitch.conf looks correct. >>>> Any ideas? >>>> >>>> --Ryan >>>> >>>> IPA server is CentOS 6 running freeipa version 3.0.0 >>> >>> Hi Ryan, >>> >>> this indeed sounds like an issue with the SSSD. >>> >>> Given that you said nsswitch.conf looks OK, can you raise debug_level >>> (let's start with 5 perhaps) in the [nss] and [domain/] sections, >>> restart the SSSD and inspect the logs in /var/log/sssd/ for any errors? >>> >>> Is there anything in the syslog? Some errors, like invalid keytab are >>> logged to the system logs as well as the SSSD debug logs. >>> >> >> Below is a snip from the sssd log with debug_level=5 >> This was an ssh attempt to the server. >> > > This log snippet is telling us about problems with keytab: > >> (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [sdap_kinit_done] >> (0x0100): Could not get TGT: 14 [Bad address] > > > Perhaps /var/log/sssd/ldap_child.log would have more info? > > Can you kinit with your keytab (kinit -k or kinit -k host/$(hostname)) ? > Running kinit -k gives the following kinit: Password incorrect while getting initial credentials Here is a snip from ldap_child.log (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] [main] (0x0400): ldap_child started. (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [host/server.csl.local at CSL.LOCAL] (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [default] (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Decrypt integrity check failed (Thu Jan 9 11:31:38 2014) [[sssd[ldap_child[2932]]]] [main] (0x0020): ldap_child_get_tgt_sync failed. (Thu Jan 9 11:31:38 2014) [[sssd[ldap_child[2932]]]] [prepare_response] (0x0400): Building response for result [-1765328353] (Thu Jan 9 11:31:38 2014) [[sssd[ldap_child[2932]]]] [main] (0x0400): ldap_child completed successfully From rcritten at redhat.com Thu Jan 9 16:45:56 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 09 Jan 2014 11:45:56 -0500 Subject: [Freeipa-users] trouble adding users In-Reply-To: <52CED13D.7050201@cs.vt.edu> References: <52CDB133.8060002@cs.vt.edu> <20140108222505.GJ10918@hendrix.brq.redhat.com> <52CEBCCC.6000401@cs.vt.edu> <20140109161510.GO14699@hendrix.brq.redhat.com> <52CED13D.7050201@cs.vt.edu> Message-ID: <52CED244.7090406@redhat.com> Ryan Chase wrote: > On 1/9/14 11:15 AM, Jakub Hrozek wrote: >> On Thu, Jan 09, 2014 at 10:14:20AM -0500, Ryan Chase wrote: >>> On 1/8/14 5:25 PM, Jakub Hrozek wrote: >>>> On Wed, Jan 08, 2014 at 03:12:35PM -0500, Ryan Chase wrote: >>>>> I've added a new user using the command "ipa user-add" from the ipa >>>>> server. I can see correct user information when I run the commands >>>>> "ipa user-show" and "ipa user-status". However, I cannot see the >>>>> user when I run "getent passwd username" or even "id username". When >>>>> I run "id username" I get, "no such user". >>>>> I feel this may be an issue with sssd, but I'm not 100% sure. >>>>> /etc/nsswitch.conf looks correct. >>>>> Any ideas? >>>>> >>>>> --Ryan >>>>> >>>>> IPA server is CentOS 6 running freeipa version 3.0.0 >>>> >>>> Hi Ryan, >>>> >>>> this indeed sounds like an issue with the SSSD. >>>> >>>> Given that you said nsswitch.conf looks OK, can you raise debug_level >>>> (let's start with 5 perhaps) in the [nss] and [domain/] sections, >>>> restart the SSSD and inspect the logs in /var/log/sssd/ for any errors? >>>> >>>> Is there anything in the syslog? Some errors, like invalid keytab are >>>> logged to the system logs as well as the SSSD debug logs. >>>> >>> >>> Below is a snip from the sssd log with debug_level=5 >>> This was an ssh attempt to the server. >>> >> >> This log snippet is telling us about problems with keytab: >> >>> (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [sdap_kinit_done] >>> (0x0100): Could not get TGT: 14 [Bad address] >> >> >> Perhaps /var/log/sssd/ldap_child.log would have more info? >> >> Can you kinit with your keytab (kinit -k or kinit -k host/$(hostname)) ? >> > > Running kinit -k gives the following > > kinit: Password incorrect while getting initial credentials > > Here is a snip from ldap_child.log > (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] [main] (0x0400): > ldap_child started. > (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] > [ldap_child_get_tgt_sync] (0x0100): Principal name is: > [host/server.csl.local at CSL.LOCAL] > (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] > [ldap_child_get_tgt_sync] (0x0100): Using keytab [default] > (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] > [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals > (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Decrypt > integrity check failed > (Thu Jan 9 11:31:38 2014) [[sssd[ldap_child[2932]]]] [main] (0x0020): > ldap_child_get_tgt_sync failed. > (Thu Jan 9 11:31:38 2014) [[sssd[ldap_child[2932]]]] [prepare_response] > (0x0400): Building response for result [-1765328353] > (Thu Jan 9 11:31:38 2014) [[sssd[ldap_child[2932]]]] [main] (0x0400): > ldap_child completed successfully So the keytab is bad, strange. You might try this: # kinit admin # kvno host/`hostname` # klist -kt /etc/krb5.keytab Compare the version number of the service in the keytab vs what kvno returns. They should be the same. If they are different then that explains the failure. It would mean though that someone else pulled a keytab for this host principal so generating a new keytab may break whatever they did. If you determine that this is ok you can fetch a new keytab with: # ipa-getkeytab -s ipa.example.com -p host/`hostname` -k /etc/krb5.keytab Then restart sssd and things should work. rob From rchase at cs.vt.edu Thu Jan 9 17:00:58 2014 From: rchase at cs.vt.edu (Ryan Chase) Date: Thu, 09 Jan 2014 12:00:58 -0500 Subject: [Freeipa-users] trouble adding users In-Reply-To: <52CED244.7090406@redhat.com> References: <52CDB133.8060002@cs.vt.edu> <20140108222505.GJ10918@hendrix.brq.redhat.com> <52CEBCCC.6000401@cs.vt.edu> <20140109161510.GO14699@hendrix.brq.redhat.com> <52CED13D.7050201@cs.vt.edu> <52CED244.7090406@redhat.com> Message-ID: <52CED5CA.4080804@cs.vt.edu> On 1/9/14 11:45 AM, Rob Crittenden wrote: > Ryan Chase wrote: >> On 1/9/14 11:15 AM, Jakub Hrozek wrote: >>> On Thu, Jan 09, 2014 at 10:14:20AM -0500, Ryan Chase wrote: >>>> On 1/8/14 5:25 PM, Jakub Hrozek wrote: >>>>> On Wed, Jan 08, 2014 at 03:12:35PM -0500, Ryan Chase wrote: >>>>>> I've added a new user using the command "ipa user-add" from the ipa >>>>>> server. I can see correct user information when I run the commands >>>>>> "ipa user-show" and "ipa user-status". However, I cannot see the >>>>>> user when I run "getent passwd username" or even "id username". When >>>>>> I run "id username" I get, "no such user". >>>>>> I feel this may be an issue with sssd, but I'm not 100% sure. >>>>>> /etc/nsswitch.conf looks correct. >>>>>> Any ideas? >>>>>> >>>>>> --Ryan >>>>>> >>>>>> IPA server is CentOS 6 running freeipa version 3.0.0 >>>>> >>>>> Hi Ryan, >>>>> >>>>> this indeed sounds like an issue with the SSSD. >>>>> >>>>> Given that you said nsswitch.conf looks OK, can you raise debug_level >>>>> (let's start with 5 perhaps) in the [nss] and [domain/] sections, >>>>> restart the SSSD and inspect the logs in /var/log/sssd/ for any >>>>> errors? >>>>> >>>>> Is there anything in the syslog? Some errors, like invalid keytab are >>>>> logged to the system logs as well as the SSSD debug logs. >>>>> >>>> >>>> Below is a snip from the sssd log with debug_level=5 >>>> This was an ssh attempt to the server. >>>> >>> >>> This log snippet is telling us about problems with keytab: >>> >>>> (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [sdap_kinit_done] >>>> (0x0100): Could not get TGT: 14 [Bad address] >>> >>> >>> Perhaps /var/log/sssd/ldap_child.log would have more info? >>> >>> Can you kinit with your keytab (kinit -k or kinit -k host/$(hostname)) ? >>> >> >> Running kinit -k gives the following >> >> kinit: Password incorrect while getting initial credentials >> >> Here is a snip from ldap_child.log >> (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] [main] (0x0400): >> ldap_child started. >> (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] >> [ldap_child_get_tgt_sync] (0x0100): Principal name is: >> [host/server.csl.local at CSL.LOCAL] >> (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] >> [ldap_child_get_tgt_sync] (0x0100): Using keytab [default] >> (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] >> [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals >> (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Decrypt >> integrity check failed >> (Thu Jan 9 11:31:38 2014) [[sssd[ldap_child[2932]]]] [main] (0x0020): >> ldap_child_get_tgt_sync failed. >> (Thu Jan 9 11:31:38 2014) [[sssd[ldap_child[2932]]]] [prepare_response] >> (0x0400): Building response for result [-1765328353] >> (Thu Jan 9 11:31:38 2014) [[sssd[ldap_child[2932]]]] [main] (0x0400): >> ldap_child completed successfully > > So the keytab is bad, strange. You might try this: > > # kinit admin > # kvno host/`hostname` > # klist -kt /etc/krb5.keytab > > Compare the version number of the service in the keytab vs what kvno > returns. They should be the same. If they are different then that > explains the failure. It would mean though that someone else pulled a > keytab for this host principal so generating a new keytab may break > whatever they did. > > If you determine that this is ok you can fetch a new keytab with: > > # ipa-getkeytab -s ipa.example.com -p host/`hostname` -k /etc/krb5.keytab > > Then restart sssd and things should work. > > rob > The version numbers don't match. How would I fix this? From simo at redhat.com Thu Jan 9 18:27:28 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 09 Jan 2014 13:27:28 -0500 Subject: [Freeipa-users] trouble adding users In-Reply-To: <52CED5CA.4080804@cs.vt.edu> References: <52CDB133.8060002@cs.vt.edu> <20140108222505.GJ10918@hendrix.brq.redhat.com> <52CEBCCC.6000401@cs.vt.edu> <20140109161510.GO14699@hendrix.brq.redhat.com> <52CED13D.7050201@cs.vt.edu> <52CED244.7090406@redhat.com> <52CED5CA.4080804@cs.vt.edu> Message-ID: <1389292048.26102.241.camel@willson.li.ssimo.org> On Thu, 2014-01-09 at 12:00 -0500, Ryan Chase wrote: > > On 1/9/14 11:45 AM, Rob Crittenden wrote: > > Ryan Chase wrote: > >> On 1/9/14 11:15 AM, Jakub Hrozek wrote: > >>> On Thu, Jan 09, 2014 at 10:14:20AM -0500, Ryan Chase wrote: > >>>> On 1/8/14 5:25 PM, Jakub Hrozek wrote: > >>>>> On Wed, Jan 08, 2014 at 03:12:35PM -0500, Ryan Chase wrote: > >>>>>> I've added a new user using the command "ipa user-add" from the ipa > >>>>>> server. I can see correct user information when I run the commands > >>>>>> "ipa user-show" and "ipa user-status". However, I cannot see the > >>>>>> user when I run "getent passwd username" or even "id username". When > >>>>>> I run "id username" I get, "no such user". > >>>>>> I feel this may be an issue with sssd, but I'm not 100% sure. > >>>>>> /etc/nsswitch.conf looks correct. > >>>>>> Any ideas? > >>>>>> > >>>>>> --Ryan > >>>>>> > >>>>>> IPA server is CentOS 6 running freeipa version 3.0.0 > >>>>> > >>>>> Hi Ryan, > >>>>> > >>>>> this indeed sounds like an issue with the SSSD. > >>>>> > >>>>> Given that you said nsswitch.conf looks OK, can you raise debug_level > >>>>> (let's start with 5 perhaps) in the [nss] and [domain/] sections, > >>>>> restart the SSSD and inspect the logs in /var/log/sssd/ for any > >>>>> errors? > >>>>> > >>>>> Is there anything in the syslog? Some errors, like invalid keytab are > >>>>> logged to the system logs as well as the SSSD debug logs. > >>>>> > >>>> > >>>> Below is a snip from the sssd log with debug_level=5 > >>>> This was an ssh attempt to the server. > >>>> > >>> > >>> This log snippet is telling us about problems with keytab: > >>> > >>>> (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [sdap_kinit_done] > >>>> (0x0100): Could not get TGT: 14 [Bad address] > >>> > >>> > >>> Perhaps /var/log/sssd/ldap_child.log would have more info? > >>> > >>> Can you kinit with your keytab (kinit -k or kinit -k host/$(hostname)) ? > >>> > >> > >> Running kinit -k gives the following > >> > >> kinit: Password incorrect while getting initial credentials > >> > >> Here is a snip from ldap_child.log > >> (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] [main] (0x0400): > >> ldap_child started. > >> (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] > >> [ldap_child_get_tgt_sync] (0x0100): Principal name is: > >> [host/server.csl.local at CSL.LOCAL] > >> (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] > >> [ldap_child_get_tgt_sync] (0x0100): Using keytab [default] > >> (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] > >> [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals > >> (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] > >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Decrypt > >> integrity check failed > >> (Thu Jan 9 11:31:38 2014) [[sssd[ldap_child[2932]]]] [main] (0x0020): > >> ldap_child_get_tgt_sync failed. > >> (Thu Jan 9 11:31:38 2014) [[sssd[ldap_child[2932]]]] [prepare_response] > >> (0x0400): Building response for result [-1765328353] > >> (Thu Jan 9 11:31:38 2014) [[sssd[ldap_child[2932]]]] [main] (0x0400): > >> ldap_child completed successfully > > > > So the keytab is bad, strange. You might try this: > > > > # kinit admin > > # kvno host/`hostname` > > # klist -kt /etc/krb5.keytab > > > > Compare the version number of the service in the keytab vs what kvno > > returns. They should be the same. If they are different then that > > explains the failure. It would mean though that someone else pulled a > > keytab for this host principal so generating a new keytab may break > > whatever they did. > > > > If you determine that this is ok you can fetch a new keytab with: > > > > # ipa-getkeytab -s ipa.example.com -p host/`hostname` -k /etc/krb5.keytab > > > > Then restart sssd and things should work. > > > > rob > > > > The version numbers don't match. How would I fix this? Using the ipa-getkeytab command mentioned above. Simo. -- Simo Sorce * Red Hat, Inc * New York From ide4you at gmail.com Thu Jan 9 18:40:54 2014 From: ide4you at gmail.com (Uzor Ide) Date: Thu, 9 Jan 2014 12:40:54 -0600 Subject: [Freeipa-users] Correct way to upgrade fedora 18 to 20 Message-ID: Hi All Seeing the problem people that upgraded fedora 18 with freeipa server to 20 is having. I would like to know the correct way to upgrade fedora 20 that will not cause a loss or failure in freeipa after the upgrade Thanks _Uz -------------- next part -------------- An HTML attachment was scrubbed... URL: From rchase at cs.vt.edu Thu Jan 9 18:43:57 2014 From: rchase at cs.vt.edu (Ryan Chase) Date: Thu, 09 Jan 2014 13:43:57 -0500 Subject: [Freeipa-users] trouble adding users In-Reply-To: <1389292048.26102.241.camel@willson.li.ssimo.org> References: <52CDB133.8060002@cs.vt.edu> <20140108222505.GJ10918@hendrix.brq.redhat.com> <52CEBCCC.6000401@cs.vt.edu> <20140109161510.GO14699@hendrix.brq.redhat.com> <52CED13D.7050201@cs.vt.edu> <52CED244.7090406@redhat.com> <52CED5CA.4080804@cs.vt.edu> <1389292048.26102.241.camel@willson.li.ssimo.org> Message-ID: <52CEEDED.5080905@cs.vt.edu> On 1/9/14 1:27 PM, Simo Sorce wrote: > On Thu, 2014-01-09 at 12:00 -0500, Ryan Chase wrote: >> >> On 1/9/14 11:45 AM, Rob Crittenden wrote: >>> Ryan Chase wrote: >>>> On 1/9/14 11:15 AM, Jakub Hrozek wrote: >>>>> On Thu, Jan 09, 2014 at 10:14:20AM -0500, Ryan Chase wrote: >>>>>> On 1/8/14 5:25 PM, Jakub Hrozek wrote: >>>>>>> On Wed, Jan 08, 2014 at 03:12:35PM -0500, Ryan Chase wrote: >>>>>>>> I've added a new user using the command "ipa user-add" from the ipa >>>>>>>> server. I can see correct user information when I run the commands >>>>>>>> "ipa user-show" and "ipa user-status". However, I cannot see the >>>>>>>> user when I run "getent passwd username" or even "id username". When >>>>>>>> I run "id username" I get, "no such user". >>>>>>>> I feel this may be an issue with sssd, but I'm not 100% sure. >>>>>>>> /etc/nsswitch.conf looks correct. >>>>>>>> Any ideas? >>>>>>>> >>>>>>>> --Ryan >>>>>>>> >>>>>>>> IPA server is CentOS 6 running freeipa version 3.0.0 >>>>>>> >>>>>>> Hi Ryan, >>>>>>> >>>>>>> this indeed sounds like an issue with the SSSD. >>>>>>> >>>>>>> Given that you said nsswitch.conf looks OK, can you raise debug_level >>>>>>> (let's start with 5 perhaps) in the [nss] and [domain/] sections, >>>>>>> restart the SSSD and inspect the logs in /var/log/sssd/ for any >>>>>>> errors? >>>>>>> >>>>>>> Is there anything in the syslog? Some errors, like invalid keytab are >>>>>>> logged to the system logs as well as the SSSD debug logs. >>>>>>> >>>>>> >>>>>> Below is a snip from the sssd log with debug_level=5 >>>>>> This was an ssh attempt to the server. >>>>>> >>>>> >>>>> This log snippet is telling us about problems with keytab: >>>>> >>>>>> (Thu Jan 9 09:52:45 2014) [sssd[be[csl.local]]] [sdap_kinit_done] >>>>>> (0x0100): Could not get TGT: 14 [Bad address] >>>>> >>>>> >>>>> Perhaps /var/log/sssd/ldap_child.log would have more info? >>>>> >>>>> Can you kinit with your keytab (kinit -k or kinit -k host/$(hostname)) ? >>>>> >>>> >>>> Running kinit -k gives the following >>>> >>>> kinit: Password incorrect while getting initial credentials >>>> >>>> Here is a snip from ldap_child.log >>>> (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] [main] (0x0400): >>>> ldap_child started. >>>> (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] >>>> [ldap_child_get_tgt_sync] (0x0100): Principal name is: >>>> [host/server.csl.local at CSL.LOCAL] >>>> (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] >>>> [ldap_child_get_tgt_sync] (0x0100): Using keytab [default] >>>> (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] >>>> [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals >>>> (Thu Jan 9 11:31:37 2014) [[sssd[ldap_child[2932]]]] >>>> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Decrypt >>>> integrity check failed >>>> (Thu Jan 9 11:31:38 2014) [[sssd[ldap_child[2932]]]] [main] (0x0020): >>>> ldap_child_get_tgt_sync failed. >>>> (Thu Jan 9 11:31:38 2014) [[sssd[ldap_child[2932]]]] [prepare_response] >>>> (0x0400): Building response for result [-1765328353] >>>> (Thu Jan 9 11:31:38 2014) [[sssd[ldap_child[2932]]]] [main] (0x0400): >>>> ldap_child completed successfully >>> >>> So the keytab is bad, strange. You might try this: >>> >>> # kinit admin >>> # kvno host/`hostname` >>> # klist -kt /etc/krb5.keytab >>> >>> Compare the version number of the service in the keytab vs what kvno >>> returns. They should be the same. If they are different then that >>> explains the failure. It would mean though that someone else pulled a >>> keytab for this host principal so generating a new keytab may break >>> whatever they did. >>> >>> If you determine that this is ok you can fetch a new keytab with: >>> >>> # ipa-getkeytab -s ipa.example.com -p host/`hostname` -k /etc/krb5.keytab >>> >>> Then restart sssd and things should work. >>> >>> rob >>> >> >> The version numbers don't match. How would I fix this? > > Using the ipa-getkeytab command mentioned above. > > Simo. That command worked. I can now authenticate to the server and users appear as they should. I checked the version numbers again with kvno and klist, and they are still different. Does this matter? There are new entries when I run the command kinit -kt, also with a different version number than what kvno displays. Thank you, everyone for your help. I've been trying to debug this for a while. --Ryan From orion at cora.nwra.com Thu Jan 9 22:53:11 2014 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 09 Jan 2014 15:53:11 -0700 Subject: [Freeipa-users] Updated doc, synchronization question In-Reply-To: <52CE9F16.4020507@redhat.com> References: <52CD9608.7090404@cora.nwra.com> <52CE9F16.4020507@redhat.com> Message-ID: <52CF2857.5050104@cora.nwra.com> On 01/09/2014 06:07 AM, Martin Kosek wrote: > On 01/08/2014 07:16 PM, Orion Poplawski wrote: >> Two questions: >> >> - Any ETA on an updated 3.3.3 Users Guide? > > Our current plan is to release next documentation release along with FreeIPA > 3.4, when more documentation fixes are factored in. > > Just in case you would like to check the most recent status of the > documentation work (or even help us with it), this page describes the details > > http://www.freeipa.org/page/Contribute/Documentation > > including instructions how to build HTMLs out of our git tree. > Thanks, I'll take a look. >> - Is AD/IPA synchronization still supported in 3.3.3? Will it always? > > The AD/IPA synchronization is supported only in terms in bug fixes. As for the > enhancements, the FreeIPA core team is focusing on the AD trusts: > > http://www.freeipa.org/page/Trusts > > (That does not mean we are not open to contributions from the community) > > Martin > Thanks for the that link - the video was helpful. Although I'm afraid that is making me lean towards implementing the not recommended "split brain" approach. Although one thing that is not clear to me is weather doing this consumes CALs for the linux machines since they authenticate against AD. Currently we have two main office locations (DNS cora.nwra.com and nwra.com) plus some remote users and a 389-ds LDAP server for the Linux boxes and an AD domain (NWRA.LOCAL). We are using the LDAP/AD password/user sync module to sync users and passwords. Essentially, all of our Linux users are Windows users and vice versa, and we have well established UIDs on both sides. We would like to move to using Kerberos on the Linux machines and to be able to have as much SSO capability as possible. Am I correct in assuming that this either requires a single KDC or trusts between KDCs? While trusts are being promoted as the way to go for this, I'm afraid it will require a lot of tweaking to our current setup. Or perhaps not. We currently maintain DNS outside of both AD and would do the same IPA. We're happy to apply custom configurations via puppet, etc. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From abokovoy at redhat.com Fri Jan 10 00:51:08 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 10 Jan 2014 02:51:08 +0200 Subject: [Freeipa-users] Updated doc, synchronization question In-Reply-To: <52CF2857.5050104@cora.nwra.com> References: <52CD9608.7090404@cora.nwra.com> <52CE9F16.4020507@redhat.com> <52CF2857.5050104@cora.nwra.com> Message-ID: <20140110005108.GA1883@redhat.com> On Thu, 09 Jan 2014, Orion Poplawski wrote: >On 01/09/2014 06:07 AM, Martin Kosek wrote: >> On 01/08/2014 07:16 PM, Orion Poplawski wrote: >>> Two questions: >>> >>> - Any ETA on an updated 3.3.3 Users Guide? >> >> Our current plan is to release next documentation release along with FreeIPA >> 3.4, when more documentation fixes are factored in. >> >> Just in case you would like to check the most recent status of the >> documentation work (or even help us with it), this page describes the details >> >> http://www.freeipa.org/page/Contribute/Documentation >> >> including instructions how to build HTMLs out of our git tree. >> > >Thanks, I'll take a look. > >>> - Is AD/IPA synchronization still supported in 3.3.3? Will it always? >> >> The AD/IPA synchronization is supported only in terms in bug fixes. As for the >> enhancements, the FreeIPA core team is focusing on the AD trusts: >> >> http://www.freeipa.org/page/Trusts >> >> (That does not mean we are not open to contributions from the community) >> >> Martin >> > >Thanks for the that link - the video was helpful. Although I'm afraid that is >making me lean towards implementing the not recommended "split brain" >approach. Although one thing that is not clear to me is weather doing this >consumes CALs for the linux machines since they authenticate against AD. Linux machines do not authenticate against AD DC in single sign-on case. Instead, usually Windows users obtain their Kerberos TGT upon logon to Windows machines and then use it to obtain tickets to services on Linux machines, by obtaining cross-realm TGT from AD DC and presenting it to IPA KDC as a proof. So in single sign-on case it works fine -- authentication against AD happens on AD side. Of course, when AD users attempt to log in with password to IPA resources, SSSD would perform communication with AD DC to obtain TGT on their behalf. There is AD DC involved in making a decision whether this AD user is allowed to authenticate. On Kerberos level, however, there are no limitations from where the authentication request comes (unless it is restricted with the firewalls). CALs play role on using Windows resources after authentication happened but in IPA AD trusts case currently only IPA resources can be consumed by AD users, IPA users cannot yet consume Windows resources and therefore get assigned rights to access them. -- / Alexander Bokovoy From christianh at 4over.com Fri Jan 10 03:45:11 2014 From: christianh at 4over.com (Christian Hernandez) Date: Thu, 9 Jan 2014 19:45:11 -0800 Subject: [Freeipa-users] Form Based Login Message-ID: Looks like like for "Form Based Login" isn't appearing What's the URL for form based login? Can I access it directly via a URL? Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christianh at 4over.com www.4over.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Jan 10 09:05:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 10 Jan 2014 10:05:05 +0100 Subject: [Freeipa-users] Correct way to upgrade fedora 18 to 20 In-Reply-To: References: Message-ID: <52CFB7C1.5020406@redhat.com> On 01/09/2014 07:40 PM, Uzor Ide wrote: > Hi All > > Seeing the problem people that upgraded fedora 18 with freeipa server to 20 > is having. I would like to know the correct way to upgrade fedora 20 that > will not cause a loss or failure in freeipa after the upgrade > > Thanks > > _Uz Hello Uzor, You should be only concerned if your FreeIPA server has CA configured (--setup-ca option) and was installed in Fedora 17 or older. If this is the case, you would need to follow migration procedure instead of in-place upgrade. We have a related article on our wiki: http://www.freeipa.org/page/Howto/Dogtag9ToDogtag10Migration If this is not a FreeIPA server with CA or it was installed in FreeIPA 18, it is eligible for in-place upgrade to Fedora 20. Martin From mkosek at redhat.com Fri Jan 10 09:07:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 10 Jan 2014 10:07:04 +0100 Subject: [Freeipa-users] Form Based Login In-Reply-To: References: Message-ID: <52CFB838.4040101@redhat.com> On 01/10/2014 04:45 AM, Christian Hernandez wrote: > Looks like like for "Form Based Login" isn't appearing > > What's the URL for form based login? Can I access it directly via a URL? > > Thank you, > > Christian Hernandez > 1225 Los Angeles Street > Glendale, CA 91204 > Phone: 877-782-2737 ext. 4566 > Fax: 818-265-3152 > christianh at 4over.com > www.4over.com What do you mean by "isn't appearing"? You type FreeIPA server FQDN and you are not redirected to the Web UI URL? The URL should be as following: https://fqdn.of.your.ipa.server/ipa/ui/ Or does it mean you are redirected, but receive a blank page instead? Martin From fvzwieten at vxcompany.com Fri Jan 10 10:52:16 2014 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Fri, 10 Jan 2014 11:52:16 +0100 Subject: [Freeipa-users] Sudo rule processing order Message-ID: Hi, I have a sudo rule in IPA that has the !authenticate option added to enable admins to execute certain programs as root without authentication. It doesn't work. There is another rule for the admins that allow all commands as long as they give their password. In a sudoers file, you can solve this by specifing the nopasswd rule as last. sudo -l from an IPA-client gives me this: *******@svr001 ~]$ sudo -l Matching Defaults entries for ******* on this host: requiretty, !visiblepw, always_set_home, 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 ******** may run the following commands on this host: (root) NOPASSWD: ALL (root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls, /bin/more, /usr/bin/less, !/bin/su (root) NOPASSWD: /usr/bin/cobbler (root) !/bin/su I want the cobbler command to run without password authentication. What am I doing wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Jan 10 14:59:24 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 10 Jan 2014 15:59:24 +0100 Subject: [Freeipa-users] Sudo rule processing order In-Reply-To: References: Message-ID: <52D00ACC.505@redhat.com> On 01/10/2014 11:52 AM, Fred van Zwieten wrote: > Hi, > > I have a sudo rule in IPA that has the !authenticate option added to enable > admins to execute certain programs as root without authentication. > > It doesn't work. There is another rule for the admins that allow all > commands as long as they give their password. > > In a sudoers file, you can solve this by specifing the nopasswd rule as > last. > > sudo -l from an IPA-client gives me this: > > *******@svr001 ~]$ sudo -l > Matching Defaults entries for ******* on this host: > requiretty, !visiblepw, always_set_home, 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 ******** may run the following commands on this host: > (root) NOPASSWD: ALL > (root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls, /bin/more, > /usr/bin/less, !/bin/su > (root) NOPASSWD: /usr/bin/cobbler > (root) !/bin/su > > I want the cobbler command to run without password authentication. What am > I doing wrong? > Would setting SUDO rule order help? # ipa sudorule-mod -h ... --order=INT integer to order the Sudo rules ... Martin From fvzwieten at vxcompany.com Fri Jan 10 15:52:27 2014 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Fri, 10 Jan 2014 16:52:27 +0100 Subject: [Freeipa-users] Sudo rule processing order In-Reply-To: <52D00ACC.505@redhat.com> References: <52D00ACC.505@redhat.com> Message-ID: Yes, you would expect that to help, wouldn't you :-) Didn't even know this existed. Thanks for that. User has 3 sudo rules. I have set the allow_all rule to 1, the second rule to 2 and the cobbler (with the "!authenticate" option) rule to 99: User ******** may run the following commands on this host: (root) ALL (root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls, /bin/more, /usr/bin/less, !/bin/su (root) NOPASSWD: /usr/bin/cobbler (root) !/bin/su Nope. Didn't help. Fred On Fri, Jan 10, 2014 at 3:59 PM, Martin Kosek wrote: > On 01/10/2014 11:52 AM, Fred van Zwieten wrote: > > Hi, > > > > I have a sudo rule in IPA that has the !authenticate option added to > enable > > admins to execute certain programs as root without authentication. > > > > It doesn't work. There is another rule for the admins that allow all > > commands as long as they give their password. > > > > In a sudoers file, you can solve this by specifing the nopasswd rule as > > last. > > > > sudo -l from an IPA-client gives me this: > > > > *******@svr001 ~]$ sudo -l > > Matching Defaults entries for ******* on this host: > > requiretty, !visiblepw, always_set_home, 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 ******** may run the following commands on this host: > > (root) NOPASSWD: ALL > > (root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls, > /bin/more, > > /usr/bin/less, !/bin/su > > (root) NOPASSWD: /usr/bin/cobbler > > (root) !/bin/su > > > > I want the cobbler command to run without password authentication. What > am > > I doing wrong? > > > > Would setting SUDO rule order help? > > # ipa sudorule-mod -h > ... > --order=INT integer to order the Sudo rules > ... > > Martin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christianh at 4over.com Fri Jan 10 16:09:27 2014 From: christianh at 4over.com (Christian Hernandez) Date: Fri, 10 Jan 2014 08:09:27 -0800 Subject: [Freeipa-users] Form Based Login In-Reply-To: <52CFB838.4040101@redhat.com> References: <52CFB838.4040101@redhat.com> Message-ID: Hi Martin, The page _is_ showing up...but there is no link for form based auth ...before there was a link for "form based authentication" Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christianh at 4over.com www.4over.com On Fri, Jan 10, 2014 at 1:07 AM, Martin Kosek wrote: > On 01/10/2014 04:45 AM, Christian Hernandez wrote: > > Looks like like for "Form Based Login" isn't appearing > > > > What's the URL for form based login? Can I access it directly via a URL? > > > > Thank you, > > > > Christian Hernandez > > 1225 Los Angeles Street > > Glendale, CA 91204 > > Phone: 877-782-2737 ext. 4566 > > Fax: 818-265-3152 > > christianh at 4over.com > > www.4over.com > > What do you mean by "isn't appearing"? You type FreeIPA server FQDN and > you are > not redirected to the Web UI URL? The URL should be as following: > > https://fqdn.of.your.ipa.server/ipa/ui/ > > Or does it mean you are redirected, but receive a blank page instead? > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Jan 10 16:17:02 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 10 Jan 2014 17:17:02 +0100 Subject: [Freeipa-users] Sudo rule processing order In-Reply-To: References: <52D00ACC.505@redhat.com> Message-ID: <52D01CFE.1030305@redhat.com> On 01/10/2014 04:52 PM, Fred van Zwieten wrote: > Yes, you would expect that to help, wouldn't you :-) Yes, I would :-) > > Didn't even know this existed. Thanks for that. > > User has 3 sudo rules. I have set the allow_all rule to 1, the second rule > to 2 and the cobbler (with the "!authenticate" option) rule to 99: What is the version of the SUDO on your system? According to http://www.sudo.ws/sudoers.ldap.man.html it was implemented in SUDO 1.7.5. Martin > > User ******** may run the following commands on this host: > (root) ALL > (root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls, /bin/more, > /usr/bin/less, !/bin/su > (root) NOPASSWD: /usr/bin/cobbler > (root) !/bin/su > > Nope. Didn't help. > > Fred > > On Fri, Jan 10, 2014 at 3:59 PM, Martin Kosek wrote: > >> On 01/10/2014 11:52 AM, Fred van Zwieten wrote: >>> Hi, >>> >>> I have a sudo rule in IPA that has the !authenticate option added to >> enable >>> admins to execute certain programs as root without authentication. >>> >>> It doesn't work. There is another rule for the admins that allow all >>> commands as long as they give their password. >>> >>> In a sudoers file, you can solve this by specifing the nopasswd rule as >>> last. >>> >>> sudo -l from an IPA-client gives me this: >>> >>> *******@svr001 ~]$ sudo -l >>> Matching Defaults entries for ******* on this host: >>> requiretty, !visiblepw, always_set_home, 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 ******** may run the following commands on this host: >>> (root) NOPASSWD: ALL >>> (root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls, >> /bin/more, >>> /usr/bin/less, !/bin/su >>> (root) NOPASSWD: /usr/bin/cobbler >>> (root) !/bin/su >>> >>> I want the cobbler command to run without password authentication. What >> am >>> I doing wrong? >>> >> >> Would setting SUDO rule order help? >> >> # ipa sudorule-mod -h >> ... >> --order=INT integer to order the Sudo rules >> ... >> >> Martin >> >> > From christianh at 4over.com Fri Jan 10 16:18:53 2014 From: christianh at 4over.com (Christian Hernandez) Date: Fri, 10 Jan 2014 08:18:53 -0800 Subject: [Freeipa-users] Form Based Login In-Reply-To: References: <52CFB838.4040101@redhat.com> Message-ID: Sorry, screen shot attached Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christianh at 4over.com www.4over.com On Fri, Jan 10, 2014 at 8:09 AM, Christian Hernandez wrote: > Hi Martin, > > The page _is_ showing up...but there is no link for form based auth > > ...before there was a link for "form based authentication" > > > > Thank you, > > Christian Hernandez > 1225 Los Angeles Street > Glendale, CA 91204 > Phone: 877-782-2737 ext. 4566 > Fax: 818-265-3152 > christianh at 4over.com > www.4over.com > > > On Fri, Jan 10, 2014 at 1:07 AM, Martin Kosek wrote: > >> On 01/10/2014 04:45 AM, Christian Hernandez wrote: >> > Looks like like for "Form Based Login" isn't appearing >> > >> > What's the URL for form based login? Can I access it directly via a URL? >> > >> > Thank you, >> > >> > Christian Hernandez >> > 1225 Los Angeles Street >> > Glendale, CA 91204 >> > Phone: 877-782-2737 ext. 4566 >> > Fax: 818-265-3152 >> > christianh at 4over.com >> > www.4over.com >> >> What do you mean by "isn't appearing"? You type FreeIPA server FQDN and >> you are >> not redirected to the Web UI URL? The URL should be as following: >> >> https://fqdn.of.your.ipa.server/ipa/ui/ >> >> Or does it mean you are redirected, but receive a blank page instead? >> >> Martin >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-01-10 at 8.04.24 AM.png Type: image/png Size: 53073 bytes Desc: not available URL: From pvoborni at redhat.com Fri Jan 10 16:21:59 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 10 Jan 2014 17:21:59 +0100 Subject: [Freeipa-users] Form Based Login In-Reply-To: References: <52CFB838.4040101@redhat.com> Message-ID: <52D01E27.6080505@redhat.com> On 10.1.2014 17:09, Christian Hernandez wrote: > Hi Martin, > > The page _is_ showing up...but there is no link for form based auth > > ...before there was a link for "form based authentication" > > > > Thank you, > > Christian Hernandez > > > On Fri, Jan 10, 2014 at 1:07 AM, Martin Kosek wrote: > >> On 01/10/2014 04:45 AM, Christian Hernandez wrote: >>> Looks like like for "Form Based Login" isn't appearing >>> >>> What's the URL for form based login? Can I access it directly via a URL? >>> >>> Thank you, >>> >>> Christian Hernandez >> >> What do you mean by "isn't appearing"? You type FreeIPA server FQDN and >> you are >> not redirected to the Web UI URL? The URL should be as following: >> >> https://fqdn.of.your.ipa.server/ipa/ui/ >> >> Or does it mean you are redirected, but receive a blank page instead? >> >> Martin >> > Hello Christian, What is the FreeIPA version? Have you upgraded? If so, try to empty cache and hard reload the page. Screenshot may help us to determine what's the problem. -- Petr Vobornik From pvoborni at redhat.com Fri Jan 10 16:24:33 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 10 Jan 2014 17:24:33 +0100 Subject: [Freeipa-users] Form Based Login In-Reply-To: References: <52CFB838.4040101@redhat.com> Message-ID: <52D01EC1.9020306@redhat.com> On 10.1.2014 17:18, Christian Hernandez wrote: > Sorry, screen shot attached > > > Thank you, > > Christian Hernandez > 1225 Los Angeles Street > Glendale, CA 91204 > Phone: 877-782-2737 ext. 4566 > Fax: 818-265-3152 > christianh at 4over.com > www.4over.com > > > On Fri, Jan 10, 2014 at 8:09 AM, Christian Hernandez > wrote: > >> Hi Martin, >> >> The page _is_ showing up...but there is no link for form based auth >> >> ...before there was a link for "form based authentication" >> >> >> >> Thank you, >> >> Christian Hernandez >> 1225 Los Angeles Street >> Glendale, CA 91204 >> Phone: 877-782-2737 ext. 4566 >> Fax: 818-265-3152 >> christianh at 4over.com >> www.4over.com >> >> >> On Fri, Jan 10, 2014 at 1:07 AM, Martin Kosek wrote: >> >>> On 01/10/2014 04:45 AM, Christian Hernandez wrote: >>>> Looks like like for "Form Based Login" isn't appearing >>>> >>>> What's the URL for form based login? Can I access it directly via a URL? >>>> >>>> Thank you, >>>> >>>> Christian Hernandez >>>> 1225 Los Angeles Street >>>> Glendale, CA 91204 >>>> Phone: 877-782-2737 ext. 4566 >>>> Fax: 818-265-3152 >>>> christianh at 4over.com >>>> www.4over.com >>> >>> What do you mean by "isn't appearing"? You type FreeIPA server FQDN and >>> you are >>> not redirected to the Web UI URL? The URL should be as following: >>> >>> https://fqdn.of.your.ipa.server/ipa/ui/ >>> >>> Or does it mean you are redirected, but receive a blank page instead? >>> >>> Martin >>> The link is not required anymore. Just write the username and password into the fields on the form and hit 'enter' key. Btw, if you don't specify password, it will try negotiate method. -- Petr Vobornik From mkosek at redhat.com Fri Jan 10 16:28:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 10 Jan 2014 17:28:54 +0100 Subject: [Freeipa-users] Sudo rule processing order In-Reply-To: <52D01CFE.1030305@redhat.com> References: <52D00ACC.505@redhat.com> <52D01CFE.1030305@redhat.com> Message-ID: <52D01FC6.6090108@redhat.com> Ah, I think I found the root cause. Our sudoers compat tree configuration missed out the sudoOrder attribute. The order was thus missing in LDAP sudoers and thus ineffective. I filed an upstream ticket to fix it: https://fedorahosted.org/freeipa/ticket/4107 However, to hotfix it in your environment, could you try manually fixing the configuration on your FreeIPA server? $ ldapmodify -h `hostname` -D "cn=Directory Manager" -x -W dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config changetype: modify add: schema-compat-entry-attribute schema-compat-entry-attribute: sudoOrder=%{sudoOrder} This should do the trick. Martin On 01/10/2014 05:17 PM, Martin Kosek wrote: > On 01/10/2014 04:52 PM, Fred van Zwieten wrote: >> Yes, you would expect that to help, wouldn't you :-) > > Yes, I would :-) > >> >> Didn't even know this existed. Thanks for that. >> >> User has 3 sudo rules. I have set the allow_all rule to 1, the second rule >> to 2 and the cobbler (with the "!authenticate" option) rule to 99: > > What is the version of the SUDO on your system? According to > http://www.sudo.ws/sudoers.ldap.man.html > it was implemented in SUDO 1.7.5. > > Martin > >> >> User ******** may run the following commands on this host: >> (root) ALL >> (root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls, /bin/more, >> /usr/bin/less, !/bin/su >> (root) NOPASSWD: /usr/bin/cobbler >> (root) !/bin/su >> >> Nope. Didn't help. >> >> Fred >> >> On Fri, Jan 10, 2014 at 3:59 PM, Martin Kosek wrote: >> >>> On 01/10/2014 11:52 AM, Fred van Zwieten wrote: >>>> Hi, >>>> >>>> I have a sudo rule in IPA that has the !authenticate option added to >>> enable >>>> admins to execute certain programs as root without authentication. >>>> >>>> It doesn't work. There is another rule for the admins that allow all >>>> commands as long as they give their password. >>>> >>>> In a sudoers file, you can solve this by specifing the nopasswd rule as >>>> last. >>>> >>>> sudo -l from an IPA-client gives me this: >>>> >>>> *******@svr001 ~]$ sudo -l >>>> Matching Defaults entries for ******* on this host: >>>> requiretty, !visiblepw, always_set_home, 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 ******** may run the following commands on this host: >>>> (root) NOPASSWD: ALL >>>> (root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls, >>> /bin/more, >>>> /usr/bin/less, !/bin/su >>>> (root) NOPASSWD: /usr/bin/cobbler >>>> (root) !/bin/su >>>> >>>> I want the cobbler command to run without password authentication. What >>> am >>>> I doing wrong? >>>> >>> >>> Would setting SUDO rule order help? >>> >>> # ipa sudorule-mod -h >>> ... >>> --order=INT integer to order the Sudo rules >>> ... >>> >>> Martin >>> >>> >> > From dpal at redhat.com Fri Jan 10 18:02:52 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 10 Jan 2014 13:02:52 -0500 Subject: [Freeipa-users] Updated doc, synchronization question In-Reply-To: <20140110005108.GA1883@redhat.com> References: <52CD9608.7090404@cora.nwra.com> <52CE9F16.4020507@redhat.com> <52CF2857.5050104@cora.nwra.com> <20140110005108.GA1883@redhat.com> Message-ID: <52D035CC.4080604@redhat.com> On 01/09/2014 07:51 PM, Alexander Bokovoy wrote: > On Thu, 09 Jan 2014, Orion Poplawski wrote: >> On 01/09/2014 06:07 AM, Martin Kosek wrote: >>> On 01/08/2014 07:16 PM, Orion Poplawski wrote: >>>> Two questions: >>>> >>>> - Any ETA on an updated 3.3.3 Users Guide? >>> >>> Our current plan is to release next documentation release along with >>> FreeIPA >>> 3.4, when more documentation fixes are factored in. >>> >>> Just in case you would like to check the most recent status of the >>> documentation work (or even help us with it), this page describes >>> the details >>> >>> http://www.freeipa.org/page/Contribute/Documentation >>> >>> including instructions how to build HTMLs out of our git tree. >>> >> >> Thanks, I'll take a look. >> >>>> - Is AD/IPA synchronization still supported in 3.3.3? Will it always? >>> >>> The AD/IPA synchronization is supported only in terms in bug fixes. >>> As for the >>> enhancements, the FreeIPA core team is focusing on the AD trusts: >>> >>> http://www.freeipa.org/page/Trusts >>> >>> (That does not mean we are not open to contributions from the >>> community) >>> >>> Martin >>> >> >> Thanks for the that link - the video was helpful. Although I'm >> afraid that is >> making me lean towards implementing the not recommended "split brain" >> approach. Although one thing that is not clear to me is weather >> doing this >> consumes CALs for the linux machines since they authenticate against AD. > Linux machines do not authenticate against AD DC in single sign-on > case. Instead, usually Windows users obtain their Kerberos TGT upon > logon to > Windows machines and then use it to obtain tickets to services on Linux > machines, by obtaining cross-realm TGT from AD DC and presenting it to > IPA KDC as a proof. So in single sign-on case it works fine -- > authentication against AD happens on AD side. > > Of course, when AD users attempt to log in with password to IPA > resources, SSSD would perform communication with AD DC to obtain TGT on > their behalf. There is AD DC involved in making a decision whether > this AD user is allowed to authenticate. On Kerberos level, however, > there are no limitations from where the authentication request comes > (unless it is restricted with the firewalls). CALs play role on using > Windows resources after authentication happened but in IPA AD trusts > case currently only IPA resources can be consumed by AD users, IPA users > cannot yet consume Windows resources and therefore get assigned rights > to access them. > To clarify the CAL part. The CALs come in two shapes: per user and per host. If it is per user and you have users in AD then regardless of how you integrate with IPA you have to pay these CALs. If your CALs is around hosts then they are based on the count of the computer objects in AD. If the client system is joined directly and has kerberos identity in AD domain you have an object in AD that counts towards CALs. If you have client joined to IPA and either trust or sync solution in place the client is not a member of AD (no computer object in AD) and this does not count towards CALs. HTH -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From shelltoesuperstar at gmail.com Sat Jan 11 14:20:57 2014 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Sat, 11 Jan 2014 14:20:57 +0000 Subject: [Freeipa-users] CA setup and ipa-gertcert questions Message-ID: Hi I'm experiencing an issue trying to use ipa-getcert on my IPA clients. When I run a command similar to this ipa-getcert request -K principal/`hostname` -D `hostname` \ -k /var/lib/ssl/private_keys/`hostname`.pem \ -f /var/lib/ssl/certs/`hostname`.pem Sometimes it will work, but 9 times out of 10 an "ipa-getcert list" will show the request failed with a status of CA_UNREACHABLE. I'm fairly certain it's not a time related issue as I tend to run the command just after enrolment and our NTP servers are rock solid. Now please correct me if I'm wrong (because it feels like I am wrong) but I think this is happening because not all of my replicas are Certificate Authorities but the clients are still trying to validate their certificate signing requests with them. Am I mistaken? Have I misconfigured something? If my theory is correct is there a way to force the client to only talk to the replica(s) running the CA service for these types of tasks? Anyway to try and get round the issue I decided to try and make all my IPA replicas Certificate Authorities and ran into the issue linked below Bug 905064 - ipa install error Unable to find preop.pin https://bugzilla.redhat.com/show_bug.cgi?id=905064 This has stopped me from rolling out the CA functionality across all of my replicas (and I almost trashed a replica in the process of trying to work around it). I'm not really bothered which way I go about solving the problem but would really appreciate some assistance as it feels like I'm stuck between a rock and a hard place. Thanks, Charlie -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.muriithi at gmail.com Sat Jan 11 21:00:13 2014 From: william.muriithi at gmail.com (William Muriithi) Date: Sat, 11 Jan 2014 16:00:13 -0500 Subject: [Freeipa-users] Updated doc, synchronization question Message-ID: > >>>> Two questions: > >>>> > >>>> - Any ETA on an updated 3.3.3 Users Guide? > >>> > >>> Our current plan is to release next documentation release along with > >>> FreeIPA > >>> 3.4, when more documentation fixes are factored in. > >>> Would you by any chance know when FreeIPA 3.4 will be realised? Looking to update a version 2.2 and would wait for 3.4 if its reasonably soon. William > >>> Just in case you would like to check the most recent status of the > >>> documentation work (or even help us with it), this page describes > >>> the details > >>> > >>> http://www.freeipa.org/page/Contribute/Documentation > >>> > >>> including instructions how to build HTMLs out of our git tree. > >>> > >> > >> Thanks, I'll take a look. > >> > >>>> - Is AD/IPA synchronization still supported in 3.3.3? Will it always? > >>> > >>> The AD/IPA synchronization is supported only in terms in bug fixes. > >>> As for the > >>> enhancements, the FreeIPA core team is focusing on the AD trusts: > >>> > >>> http://www.freeipa.org/page/Trusts > >>> > >>> (That does not mean we are not open to contributions from the > >>> community) > >>> > >>> Martin > >>> > >> > >> Thanks for the that link - the video was helpful. Although I'm > >> afraid that is > >> making me lean towards implementing the not recommended "split brain" > >> approach. Although one thing that is not clear to me is weather > >> doing this > >> consumes CALs for the linux machines since they authenticate against AD. > > Linux machines do not authenticate against AD DC in single sign-on > > case. Instead, usually Windows users obtain their Kerberos TGT upon > > logon to > > Windows machines and then use it to obtain tickets to services on Linux > > machines, by obtaining cross-realm TGT from AD DC and presenting it to > > IPA KDC as a proof. So in single sign-on case it works fine -- > > authentication against AD happens on AD side. > > > > Of course, when AD users attempt to log in with password to IPA > > resources, SSSD would perform communication with AD DC to obtain TGT on > > their behalf. There is AD DC involved in making a decision whether > > this AD user is allowed to authenticate. On Kerberos level, however, > > there are no limitations from where the authentication request comes > > (unless it is restricted with the firewalls). CALs play role on using > > Windows resources after authentication happened but in IPA AD trusts > > case currently only IPA resources can be consumed by AD users, IPA users > > cannot yet consume Windows resources and therefore get assigned rights > > to access them. > > > > To clarify the CAL part. > The CALs come in two shapes: per user and per host. > If it is per user and you have users in AD then regardless of how you > integrate with IPA you have to pay these CALs. > If your CALs is around hosts then they are based on the count of the > computer objects in AD. > If the client system is joined directly and has kerberos identity in AD > domain you have an object in AD that counts towards CALs. > If you have client joined to IPA and either trust or sync solution in > place the client is not a member of AD (no computer object in AD) and > this does not count towards CALs. > > HTH > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sun Jan 12 23:01:53 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 12 Jan 2014 18:01:53 -0500 Subject: [Freeipa-users] CA setup and ipa-gertcert questions In-Reply-To: References: Message-ID: <52D31EE1.4090305@redhat.com> On 01/11/2014 09:20 AM, Charlie Derwent wrote: > Hi > > I'm experiencing an issue trying to use ipa-getcert on my IPA clients. > > When I run a command similar to this > ipa-getcert request -K principal/`hostname` -D `hostname` \ > | ||-k /var/lib/ssl/private_keys/`hostname`.pem \| > | ||-f /var/lib/ssl/certs/`hostname`.pem| > > Sometimes it will work, but 9 times out of 10 an "ipa-getcert list" > will show the request failed with a status of CA_UNREACHABLE. I'm > fairly certain it's not a time related issue as I tend to run the > command just after enrolment and our NTP servers are rock solid. > > Now please correct me if I'm wrong (because it feels like I > am wrong) but I think this is happening because not all of my replicas > are Certificate Authorities but the clients are still trying to > validate their certificate signing requests with them. > > Am I mistaken? Have I misconfigured something? If my theory is > correct is there a way to force the client to only talk to the > replica(s) running the CA service for these types of tasks? > > Anyway to try and get round the issue I decided to try and make all my > IPA replicas Certificate Authorities and ran into the issue linked below > > Bug 905064 - ipa install error Unable to find preop.pin > https://bugzilla.redhat.com/show_bug.cgi?id=905064 > > This has stopped me from rolling out the CA functionality across all > of my replicas (and I almost trashed a replica in the process of > trying to work around it). > > I'm not really bothered which way I go about solving the problem but > would really appreciate some assistance as it feels like I'm stuck > between a rock and a hard place. > > Thanks, > Charlie > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Even if the replica does not have CA it has code to turn around and proxy request to the corresponding replica that has CA. The first thing to check is the logs on the certmonger side that does the certificate request to see which replica it is trying to connect and httpd logs from the replica it tries to hit. If the requests do not hit (which I suspect the case since the client returned CA_UNREACHABLE) then it might be a firewall issue between the client and the replica. If it hits the server but server fails to proxy and returns CA_UNREACHABLE to the client then it is probably a FW issue between replicas. At least this is where I would dig. Also the bug you mentioned is a race condition and seems like a rare one so there is a chance it would not happen all the time if you try more than once or may be choose a different system. Do you hit every time you try? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sun Jan 12 23:04:32 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 12 Jan 2014 18:04:32 -0500 Subject: [Freeipa-users] Updated doc, synchronization question In-Reply-To: References: Message-ID: <52D31F80.5050206@redhat.com> On 01/11/2014 04:00 PM, William Muriithi wrote: > > > > >>>> Two questions: > > >>>> > > >>>> - Any ETA on an updated 3.3.3 Users Guide? > > >>> > > >>> Our current plan is to release next documentation release along with > > >>> FreeIPA > > >>> 3.4, when more documentation fixes are factored in. > > >>> > > Would you by any chance know when FreeIPA 3.4 will be realised? > > Looking to update a version 2.2 and would wait for 3.4 if its > reasonably soon. > We planned for Feb but it seems like it would slip. How much is unclear. We might reduce the scope and cut it earlier (I mean do not slip too much) or try to keep the scope and extend the time couple months. We will decide in early Feb. Sorry not to have a more precise answer. Thanks Dmitri > William > > > >>> Just in case you would like to check the most recent status of the > > >>> documentation work (or even help us with it), this page describes > > >>> the details > > >>> > > >>> http://www.freeipa.org/page/Contribute/Documentation > > >>> > > >>> including instructions how to build HTMLs out of our git tree. > > >>> > > >> > > >> Thanks, I'll take a look. > > >> > > >>>> - Is AD/IPA synchronization still supported in 3.3.3? Will it > always? > > >>> > > >>> The AD/IPA synchronization is supported only in terms in bug fixes. > > >>> As for the > > >>> enhancements, the FreeIPA core team is focusing on the AD trusts: > > >>> > > >>> http://www.freeipa.org/page/Trusts > > >>> > > >>> (That does not mean we are not open to contributions from the > > >>> community) > > >>> > > >>> Martin > > >>> > > >> > > >> Thanks for the that link - the video was helpful. Although I'm > > >> afraid that is > > >> making me lean towards implementing the not recommended "split brain" > > >> approach. Although one thing that is not clear to me is weather > > >> doing this > > >> consumes CALs for the linux machines since they authenticate > against AD. > > > Linux machines do not authenticate against AD DC in single sign-on > > > case. Instead, usually Windows users obtain their Kerberos TGT upon > > > logon to > > > Windows machines and then use it to obtain tickets to services on > Linux > > > machines, by obtaining cross-realm TGT from AD DC and presenting it to > > > IPA KDC as a proof. So in single sign-on case it works fine -- > > > authentication against AD happens on AD side. > > > > > > Of course, when AD users attempt to log in with password to IPA > > > resources, SSSD would perform communication with AD DC to obtain > TGT on > > > their behalf. There is AD DC involved in making a decision whether > > > this AD user is allowed to authenticate. On Kerberos level, however, > > > there are no limitations from where the authentication request comes > > > (unless it is restricted with the firewalls). CALs play role on using > > > Windows resources after authentication happened but in IPA AD trusts > > > case currently only IPA resources can be consumed by AD users, IPA > users > > > cannot yet consume Windows resources and therefore get assigned rights > > > to access them. > > > > > > > To clarify the CAL part. > > The CALs come in two shapes: per user and per host. > > If it is per user and you have users in AD then regardless of how you > > integrate with IPA you have to pay these CALs. > > If your CALs is around hosts then they are based on the count of the > > computer objects in AD. > > If the client system is joined directly and has kerberos identity in AD > > domain you have an object in AD that counts towards CALs. > > If you have client joined to IPA and either trust or sync solution in > > place the client is not a member of AD (no computer object in AD) and > > this does not count towards CALs. > > > > HTH > > > > > > > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager for IdM portfolio > > Red Hat Inc. > > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shelltoesuperstar at gmail.com Sun Jan 12 23:53:00 2014 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Sun, 12 Jan 2014 23:53:00 +0000 Subject: [Freeipa-users] CA setup and ipa-gertcert questions In-Reply-To: <52D31EE1.4090305@redhat.com> References: <52D31EE1.4090305@redhat.com> Message-ID: On Sun, Jan 12, 2014 at 11:01 PM, Dmitri Pal wrote: > On 01/11/2014 09:20 AM, Charlie Derwent wrote: > > Hi > > I'm experiencing an issue trying to use ipa-getcert on my IPA clients. > > When I run a command similar to this > ipa-getcert request -K principal/`hostname` -D `hostname` \ > -k /var/lib/ssl/private_keys/`hostname`.pem \ > -f /var/lib/ssl/certs/`hostname`.pem > > Sometimes it will work, but 9 times out of 10 an "ipa-getcert list" will > show the request failed with a status of CA_UNREACHABLE. I'm fairly certain > it's not a time related issue as I tend to run the command just after > enrolment and our NTP servers are rock solid. > > Now please correct me if I'm wrong (because it feels like I > am wrong) but I think this is happening because not all of my replicas are > Certificate Authorities but the clients are still trying to validate their > certificate signing requests with them. > > Am I mistaken? Have I misconfigured something? If my theory is > correct is there a way to force the client to only talk to the replica(s) > running the CA service for these types of tasks? > > Anyway to try and get round the issue I decided to try and make all my > IPA replicas Certificate Authorities and ran into the issue linked below > > Bug 905064 - ipa install error Unable to find preop.pin > https://bugzilla.redhat.com/show_bug.cgi?id=905064 > > This has stopped me from rolling out the CA functionality across all of > my replicas (and I almost trashed a replica in the process of trying to > work around it). > > I'm not really bothered which way I go about solving the problem but > would really appreciate some assistance as it feels like I'm stuck between > a rock and a hard place. > > Thanks, > Charlie > > > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > Even if the replica does not have CA it has code to turn around and proxy > request to the corresponding replica that has CA. > The first thing to check is the logs on the certmonger side that does the > certificate request to see which replica it is trying to connect and httpd > logs from the replica it tries to hit. If the requests do not hit (which I > suspect the case since the client returned CA_UNREACHABLE) then it might be > a firewall issue between the client and the replica. If it hits the server > but server fails to proxy and returns CA_UNREACHABLE to the client then it > is probably a FW issue between replicas. > > At least this is where I would dig. > > Also the bug you mentioned is a race condition and seems like a rare one > so there is a chance it would not happen all the time if you try more than > once or may be choose a different system. > Do you hit every time you try? > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > Thanks for the tips regarding the CA authorization chain I'll try to take a closer log at the logs now I know what I'm looking for. Regarding the replica CA setup, once the installation failed the first time I didn't get another chance. No matter what I did the replica was convinced there was another CA already installed. I even resorted to uninstalling the replica completely by running "ipa-setup-install --uninstall" a few times consecutively to make sure everything was gone but whenever I tried to re-install adding the --setup-ca option it didn't work. I assumed there was a file or a service I had to stop or remove to get it going again so when I found this bug here https://bugzilla.redhat.com/show_bug.cgi?id=953488 I followed Tomas' steps in comment 4, not all the paths were the same (differences between IPA 3.0.0 and 3.2.0 I assume) but still no success. In the end dropping the --setup-ca option and reinstalling got me back to where I had left off. Was there a file/service I missed? I appreciate the help. Thanks Charlie -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Jan 13 08:34:03 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 13 Jan 2014 09:34:03 +0100 Subject: [Freeipa-users] CA setup and ipa-gertcert questions In-Reply-To: References: <52D31EE1.4090305@redhat.com> Message-ID: <52D3A4FB.6060604@redhat.com> On 01/13/2014 12:53 AM, Charlie Derwent wrote: > On Sun, Jan 12, 2014 at 11:01 PM, Dmitri Pal wrote: > >> On 01/11/2014 09:20 AM, Charlie Derwent wrote: >> >> Hi >> >> I'm experiencing an issue trying to use ipa-getcert on my IPA clients. >> >> When I run a command similar to this >> ipa-getcert request -K principal/`hostname` -D `hostname` \ >> -k /var/lib/ssl/private_keys/`hostname`.pem \ >> -f /var/lib/ssl/certs/`hostname`.pem >> >> Sometimes it will work, but 9 times out of 10 an "ipa-getcert list" will >> show the request failed with a status of CA_UNREACHABLE. I'm fairly certain >> it's not a time related issue as I tend to run the command just after >> enrolment and our NTP servers are rock solid. >> >> Now please correct me if I'm wrong (because it feels like I >> am wrong) but I think this is happening because not all of my replicas are >> Certificate Authorities but the clients are still trying to validate their >> certificate signing requests with them. >> >> Am I mistaken? Have I misconfigured something? If my theory is >> correct is there a way to force the client to only talk to the replica(s) >> running the CA service for these types of tasks? >> >> Anyway to try and get round the issue I decided to try and make all my >> IPA replicas Certificate Authorities and ran into the issue linked below >> >> Bug 905064 - ipa install error Unable to find preop.pin >> https://bugzilla.redhat.com/show_bug.cgi?id=905064 >> >> This has stopped me from rolling out the CA functionality across all of >> my replicas (and I almost trashed a replica in the process of trying to >> work around it). >> >> I'm not really bothered which way I go about solving the problem but >> would really appreciate some assistance as it feels like I'm stuck between >> a rock and a hard place. >> >> Thanks, >> Charlie >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> Even if the replica does not have CA it has code to turn around and proxy >> request to the corresponding replica that has CA. >> The first thing to check is the logs on the certmonger side that does the >> certificate request to see which replica it is trying to connect and httpd >> logs from the replica it tries to hit. If the requests do not hit (which I >> suspect the case since the client returned CA_UNREACHABLE) then it might be >> a firewall issue between the client and the replica. If it hits the server >> but server fails to proxy and returns CA_UNREACHABLE to the client then it >> is probably a FW issue between replicas. >> >> At least this is where I would dig. >> >> Also the bug you mentioned is a race condition and seems like a rare one >> so there is a chance it would not happen all the time if you try more than >> once or may be choose a different system. >> Do you hit every time you try? >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs?www.redhat.com/carveoutcosts/ >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > Thanks for the tips regarding the CA authorization chain I'll try to take a > closer log at the logs now I know what I'm looking for. > > Regarding the replica CA setup, once the installation failed the first time > I didn't get another chance. No matter what I did the replica was convinced > there was another CA already installed. I even resorted to uninstalling the > replica completely by running "ipa-setup-install --uninstall" a few times > consecutively to make sure everything was gone but whenever I tried to > re-install adding the --setup-ca option it didn't work. > > I assumed there was a file or a service I had to stop or remove to get it > going again so when I found this bug here > https://bugzilla.redhat.com/show_bug.cgi?id=953488 I followed Tomas' steps > in comment 4, not all the paths were the same (differences between IPA > 3.0.0 and 3.2.0 I assume) but still no success. > > In the end dropping the --setup-ca option and reinstalling got me back to > where I had left off. > > Was there a file/service I missed? I appreciate the help. > Thanks > Charlie It is hard to tell what went wrong without logs from ipareplica-install.log or PKI. But I would guess that the failed PKI instance is still here and not being uninstalled by IPA uninstaller. Tomas' instructions were for Dogtag 10 based CA, while you seem to use Dogtag 9. You can try uninstalling the Dogtag 9 based CA instance with following command run on the replica with broken CA (if it is still there): # /usr/bin/pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca --force If that does not help, we would need the logs to continue investigating. Martin From fvzwieten at vxcompany.com Mon Jan 13 13:41:57 2014 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Mon, 13 Jan 2014 14:41:57 +0100 Subject: [Freeipa-users] Sudo rule processing order In-Reply-To: <52D01FC6.6090108@redhat.com> References: <52D00ACC.505@redhat.com> <52D01CFE.1030305@redhat.com> <52D01FC6.6090108@redhat.com> Message-ID: Martin, Sorry for the late reply. Thanks for spotting this. I suspect I cannot "just" change ldap in our IPA. This is part of a production environment consisting solely of supported RHEL 6.4 servers. I can snapshot the IPA servers (they are VM's) to be able to roll back in case of trouble, but I am not sure such a change is "supported". Fred On Fri, Jan 10, 2014 at 5:28 PM, Martin Kosek wrote: > Ah, I think I found the root cause. Our sudoers compat tree configuration > missed out the sudoOrder attribute. The order was thus missing in LDAP > sudoers > and thus ineffective. I filed an upstream ticket to fix it: > https://fedorahosted.org/freeipa/ticket/4107 > > However, to hotfix it in your environment, could you try manually fixing > the > configuration on your FreeIPA server? > > $ ldapmodify -h `hostname` -D "cn=Directory Manager" -x -W > dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config > changetype: modify > add: schema-compat-entry-attribute > schema-compat-entry-attribute: sudoOrder=%{sudoOrder} > > > This should do the trick. > > Martin > > On 01/10/2014 05:17 PM, Martin Kosek wrote: > > On 01/10/2014 04:52 PM, Fred van Zwieten wrote: > >> Yes, you would expect that to help, wouldn't you :-) > > > > Yes, I would :-) > > > >> > >> Didn't even know this existed. Thanks for that. > >> > >> User has 3 sudo rules. I have set the allow_all rule to 1, the second > rule > >> to 2 and the cobbler (with the "!authenticate" option) rule to 99: > > > > What is the version of the SUDO on your system? According to > > http://www.sudo.ws/sudoers.ldap.man.html > > it was implemented in SUDO 1.7.5. > > > > Martin > > > >> > >> User ******** may run the following commands on this host: > >> (root) ALL > >> (root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls, > /bin/more, > >> /usr/bin/less, !/bin/su > >> (root) NOPASSWD: /usr/bin/cobbler > >> (root) !/bin/su > >> > >> Nope. Didn't help. > >> > >> Fred > >> > >> On Fri, Jan 10, 2014 at 3:59 PM, Martin Kosek > wrote: > >> > >>> On 01/10/2014 11:52 AM, Fred van Zwieten wrote: > >>>> Hi, > >>>> > >>>> I have a sudo rule in IPA that has the !authenticate option added to > >>> enable > >>>> admins to execute certain programs as root without authentication. > >>>> > >>>> It doesn't work. There is another rule for the admins that allow all > >>>> commands as long as they give their password. > >>>> > >>>> In a sudoers file, you can solve this by specifing the nopasswd rule > as > >>>> last. > >>>> > >>>> sudo -l from an IPA-client gives me this: > >>>> > >>>> *******@svr001 ~]$ sudo -l > >>>> Matching Defaults entries for ******* on this host: > >>>> requiretty, !visiblepw, always_set_home, 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 ******** may run the following commands on this host: > >>>> (root) NOPASSWD: ALL > >>>> (root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls, > >>> /bin/more, > >>>> /usr/bin/less, !/bin/su > >>>> (root) NOPASSWD: /usr/bin/cobbler > >>>> (root) !/bin/su > >>>> > >>>> I want the cobbler command to run without password authentication. > What > >>> am > >>>> I doing wrong? > >>>> > >>> > >>> Would setting SUDO rule order help? > >>> > >>> # ipa sudorule-mod -h > >>> ... > >>> --order=INT integer to order the Sudo rules > >>> ... > >>> > >>> Martin > >>> > >>> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigbjorn at nixtra.com Mon Jan 13 14:30:31 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 13 Jan 2014 15:30:31 +0100 (CET) Subject: [Freeipa-users] Certificate system unavailable Message-ID: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> Hi, I seem to have issues with the certificate system on my IPA installation. Looking up hosts in the IPA WEBUI on any of the IPA servers says "Certificate format error: [Errno -8015] error (-8015) unknown". I also notice that hosts says the certificate system is unavailable. certmonger: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Failure decoding Certificate Signing Request). Looking at the pki-ca logs on the ipa servers I see that some selftest failed: # tail -100 selftests.log 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Initializing self test plugins: 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: Running self test plugins specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] CAPresence: CA is present 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: system certs verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The CRITICAL self test plugin called selftests.container.instance.SystemCertsVerification running at startup FAILED! the pki-cad service is running and "pki-cad status" displays the ports available. /etc/init.d/pki-cad status pki-ca (pid 28697) is running... [ OK ] My main consern is that the certmonger requests for renew of certificates for LDAP on 2 out of 3 of the IPA servers has failed, and the current certificate is expiring the 19th of January, under a week from now. Do you have any suggestions to where I can start troubleshootng this issue? Regards, Siggi From tizone at gmail.com Mon Jan 13 13:35:01 2014 From: tizone at gmail.com (tizo) Date: Mon, 13 Jan 2014 11:35:01 -0200 Subject: [Freeipa-users] About Freeipa Message-ID: Hi there, We have a working authentication system for GNU/Linux consisting in a Mit Kerberos Server, and an OpenLDAP directory with a particular structure. I was wondering if we could use Freeipa to administer those working components as they are, without having to deploy a new Freeipa server from scratch. Thanks, tizo -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Jan 13 14:50:23 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 13 Jan 2014 16:50:23 +0200 Subject: [Freeipa-users] About Freeipa In-Reply-To: References: Message-ID: <20140113145023.GB12003@redhat.com> On Mon, 13 Jan 2014, tizo wrote: >Hi there, > >We have a working authentication system for GNU/Linux consisting in a Mit >Kerberos Server, and an OpenLDAP directory with a particular structure. I >was wondering if we could use Freeipa to administer those working >components as they are, without having to deploy a new Freeipa server from >scratch. In short, no, it is not possible. -- / Alexander Bokovoy From rcritten at redhat.com Mon Jan 13 14:58:24 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 13 Jan 2014 09:58:24 -0500 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> Message-ID: <52D3FF10.3060504@redhat.com> Sigbjorn Lie wrote: > Hi, > > I seem to have issues with the certificate system on my IPA installation. Looking up hosts in the > IPA WEBUI on any of the IPA servers says "Certificate format error: [Errno -8015] error (-8015) > unknown". > > I also notice that hosts says the certificate system is unavailable. > > certmonger: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation > cannot be completed: Failure decoding Certificate Signing Request). > > > Looking at the pki-ca logs on the ipa servers I see that some selftest failed: > > # tail -100 selftests.log > 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Initializing self test plugins: > 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin > logger parameters > 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin > instances > 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin > instance parameters > 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in > on-demand order > 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in > startup order > 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test plugins have been > successfully loaded! > 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: Running self test plugins > specified to be executed at startup: > 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] CAPresence: CA is present > 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: system certs > verification failure > 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The CRITICAL self test plugin > called selftests.container.instance.SystemCertsVerification running at startup FAILED! > > the pki-cad service is running and "pki-cad status" displays the ports available. > /etc/init.d/pki-cad status > pki-ca (pid 28697) is running... [ OK ] > > > My main consern is that the certmonger requests for renew of certificates for LDAP on 2 out of 3 > of the IPA servers has failed, and the current certificate is expiring the 19th of January, under > a week from now. > > Do you have any suggestions to where I can start troubleshootng this issue? Check the trust on the audit certificate: # certutil -L -d /var/lib/pki-ca/alias/ ... auditSigningCert cert-pki-ca u,u,Pu If the trust is not u,u,Pu then you can fix it with: # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' -t u,u,Pu Then restart the CA and it should be ok. What is the status on the failed certmonger requests? rob From sigbjorn at nixtra.com Mon Jan 13 15:07:16 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 13 Jan 2014 16:07:16 +0100 (CET) Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <52D3FF10.3060504@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> Message-ID: <32553.213.225.75.97.1389625636.squirrel@www.nixtra.com> Hi, Thank you for your prompt reply Rob. On Mon, January 13, 2014 15:58, Rob Crittenden wrote: > Sigbjorn Lie wrote: > >> Hi, >> >> >> I seem to have issues with the certificate system on my IPA installation. Looking up hosts in >> the IPA WEBUI on any of the IPA servers says "Certificate format error: [Errno -8015] error >> (-8015) >> unknown". >> >> I also notice that hosts says the certificate system is unavailable. >> >> >> certmonger: Server failed request, will retry: 4301 (RPC failed at server. Certificate >> operation cannot be completed: Failure decoding Certificate Signing Request). >> >> >> Looking at the pki-ca logs on the ipa servers I see that some selftest failed: >> >> >> # tail -100 selftests.log >> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Initializing self test >> plugins: >> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test >> plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: >> loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] >> SelfTestSubsystem: loading all self test plugin >> instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading >> self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] >> SelfTestSubsystem: loading self test plugins in >> startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test >> plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] >> SelfTestSubsystem: Running self test plugins >> specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] CAPresence: >> CA is present >> 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: system certs >> verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The >> CRITICAL self test plugin >> called selftests.container.instance.SystemCertsVerification running at startup FAILED! >> >> the pki-cad service is running and "pki-cad status" displays the ports available. >> /etc/init.d/pki-cad status >> pki-ca (pid 28697) is running... [ OK ] >> >> >> My main consern is that the certmonger requests for renew of certificates for LDAP on 2 out of >> 3 >> of the IPA servers has failed, and the current certificate is expiring the 19th of January, >> under a week from now. >> >> Do you have any suggestions to where I can start troubleshootng this issue? >> > > Check the trust on the audit certificate: > > > # certutil -L -d /var/lib/pki-ca/alias/ > ... > auditSigningCert cert-pki-ca u,u,Pu All the 3 ipa servers return u,u,Pu for auditSigningCert # certutil -L -d /var/lib/pki-ca/alias/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI caSigningCert cert-pki-ca CTu,Cu,Cu Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u > > If the trust is not u,u,Pu then you can fix it with: > > > # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' > -t u,u,Pu > > > Then restart the CA and it should be ok. > I have restarted the dirsrv for PKI-IPA, and the pki-cad service on all 3 IPA servers. > > What is the status on the failed certmonger requests? After I restarted dirsrv, pki-cad and then the httpd on ipa01 the status of the request is now: Request ID '20120119194518': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://ipa01.dns.domain:443/ca/agent/ca/displayBySerial': [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-DNS-DOMAIN//pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=DNS-DOMAIN subject: CN=ipa01.dns.domain,O=DNS-DOMAIN expires: 2014-01-19 19:45:18 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes However I cannot find the certificate that's expired? Regards, Siggi From rcritten at redhat.com Mon Jan 13 15:17:39 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 13 Jan 2014 10:17:39 -0500 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <32553.213.225.75.97.1389625636.squirrel@www.nixtra.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32553.213.225.75.97.1389625636.squirrel@www.nixtra.com> Message-ID: <52D40393.4060108@redhat.com> Sigbjorn Lie wrote: > Hi, > > Thank you for your prompt reply Rob. > > > On Mon, January 13, 2014 15:58, Rob Crittenden wrote: >> Sigbjorn Lie wrote: >> >>> Hi, >>> >>> >>> I seem to have issues with the certificate system on my IPA installation. Looking up hosts in >>> the IPA WEBUI on any of the IPA servers says "Certificate format error: [Errno -8015] error >>> (-8015) >>> unknown". >>> >>> I also notice that hosts says the certificate system is unavailable. >>> >>> >>> certmonger: Server failed request, will retry: 4301 (RPC failed at server. Certificate >>> operation cannot be completed: Failure decoding Certificate Signing Request). >>> >>> >>> Looking at the pki-ca logs on the ipa servers I see that some selftest failed: >>> >>> >>> # tail -100 selftests.log >>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Initializing self test >>> plugins: >>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test >>> plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: >>> loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] >>> SelfTestSubsystem: loading all self test plugin >>> instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading >>> self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] >>> SelfTestSubsystem: loading self test plugins in >>> startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test >>> plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] >>> SelfTestSubsystem: Running self test plugins >>> specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] CAPresence: >>> CA is present >>> 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: system certs >>> verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The >>> CRITICAL self test plugin >>> called selftests.container.instance.SystemCertsVerification running at startup FAILED! >>> >>> the pki-cad service is running and "pki-cad status" displays the ports available. >>> /etc/init.d/pki-cad status >>> pki-ca (pid 28697) is running... [ OK ] >>> >>> >>> My main consern is that the certmonger requests for renew of certificates for LDAP on 2 out of >>> 3 >>> of the IPA servers has failed, and the current certificate is expiring the 19th of January, >>> under a week from now. >>> >>> Do you have any suggestions to where I can start troubleshootng this issue? >>> >> >> Check the trust on the audit certificate: >> >> >> # certutil -L -d /var/lib/pki-ca/alias/ >> ... >> auditSigningCert cert-pki-ca u,u,Pu > > All the 3 ipa servers return u,u,Pu for auditSigningCert > > # certutil -L -d /var/lib/pki-ca/alias/ > > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > > caSigningCert cert-pki-ca CTu,Cu,Cu > Server-Cert cert-pki-ca u,u,u > auditSigningCert cert-pki-ca u,u,Pu > ocspSigningCert cert-pki-ca u,u,u > subsystemCert cert-pki-ca u,u,u > >> >> If the trust is not u,u,Pu then you can fix it with: >> >> >> # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' >> -t u,u,Pu >> >> >> Then restart the CA and it should be ok. >> > > I have restarted the dirsrv for PKI-IPA, and the pki-cad service on all 3 IPA servers. > >> >> What is the status on the failed certmonger requests? > > After I restarted dirsrv, pki-cad and then the httpd on ipa01 the status of the request is now: > > Request ID '20120119194518': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: 907 (RPC failed at server. cannot connect to > 'https://ipa01.dns.domain:443/ca/agent/ca/displayBySerial': [Errno -12269] > (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS Certificate > DB',pinfile='/etc/dirsrv/slapd-DNS-DOMAIN//pwdfile.txt' > certificate: type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=DNS-DOMAIN > subject: CN=ipa01.dns.domain,O=DNS-DOMAIN > expires: 2014-01-19 19:45:18 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > > However I cannot find the certificate that's expired? Can provide the output of getcert rather than ipa-getcert? It will show additional certificates that are issued/renewed outside of the IPA API. rob From mkosek at redhat.com Mon Jan 13 15:18:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 13 Jan 2014 16:18:15 +0100 Subject: [Freeipa-users] Sudo rule processing order In-Reply-To: References: <52D00ACC.505@redhat.com> <52D01CFE.1030305@redhat.com> <52D01FC6.6090108@redhat.com> Message-ID: <52D403B7.2030606@redhat.com> Ok, that's up to your preference. The hotfix below worked for me in my test environment and is pretty low risk. But of course, it is not "RHEL rubber stamped". Eventually, you can evaluate the fix yourself in a test environment. HTH, Martin On 01/13/2014 02:41 PM, Fred van Zwieten wrote: > Martin, > > Sorry for the late reply. > > Thanks for spotting this. I suspect I cannot "just" change ldap in our IPA. > This is part of a production environment consisting solely of supported > RHEL 6.4 servers. I can snapshot the IPA servers (they are VM's) to be able > to roll back in case of trouble, but I am not sure such a change is > "supported". > > Fred > > > On Fri, Jan 10, 2014 at 5:28 PM, Martin Kosek wrote: > >> Ah, I think I found the root cause. Our sudoers compat tree configuration >> missed out the sudoOrder attribute. The order was thus missing in LDAP >> sudoers >> and thus ineffective. I filed an upstream ticket to fix it: >> https://fedorahosted.org/freeipa/ticket/4107 >> >> However, to hotfix it in your environment, could you try manually fixing >> the >> configuration on your FreeIPA server? >> >> $ ldapmodify -h `hostname` -D "cn=Directory Manager" -x -W >> dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config >> changetype: modify >> add: schema-compat-entry-attribute >> schema-compat-entry-attribute: sudoOrder=%{sudoOrder} >> >> >> This should do the trick. >> >> Martin >> >> On 01/10/2014 05:17 PM, Martin Kosek wrote: >>> On 01/10/2014 04:52 PM, Fred van Zwieten wrote: >>>> Yes, you would expect that to help, wouldn't you :-) >>> >>> Yes, I would :-) >>> >>>> >>>> Didn't even know this existed. Thanks for that. >>>> >>>> User has 3 sudo rules. I have set the allow_all rule to 1, the second >> rule >>>> to 2 and the cobbler (with the "!authenticate" option) rule to 99: >>> >>> What is the version of the SUDO on your system? According to >>> http://www.sudo.ws/sudoers.ldap.man.html >>> it was implemented in SUDO 1.7.5. >>> >>> Martin >>> >>>> >>>> User ******** may run the following commands on this host: >>>> (root) ALL >>>> (root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls, >> /bin/more, >>>> /usr/bin/less, !/bin/su >>>> (root) NOPASSWD: /usr/bin/cobbler >>>> (root) !/bin/su >>>> >>>> Nope. Didn't help. >>>> >>>> Fred >>>> >>>> On Fri, Jan 10, 2014 at 3:59 PM, Martin Kosek >> wrote: >>>> >>>>> On 01/10/2014 11:52 AM, Fred van Zwieten wrote: >>>>>> Hi, >>>>>> >>>>>> I have a sudo rule in IPA that has the !authenticate option added to >>>>> enable >>>>>> admins to execute certain programs as root without authentication. >>>>>> >>>>>> It doesn't work. There is another rule for the admins that allow all >>>>>> commands as long as they give their password. >>>>>> >>>>>> In a sudoers file, you can solve this by specifing the nopasswd rule >> as >>>>>> last. >>>>>> >>>>>> sudo -l from an IPA-client gives me this: >>>>>> >>>>>> *******@svr001 ~]$ sudo -l >>>>>> Matching Defaults entries for ******* on this host: >>>>>> requiretty, !visiblepw, always_set_home, 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 ******** may run the following commands on this host: >>>>>> (root) NOPASSWD: ALL >>>>>> (root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls, >>>>> /bin/more, >>>>>> /usr/bin/less, !/bin/su >>>>>> (root) NOPASSWD: /usr/bin/cobbler >>>>>> (root) !/bin/su >>>>>> >>>>>> I want the cobbler command to run without password authentication. >> What >>>>> am >>>>>> I doing wrong? >>>>>> >>>>> >>>>> Would setting SUDO rule order help? >>>>> >>>>> # ipa sudorule-mod -h >>>>> ... >>>>> --order=INT integer to order the Sudo rules >>>>> ... >>>>> >>>>> Martin >>>>> >>>>> >>>> >>> >> >> > From pspacek at redhat.com Mon Jan 13 15:24:41 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 13 Jan 2014 16:24:41 +0100 Subject: [Freeipa-users] Migration from OpenLDAP In-Reply-To: <20140113145023.GB12003@redhat.com> References: <20140113145023.GB12003@redhat.com> Message-ID: <52D40539.1010103@redhat.com> On 13.1.2014 15:50, Alexander Bokovoy wrote: > On Mon, 13 Jan 2014, tizo wrote: >> Hi there, >> >> We have a working authentication system for GNU/Linux consisting in a Mit >> Kerberos Server, and an OpenLDAP directory with a particular structure. I >> was wondering if we could use Freeipa to administer those working >> components as they are, without having to deploy a new Freeipa server from >> scratch. > In short, no, it is not possible. I would like to elaborate this a bit more: You really can't use FreeIPA WebUI with home-grown LDAP+Kerberos system, but FreeIPA provides migrate-ds scripts which ease the transition from OpenLDAP. Please see http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Migrating_from_a_Directory_Server_to_IPA.html You need to migrate OpenLDAP data to one FreeIPA server and then you can simply create FreeIPA server replicas as need. In other words, the migrate-ds script is run only once even if you have multiple servers with replicated data. There are some limited capabilities for migration with user passwords, but I will let other people to elaborate - this is not area of my expertise. Let us know if you need any assistance during migration. -- Petr^2 Spacek From sigbjorn at nixtra.com Mon Jan 13 15:29:16 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 13 Jan 2014 16:29:16 +0100 (CET) Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <52D3FF10.3060504@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> Message-ID: <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> On Mon, January 13, 2014 15:58, Rob Crittenden wrote: > Sigbjorn Lie wrote: > >> Hi, >> >> >> I seem to have issues with the certificate system on my IPA installation. Looking up hosts in >> the IPA WEBUI on any of the IPA servers says "Certificate format error: [Errno -8015] error >> (-8015) >> unknown". >> >> I also notice that hosts says the certificate system is unavailable. >> >> >> certmonger: Server failed request, will retry: 4301 (RPC failed at server. Certificate >> operation cannot be completed: Failure decoding Certificate Signing Request). >> >> >> Looking at the pki-ca logs on the ipa servers I see that some selftest failed: >> >> >> # tail -100 selftests.log >> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Initializing self test >> plugins: >> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test >> plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: >> loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] >> SelfTestSubsystem: loading all self test plugin >> instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading >> self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] >> SelfTestSubsystem: loading self test plugins in >> startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test >> plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] >> SelfTestSubsystem: Running self test plugins >> specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] CAPresence: >> CA is present >> 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: system certs >> verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The >> CRITICAL self test plugin >> called selftests.container.instance.SystemCertsVerification running at startup FAILED! >> >> the pki-cad service is running and "pki-cad status" displays the ports available. >> /etc/init.d/pki-cad status >> pki-ca (pid 28697) is running... [ OK ] >> >> >> My main consern is that the certmonger requests for renew of certificates for LDAP on 2 out of >> 3 >> of the IPA servers has failed, and the current certificate is expiring the 19th of January, >> under a week from now. >> >> Do you have any suggestions to where I can start troubleshootng this issue? >> > > Check the trust on the audit certificate: > > > # certutil -L -d /var/lib/pki-ca/alias/ > ... > auditSigningCert cert-pki-ca u,u,Pu > > If the trust is not u,u,Pu then you can fix it with: > > > # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' > -t u,u,Pu > > > Then restart the CA and it should be ok. > Looks like this certificate is expired. This is the same output on all 3 of the ipa servers. How can this be fixed? # certutil -L -d /var/lib/pki-ca/alias/ -n "auditSigningCert cert-pki-ca" Certificate: Data: Version: 3 (0x2) Serial Number: 5 (0x5) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: "CN=Certificate Authority,O=DNS.DOMAIN" Validity: Not Before: Thu Jan 19 19:44:24 2012 Not After : Wed Jan 08 19:44:24 2014 From rcritten at redhat.com Mon Jan 13 15:34:30 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 13 Jan 2014 10:34:30 -0500 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> Message-ID: <52D40786.5070401@redhat.com> Sigbjorn Lie wrote: > > > > On Mon, January 13, 2014 15:58, Rob Crittenden wrote: >> Sigbjorn Lie wrote: >> >>> Hi, >>> >>> >>> I seem to have issues with the certificate system on my IPA installation. Looking up hosts in >>> the IPA WEBUI on any of the IPA servers says "Certificate format error: [Errno -8015] error >>> (-8015) >>> unknown". >>> >>> I also notice that hosts says the certificate system is unavailable. >>> >>> >>> certmonger: Server failed request, will retry: 4301 (RPC failed at server. Certificate >>> operation cannot be completed: Failure decoding Certificate Signing Request). >>> >>> >>> Looking at the pki-ca logs on the ipa servers I see that some selftest failed: >>> >>> >>> # tail -100 selftests.log >>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Initializing self test >>> plugins: >>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test >>> plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: >>> loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] >>> SelfTestSubsystem: loading all self test plugin >>> instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading >>> self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] >>> SelfTestSubsystem: loading self test plugins in >>> startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test >>> plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] >>> SelfTestSubsystem: Running self test plugins >>> specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] CAPresence: >>> CA is present >>> 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: system certs >>> verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The >>> CRITICAL self test plugin >>> called selftests.container.instance.SystemCertsVerification running at startup FAILED! >>> >>> the pki-cad service is running and "pki-cad status" displays the ports available. >>> /etc/init.d/pki-cad status >>> pki-ca (pid 28697) is running... [ OK ] >>> >>> >>> My main consern is that the certmonger requests for renew of certificates for LDAP on 2 out of >>> 3 >>> of the IPA servers has failed, and the current certificate is expiring the 19th of January, >>> under a week from now. >>> >>> Do you have any suggestions to where I can start troubleshootng this issue? >>> >> >> Check the trust on the audit certificate: >> >> >> # certutil -L -d /var/lib/pki-ca/alias/ >> ... >> auditSigningCert cert-pki-ca u,u,Pu >> >> If the trust is not u,u,Pu then you can fix it with: >> >> >> # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' >> -t u,u,Pu >> >> >> Then restart the CA and it should be ok. >> > > Looks like this certificate is expired. This is the same output on all 3 of the ipa servers. > > How can this be fixed? > > > # certutil -L -d /var/lib/pki-ca/alias/ -n "auditSigningCert cert-pki-ca" > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 5 (0x5) > Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption > Issuer: "CN=Certificate Authority,O=DNS.DOMAIN" > Validity: > Not Before: Thu Jan 19 19:44:24 2012 > Not After : Wed Jan 08 19:44:24 2014 > > Go back in time to the 7th or 8th and run: # getcert resubmit -d /var/lib/pki-ca/alias -n "auditSigningCert cert-pki-ca" There may be other certs in a similar situation. getcert list will show you. rob From sigbjorn at nixtra.com Mon Jan 13 15:43:52 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 13 Jan 2014 16:43:52 +0100 (CET) Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <52D40786.5070401@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> Message-ID: <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> On Mon, January 13, 2014 16:34, Rob Crittenden wrote: > Sigbjorn Lie wrote: > >> >> >> >> On Mon, January 13, 2014 15:58, Rob Crittenden wrote: >> >>> Sigbjorn Lie wrote: >>> >>> >>>> Hi, >>>> >>>> >>>> >>>> I seem to have issues with the certificate system on my IPA installation. Looking up hosts >>>> in the IPA WEBUI on any of the IPA servers says "Certificate format error: [Errno -8015] >>>> error (-8015) >>>> unknown". >>>> >>>> I also notice that hosts says the certificate system is unavailable. >>>> >>>> >>>> >>>> certmonger: Server failed request, will retry: 4301 (RPC failed at server. Certificate >>>> operation cannot be completed: Failure decoding Certificate Signing Request). >>>> >>>> >>>> Looking at the pki-ca logs on the ipa servers I see that some selftest failed: >>>> >>>> >>>> >>>> # tail -100 selftests.log >>>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Initializing self test >>>> plugins: >>>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test >>>> plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: >>>> loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] >>>> SelfTestSubsystem: loading all self test plugin >>>> instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: >>>> loading self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] [20] >>>> [1] >>>> SelfTestSubsystem: loading self test plugins in >>>> startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test >>>> plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] >>>> SelfTestSubsystem: Running self test plugins >>>> specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] >>>> CAPresence: >>>> CA is present >>>> 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: system certs >>>> verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The >>>> CRITICAL self test plugin >>>> called selftests.container.instance.SystemCertsVerification running at startup FAILED! >>>> >>>> the pki-cad service is running and "pki-cad status" displays the ports available. >>>> /etc/init.d/pki-cad status >>>> pki-ca (pid 28697) is running... [ OK ] >>>> >>>> >>>> My main consern is that the certmonger requests for renew of certificates for LDAP on 2 out >>>> of 3 >>>> of the IPA servers has failed, and the current certificate is expiring the 19th of January, >>>> under a week from now. >>>> >>>> Do you have any suggestions to where I can start troubleshootng this issue? >>>> >>>> >>> >>> Check the trust on the audit certificate: >>> >>> >>> >>> # certutil -L -d /var/lib/pki-ca/alias/ >>> ... >>> auditSigningCert cert-pki-ca u,u,Pu >>> >>> If the trust is not u,u,Pu then you can fix it with: >>> >>> >>> >>> # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' >>> -t u,u,Pu >>> >>> >>> >>> Then restart the CA and it should be ok. >>> >>> >> >> Looks like this certificate is expired. This is the same output on all 3 of the ipa servers. >> >> >> How can this be fixed? >> >> >> >> # certutil -L -d /var/lib/pki-ca/alias/ -n "auditSigningCert cert-pki-ca" >> Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: 5 (0x5) >> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >> Issuer: "CN=Certificate Authority,O=DNS.DOMAIN" >> Validity: >> Not Before: Thu Jan 19 19:44:24 2012 >> Not After : Wed Jan 08 19:44:24 2014 >> >> >> > > Go back in time to the 7th or 8th and run: > > > # getcert resubmit -d /var/lib/pki-ca/alias -n "auditSigningCert > cert-pki-ca" > > There may be other certs in a similar situation. getcert list will show you. > > Ouch. That would be rather disruptive I suppose. There is quite a lot of activity going to this server, not to mention it's the primary ntp and dns server for the network. Do you suppose this todo list will work ? Firewall off the rest of the network, leaving the ipa server alone Stop ntpd Set date to 8th of January Run the getcert resubmit command. Change date back to correct date Start ntpd Remove the firewall rules How many of the services is required to be restarted for the renewal to work after the date is changed to the 7th? Regards, Siggi From dpal at redhat.com Mon Jan 13 15:48:28 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 13 Jan 2014 10:48:28 -0500 Subject: [Freeipa-users] Migration from OpenLDAP In-Reply-To: <52D40539.1010103@redhat.com> References: <20140113145023.GB12003@redhat.com> <52D40539.1010103@redhat.com> Message-ID: <52D40ACC.4090101@redhat.com> On 01/13/2014 10:24 AM, Petr Spacek wrote: > On 13.1.2014 15:50, Alexander Bokovoy wrote: >> On Mon, 13 Jan 2014, tizo wrote: >>> Hi there, >>> >>> We have a working authentication system for GNU/Linux consisting in >>> a Mit >>> Kerberos Server, and an OpenLDAP directory with a particular >>> structure. I >>> was wondering if we could use Freeipa to administer those working >>> components as they are, without having to deploy a new Freeipa >>> server from >>> scratch. >> In short, no, it is not possible. > > I would like to elaborate this a bit more: > You really can't use FreeIPA WebUI with home-grown LDAP+Kerberos > system, but FreeIPA provides migrate-ds scripts which ease the > transition from OpenLDAP. > > Please see > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Migrating_from_a_Directory_Server_to_IPA.html > > > You need to migrate OpenLDAP data to one FreeIPA server and then you > can simply create FreeIPA server replicas as need. > > In other words, the migrate-ds script is run only once even if you > have multiple servers with replicated data. > > There are some limited capabilities for migration with user passwords, > but I will let other people to elaborate - this is not area of my > expertise. See the documentation about password migration. There are couple options. > > Let us know if you need any assistance during migration. > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sigbjorn at nixtra.com Mon Jan 13 17:25:14 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 13 Jan 2014 18:25:14 +0100 (CET) Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <52D40393.4060108@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32553.213.225.75.97.1389625636.squirrel@www.nixtra.com> <52D40393.4060108@redhat.com> Message-ID: <40999.213.225.75.97.1389633914.squirrel@www.nixtra.com> On Mon, January 13, 2014 16:17, Rob Crittenden wrote: > Sigbjorn Lie wrote: > >> Hi, >> >> >> Thank you for your prompt reply Rob. >> >> >> >> On Mon, January 13, 2014 15:58, Rob Crittenden wrote: >> >>> Sigbjorn Lie wrote: >>> >>> >>>> Hi, >>>> >>>> >>>> >>>> I seem to have issues with the certificate system on my IPA installation. Looking up hosts >>>> in the IPA WEBUI on any of the IPA servers says "Certificate format error: [Errno -8015] >>>> error (-8015) >>>> unknown". >>>> >>>> I also notice that hosts says the certificate system is unavailable. >>>> >>>> >>>> >>>> certmonger: Server failed request, will retry: 4301 (RPC failed at server. Certificate >>>> operation cannot be completed: Failure decoding Certificate Signing Request). >>>> >>>> >>>> Looking at the pki-ca logs on the ipa servers I see that some selftest failed: >>>> >>>> >>>> >>>> # tail -100 selftests.log >>>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Initializing self test >>>> plugins: >>>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test >>>> plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: >>>> loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] >>>> SelfTestSubsystem: loading all self test plugin >>>> instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: >>>> loading self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] [20] >>>> [1] >>>> SelfTestSubsystem: loading self test plugins in >>>> startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test >>>> plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] >>>> SelfTestSubsystem: Running self test plugins >>>> specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] >>>> CAPresence: >>>> CA is present >>>> 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: system certs >>>> verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The >>>> CRITICAL self test plugin >>>> called selftests.container.instance.SystemCertsVerification running at startup FAILED! >>>> >>>> the pki-cad service is running and "pki-cad status" displays the ports available. >>>> /etc/init.d/pki-cad status >>>> pki-ca (pid 28697) is running... [ OK ] >>>> >>>> >>>> My main consern is that the certmonger requests for renew of certificates for LDAP on 2 out >>>> of 3 >>>> of the IPA servers has failed, and the current certificate is expiring the 19th of January, >>>> under a week from now. >>>> >>>> Do you have any suggestions to where I can start troubleshootng this issue? >>>> >>>> >>> >>> Check the trust on the audit certificate: >>> >>> >>> >>> # certutil -L -d /var/lib/pki-ca/alias/ >>> ... >>> auditSigningCert cert-pki-ca u,u,Pu >> >> All the 3 ipa servers return u,u,Pu for auditSigningCert >> >> >> # certutil -L -d /var/lib/pki-ca/alias/ >> >> >> Certificate Nickname Trust Attributes >> SSL,S/MIME,JAR/XPI >> >> >> caSigningCert cert-pki-ca CTu,Cu,Cu Server-Cert cert-pki-ca >> u,u,u auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert >> cert-pki-ca u,u,u subsystemCert cert-pki-ca >> u,u,u >> >>> >>> If the trust is not u,u,Pu then you can fix it with: >>> >>> >>> >>> # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' >>> -t u,u,Pu >>> >>> >>> >>> Then restart the CA and it should be ok. >>> >>> >> >> I have restarted the dirsrv for PKI-IPA, and the pki-cad service on all 3 IPA servers. >> >> >>> >>> What is the status on the failed certmonger requests? >>> >> >> After I restarted dirsrv, pki-cad and then the httpd on ipa01 the status of the request is now: >> >> >> Request ID '20120119194518': >> status: CA_UNREACHABLE >> ca-error: Server failed request, will retry: 907 (RPC failed at server. cannot connect to >> 'https://ipa01.dns.domain:443/ca/agent/ca/displayBySerial': [Errno -12269] >> (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.). >> stuck: yes >> key pair storage: >> type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS >> Certificate >> DB',pinfile='/etc/dirsrv/slapd-DNS-DOMAIN//pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS Certificate >> DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=DNS-DOMAIN >> subject: CN=ipa01.dns.domain,O=DNS-DOMAIN >> expires: 2014-01-19 19:45:18 UTC >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: post-save command: track: yes >> auto-renew: yes >> >> >> However I cannot find the certificate that's expired? >> > > Can provide the output of getcert rather than ipa-getcert? It will show > additional certificates that are issued/renewed outside of the IPA API. > > rob > > Sure, I'll send you the output in private so I don't have to remove the domain names. Regards, Siggi From william.muriithi at gmail.com Mon Jan 13 17:32:50 2014 From: william.muriithi at gmail.com (William Muriithi) Date: Mon, 13 Jan 2014 12:32:50 -0500 Subject: [Freeipa-users] Updated doc, synchronization question Message-ID: > > > >>>> Two questions: > > > >>>> > > > >>>> - Any ETA on an updated 3.3.3 Users Guide? > > > >>> > > > >>> Our current plan is to release next documentation release along with > > > >>> FreeIPA > > > >>> 3.4, when more documentation fixes are factored in. > > > >>> > > > > Would you by any chance know when FreeIPA 3.4 will be realised? > > > > Looking to update a version 2.2 and would wait for 3.4 if its > > reasonably soon. > > > > We planned for Feb but it seems like it would slip. How much is unclear. > We might reduce the scope and cut it earlier (I mean do not slip too > much) or try to keep the scope and extend the time couple months. > We will decide in early Feb. Thanks a lot for the estimated release date. Please do make some announcement once you guys make up your mind which route to take. William > > Sorry not to have a more precise answer. > > Thanks > Dmitri > > > William > > > > > >>> Just in case you would like to check the most recent status of the > > > >>> documentation work (or even help us with it), this page describes > > > >>> the details > > > >>> > > > >>> http://www.freeipa.org/page/Contribute/Documentation > > > >>> > > > >>> including instructions how to build HTMLs out of our git tree. > > > >>> > > > >> > > > >> Thanks, I'll take a look. > > > >> > > > >>>> - Is AD/IPA synchronization still supported in 3.3.3? Will it > > always? > > > >>> > > > >>> The AD/IPA synchronization is supported only in terms in bug fixes. > > > >>> As for the > > > >>> enhancements, the FreeIPA core team is focusing on the AD trusts: > > > >>> > > > >>> http://www.freeipa.org/page/Trusts > > > >>> > > > >>> (That does not mean we are not open to contributions from the > > > >>> community) > > > >>> > > > >>> Martin > > > >>> > > > >> > > > >> Thanks for the that link - the video was helpful. Although I'm > > > >> afraid that is > > > >> making me lean towards implementing the not recommended "split brain" > > > >> approach. Although one thing that is not clear to me is weather > > > >> doing this > > > >> consumes CALs for the linux machines since they authenticate > > against AD. > > > > Linux machines do not authenticate against AD DC in single sign-on > > > > case. Instead, usually Windows users obtain their Kerberos TGT upon > > > > logon to > > > > Windows machines and then use it to obtain tickets to services on > > Linux > > > > machines, by obtaining cross-realm TGT from AD DC and presenting it to > > > > IPA KDC as a proof. So in single sign-on case it works fine -- > > > > authentication against AD happens on AD side. > > > > > > > > Of course, when AD users attempt to log in with password to IPA > > > > resources, SSSD would perform communication with AD DC to obtain > > TGT on > > > > their behalf. There is AD DC involved in making a decision whether > > > > this AD user is allowed to authenticate. On Kerberos level, however, > > > > there are no limitations from where the authentication request comes > > > > (unless it is restricted with the firewalls). CALs play role on using > > > > Windows resources after authentication happened but in IPA AD trusts > > > > case currently only IPA resources can be consumed by AD users, IPA > > users > > > > cannot yet consume Windows resources and therefore get assigned rights > > > > to access them. > > > > > > > > > > To clarify the CAL part. > > > The CALs come in two shapes: per user and per host. > > > If it is per user and you have users in AD then regardless of how you > > > integrate with IPA you have to pay these CALs. > > > If your CALs is around hosts then they are based on the count of the > > > computer objects in AD. > > > If the client system is joined directly and has kerberos identity in AD > > > domain you have an object in AD that counts towards CALs. > > > If you have client joined to IPA and either trust or sync solution in > > > place the client is not a member of AD (no computer object in AD) and > > > this does not count towards CALs. > > > > > > HTH > > > > > > > > > > > > > > > -- > > > Thank you, > > > Dmitri Pal > > > > > > Sr. Engineering Manager for IdM portfolio > > > Red Hat Inc. > > > > > > > > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < https://www.redhat.com/archives/freeipa-users/attachments/20140112/fe887df9/attachment.html > > > --------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From nalin at redhat.com Mon Jan 13 18:13:10 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 13 Jan 2014 13:13:10 -0500 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <32553.213.225.75.97.1389625636.squirrel@www.nixtra.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32553.213.225.75.97.1389625636.squirrel@www.nixtra.com> Message-ID: <20140113181310.GA12071@redhat.com> On Mon, Jan 13, 2014 at 04:07:16PM +0100, Sigbjorn Lie wrote: > After I restarted dirsrv, pki-cad and then the httpd on ipa01 the status of the request is now: > > Request ID '20120119194518': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: 907 (RPC failed at server. cannot connect to > 'https://ipa01.dns.domain:443/ca/agent/ca/displayBySerial': [Errno -12269] > (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS Certificate > DB',pinfile='/etc/dirsrv/slapd-DNS-DOMAIN//pwdfile.txt' > certificate: type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=DNS-DOMAIN > subject: CN=ipa01.dns.domain,O=DNS-DOMAIN > expires: 2014-01-19 19:45:18 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > > However I cannot find the certificate that's expired? That error message was the one the IPA server received and then relayed back to certmonger, so I'd expect that the expired certificate is the agent certificate that IPA uses when connecting to the CA's agent interface. That's stored in the NSS database in /etc/httpd/alias, with nickname "ipaCert". HTH, Nalin From sigbjorn at nixtra.com Mon Jan 13 18:24:17 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 13 Jan 2014 19:24:17 +0100 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <20140113181310.GA12071@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32553.213.225.75.97.1389625636.squirrel@www.nixtra.com> <20140113181310.GA12071@redhat.com> Message-ID: <52D42F51.8080000@nixtra.com> On 13/01/14 19:13, Nalin Dahyabhai wrote: > On Mon, Jan 13, 2014 at 04:07:16PM +0100, Sigbjorn Lie wrote: >> After I restarted dirsrv, pki-cad and then the httpd on ipa01 the status of the request is now: >> >> Request ID '20120119194518': >> status: CA_UNREACHABLE >> ca-error: Server failed request, will retry: 907 (RPC failed at server. cannot connect to >> 'https://ipa01.dns.domain:443/ca/agent/ca/displayBySerial': [Errno -12269] >> (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.). >> stuck: yes >> key pair storage: >> type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS Certificate >> DB',pinfile='/etc/dirsrv/slapd-DNS-DOMAIN//pwdfile.txt' >> certificate: type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS >> Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=DNS-DOMAIN >> subject: CN=ipa01.dns.domain,O=DNS-DOMAIN >> expires: 2014-01-19 19:45:18 UTC >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes >> >> However I cannot find the certificate that's expired? > That error message was the one the IPA server received and then relayed > back to certmonger, so I'd expect that the expired certificate is the > agent certificate that IPA uses when connecting to the CA's agent > interface. That's stored in the NSS database in /etc/httpd/alias, with > nickname "ipaCert". > > Yes, the ipaCert certificate in /etc/httpd/alias/ is expired. Actually all certificates in /var/lib/pki-ca/alias/ is expired too, they all expired at the same date, within minutes of each other. It looks like they are the original certificates issued when I installed IPA, when I look at the "Not Before" timestamp of the certificates. Regards, Siggi From mitkany at gmail.com Mon Jan 13 18:26:20 2014 From: mitkany at gmail.com (Dimitar Georgievski) Date: Mon, 13 Jan 2014 13:26:20 -0500 Subject: [Freeipa-users] Manage records while primary IPA is down Message-ID: This question is really about HA of FreeIPA. I've noticed that new records cannot be added on the replica server while the primary is down. Ideally these services should be always available even when the Primary server is down (for maintenance or other reasons). Is it possible to have another Primary server replicating with the first Primary or to use one of the Replica servers to manage records while the Primary server is down. Thanks Dimitar -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Jan 13 18:33:27 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 13 Jan 2014 13:33:27 -0500 Subject: [Freeipa-users] Manage records while primary IPA is down In-Reply-To: References: Message-ID: <52D43177.7010201@redhat.com> Dimitar Georgievski wrote: > This question is really about HA of FreeIPA. I've noticed that new > records cannot be added on the replica server while the primary is down. > > Ideally these services should be always available even when the Primary > server is down (for maintenance or other reasons). > > Is it possible to have another Primary server replicating with the first > Primary or to use one of the Replica servers to manage records while the > Primary server is down. All servers in IPA are equal masters, the only difference may be the services running on any given server (DNS and a CA). The exception is if a master runs out of DNA values or has never been used to add an entry that requires one and the original IPA master is down. An IPA server will request a DNA range the first time it needs one but doesn't get one until then. I'm guessing that is what happened. I believe IPA 3.3 added some options to ipa-replica-manage to be able to control the DNA configuration. rob From dpal at redhat.com Mon Jan 13 18:36:04 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 13 Jan 2014 13:36:04 -0500 Subject: [Freeipa-users] Manage records while primary IPA is down In-Reply-To: <52D43177.7010201@redhat.com> References: <52D43177.7010201@redhat.com> Message-ID: <52D43214.3000907@redhat.com> On 01/13/2014 01:33 PM, Rob Crittenden wrote: > Dimitar Georgievski wrote: >> This question is really about HA of FreeIPA. I've noticed that new >> records cannot be added on the replica server while the primary is down. >> >> Ideally these services should be always available even when the Primary >> server is down (for maintenance or other reasons). >> >> Is it possible to have another Primary server replicating with the first >> Primary or to use one of the Replica servers to manage records while the >> Primary server is down. > > All servers in IPA are equal masters, the only difference may be the > services running on any given server (DNS and a CA). > > The exception is if a master runs out of DNA values or has never been > used to add an entry that requires one and the original IPA master is > down. An IPA server will request a DNA range the first time it needs > one but doesn't get one until then. I'm guessing that is what happened. > > I believe IPA 3.3 added some options to ipa-replica-manage to be able > to control the DNA configuration. We might be talking about the entries that have certificates. Is this the case? If so the certificate operations are proxied to the server that has full CA but AFAIR there is not failover there and I vaguely recall that there was ticket filed to address this scenario. So which entries we are talking about? > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Mon Jan 13 18:37:49 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 13 Jan 2014 13:37:49 -0500 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> Message-ID: <52D4327D.10108@redhat.com> Sigbjorn Lie wrote: > > > > On Mon, January 13, 2014 16:34, Rob Crittenden wrote: >> Sigbjorn Lie wrote: >> >>> >>> >>> >>> On Mon, January 13, 2014 15:58, Rob Crittenden wrote: >>> >>>> Sigbjorn Lie wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> I seem to have issues with the certificate system on my IPA installation. Looking up hosts >>>>> in the IPA WEBUI on any of the IPA servers says "Certificate format error: [Errno -8015] >>>>> error (-8015) >>>>> unknown". >>>>> >>>>> I also notice that hosts says the certificate system is unavailable. >>>>> >>>>> >>>>> >>>>> certmonger: Server failed request, will retry: 4301 (RPC failed at server. Certificate >>>>> operation cannot be completed: Failure decoding Certificate Signing Request). >>>>> >>>>> >>>>> Looking at the pki-ca logs on the ipa servers I see that some selftest failed: >>>>> >>>>> >>>>> >>>>> # tail -100 selftests.log >>>>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Initializing self test >>>>> plugins: >>>>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test >>>>> plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: >>>>> loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] >>>>> SelfTestSubsystem: loading all self test plugin >>>>> instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: >>>>> loading self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] [20] >>>>> [1] >>>>> SelfTestSubsystem: loading self test plugins in >>>>> startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test >>>>> plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] >>>>> SelfTestSubsystem: Running self test plugins >>>>> specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] >>>>> CAPresence: >>>>> CA is present >>>>> 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: system certs >>>>> verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The >>>>> CRITICAL self test plugin >>>>> called selftests.container.instance.SystemCertsVerification running at startup FAILED! >>>>> >>>>> the pki-cad service is running and "pki-cad status" displays the ports available. >>>>> /etc/init.d/pki-cad status >>>>> pki-ca (pid 28697) is running... [ OK ] >>>>> >>>>> >>>>> My main consern is that the certmonger requests for renew of certificates for LDAP on 2 out >>>>> of 3 >>>>> of the IPA servers has failed, and the current certificate is expiring the 19th of January, >>>>> under a week from now. >>>>> >>>>> Do you have any suggestions to where I can start troubleshootng this issue? >>>>> >>>>> >>>> >>>> Check the trust on the audit certificate: >>>> >>>> >>>> >>>> # certutil -L -d /var/lib/pki-ca/alias/ >>>> ... >>>> auditSigningCert cert-pki-ca u,u,Pu >>>> >>>> If the trust is not u,u,Pu then you can fix it with: >>>> >>>> >>>> >>>> # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' >>>> -t u,u,Pu >>>> >>>> >>>> >>>> Then restart the CA and it should be ok. >>>> >>>> >>> >>> Looks like this certificate is expired. This is the same output on all 3 of the ipa servers. >>> >>> >>> How can this be fixed? >>> >>> >>> >>> # certutil -L -d /var/lib/pki-ca/alias/ -n "auditSigningCert cert-pki-ca" >>> Certificate: >>> Data: >>> Version: 3 (0x2) >>> Serial Number: 5 (0x5) >>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>> Issuer: "CN=Certificate Authority,O=DNS.DOMAIN" >>> Validity: >>> Not Before: Thu Jan 19 19:44:24 2012 >>> Not After : Wed Jan 08 19:44:24 2014 >>> >>> >>> >> >> Go back in time to the 7th or 8th and run: >> >> >> # getcert resubmit -d /var/lib/pki-ca/alias -n "auditSigningCert >> cert-pki-ca" >> >> There may be other certs in a similar situation. getcert list will show you. >> >> > > Ouch. That would be rather disruptive I suppose. There is quite a lot of activity going to this > server, not to mention it's the primary ntp and dns server for the network. > > Do you suppose this todo list will work ? > > Firewall off the rest of the network, leaving the ipa server alone > Stop ntpd > Set date to 8th of January > Run the getcert resubmit command. > Change date back to correct date > Start ntpd > Remove the firewall rules Looks good. I'd restart the certmonger service rather than resubmitting each individually. Be prepared for renewal to not succeed. For some reason it didn't on and before expiration time so whatever problem existed then likely still remains. So the question to ask is "what will I do if renewal fails again?" Nothing catastrophic will happen, but it will likely mean having to roll forward again, debug, roll back, try again, and perhaps more than once. It's hard to say w/o knowing why it failed in the first place. > How many of the services is required to be restarted for the renewal to work after the date is > changed to the 7th? The renewal itself should restart the required services. rob From bret.wortman at damascusgrp.com Mon Jan 13 19:14:02 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 13 Jan 2014 14:14:02 -0500 Subject: [Freeipa-users] Odd problem with SSSD and SSH keys Message-ID: <52D43AFA.1010207@damascusgrp.com> I've got a strange situation where some of my workstations are reporting difficulty when sshing to remote systems, but there's no pattern I can discern. One user's machine can't get to system A, but I can, though I can't ssh to his workstation directly. Here's the kind of thing I see when doing ssh -vvv: debug1: Server host key: RSA 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab debug3: load_hostkeys: loading entries for host "rs512" from file "/root/.ssh/known_hosts" debug3: load_hostkeys: loaded 0 keys debug3: load_hostkeys: loading entries for host "rs512" from file "/var/lib/sss/pubconf/known_hosts" debug3: load_hostkeys: found key type RSA in file /var/lib/sss/pubconf/known_hosts:2 debug3: load_hostkeys: loaded 1 keys @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone coudl be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending RSA key in /var/lib/sss/pubconf/known_hosts:2 RSA host key for zw131 has changed and you have requested strict checking. Host key verification failed. # We haven't changed the host key; the public key files are dated October 23 of last year. Our configuration files for SSSD and SSH are managed by Puppet, so they are consistent from system to system. That said, I did compare a system that could remote to rs512 to one that could not and found no differences. Here are the files: /etc/sssd/sssd.conf: [domain/spx.net] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = foo.net id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = zw129.foo.net chpass_provider = ipa ipa_dyndns_update = True ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49 ldap_tls_cacert = /etc/ipa/ca.crt [domain/.spx.net] cache_credentials = True krb5_store_password_if_offline = True krb5_realm = FOO.NET ipa_domain = .foo.net id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt chpass_provider = ipa ipa_dyndns_update = True ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49 ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net dns_discovery_domain = .spx.net [sssd] services = nss, pam, ssh config_file_version = 2 domains = .spx.net, spx.net [nss] [pam] [sudo] [autofs] [ssh] Is there anything else relevant that I should be looking at? -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Jan 13 19:36:05 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 13 Jan 2014 14:36:05 -0500 Subject: [Freeipa-users] Odd problem with SSSD and SSH keys In-Reply-To: <52D43AFA.1010207@damascusgrp.com> References: <52D43AFA.1010207@damascusgrp.com> Message-ID: <52D44025.1020800@redhat.com> Bret Wortman wrote: > I've got a strange situation where some of my workstations are reporting > difficulty when sshing to remote systems, but there's no pattern I can > discern. One user's machine can't get to system A, but I can, though I > can't ssh to his workstation directly. > > Here's the kind of thing I see when doing ssh -vvv: > > debug1: Server host key: RSA 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab > debug3: load_hostkeys: loading entries for host "rs512" from file > "/root/.ssh/known_hosts" > debug3: load_hostkeys: loaded 0 keys > debug3: load_hostkeys: loading entries for host "rs512" from file > "/var/lib/sss/pubconf/known_hosts" > debug3: load_hostkeys: found key type RSA in file > /var/lib/sss/pubconf/known_hosts:2 > debug3: load_hostkeys: loaded 1 keys > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! > Someone coudl be eavesdropping on you right now (man-in-the-middle attack)! > It is also possible that a host key has just been changed. > The fingerprint for the RSA key sent by the remote host is > 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab > Please contact your system administrator. > Add correct host key in /root/.ssh/known_hosts to get rid of this message. > Offending RSA key in /var/lib/sss/pubconf/known_hosts:2 > RSA host key for zw131 has changed and you have requested strict checking. > Host key verification failed. > # > > We haven't changed the host key; the public key files are dated October > 23 of last year. Our configuration files for SSSD and SSH are managed by > Puppet, so they are consistent from system to system. That said, I did > compare a system that could remote to rs512 to one that could not and > found no differences. Here are the files: > > /etc/sssd/sssd.conf: > [domain/spx.net] > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = foo.net > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = zw129.foo.net > chpass_provider = ipa > ipa_dyndns_update = True > ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49 > ldap_tls_cacert = /etc/ipa/ca.crt > [domain/.spx.net] > cache_credentials = True > krb5_store_password_if_offline = True > krb5_realm = FOO.NET > ipa_domain = .foo.net > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ldap_tls_cacert = /etc/ipa/ca.crt > chpass_provider = ipa > ipa_dyndns_update = True > ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49 > ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net > dns_discovery_domain = .spx.net > [sssd] > services = nss, pam, ssh > config_file_version = 2 > > domains = .spx.net, spx.net > [nss] > > [pam] > > [sudo] > > [autofs] > > [ssh] > > Is there anything else relevant that I should be looking at? You might compare the value of the key in IPA to what is in /var/lib/sss/pubconf/known_hosts rob From bret.wortman at damascusgrp.com Mon Jan 13 19:44:29 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 13 Jan 2014 14:44:29 -0500 Subject: [Freeipa-users] Odd problem with SSSD and SSH keys In-Reply-To: <52D44025.1020800@redhat.com> References: <52D43AFA.1010207@damascusgrp.com> <52D44025.1020800@redhat.com> Message-ID: <52D4421D.6040109@damascusgrp.com> They're definitely different. I deleted the one in the file, then tried again. It put the bad key back in the file. I blew the whole file away and the same thing happened. Where is this key coming from if not from IPA? On 01/13/2014 02:36 PM, Rob Crittenden wrote: > Bret Wortman wrote: >> I've got a strange situation where some of my workstations are reporting >> difficulty when sshing to remote systems, but there's no pattern I can >> discern. One user's machine can't get to system A, but I can, though I >> can't ssh to his workstation directly. >> >> Here's the kind of thing I see when doing ssh -vvv: >> >> debug1: Server host key: RSA >> 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab >> debug3: load_hostkeys: loading entries for host "rs512" from file >> "/root/.ssh/known_hosts" >> debug3: load_hostkeys: loaded 0 keys >> debug3: load_hostkeys: loading entries for host "rs512" from file >> "/var/lib/sss/pubconf/known_hosts" >> debug3: load_hostkeys: found key type RSA in file >> /var/lib/sss/pubconf/known_hosts:2 >> debug3: load_hostkeys: loaded 1 keys >> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ >> @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ >> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ >> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! >> Someone coudl be eavesdropping on you right now (man-in-the-middle >> attack)! >> It is also possible that a host key has just been changed. >> The fingerprint for the RSA key sent by the remote host is >> 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab >> Please contact your system administrator. >> Add correct host key in /root/.ssh/known_hosts to get rid of this >> message. >> Offending RSA key in /var/lib/sss/pubconf/known_hosts:2 >> RSA host key for zw131 has changed and you have requested strict >> checking. >> Host key verification failed. >> # >> >> We haven't changed the host key; the public key files are dated October >> 23 of last year. Our configuration files for SSSD and SSH are managed by >> Puppet, so they are consistent from system to system. That said, I did >> compare a system that could remote to rs512 to one that could not and >> found no differences. Here are the files: >> >> /etc/sssd/sssd.conf: >> [domain/spx.net] >> cache_credentials = True >> krb5_store_password_if_offline = True >> ipa_domain = foo.net >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = zw129.foo.net >> chpass_provider = ipa >> ipa_dyndns_update = True >> ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49 >> ldap_tls_cacert = /etc/ipa/ca.crt >> [domain/.spx.net] >> cache_credentials = True >> krb5_store_password_if_offline = True >> krb5_realm = FOO.NET >> ipa_domain = .foo.net >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ldap_tls_cacert = /etc/ipa/ca.crt >> chpass_provider = ipa >> ipa_dyndns_update = True >> ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49 >> ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net >> dns_discovery_domain = .spx.net >> [sssd] >> services = nss, pam, ssh >> config_file_version = 2 >> >> domains = .spx.net, spx.net >> [nss] >> >> [pam] >> >> [sudo] >> >> [autofs] >> >> [ssh] >> >> Is there anything else relevant that I should be looking at? > > You might compare the value of the key in IPA to what is in > /var/lib/sss/pubconf/known_hosts > > rob > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Mon Jan 13 19:52:07 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 13 Jan 2014 14:52:07 -0500 Subject: [Freeipa-users] Odd problem with SSSD and SSH keys In-Reply-To: <52D4421D.6040109@damascusgrp.com> References: <52D43AFA.1010207@damascusgrp.com> <52D44025.1020800@redhat.com> <52D4421D.6040109@damascusgrp.com> Message-ID: <52D443E7.3000300@redhat.com> On 01/13/2014 02:44 PM, Bret Wortman wrote: > They're definitely different. I deleted the one in the file, then > tried again. It put the bad key back in the file. I blew the whole > file away and the same thing happened. Where is this key coming from > if not from IPA? Puppet? > > > On 01/13/2014 02:36 PM, Rob Crittenden wrote: >> Bret Wortman wrote: >>> I've got a strange situation where some of my workstations are >>> reporting >>> difficulty when sshing to remote systems, but there's no pattern I can >>> discern. One user's machine can't get to system A, but I can, though I >>> can't ssh to his workstation directly. >>> >>> Here's the kind of thing I see when doing ssh -vvv: >>> >>> debug1: Server host key: RSA >>> 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab >>> debug3: load_hostkeys: loading entries for host "rs512" from file >>> "/root/.ssh/known_hosts" >>> debug3: load_hostkeys: loaded 0 keys >>> debug3: load_hostkeys: loading entries for host "rs512" from file >>> "/var/lib/sss/pubconf/known_hosts" >>> debug3: load_hostkeys: found key type RSA in file >>> /var/lib/sss/pubconf/known_hosts:2 >>> debug3: load_hostkeys: loaded 1 keys >>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ >>> @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ >>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ >>> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! >>> Someone coudl be eavesdropping on you right now (man-in-the-middle >>> attack)! >>> It is also possible that a host key has just been changed. >>> The fingerprint for the RSA key sent by the remote host is >>> 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab >>> Please contact your system administrator. >>> Add correct host key in /root/.ssh/known_hosts to get rid of this >>> message. >>> Offending RSA key in /var/lib/sss/pubconf/known_hosts:2 >>> RSA host key for zw131 has changed and you have requested strict >>> checking. >>> Host key verification failed. >>> # >>> >>> We haven't changed the host key; the public key files are dated October >>> 23 of last year. Our configuration files for SSSD and SSH are >>> managed by >>> Puppet, so they are consistent from system to system. That said, I did >>> compare a system that could remote to rs512 to one that could not and >>> found no differences. Here are the files: >>> >>> /etc/sssd/sssd.conf: >>> [domain/spx.net] >>> cache_credentials = True >>> krb5_store_password_if_offline = True >>> ipa_domain = foo.net >>> id_provider = ipa >>> auth_provider = ipa >>> access_provider = ipa >>> ipa_hostname = zw129.foo.net >>> chpass_provider = ipa >>> ipa_dyndns_update = True >>> ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49 >>> ldap_tls_cacert = /etc/ipa/ca.crt >>> [domain/.spx.net] >>> cache_credentials = True >>> krb5_store_password_if_offline = True >>> krb5_realm = FOO.NET >>> ipa_domain = .foo.net >>> id_provider = ipa >>> auth_provider = ipa >>> access_provider = ipa >>> ldap_tls_cacert = /etc/ipa/ca.crt >>> chpass_provider = ipa >>> ipa_dyndns_update = True >>> ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49 >>> ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net >>> dns_discovery_domain = .spx.net >>> [sssd] >>> services = nss, pam, ssh >>> config_file_version = 2 >>> >>> domains = .spx.net, spx.net >>> [nss] >>> >>> [pam] >>> >>> [sudo] >>> >>> [autofs] >>> >>> [ssh] >>> >>> Is there anything else relevant that I should be looking at? >> >> You might compare the value of the key in IPA to what is in >> /var/lib/sss/pubconf/known_hosts >> >> rob >> > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitkany at gmail.com Mon Jan 13 20:01:40 2014 From: mitkany at gmail.com (Dimitar Georgievski) Date: Mon, 13 Jan 2014 15:01:40 -0500 Subject: [Freeipa-users] Manage records while primary IPA is down In-Reply-To: <52D43214.3000907@redhat.com> References: <52D43177.7010201@redhat.com> <52D43214.3000907@redhat.com> Message-ID: I was referring to user accounts, and I believe they require certificates. With the Primary IPA being down I was not able to create new user entries on the replica servers. Hopefully the CA fail-over requirement is addressed in a new release of FreeIPA. Thanks, Dimitar On Mon, Jan 13, 2014 at 1:36 PM, Dmitri Pal wrote: > On 01/13/2014 01:33 PM, Rob Crittenden wrote: > > Dimitar Georgievski wrote: > >> This question is really about HA of FreeIPA. I've noticed that new > >> records cannot be added on the replica server while the primary is down. > >> > >> Ideally these services should be always available even when the Primary > >> server is down (for maintenance or other reasons). > >> > >> Is it possible to have another Primary server replicating with the first > >> Primary or to use one of the Replica servers to manage records while the > >> Primary server is down. > > > > All servers in IPA are equal masters, the only difference may be the > > services running on any given server (DNS and a CA). > > > > The exception is if a master runs out of DNA values or has never been > > used to add an entry that requires one and the original IPA master is > > down. An IPA server will request a DNA range the first time it needs > > one but doesn't get one until then. I'm guessing that is what happened. > > > > I believe IPA 3.3 added some options to ipa-replica-manage to be able > > to control the DNA configuration. > > > We might be talking about the entries that have certificates. Is this > the case? > If so the certificate operations are proxied to the server that has full > CA but AFAIR there is not failover there and I vaguely recall that there > was ticket filed to address this scenario. > > So which entries we are talking about? > > > > > rob > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Jan 13 20:24:52 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 13 Jan 2014 15:24:52 -0500 Subject: [Freeipa-users] Manage records while primary IPA is down In-Reply-To: References: <52D43177.7010201@redhat.com> <52D43214.3000907@redhat.com> Message-ID: <52D44B94.4000802@redhat.com> On 01/13/2014 03:01 PM, Dimitar Georgievski wrote: > > I was referring to user accounts, and I believe they require > certificates. With the Primary IPA being down I was not able to create > new user entries on the replica servers. Hm? What kind of error you get? What does HTTP log shows on the replica you are performing operation against? User accounts have a certificate attribute but it is not used yet so it might be something else not related to certificates. Answers to the questions above would help. Also here are some hints that might be helpful in collecting and preparing information for our analysis: http://www.freeipa.org/page/Troubleshooting > > Hopefully the CA fail-over requirement is addressed in a new release > of FreeIPA. > > Thanks, > > Dimitar > > > On Mon, Jan 13, 2014 at 1:36 PM, Dmitri Pal > wrote: > > On 01/13/2014 01:33 PM, Rob Crittenden wrote: > > Dimitar Georgievski wrote: > >> This question is really about HA of FreeIPA. I've noticed that new > >> records cannot be added on the replica server while the primary > is down. > >> > >> Ideally these services should be always available even when the > Primary > >> server is down (for maintenance or other reasons). > >> > >> Is it possible to have another Primary server replicating with > the first > >> Primary or to use one of the Replica servers to manage records > while the > >> Primary server is down. > > > > All servers in IPA are equal masters, the only difference may be the > > services running on any given server (DNS and a CA). > > > > The exception is if a master runs out of DNA values or has never > been > > used to add an entry that requires one and the original IPA > master is > > down. An IPA server will request a DNA range the first time it needs > > one but doesn't get one until then. I'm guessing that is what > happened. > > > > I believe IPA 3.3 added some options to ipa-replica-manage to be > able > > to control the DNA configuration. > > > We might be talking about the entries that have certificates. Is this > the case? > If so the certificate operations are proxied to the server that > has full > CA but AFAIR there is not failover there and I vaguely recall that > there > was ticket filed to address this scenario. > > So which entries we are talking about? > > > > > rob > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Jan 13 21:18:44 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 13 Jan 2014 22:18:44 +0100 Subject: [Freeipa-users] Odd problem with SSSD and SSH keys In-Reply-To: <52D4421D.6040109@damascusgrp.com> References: <52D43AFA.1010207@damascusgrp.com> <52D44025.1020800@redhat.com> <52D4421D.6040109@damascusgrp.com> Message-ID: <20140113211844.GA31257@hendrix.redhat.com> On Mon, Jan 13, 2014 at 02:44:29PM -0500, Bret Wortman wrote: > They're definitely different. I deleted the one in the file, then > tried again. It put the bad key back in the file. I blew the whole > file away and the same thing happened. Where is this key coming from > if not from IPA? Can you try running sss_ssh_knownhostsproxy manually to see what key does it return? The keys are propagated to the file from the sssd database. If the client was offline, the client could use stale records. Can you verify the client has no connectivity issues? Honza (CC-ed) might have some more hints. From sigbjorn at nixtra.com Mon Jan 13 22:08:36 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 13 Jan 2014 23:08:36 +0100 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <52D4327D.10108@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> Message-ID: <52D463E4.2080006@nixtra.com> On 13/01/14 19:37, Rob Crittenden wrote: > Sigbjorn Lie wrote: >> >> >> >> On Mon, January 13, 2014 16:34, Rob Crittenden wrote: >>> Sigbjorn Lie wrote: >>> >>>> >>>> >>>> >>>> On Mon, January 13, 2014 15:58, Rob Crittenden wrote: >>>> >>>>> Sigbjorn Lie wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> I seem to have issues with the certificate system on my IPA >>>>>> installation. Looking up hosts >>>>>> in the IPA WEBUI on any of the IPA servers says "Certificate >>>>>> format error: [Errno -8015] >>>>>> error (-8015) >>>>>> unknown". >>>>>> >>>>>> I also notice that hosts says the certificate system is unavailable. >>>>>> >>>>>> >>>>>> >>>>>> certmonger: Server failed request, will retry: 4301 (RPC failed >>>>>> at server. Certificate >>>>>> operation cannot be completed: Failure decoding Certificate >>>>>> Signing Request). >>>>>> >>>>>> >>>>>> Looking at the pki-ca logs on the ipa servers I see that some >>>>>> selftest failed: >>>>>> >>>>>> >>>>>> >>>>>> # tail -100 selftests.log >>>>>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] >>>>>> SelfTestSubsystem: Initializing self test >>>>>> plugins: >>>>>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] >>>>>> SelfTestSubsystem: loading all self test >>>>>> plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] >>>>>> [20] [1] SelfTestSubsystem: >>>>>> loading all self test plugin instances 28697.main - >>>>>> [13/Jan/2014:15:06:33 CET] [20] [1] >>>>>> SelfTestSubsystem: loading all self test plugin >>>>>> instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] >>>>>> [1] SelfTestSubsystem: >>>>>> loading self test plugins in on-demand order 28697.main - >>>>>> [13/Jan/2014:15:06:33 CET] [20] >>>>>> [1] >>>>>> SelfTestSubsystem: loading self test plugins in >>>>>> startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] >>>>>> SelfTestSubsystem: Self test >>>>>> plugins have been successfully loaded! 28697.main - >>>>>> [13/Jan/2014:15:06:34 CET] [20] [1] >>>>>> SelfTestSubsystem: Running self test plugins >>>>>> specified to be executed at startup: 28697.main - >>>>>> [13/Jan/2014:15:06:34 CET] [20] [1] >>>>>> CAPresence: >>>>>> CA is present >>>>>> 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] >>>>>> SystemCertsVerification: system certs >>>>>> verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] >>>>>> [1] SelfTestSubsystem: The >>>>>> CRITICAL self test plugin >>>>>> called selftests.container.instance.SystemCertsVerification >>>>>> running at startup FAILED! >>>>>> >>>>>> the pki-cad service is running and "pki-cad status" displays the >>>>>> ports available. >>>>>> /etc/init.d/pki-cad status >>>>>> pki-ca (pid 28697) is running... [ OK ] >>>>>> >>>>>> >>>>>> My main consern is that the certmonger requests for renew of >>>>>> certificates for LDAP on 2 out >>>>>> of 3 >>>>>> of the IPA servers has failed, and the current certificate is >>>>>> expiring the 19th of January, >>>>>> under a week from now. >>>>>> >>>>>> Do you have any suggestions to where I can start troubleshootng >>>>>> this issue? >>>>>> >>>>>> >>>>> >>>>> Check the trust on the audit certificate: >>>>> >>>>> >>>>> >>>>> # certutil -L -d /var/lib/pki-ca/alias/ >>>>> ... >>>>> auditSigningCert cert-pki-ca u,u,Pu >>>>> >>>>> If the trust is not u,u,Pu then you can fix it with: >>>>> >>>>> >>>>> >>>>> # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert >>>>> cert-pki-ca' >>>>> -t u,u,Pu >>>>> >>>>> >>>>> >>>>> Then restart the CA and it should be ok. >>>>> >>>>> >>>> >>>> Looks like this certificate is expired. This is the same output on >>>> all 3 of the ipa servers. >>>> >>>> >>>> How can this be fixed? >>>> >>>> >>>> >>>> # certutil -L -d /var/lib/pki-ca/alias/ -n "auditSigningCert >>>> cert-pki-ca" >>>> Certificate: >>>> Data: >>>> Version: 3 (0x2) >>>> Serial Number: 5 (0x5) >>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>> Issuer: "CN=Certificate Authority,O=DNS.DOMAIN" >>>> Validity: >>>> Not Before: Thu Jan 19 19:44:24 2012 >>>> Not After : Wed Jan 08 19:44:24 2014 >>>> >>>> >>>> >>> >>> Go back in time to the 7th or 8th and run: >>> >>> >>> # getcert resubmit -d /var/lib/pki-ca/alias -n "auditSigningCert >>> cert-pki-ca" >>> >>> There may be other certs in a similar situation. getcert list will >>> show you. >>> >>> >> >> Ouch. That would be rather disruptive I suppose. There is quite a lot >> of activity going to this >> server, not to mention it's the primary ntp and dns server for the >> network. >> >> Do you suppose this todo list will work ? >> >> Firewall off the rest of the network, leaving the ipa server alone >> Stop ntpd >> Set date to 8th of January >> Run the getcert resubmit command. >> Change date back to correct date >> Start ntpd >> Remove the firewall rules > > Looks good. I'd restart the certmonger service rather than > resubmitting each individually. Be prepared for renewal to not > succeed. For some reason it didn't on and before expiration time so > whatever problem existed then likely still remains. > > So the question to ask is "what will I do if renewal fails again?" > > Nothing catastrophic will happen, but it will likely mean having to > roll forward again, debug, roll back, try again, and perhaps more than > once. It's hard to say w/o knowing why it failed in the first place. > >> How many of the services is required to be restarted for the renewal >> to work after the date is >> changed to the 7th? > > The renewal itself should restart the required services. > This worked better than expected. Thank you! :) ipa01 and ipa02 seem to be happy again, "getcert list" no longer displays any certificates out of date, and all certificates in need of renewal within 28 days has been renewed. The webui also started working again and things seem to be back to normal. ipa03 however is still having issues. I could not renew any certificates on this server to begin with, but I managed to renew the certificates for the directory servers by changing the xmlrpc url to another ipa server in /etc/ipa/default.conf and resubmitting these requests. "getcert resubmit -i I'm very new to IPA. I run a ODSEE and I need to add in krb5. ODSEE allows us to store the KRB5 data in ldap, but there is no easy means of keeping the LDAP and Kerberos password in sync for a given account. I understand that IPA supplies Kerberos services. But is the krb5 password the same password that a LDAP bind would use. Meaning I have many applications that can not use Kerberos, but can use LDAP. Can these applications use IPA and expect that a given user account will have the LDAP password kept in sync with the krb5 password? thanks, Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From christianh at 4over.com Mon Jan 13 22:54:05 2014 From: christianh at 4over.com (Christian Hernandez) Date: Mon, 13 Jan 2014 14:54:05 -0800 Subject: [Freeipa-users] Keberos and LDAP password In-Reply-To: References: Message-ID: >From what I understand I use currently... You can use "just LDAP"...I'm currently using LDAP/KRB where supported...and just straight LDAP on applications that don't support KRB Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christianh at 4over.com www.4over.com On Mon, Jan 13, 2014 at 2:04 PM, Bob wrote: > I'm very new to IPA. I run a ODSEE and I need to add in krb5. ODSEE allows > us to store the KRB5 data in ldap, but there is no easy means of keeping > the LDAP and Kerberos password in sync for a given account. > > I understand that IPA supplies Kerberos services. But is the krb5 password > the same password that a LDAP bind would use. Meaning I have many > applications that can not use Kerberos, but can use LDAP. Can these > applications use IPA and expect that a given user account will have the > LDAP password kept in sync with the krb5 password? > > thanks, > > Bob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Jan 13 23:01:11 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 13 Jan 2014 18:01:11 -0500 Subject: [Freeipa-users] Keberos and LDAP password In-Reply-To: References: Message-ID: <52D47037.7080007@redhat.com> On 01/13/2014 05:04 PM, Bob wrote: > I'm very new to IPA. I run a ODSEE and I need to add in krb5. ODSEE > allows us to store the KRB5 data in ldap, but there is no easy means > of keeping the LDAP and Kerberos password in sync for a given account. > > I understand that IPA supplies Kerberos services. But is the krb5 > password the same password that a LDAP bind would use. Meaning I have > many applications that can not use Kerberos, but can use LDAP. Can > these applications use IPA and expect that a given user account will > have the LDAP password kept in sync with the krb5 password? Yes. It is the same. You can use IPA with Kerberos and/or LDAP clients. > > thanks, > > Bob > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Mon Jan 13 23:29:23 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Mon, 13 Jan 2014 23:29:23 +0000 Subject: [Freeipa-users] One way trusts Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E66C085@001FSN2MPN1-044.001f.mgd2.msft.net> Hello, I manage a suite of machines and services which are used for collaborative projects with external partners. I want to allow users within our organization to authenticate with their existing Active Directory accounts, and I have set up an "External Users" LDAP directory to establish identities for our partners. I have an LDAP server set up which merges the two directories and which forwards requests on to the correct directory. I like the idea of FreeIPA, however, I need support for a one-way trust. I don't have the ability to modify any entries in our AD server, but I do have a normal user account (hence I can bind to AD's LDAP interface). However, I think this is kind of a moot point since external users should under no circumstances be allowed access to our internal network/services. Read-only access to AD is just peachy. I found this old message (June 2012) on your mailing list which suggests one-way trusts may be on your radar. [1] However, I looked through your Trac tickets and didn't see any follow up. Did I miss something? Is this already implemented, or are plans in place? Thanks much, Bryce [1] https://www.redhat.com/archives/freeipa-users/2012-June/msg00206.html 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Jan 14 00:31:17 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 13 Jan 2014 19:31:17 -0500 Subject: [Freeipa-users] One way trusts In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E66C085@001FSN2MPN1-044.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E66C085@001FSN2MPN1-044.001f.mgd2.msft.net> Message-ID: <52D48555.4040008@redhat.com> On 01/13/2014 06:29 PM, Nordgren, Bryce L -FS wrote: > > Hello, > > > > I manage a suite of machines and services which are used for > collaborative projects with external partners. I want to allow users > within our organization to authenticate with their existing Active > Directory accounts, and I have set up an "External Users" LDAP > directory to establish identities for our partners. I have an LDAP > server set up which merges the two directories and which forwards > requests on to the correct directory. > > > > I like the idea of FreeIPA, however, I need support for a one-way > trust. I don't have the ability to modify any entries in our AD > server, but I do have a normal user account (hence I can bind to AD's > LDAP interface). However, I think this is kind of a moot point since > external users should under no circumstances be allowed access to our > internal network/services. Read-only access to AD is just peachy. I > found this old message (June 2012) on your mailing list which suggests > one-way trusts may be on your radar. [1] However, I looked through > your Trac tickets and didn't see any follow up. Did I miss something? > Is this already implemented, or are plans in place? > Just to be sure I understand. You have internal users - they are in AD. You have external users - they are in LDAP. You merge two directories and you want to replace this setup with IPA. IPA can trust AD. Formally it is a mutual trust but in reality IPA does not have global catalog support for users in IPA to be able to access the resources in AD. So it is one way trust due to limited functionality. The global catalog support is being worked on. As soon as it is implemented we will add more granularity to the way the trusts are established and thus allow formal one way trusts. It seems that to support your use case you would need to make the external users be IPA users and make AD and IPA trust each other. Also if external users do not authenticate using Kerberos (for example they always use a special portal) then it does not matter what trust is between AD and IPA because those users will not have kerberos tickets that are leveraged in SSO in trust case. HTH. > > > Thanks much, > > Bryce > > > > [1] https://www.redhat.com/archives/freeipa-users/2012-June/msg00206.html > > > > > > 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. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Tue Jan 14 01:05:04 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Tue, 14 Jan 2014 01:05:04 +0000 Subject: [Freeipa-users] One way trusts In-Reply-To: <52D48555.4040008@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E66C085@001FSN2MPN1-044.001f.mgd2.msft.net> <52D48555.4040008@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E66C0D3@001FSN2MPN1-044.001f.mgd2.msft.net> Hi Dimitri, >Just to be sure I understand. >You have internal users - they are in AD. You have external users - they are in LDAP. >You merge two directories and you want to replace this setup with IPA. Yes. >It seems that to support your use case you would need to make the external users be IPA users and make AD and IPA trust each other. I think I concur about migrating my external users into IPA and making IPA trust AD. I may be ignorant of some AD nuance, but I do not see why AD needs to trust IPA. AD does not need to trust my LDAP clients currently. >Also if external users do not authenticate using Kerberos (for example they always use a special portal) then it does not matter what trust is between AD and IPA because those users will not have kerberos tickets that are leveraged in SSO in trust case. I want to be able to point either an LDAP or a Kerberos client at IPA, and have it authenticate my "enterprise" and "external" users for me. I'm not going to tangle with SSO at the moment. Right now, we're just establishing an identity store. >IPA can trust AD. Formally it is a mutual trust but in reality IPA does not have global catalog support for users in IPA to be able to access the resources in AD. In many of the tutorials/HOWTOs, I see that there is a requirement to provide credentials having the permission to add a computer to the domain, or being a member of an AD administration group. I'm a lowly standard "User" in the AD. I don't know if that means I can add a computer to the domain or not. I know I lack the ability to edit AD entries that aren't mine, so I really need a solution that does not require creating a trust relationship inside AD. Is there a way for me to comment out the AD->IPA trust creation, or would that break the IPA->AD trust? Thanks much, 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 bnordgren at fs.fed.us Tue Jan 14 02:50:24 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Tue, 14 Jan 2014 02:50:24 +0000 Subject: [Freeipa-users] FreeIPA and abfab? Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E66C12A@001FSN2MPN1-044.001f.mgd2.msft.net> In my previous message, I asked about one-way trust with AD to provide a means of "extending" our corporate AD with accounts for external cooperators. I expect this is just a technical matter: either FreeIPA supports it or not, and there's no conceptual obstacles. So, my password is the same, and everyone else needs a new account. Not ideal, but it's achievable fairly easily with existing tools. But what I really really want is an identity provider for the edge of the enterprise, where I live. My password is the same and external users can also use their normal password. Essentially, I want a software suite which interfaces between the enterprise environment where everything is centrally managed, and a federated environment where there are too many organizations to shake a stick at. I've been reading about "Application Bridging for Federated Access Beyond Web" (abfab). https://datatracker.ietf.org/wg/abfab/ It appears to me that the draft architecture document and the recently published RFCs (7055, 7056, 7057) defines a mechanism for enterprises to federate and opens up a whole new application space. The big question is, should enterprise-centric management apps expand to include federation, or will a whole new crop of solutions pop up? Or, more pointedly, could this gap be filled by augmenting an enterprise's existing AD deployment with a federation-aware FreeIPA? Has FreeIPA considered moving into this space? I can see several areas where a federation aware, AD compatible solution could add value to an organization: Use case 1: Synchronizing enterprise IDs with IDs exposed to the federation. (Currently, we have "AD" credentials and SAML credentials, and they are not synched. And our SAML IdP does not participate in a federation.) Use case 2: Software can use SAML credentials for workstation logins (if the workstations are on the "research net"); and allow only internal users to use "internal services". Use case 3: Software provides access to "internal + federated" identities using LDAP, SAML, Kerberos, etc. Food for thought. I know this isn't near term, but at this point, I'm just curious if people are even thinking along these lines? 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Less at imagine-sw.com Tue Jan 14 03:44:12 2014 From: Less at imagine-sw.com (Les Stott) Date: Tue, 14 Jan 2014 03:44:12 +0000 Subject: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos) Message-ID: <4ED173A868981548967B4FCA2707222605488D@AACMBXP04.exchserver.com> Been banging my head against the wall on this one for a few days, trying to get a workable configuration for HP ILO to authenticate via FreeIPA. I have a standard rhel6 environment (64 bit 6.4) with freeipa server (ipa-3.0.0-37.el6). The following works for me...... HP ILO4 Firmware 1.22 Default Directory Schema Directory Server Address: fqdn_of_myfreeipaserver Directory Server LDAP Port: 636 Directory User Context 1: cn=users,cn=accounts,dc=mydomain,dc=com Directory Groups: cn=sys_admins,cn=groups,cn=accounts,dc=mydomain,dc=com ....but only if I login with my full dn.... Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com The test settings button in the ILO works only with the full dn. It doesn't work if I use the uid (less), or the cn (Les Stott). I can then login to ILO with .... Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com If I try to login with the cn, Les Stott I see an error in the logs... [13/Jan/2014:22:36:29 -0500] ipalockout_postop - [file ipa_lockout.c, line 473]: Failed to retrieve entry "CN=Les Stott,cn=users,cn=accounts,dc=mydomain,dc=com": 32 I've read a lot of things about getting this to work. Apparently there are issues with HP ILO requiring the username in cn format but its in uid format in freeipa. You should also be able to login with your cn, but that doesn't work. I had a crack at trying Kerberos authentication as well, but it doesn't work and errors with "Additional Pre-authentication required". Has anyone successfully been able to get HP ILO to work with FreeIPA such that you can login with just the username (i.e. "less") or the CN (i.e. "Les Stott")? Are schema changes required? Alternatively has anyone been able to get HP ILO to work with Kerberos auth to FreeIPA? Any help would be greatly appreciated. Regards, Les -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Jan 14 04:50:25 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 14 Jan 2014 06:50:25 +0200 Subject: [Freeipa-users] One way trusts In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E66C0D3@001FSN2MPN1-044.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E66C085@001FSN2MPN1-044.001f.mgd2.msft.net> <52D48555.4040008@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E66C0D3@001FSN2MPN1-044.001f.mgd2.msft.net> Message-ID: <20140114045025.GG12003@redhat.com> Hi, On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote: >Hi Dimitri, > >>Just to be sure I understand. You have internal users - they are in >>AD. You have external users - they are in LDAP. You merge two >>directories and you want to replace this setup with IPA. > >Yes. > >>It seems that to support your use case you would need to make the >>external users be IPA users and make AD and IPA trust each other. > >I think I concur about migrating my external users into IPA and making >IPA trust AD. I may be ignorant of some AD nuance, but I do not see why >AD needs to trust IPA. AD does not need to trust my LDAP clients >currently. 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. Since we don't implement fully all services needed to grant privileges beyond read-only in AD, these binds to AD Global Catalog become read-only. They are still required. An alternative would have been to always keep an account in AD for each IPA host that needs to query user and group identities from AD. We decided to go with the cross-realm Kerberos trust instead since it gives better way of privilege separation. Cross-realm Kerberos trust is known as cross-forest domain trust in AD speak since there are more protocol layers than Kerberos involved (SMB protocol, in particular, is used to set up and verify trust relationship). Once we implement AD GC service, AD admins will be able to subject IPA users/hosts to further limit their access to other AD services beyond simple read-only access to AD LDAP and SMB services. As result, in future more fine-grained privilege and security separation between AD and IPA will be possible. > >>Also if external users do not authenticate using Kerberos (for example >>they always use a special portal) then it does not matter what trust >>is between AD and IPA because those users will not have kerberos >>tickets that are leveraged in SSO in trust case. > >I want to be able to point either an LDAP or a Kerberos client at IPA, >and have it authenticate my "enterprise" and "external" users for me. >I'm not going to tangle with SSO at the moment. Right now, we're just >establishing an identity store. That is what provided by IPA's AD trusts. IPA machines can resolve identities of the users and groups in AD and can authenticate those users on logons, subject to HBAC policies. >>IPA can trust AD. Formally it is a mutual trust but in reality IPA >>does not have global catalog support for users in IPA to be able to >>access the resources in AD. > >In many of the tutorials/HOWTOs, I see that there is a requirement to >provide credentials having the permission to add a computer to the >domain, or being a member of an AD administration group. I'm a lowly >standard "User" in the AD. I don't know if that means I can add a >computer to the domain or not. I know I lack the ability to edit AD >entries that aren't mine, so I really need a solution that does not >require creating a trust relationship inside AD. Both AD integration solutions we have (synchronization and cross-forest domain trusts) assume having higher level access privileges at the time integration is set up. I'm unaware of other mechanisms that would give you the same flexibility and level of privilege separation between the AD and IPA domains. Having a standard 'User' account in AD only entitles you to join up to 10 machines in AD. These machine will become a part of AD domain and are subject of their policies which are quite extended by default. Cross-forest domain trusts, on the other hand, are subject to inter-domain trust relationship policies which are better constrained. One could try to fiddle with AD-joined machine accounts to represent IPA hosts but it is very much uncharted territory since there will be no integration whatsoever on any of IPA features (access controls to IPA services, ID allocation, etc) and everything will need to be set up and maintained manually, including periodical refreshes of the machine accounts. In addition, Kerberos authentication will simply not work as AD has certain assumption over DNS namespace mapping to Kerberos realms. >Is there a way for me to comment out the AD->IPA trust creation, or >would that break the IPA->AD trust? The latter, since AD->IPA part of the trust is used to query AD users and groups. In other words, it is used to provide the key resources needed to operate IPA->AD trust part. -- / Alexander Bokovoy From abokovoy at redhat.com Tue Jan 14 05:18:48 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 14 Jan 2014 07:18:48 +0200 Subject: [Freeipa-users] FreeIPA and abfab? In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E66C12A@001FSN2MPN1-044.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E66C12A@001FSN2MPN1-044.001f.mgd2.msft.net> Message-ID: <20140114051848.GH12003@redhat.com> On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote: >In my previous message, I asked about one-way trust with AD to provide >a means of "extending" our corporate AD with accounts for external >cooperators. I expect this is just a technical matter: either FreeIPA >supports it or not, and there's no conceptual obstacles. So, my >password is the same, and everyone else needs a new account. Not ideal, >but it's achievable fairly easily with existing tools. > >But what I really really want is an identity provider for the edge of >the enterprise, where I live. My password is the same and external >users can also use their normal password. Essentially, I want a >software suite which interfaces between the enterprise environment >where everything is centrally managed, and a federated environment >where there are too many organizations to shake a stick at. > >I've been reading about "Application Bridging for Federated Access >Beyond Web" (abfab). https://datatracker.ietf.org/wg/abfab/ It appears >to me that the draft architecture document and the recently published >RFCs (7055, 7056, 7057) defines a mechanism for enterprises to federate >and opens up a whole new application space. The big question is, >should enterprise-centric management apps expand to include federation, >or will a whole new crop of solutions pop up? Or, more pointedly, could >this gap be filled by augmenting an enterprise's existing AD deployment >with a federation-aware FreeIPA? Has FreeIPA considered moving into >this space? > >I can see several areas where a federation aware, AD compatible >solution could add value to an organization: > >Use case 1: Synchronizing enterprise IDs with IDs exposed to the >federation. (Currently, we have "AD" credentials and SAML credentials, >and they are not synched. And our SAML IdP does not participate in a >federation.) > >Use case 2: Software can use SAML credentials for workstation logins >(if the workstations are on the "research net"); and allow only >internal users to use "internal services". > >Use case 3: Software provides access to "internal + federated" >identities using LDAP, SAML, Kerberos, etc. > > >Food for thought. I know this isn't near term, but at this point, I'm >just curious if people are even thinking along these lines? Yes, we do have plans on being able to bridge with SAML IdP. This work is not yet available for production use but we certainly are looking into making IPA identities available for consumption through SAML-assertions. -- / Alexander Bokovoy From jcholast at redhat.com Tue Jan 14 10:43:36 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 14 Jan 2014 11:43:36 +0100 Subject: [Freeipa-users] Odd problem with SSSD and SSH keys In-Reply-To: <20140113211844.GA31257@hendrix.redhat.com> References: <52D43AFA.1010207@damascusgrp.com> <52D44025.1020800@redhat.com> <52D4421D.6040109@damascusgrp.com> <20140113211844.GA31257@hendrix.redhat.com> Message-ID: <52D514D8.2000908@redhat.com> On 13.1.2014 22:18, Jakub Hrozek wrote: > On Mon, Jan 13, 2014 at 02:44:29PM -0500, Bret Wortman wrote: >> They're definitely different. I deleted the one in the file, then >> tried again. It put the bad key back in the file. I blew the whole >> file away and the same thing happened. Where is this key coming from >> if not from IPA? > > Can you try running sss_ssh_knownhostsproxy manually to see what key > does it return? > > The keys are propagated to the file from the sssd database. If the client > was offline, the client could use stale records. Can you verify the client > has no connectivity issues? > > Honza (CC-ed) might have some more hints. > Compare the public key in /etc/ssh/ssh_host_rsa_key.pub on the host with the public key for that host in IPA. If they do not match, the host key was changed after IPA client was installed and the host record in IPA must be manually updated with the new key. Honza -- Jan Cholasta From natxo.asenjo at gmail.com Tue Jan 14 11:17:47 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 14 Jan 2014 12:17:47 +0100 Subject: [Freeipa-users] sudo log errors Message-ID: hi, after using sudo from ipa extensively I needed to configure a local user to also use sudo. This is for monitoring, we use nagios. It works but now I have lots of error messages in /var/log/messages like this one: sudo: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_0' not found) Well, yes, obviously the nagios local user does not have a kerberos ticket. Why the error? I modified /etc/sudoers to allow the nagios user to not use a tty: Defaults:nagios !requiretty And have added nagios config files for sudo in /etc/sudoers.d/ nagios ALL=NOPASSWD: /usr/lib/nagios/plugins/check_logfiles In /etc/nsswitch.conf, sudo looks like this: sudoers: files ldap Is there anything else I can do or do I just have to live with the error on syslog? TIA, -- Groeten, natxo From bret.wortman at damascusgrp.com Tue Jan 14 11:34:01 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Tue, 14 Jan 2014 06:34:01 -0500 Subject: [Freeipa-users] Odd problem with SSSD and SSH keys In-Reply-To: <52D514D8.2000908@redhat.com> References: <52D43AFA.1010207@damascusgrp.com> <52D44025.1020800@redhat.com> <52D4421D.6040109@damascusgrp.com> <20140113211844.GA31257@hendrix.redhat.com> <52D514D8.2000908@redhat.com> Message-ID: <52D520A9.2080003@damascusgrp.com> The key in /etc/ssh/ssh_host_rsa_key.pub matches what's in IPA for the host in question. It should not have had any connectivity issues; it's co-located with several of our IPA masters. I'd be happy to run sss_ssh_knownhostsproxy manually but haven't been able to locate the proxy command to use via Google yet. Any guidance? On 01/14/2014 05:43 AM, Jan Cholasta wrote: > On 13.1.2014 22:18, Jakub Hrozek wrote: >> On Mon, Jan 13, 2014 at 02:44:29PM -0500, Bret Wortman wrote: >>> They're definitely different. I deleted the one in the file, then >>> tried again. It put the bad key back in the file. I blew the whole >>> file away and the same thing happened. Where is this key coming from >>> if not from IPA? >> >> Can you try running sss_ssh_knownhostsproxy manually to see what key >> does it return? >> >> The keys are propagated to the file from the sssd database. If the >> client >> was offline, the client could use stale records. Can you verify the >> client >> has no connectivity issues? >> >> Honza (CC-ed) might have some more hints. >> > > Compare the public key in /etc/ssh/ssh_host_rsa_key.pub on the host > with the public key for that host in IPA. If they do not match, the > host key was changed after IPA client was installed and the host > record in IPA must be manually updated with the new key. > > Honza > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From bret.wortman at damascusgrp.com Tue Jan 14 11:46:51 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Tue, 14 Jan 2014 06:46:51 -0500 Subject: [Freeipa-users] Odd problem with SSSD and SSH keys In-Reply-To: <52D443E7.3000300@redhat.com> References: <52D43AFA.1010207@damascusgrp.com> <52D44025.1020800@redhat.com> <52D4421D.6040109@damascusgrp.com> <52D443E7.3000300@redhat.com> Message-ID: <52D523AB.1030808@damascusgrp.com> I was assuming that the key was being re-inserted by the ssh authentication request, but to eliminate puppet, I just tried this sequence: # puppet agent --disable # rm -f /var/lib/sss/pubconf/known_hosts # ls -l /var/lib/sss/pubconf/known_hosts # ssh zw131 : : (errors about the key being incorrect) : # cat /var/lib/sss/pubconf/known_hosts : it now contained the bad key again. On 01/13/2014 02:52 PM, Dmitri Pal wrote: > On 01/13/2014 02:44 PM, Bret Wortman wrote: >> They're definitely different. I deleted the one in the file, then >> tried again. It put the bad key back in the file. I blew the whole >> file away and the same thing happened. Where is this key coming from >> if not from IPA? > > Puppet? > >> >> >> On 01/13/2014 02:36 PM, Rob Crittenden wrote: >>> Bret Wortman wrote: >>>> I've got a strange situation where some of my workstations are >>>> reporting >>>> difficulty when sshing to remote systems, but there's no pattern I can >>>> discern. One user's machine can't get to system A, but I can, though I >>>> can't ssh to his workstation directly. >>>> >>>> Here's the kind of thing I see when doing ssh -vvv: >>>> >>>> debug1: Server host key: RSA >>>> 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab >>>> debug3: load_hostkeys: loading entries for host "rs512" from file >>>> "/root/.ssh/known_hosts" >>>> debug3: load_hostkeys: loaded 0 keys >>>> debug3: load_hostkeys: loading entries for host "rs512" from file >>>> "/var/lib/sss/pubconf/known_hosts" >>>> debug3: load_hostkeys: found key type RSA in file >>>> /var/lib/sss/pubconf/known_hosts:2 >>>> debug3: load_hostkeys: loaded 1 keys >>>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ >>>> @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ >>>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ >>>> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! >>>> Someone coudl be eavesdropping on you right now (man-in-the-middle >>>> attack)! >>>> It is also possible that a host key has just been changed. >>>> The fingerprint for the RSA key sent by the remote host is >>>> 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab >>>> Please contact your system administrator. >>>> Add correct host key in /root/.ssh/known_hosts to get rid of this >>>> message. >>>> Offending RSA key in /var/lib/sss/pubconf/known_hosts:2 >>>> RSA host key for zw131 has changed and you have requested strict >>>> checking. >>>> Host key verification failed. >>>> # >>>> >>>> We haven't changed the host key; the public key files are dated >>>> October >>>> 23 of last year. Our configuration files for SSSD and SSH are >>>> managed by >>>> Puppet, so they are consistent from system to system. That said, I did >>>> compare a system that could remote to rs512 to one that could not and >>>> found no differences. Here are the files: >>>> >>>> /etc/sssd/sssd.conf: >>>> [domain/spx.net] >>>> cache_credentials = True >>>> krb5_store_password_if_offline = True >>>> ipa_domain = foo.net >>>> id_provider = ipa >>>> auth_provider = ipa >>>> access_provider = ipa >>>> ipa_hostname = zw129.foo.net >>>> chpass_provider = ipa >>>> ipa_dyndns_update = True >>>> ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49 >>>> ldap_tls_cacert = /etc/ipa/ca.crt >>>> [domain/.spx.net] >>>> cache_credentials = True >>>> krb5_store_password_if_offline = True >>>> krb5_realm = FOO.NET >>>> ipa_domain = .foo.net >>>> id_provider = ipa >>>> auth_provider = ipa >>>> access_provider = ipa >>>> ldap_tls_cacert = /etc/ipa/ca.crt >>>> chpass_provider = ipa >>>> ipa_dyndns_update = True >>>> ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49 >>>> ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net >>>> dns_discovery_domain = .spx.net >>>> [sssd] >>>> services = nss, pam, ssh >>>> config_file_version = 2 >>>> >>>> domains = .spx.net, spx.net >>>> [nss] >>>> >>>> [pam] >>>> >>>> [sudo] >>>> >>>> [autofs] >>>> >>>> [ssh] >>>> >>>> Is there anything else relevant that I should be looking at? >>> >>> You might compare the value of the key in IPA to what is in >>> /var/lib/sss/pubconf/known_hosts >>> >>> rob >>> >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From mitkany at gmail.com Tue Jan 14 15:27:00 2014 From: mitkany at gmail.com (Dimitar Georgievski) Date: Tue, 14 Jan 2014 10:27:00 -0500 Subject: [Freeipa-users] Sudo policy not working with group of servers Message-ID: Hi, I've been trying to create a simple sudo policy, that would grant certain privileges to a group of users on a group of hosts. The policy would not work unless I specify the hosts individually in the *Sudo Rule* definition page under *Access this hos*t section. I am using FreeIPA v3.0 and SSSD v1.9.2 on CentOS 6.5 Thanks, Dimitar -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Jan 14 15:40:56 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 14 Jan 2014 10:40:56 -0500 Subject: [Freeipa-users] Sudo policy not working with group of servers In-Reply-To: References: Message-ID: <52D55A88.80305@redhat.com> Dimitar Georgievski wrote: > Hi, > > I've been trying to create a simple sudo policy, that would grant > certain privileges to a group of users on a group of hosts. The policy > would not work unless I specify the hosts individually in the *Sudo > Rule* definition page under *Access this hos*t section. > > I am using FreeIPA v3.0 and SSSD v1.9.2 on CentOS 6.5 You need to set the NIS domain name on the client machine: # domainname example.com Then it should work. You can test with getent netgroup some_hostgroup rob From mkosek at redhat.com Tue Jan 14 15:41:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 14 Jan 2014 16:41:53 +0100 Subject: [Freeipa-users] Sudo policy not working with group of servers In-Reply-To: References: Message-ID: <52D55AC1.1090707@redhat.com> On 01/14/2014 04:27 PM, Dimitar Georgievski wrote: > Hi, > > I've been trying to create a simple sudo policy, that would grant certain > privileges to a group of users on a group of hosts. The policy would not > work unless I specify the hosts individually in the *Sudo Rule* definition > page under *Access this hos*t section. > > I am using FreeIPA v3.0 and SSSD v1.9.2 on CentOS 6.5 > > Thanks, > > Dimitar Hello Dimitar, I would recommend starting investigation by following this article: http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups Martin From dpal at redhat.com Tue Jan 14 16:22:11 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 14 Jan 2014 11:22:11 -0500 Subject: [Freeipa-users] One way trusts In-Reply-To: <20140114045025.GG12003@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E66C085@001FSN2MPN1-044.001f.mgd2.msft.net> <52D48555.4040008@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E66C0D3@001FSN2MPN1-044.001f.mgd2.msft.net> <20140114045025.GG12003@redhat.com> Message-ID: <52D56433.9060703@redhat.com> On 01/13/2014 11:50 PM, Alexander Bokovoy wrote: > Hi, > > On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote: >> Hi Dimitri, >> >>> Just to be sure I understand. You have internal users - they are in >>> AD. You have external users - they are in LDAP. You merge two >>> directories and you want to replace this setup with IPA. >> >> Yes. >> >>> It seems that to support your use case you would need to make the >>> external users be IPA users and make AD and IPA trust each other. >> >> I think I concur about migrating my external users into IPA and making >> IPA trust AD. I may be ignorant of some AD nuance, but I do not see why >> AD needs to trust IPA. AD does not need to trust my LDAP clients >> currently. > 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. > > Since we don't implement fully all services needed to grant privileges > beyond read-only in AD, these binds to AD Global Catalog become > read-only. They are still required. An alternative would have been to > always keep an account in AD for each IPA host that needs to query user > and group identities from AD. We decided to go with the cross-realm > Kerberos trust instead since it gives better way of privilege separation. > Cross-realm Kerberos trust is known as cross-forest domain trust in AD > speak since there are more protocol layers than Kerberos involved (SMB > protocol, in particular, is used to set up and verify trust > relationship). > > Once we implement AD GC service, AD admins will be able to subject IPA > users/hosts to further limit their access to other AD services beyond > simple read-only access to AD LDAP and SMB services. As result, in > future more fine-grained privilege and security separation between AD > and IPA will be possible. > >> >>> Also if external users do not authenticate using Kerberos (for example >>> they always use a special portal) then it does not matter what trust >>> is between AD and IPA because those users will not have kerberos >>> tickets that are leveraged in SSO in trust case. >> >> I want to be able to point either an LDAP or a Kerberos client at IPA, >> and have it authenticate my "enterprise" and "external" users for me. >> I'm not going to tangle with SSO at the moment. Right now, we're just >> establishing an identity store. > That is what provided by IPA's AD trusts. IPA machines can resolve > identities of the users and groups in AD and can authenticate those > users on logons, subject to HBAC policies. > >>> IPA can trust AD. Formally it is a mutual trust but in reality IPA >>> does not have global catalog support for users in IPA to be able to >>> access the resources in AD. >> >> In many of the tutorials/HOWTOs, I see that there is a requirement to >> provide credentials having the permission to add a computer to the >> domain, or being a member of an AD administration group. I'm a lowly >> standard "User" in the AD. I don't know if that means I can add a >> computer to the domain or not. I know I lack the ability to edit AD >> entries that aren't mine, so I really need a solution that does not >> require creating a trust relationship inside AD. > Both AD integration solutions we have (synchronization and cross-forest > domain trusts) assume having higher level access privileges at the time > integration is set up. I'm unaware of other mechanisms that would give > you the same flexibility and level of privilege separation between the > AD and IPA domains. Having a standard 'User' account in AD only entitles > you to join up to 10 machines in AD. These machine will become a part of > AD domain and are subject of their policies which are quite extended by > default. Cross-forest domain trusts, on the other hand, are subject to > inter-domain trust relationship policies which are better constrained. > > One could try to fiddle with AD-joined machine accounts to represent IPA > hosts but it is very much uncharted territory since there will be no > integration whatsoever on any of IPA features (access controls to IPA > services, ID allocation, etc) and everything will need to be set up and > maintained manually, including periodical refreshes of the machine > accounts. In addition, Kerberos authentication will simply not work as > AD has certain assumption over DNS namespace mapping to Kerberos realms. > > >> Is there a way for me to comment out the AD->IPA trust creation, or >> would that break the IPA->AD trust? > The latter, since AD->IPA part of the trust is used to query AD users > and groups. In other words, it is used to provide the key resources > needed to operate IPA->AD trust part. > > The shorter answer is: to setup any integration you need to ask AD admin to help you out to setup trust or sync and then you can continue on your own. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Tue Jan 14 16:30:58 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 14 Jan 2014 11:30:58 -0500 Subject: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos) In-Reply-To: <4ED173A868981548967B4FCA2707222605488D@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222605488D@AACMBXP04.exchserver.com> Message-ID: <52D56642.7040506@redhat.com> On 01/13/2014 10:44 PM, Les Stott wrote: > > Been banging my head against the wall on this one for a few days, > trying to get a workable configuration for HP ILO to authenticate via > FreeIPA. > > > > I have a standard rhel6 environment (64 bit 6.4) with freeipa server > (ipa-3.0.0-37.el6). > > > > The following works for me...... > > > > HP ILO4 Firmware 1.22 > > Default Directory Schema > > Directory Server Address: fqdn_of_myfreeipaserver > > Directory Server LDAP Port: 636 > > Directory User Context 1: cn=users,cn=accounts,dc=mydomain,dc=com > > Directory Groups: cn=sys_admins,cn=groups,cn=accounts,dc=mydomain,dc=com > > > > ....but only if I login with my full dn.... > > > > Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com > > > > The test settings button in the ILO works only with the full dn. > > > > It doesn't work if I use the uid (less), or the cn (Les Stott). > > > > I can then login to ILO with .... > > Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com > > > > If I try to login with the cn, Les Stott I see an error in the logs... > > > > [13/Jan/2014:22:36:29 -0500] ipalockout_postop - [file ipa_lockout.c, > line 473]: Failed to retrieve entry "CN=Les > Stott,cn=users,cn=accounts,dc=mydomain,dc=com": 32 > > > > I've read a lot of things about getting this to work. Apparently there > are issues with HP ILO requiring the username in cn format but its in > uid format in freeipa. You should also be able to login with your cn, > but that doesn't work. > > > > I had a crack at trying Kerberos authentication as well, but it > doesn't work and errors with "Additional Pre-authentication required". > > > > Has anyone successfully been able to get HP ILO to work with FreeIPA > such that you can login with just the username (i.e. "less") or the CN > (i.e. "Les Stott")? > > > > Are schema changes required? > > > > Alternatively has anyone been able to get HP ILO to work with Kerberos > auth to FreeIPA? > > > > Any help would be greatly appreciated. > > > > Regards, > > > > Les > > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Have you searched freeipa-users archives? The issue sounds familiar and I vaguely recalled there was a workaround. This is the thread https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html I think you can use compat plugin on the IPA to expose the tree in the way HP ILO expects. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Jan 14 16:34:04 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 14 Jan 2014 11:34:04 -0500 Subject: [Freeipa-users] sudo log errors In-Reply-To: References: Message-ID: <52D566FC.2070108@redhat.com> On 01/14/2014 06:17 AM, Natxo Asenjo wrote: > hi, > > after using sudo from ipa extensively I needed to configure a local > user to also use sudo. > > This is for monitoring, we use nagios. > > It works but now I have lots of error messages in /var/log/messages > like this one: > > sudo: GSSAPI Error: Unspecified GSS failure. Minor code may provide > more information (Credentials cache file '/tmp/krb5cc_0' not found) > > Well, yes, obviously the nagios local user does not have a kerberos > ticket. Why the error? > > I modified /etc/sudoers to allow the nagios user to not use a tty: > > Defaults:nagios !requiretty > > And have added nagios config files for sudo in /etc/sudoers.d/ > > nagios ALL=NOPASSWD: /usr/lib/nagios/plugins/check_logfiles > > In /etc/nsswitch.conf, sudo looks like this: > > sudoers: files ldap > > Is there anything else I can do or do I just have to live with the > error on syslog? > > TIA, > -- > Groeten, > natxo > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users I wonder if putting this user into the local sssd provider would silence it... Just a thought... -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Less at imagine-sw.com Tue Jan 14 21:01:42 2014 From: Less at imagine-sw.com (Les Stott) Date: Tue, 14 Jan 2014 21:01:42 +0000 Subject: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos) In-Reply-To: <52D56642.7040506@redhat.com> References: <4ED173A868981548967B4FCA2707222605488D@AACMBXP04.exchserver.com>, <52D56642.7040506@redhat.com> Message-ID: <4ED173A868981548967B4FCA27072226054E59@AACMBXP04.exchserver.com> I had seen that thread... https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html all it says is... On 11/05/2013 02:51 PM, KodaK wrote: If I use the whole connection string: uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com I can authenticate. Which i can do successfully, but its not great to have to tell everyone your username for ilo is uid=blah,cn=users,cn=accounts..etc There is also mentioned in that thread... "The HP iLO documentation doesn't list using the uid value as a supported form of specifying the login. You can use the CN value or the full DN. They say that "DOMAIN\user" and "user domain" forms are also accepted, but that likely only works against Active Directory." CN doesn't work. full DN does. I don't see any reference to a workaround via compat plugin in that thread. Have you got any more info on the compat workaround? Thanks, Les ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Wednesday, January 15, 2014 3:30 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos) On 01/13/2014 10:44 PM, Les Stott wrote: Been banging my head against the wall on this one for a few days, trying to get a workable configuration for HP ILO to authenticate via FreeIPA. I have a standard rhel6 environment (64 bit 6.4) with freeipa server (ipa-3.0.0-37.el6). The following works for me?? HP ILO4 Firmware 1.22 Default Directory Schema Directory Server Address: fqdn_of_myfreeipaserver Directory Server LDAP Port: 636 Directory User Context 1: cn=users,cn=accounts,dc=mydomain,dc=com Directory Groups: cn=sys_admins,cn=groups,cn=accounts,dc=mydomain,dc=com ?.but only if I login with my full dn?. Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com The test settings button in the ILO works only with the full dn. It doesn?t work if I use the uid (less), or the cn (Les Stott). I can then login to ILO with ?. Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com If I try to login with the cn, Les Stott I see an error in the logs? [13/Jan/2014:22:36:29 -0500] ipalockout_postop - [file ipa_lockout.c, line 473]: Failed to retrieve entry "CN=Les Stott,cn=users,cn=accounts,dc=mydomain,dc=com": 32 I?ve read a lot of things about getting this to work. Apparently there are issues with HP ILO requiring the username in cn format but its in uid format in freeipa. You should also be able to login with your cn, but that doesn?t work. I had a crack at trying Kerberos authentication as well, but it doesn?t work and errors with ?Additional Pre-authentication required?. Has anyone successfully been able to get HP ILO to work with FreeIPA such that you can login with just the username (i.e. ?less?) or the CN (i.e. ?Les Stott?)? Are schema changes required? Alternatively has anyone been able to get HP ILO to work with Kerberos auth to FreeIPA? Any help would be greatly appreciated. Regards, Les _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Have you searched freeipa-users archives? The issue sounds familiar and I vaguely recalled there was a workaround. This is the thread https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html I think you can use compat plugin on the IPA to expose the tree in the way HP ILO expects. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Jan 14 21:35:52 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 14 Jan 2014 16:35:52 -0500 Subject: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos) In-Reply-To: <4ED173A868981548967B4FCA27072226054E59@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222605488D@AACMBXP04.exchserver.com>, <52D56642.7040506@redhat.com> <4ED173A868981548967B4FCA27072226054E59@AACMBXP04.exchserver.com> Message-ID: <52D5ADB8.8030504@redhat.com> On 01/14/2014 04:01 PM, Les Stott wrote: > I had seen that thread... > https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html > > all it says is... > > On 11/05/2013 02:51 PM, KodaK wrote: >> If I use the whole connection string: >> >> uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com >> >> I can authenticate. > Which i can do successfully, but its not great to have to tell > everyone your username for ilo is uid=blah,cn=users,cn=accounts..etc > > There is also mentioned in that thread... > > "The HP iLO documentation doesn't list using the uid value as a > supported form of specifying the login. You can use the CN value or > the full DN. They say that "DOMAIN\user" and "user domain" forms are > also accepted, but that likely only works against Active Directory." > > CN doesn't work. full DN does. > > I don't see any reference to a workaround via compat plugin in that > thread. > > Have you got any more info on the compat workaround? > You can create a compat tree using compat plugin of IPA. It is used for NIS, support of Solaris clients and for AD trusts in latest IPA. As a simple test you can enable the plugin: ipa-compat-manage enable That will expose the tree on the cn=compat hive but using 2307 schema. You can then change the configuration of the plugin to use uid value instead of CN in this view, i.e expose CN as uid. Then you can point your HP ILO to that tree. AFAIU in the past it was not possible because we did not allow bind against compat tree but now we allow it so it should work with the latest IPA 3.3.x bits. Details on how to change compat configuration can be found in the plugin configuration here: https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc I am not sure that would 100% work but IMO worth a shot. > Thanks, > > Les > > ------------------------------------------------------------------------ > *From:* freeipa-users-bounces at redhat.com > [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal > [dpal at redhat.com] > *Sent:* Wednesday, January 15, 2014 3:30 AM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] HP ILO Authentication via LDAP (or even > kerberos) > > On 01/13/2014 10:44 PM, Les Stott wrote: >> >> Been banging my head against the wall on this one for a few days, >> trying to get a workable configuration for HP ILO to authenticate via >> FreeIPA. >> >> >> >> I have a standard rhel6 environment (64 bit 6.4) with freeipa server >> (ipa-3.0.0-37.el6). >> >> >> >> The following works for me?? >> >> >> >> HP ILO4 Firmware 1.22 >> >> Default Directory Schema >> >> Directory Server Address: fqdn_of_myfreeipaserver >> >> Directory Server LDAP Port: 636 >> >> Directory User Context 1: cn=users,cn=accounts,dc=mydomain,dc=com >> >> Directory Groups: cn=sys_admins,cn=groups,cn=accounts,dc=mydomain,dc=com >> >> >> >> ?.but only if I login with my full dn?. >> >> >> >> Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com >> >> >> >> The test settings button in the ILO works only with the full dn. >> >> >> >> It doesn?t work if I use the uid (less), or the cn (Les Stott). >> >> >> >> I can then login to ILO with ?. >> >> Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com >> >> >> >> If I try to login with the cn, Les Stott I see an error in the logs? >> >> >> >> [13/Jan/2014:22:36:29 -0500] ipalockout_postop - [file ipa_lockout.c, >> line 473]: Failed to retrieve entry "CN=Les >> Stott,cn=users,cn=accounts,dc=mydomain,dc=com": 32 >> >> >> >> I?ve read a lot of things about getting this to work. Apparently >> there are issues with HP ILO requiring the username in cn format but >> its in uid format in freeipa. You should also be able to login with >> your cn, but that doesn?t work. >> >> >> >> I had a crack at trying Kerberos authentication as well, but it >> doesn?t work and errors with ?Additional Pre-authentication required?. >> >> >> >> Has anyone successfully been able to get HP ILO to work with FreeIPA >> such that you can login with just the username (i.e. ?less?) or the >> CN (i.e. ?Les Stott?)? >> >> >> >> Are schema changes required? >> >> >> >> Alternatively has anyone been able to get HP ILO to work with >> Kerberos auth to FreeIPA? >> >> >> >> Any help would be greatly appreciated. >> >> >> >> Regards, >> >> >> >> Les >> >> >> >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > Have you searched freeipa-users archives? The issue sounds familiar > and I vaguely recalled there was a workaround. > This is the thread > https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html > > I think you can use compat plugin on the IPA to expose the tree in the > way HP ILO expects. > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Tue Jan 14 22:23:41 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Tue, 14 Jan 2014 22:23:41 +0000 Subject: [Freeipa-users] One way trusts In-Reply-To: <52D56433.9060703@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E66C085@001FSN2MPN1-044.001f.mgd2.msft.net> <52D48555.4040008@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E66C0D3@001FSN2MPN1-044.001f.mgd2.msft.net> <20140114045025.GG12003@redhat.com> <52D56433.9060703@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E66C358@001FSN2MPN1-044.001f.mgd2.msft.net> > Both AD integration solutions we have (synchronization and > cross-forest domain trusts) assume having higher level access > privileges at the time integration is set up. My problem here is that I'm too ignorable. :) There's over 15000 users in our AD; I'm in Montana, the admins are in DC. Worse, our agency's AD is being absorbed into the next level up the chain (Forest Service AD is going to become a part of the overall USDA AD). Then I'm an even smaller fish, relatively speaking. > I'm unaware of other > mechanisms that would give you the same flexibility and level of > privilege separation between the AD and IPA domains. ?? The current solution using the LDAP interface to AD (and a metadirectory to merge "external users") provides privilege separation and the flexibility to add external users. I don't need more; I just need it to be less clunky. It weakens security, of course, as my AD password is stored in various plaintext configuration files for each application needing binding credentials to search for users in AD. I also have an index to which files contain my password, as it forms a "password-change-checklist" which I need to run thru every 60 days. If I might try to repeat the problem back to you to see if I got it right...the factor which requires access to the corporate AD is setting up a Kerberos cross realm trust. This is required so that machines in IPA can connect directly to AD for authentication. This in turn is necessary so that identities in the AD Kerberos Realm are correctly and consistently identified as being sourced from AD. And of course, this requirement is necessary for services in AD to recognize users and groups in AD. Let me ask what is probably a series of dumb questions: What do I lose if my FreeIPA server is set up as one of the 10 machines I can join to the network as a regular user, and all the machines in IPA connect directly to IPA? Could FreeIPA (current or future) be configured to relay the credentials to AD either via Kerberos or using AD's LDAP interface (binding as itself because it's joined to the AD domain)? If AD accepts the provided credentials can FreeIPA issue the user a ticket in the FreeIPA realm? Would this look to AD like a bunch of users are logging into the FreeIPA server machine? I know this arrangement would sacrifice access to any of the AD services by AD-users-on-the-IPA network. That's fine. If it's technically feasible, tho, it gives me one server that can authenticate both "corporate users" and "external users", and a central administration point for the external network. It also plainly differentiates between corporate users logged in on the corporate network, and corporate users logged in on the "external network". I'd consider that a good thing. Finally, if this is possible, it seems to me that this stands a chance of reducing the number of places my password is stored in plaintext. 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 Wed Jan 15 00:29:06 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 14 Jan 2014 19:29:06 -0500 Subject: [Freeipa-users] One way trusts In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E66C358@001FSN2MPN1-044.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E66C085@001FSN2MPN1-044.001f.mgd2.msft.net> <52D48555.4040008@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E66C0D3@001FSN2MPN1-044.001f.mgd2.msft.net> <20140114045025.GG12003@redhat.com> <52D56433.9060703@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E66C358@001FSN2MPN1-044.001f.mgd2.msft.net> Message-ID: <52D5D652.9060500@redhat.com> On 01/14/2014 05:23 PM, Nordgren, Bryce L -FS wrote: >> Both AD integration solutions we have (synchronization and >> cross-forest domain trusts) assume having higher level access >> privileges at the time integration is set up. > My problem here is that I'm too ignorable. :) There's over 15000 users in our AD; I'm in Montana, the admins are in DC. Worse, our agency's AD is being absorbed into the next level up the chain (Forest Service AD is going to become a part of the overall USDA AD). Then I'm an even smaller fish, relatively speaking. > >> I'm unaware of other >> mechanisms that would give you the same flexibility and level of >> privilege separation between the AD and IPA domains. > ?? The current solution using the LDAP interface to AD (and a metadirectory to merge "external users") provides privilege separation and the flexibility to add external users. I don't need more; I just need it to be less clunky. It weakens security, of course, as my AD password is stored in various plaintext configuration files for each application needing binding credentials to search for users in AD. I also have an index to which files contain my password, as it forms a "password-change-checklist" which I need to run thru every 60 days. > > If I might try to repeat the problem back to you to see if I got it right...the factor which requires access to the corporate AD is setting up a Kerberos cross realm trust. This is required so that machines in IPA can connect directly to AD for authentication. This in turn is necessary so that identities in the AD Kerberos Realm are correctly and consistently identified as being sourced from AD. And of course, this requirement is necessary for services in AD to recognize users and groups in AD. > > Let me ask what is probably a series of dumb questions: What do I lose if my FreeIPA server is set up as one of the 10 machines I can join to the network as a regular user, and all the machines in IPA connect directly to IPA? Could FreeIPA (current or future) be configured to relay the credentials to AD either via Kerberos or using AD's LDAP interface (binding as itself because it's joined to the AD domain)? If AD accepts the provided credentials can FreeIPA issue the user a ticket in the FreeIPA realm? Would this look to AD like a bunch of users are logging into the FreeIPA server machine? > > I know this arrangement would sacrifice access to any of the AD services by AD-users-on-the-IPA network. That's fine. If it's technically feasible, tho, it gives me one server that can authenticate both "corporate users" and "external users", and a central administration point for the external network. It also plainly differentiates between corporate users logged in on the corporate network, and corporate users logged in on the "external network". I'd consider that a good thing. Finally, if this is possible, it seems to me that this stands a chance of reducing the number of places my password is stored in plaintext. > > Bryce > You might be able to do one of the following hacks. I am saying hack because no one tried to do it and it might not work and hit some bugs and issues. 1) Use pam proxy capability. If you bind to IPA DS via LDAP you can configure users to authenticate using pam proxy feature of DS and via pam point to AD. This has limitation that it works only for LDAP binds but not for kerberos so your clients would be deprived off SSO. Alternatively you can separate external and internal users. Internal users would be able to do LDAP only while external users since they would be stored in IPA would be able to do both. AFAIU this is not what you want. 2) IPA in 3.3 uses compat tree to present AD data to legacy clients and allow bind to that tree. This is just LDAP so has similar limitations. I suspect it would also rely on the presence of trust to be able to bind to AD but I am not sure. Alexander, CCed would have more details to share for this case. 3) Finally the grand hack that actually might work. IPA 3.3 and 3.4 that is being worked on have OTP support. You will setup winsync to sync AD users (one way from AD), you will make sure that these users can't be modified in IPA via permissions and ACIs so that you do not get into the situation when users become different in IPA and AD. Since you own IPA you will have full control so this part is really up to you. When users are synced in you will add a way of setting additional attributes for the synced in users. I am not sure if this can be done without adding a DS or Winsync plugin but I think it would not be a lot of code for you to do (may be there is a trick that I do not know that might be done to avoid writing a plugin, see below). As a result the synced in users will have following attributes set: **ipatokenRadiusConfigLink - this attribute should point to a RADIUS server configuration object. There will be one such object (see below). All synced in users will point to its DN via this attribute. ipaUserAuthTypeClass - this attribute should specify that the user should use RADIUS for his authentication. I.e. the value should be "radius". Corresponding object classes that these attributes belong to should already be a part of user object by default in 3.4 (Nathaniel?) Now back to plugin. Since all the synced users will have the same values for these two attributes it might be possible to avoid writing a plugin. I just do not know how. Now you add the RADIUS object via UI or CLI. You actually do it first before setting up winsync. Some hints can be found here: http://www.freeipa.org/page/V3/OTP. The RADIUS configuration should point to some RADIUS server. If there is a RADIUS server in your organization you might point to it. Otherwise you can setup FreeRADIUS and use its LDAP or pam configuration to do an LDAP bind against AD. You can then add "external" users as normal IPA users without setting any extra attributes for them. It might be possible to avoid writing a plugin by actually not setting anything for synced users, defining a global ipaUserAuthTypeClass as "radius" and defining ipaUserAuthTypeClass as "passord" for any manually added external user. However I am not sure if that would work (I suspect there might be a bug there). Nathaniel, when you set global policy to "radius" ipa config-mod --user-auth-type=radius which radius configuration would it pick? How would it work? So let us assume that the bug is not there and things would work. Let me summarize my thinking... 1) Install IPA 2) Install RADIUS server, configure it to authenticate against AD 3) Add RADIUS server configuration to IPA using 'ipa radiusproxy-add' command 4) Set ipaUserAuthTypeClass attribute to 'password' for your admin user. You can do it using 'ipa user-mod ... --setattr...' command. If you do not do it I suspect you lock yourself out by the next step. 5) Set global IPA policy 'ipa config-mod --user-auth-type=radius' - that will force all users without ipaUserAuthTypeClass explicitly set to authenticate using RADIUS. 6) Setup one way winsync agreement with AD (that might require some tweaking of the winsync configuration, Rich?). Follow docs. https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html 7) Always set ipaUserAuthTypeClass to 'password' when you add users (you can probably wrap 'ipa user-add' command with a specific shell script to always add it in your case. That seems to be it. External and internal users would be able to authenticate using kerberos while internal users will use their AD passwords but it will be IPA that would issue the tickets. I suggest you start will latest bits from a nightly repo as I know there have been bug fixes in this area that are not released yet. > > > > > 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. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Less at imagine-sw.com Wed Jan 15 02:57:45 2014 From: Less at imagine-sw.com (Les Stott) Date: Wed, 15 Jan 2014 02:57:45 +0000 Subject: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos) In-Reply-To: <52D5ADB8.8030504@redhat.com> References: <4ED173A868981548967B4FCA2707222605488D@AACMBXP04.exchserver.com>, <52D56642.7040506@redhat.com> <4ED173A868981548967B4FCA27072226054E59@AACMBXP04.exchserver.com> <52D5ADB8.8030504@redhat.com> Message-ID: <4ED173A868981548967B4FCA270722260550F0@AACMBXP04.exchserver.com> Still no joy. Although I don't profess to be a schema changing expert. Compat plugin was already enabled. Ipa version is 3.0.0-37.el6 So I modified /etc/dirsrv/slapd-MYDOMAIN-COM/dse.ldif... Under dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config I set the following... schema-compat-entry-attribute: cn=%{cn} schema-compat-entry-rdn: cn=%{cn} Left the rest as default. When I ldapsearch against the compat tree, I see it working the way I want (i.e. dn starts with cn instead of uid). ldapsearch -x -b "cn=compat,dc=mydomain,dc=com" "cn=Les Stott" # Les Stott, users, compat, mydomain.com dn: cn=Les Stott,cn=users,cn=compat,dc=mydomain,dc=com ILO Search context was set as: cn=users,cn=compat,dc=mydomain,dc=com So it looks good, but when I test from ILO it fails still. Try.. Les Stott ...It cant bind [14/Jan/2014:21:52:31 -0500] conn=47 op=0 BIND dn="CN=Les Stott,cn=users,cn=compat,dc=mydomain,dc=com" method=128 version=2 [14/Jan/2014:21:52:31 -0500] conn=47 op=0 RESULT err=49 tag=97 nentries=0 etime=0 [14/Jan/2014:21:52:31 -0500] conn=47 op=1 UNBIND [14/Jan/2014:21:52:31 -0500] conn=48 op=0 BIND dn="Les Stott" authzid="(null)", invalid bind dn [14/Jan/2014:21:52:31 -0500] conn=48 op=0 RESULT err=34 tag=97 nentries=0 etime=0 [14/Jan/2014:21:52:31 -0500] conn=48 op=1 BIND dn="CN=Les Stott,cn=users,cn=compat,dc=mydomain,dc=com" method=128 version=2 [14/Jan/2014:21:52:31 -0500] conn=48 op=1 RESULT err=49 tag=97 nentries=0 etime=0 [14/Jan/2014:21:52:31 -0500] conn=48 op=2 UNBIND [14/Jan/2014:21:52:31 -0500] conn=50 op=0 BIND dn="CN=Les Stott,cn=users,cn=compat,dc=mydomain,dc=com" method=128 version=2 [14/Jan/2014:21:52:31 -0500] conn=50 op=0 RESULT err=49 tag=97 nentries=0 etime=0 [14/Jan/2014:21:52:31 -0500] conn=50 op=1 UNBIND Is it just not supporting to bind against the compat tree in 3.0.0.37? or am I doing something wrong? Regards, Les From: Dmitri Pal [mailto:dpal at redhat.com] Sent: Wednesday, 15 January 2014 8:36 AM To: Les Stott Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos) On 01/14/2014 04:01 PM, Les Stott wrote: I had seen that thread... https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html all it says is... On 11/05/2013 02:51 PM, KodaK wrote: If I use the whole connection string: uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com I can authenticate. Which i can do successfully, but its not great to have to tell everyone your username for ilo is uid=blah,cn=users,cn=accounts..etc There is also mentioned in that thread... "The HP iLO documentation doesn't list using the uid value as a supported form of specifying the login. You can use the CN value or the full DN. They say that "DOMAIN\user" and "user domain" forms are also accepted, but that likely only works against Active Directory." CN doesn't work. full DN does. I don't see any reference to a workaround via compat plugin in that thread. Have you got any more info on the compat workaround? You can create a compat tree using compat plugin of IPA. It is used for NIS, support of Solaris clients and for AD trusts in latest IPA. As a simple test you can enable the plugin: ipa-compat-manage enable That will expose the tree on the cn=compat hive but using 2307 schema. You can then change the configuration of the plugin to use uid value instead of CN in this view, i.e expose CN as uid. Then you can point your HP ILO to that tree. AFAIU in the past it was not possible because we did not allow bind against compat tree but now we allow it so it should work with the latest IPA 3.3.x bits. Details on how to change compat configuration can be found in the plugin configuration here: https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc I am not sure that would 100% work but IMO worth a shot. Thanks, Les ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Wednesday, January 15, 2014 3:30 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos) On 01/13/2014 10:44 PM, Les Stott wrote: Been banging my head against the wall on this one for a few days, trying to get a workable configuration for HP ILO to authenticate via FreeIPA. I have a standard rhel6 environment (64 bit 6.4) with freeipa server (ipa-3.0.0-37.el6). The following works for me...... HP ILO4 Firmware 1.22 Default Directory Schema Directory Server Address: fqdn_of_myfreeipaserver Directory Server LDAP Port: 636 Directory User Context 1: cn=users,cn=accounts,dc=mydomain,dc=com Directory Groups: cn=sys_admins,cn=groups,cn=accounts,dc=mydomain,dc=com ....but only if I login with my full dn.... Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com The test settings button in the ILO works only with the full dn. It doesn't work if I use the uid (less), or the cn (Les Stott). I can then login to ILO with .... Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com If I try to login with the cn, Les Stott I see an error in the logs... [13/Jan/2014:22:36:29 -0500] ipalockout_postop - [file ipa_lockout.c, line 473]: Failed to retrieve entry "CN=Les Stott,cn=users,cn=accounts,dc=mydomain,dc=com": 32 I've read a lot of things about getting this to work. Apparently there are issues with HP ILO requiring the username in cn format but its in uid format in freeipa. You should also be able to login with your cn, but that doesn't work. I had a crack at trying Kerberos authentication as well, but it doesn't work and errors with "Additional Pre-authentication required". Has anyone successfully been able to get HP ILO to work with FreeIPA such that you can login with just the username (i.e. "less") or the CN (i.e. "Les Stott")? Are schema changes required? Alternatively has anyone been able to get HP ILO to work with Kerberos auth to FreeIPA? Any help would be greatly appreciated. Regards, Les _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Have you searched freeipa-users archives? The issue sounds familiar and I vaguely recalled there was a workaround. This is the thread https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html I think you can use compat plugin on the IPA to expose the tree in the way HP ILO expects. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Jan 15 03:12:42 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 14 Jan 2014 20:12:42 -0700 Subject: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos) In-Reply-To: <4ED173A868981548967B4FCA270722260550F0@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222605488D@AACMBXP04.exchserver.com>, <52D56642.7040506@redhat.com> <4ED173A868981548967B4FCA27072226054E59@AACMBXP04.exchserver.com> <52D5ADB8.8030504@redhat.com> <4ED173A868981548967B4FCA270722260550F0@AACMBXP04.exchserver.com> Message-ID: <52D5FCAA.4020407@redhat.com> On 01/14/2014 07:57 PM, Les Stott wrote: > > Still no joy. Although I don't profess to be a schema changing expert. > > Compat plugin was already enabled. Ipa version is 3.0.0-37.el6 > > So I modified /etc/dirsrv/slapd-MYDOMAIN-COM/dse.ldif... > > Under > > dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config > > I set the following... > > schema-compat-entry-attribute: cn=%{cn} > > schema-compat-entry-rdn: cn=%{cn} > > Left the rest as default. > > When I ldapsearch against the compat tree, I see it working the way I > want (i.e. dn starts with cn instead of uid). > > ldapsearch -x -b "cn=compat,dc=mydomain,dc=com" "cn=Les Stott" > > # Les Stott, users, compat, mydomain.com > > dn: cn=Les Stott,cn=users,cn=compat,dc=mydomain,dc=com > > ILO Search context was set as: cn=users,cn=compat,dc=mydomain,dc=com > > So it looks good, but when I test from ILO it fails still. > > Try.. > > Les Stott > > ...It cant bind > > [14/Jan/2014:21:52:31 -0500] conn=47 op=0 BIND dn="CN=Les > Stott,cn=users,cn=compat,dc=mydomain,dc=com" method=128 version=2 > > [14/Jan/2014:21:52:31 -0500] conn=47 op=0 RESULT err=49 tag=97 > nentries=0 etime=0 > > [14/Jan/2014:21:52:31 -0500] conn=47 op=1 UNBIND > > [14/Jan/2014:21:52:31 -0500] conn=48 op=0 BIND dn="Les Stott" > authzid="(null)", invalid bind dn > > [14/Jan/2014:21:52:31 -0500] conn=48 op=0 RESULT err=34 tag=97 > nentries=0 etime=0 > > [14/Jan/2014:21:52:31 -0500] conn=48 op=1 BIND dn="CN=Les > Stott,cn=users,cn=compat,dc=mydomain,dc=com" method=128 version=2 > > [14/Jan/2014:21:52:31 -0500] conn=48 op=1 RESULT err=49 tag=97 > nentries=0 etime=0 > > [14/Jan/2014:21:52:31 -0500] conn=48 op=2 UNBIND > > [14/Jan/2014:21:52:31 -0500] conn=50 op=0 BIND dn="CN=Les > Stott,cn=users,cn=compat,dc=mydomain,dc=com" method=128 version=2 > > [14/Jan/2014:21:52:31 -0500] conn=50 op=0 RESULT err=49 tag=97 > nentries=0 etime=0 > > [14/Jan/2014:21:52:31 -0500] conn=50 op=1 UNBIND > > Is it just not supporting to bind against the compat tree in 3.0.0.37? > or am I doing something wrong? > Not sure, but err=49 means wrong password, and err=34 means invalid DN ("Les Stott" is not a DN). > Regards, > > Les > > *From:*Dmitri Pal [mailto:dpal at redhat.com] > *Sent:* Wednesday, 15 January 2014 8:36 AM > *To:* Les Stott > *Cc:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] HP ILO Authentication via LDAP (or even > kerberos) > > On 01/14/2014 04:01 PM, Les Stott wrote: > > I had seen that thread... > https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html > > all it says is... > > On 11/05/2013 02:51 PM, KodaK wrote: > > If I use the whole connection string: > > uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com > > I can authenticate. > > Which i can do successfully, but its not great to have to tell > everyone your username for ilo is uid=blah,cn=users,cn=accounts..etc > > There is also mentioned in that thread... > > "The HP iLO documentation doesn't list using the uid value as a > supported form of specifying the login. You can use the CN value or > the full DN. They say that "DOMAIN\user" and "user domain" forms are > also accepted, but that likely only works against Active Directory." > > CN doesn't work. full DN does. > > I don't see any reference to a workaround via compat plugin in that > thread. > > Have you got any more info on the compat workaround? > > > You can create a compat tree using compat plugin of IPA. It is used > for NIS, support of Solaris clients and for AD trusts in latest IPA. > As a simple test you can enable the plugin: > > ipa-compat-manage enable > > That will expose the tree on the cn=compat hive but using 2307 schema. > You can then change the configuration of the plugin to use uid value instead of CN in this view, i.e expose CN as uid. > Then you can point your HP ILO to that tree. > > AFAIU in the past it was not possible because we did not allow bind against compat tree but now we allow it so it should work with the latest IPA 3.3.x bits. > > Details on how to change compat configuration can be found in the plugin configuration here: > https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc > > I am not sure that would 100% work but IMO worth a shot. > > > > > > Thanks, > > Les > > ------------------------------------------------------------------------ > > *From:*freeipa-users-bounces at redhat.com > > [freeipa-users-bounces at redhat.com > ] on behalf of Dmitri Pal > [dpal at redhat.com ] > *Sent:* Wednesday, January 15, 2014 3:30 AM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] HP ILO Authentication via LDAP (or even > kerberos) > > On 01/13/2014 10:44 PM, Les Stott wrote: > > Been banging my head against the wall on this one for a few days, > trying to get a workable configuration for HP ILO to authenticate via > FreeIPA. > > I have a standard rhel6 environment (64 bit 6.4) with freeipa server > (ipa-3.0.0-37.el6). > > The following works for me...... > > HP ILO4 Firmware 1.22 > > Default Directory Schema > > Directory Server Address: fqdn_of_myfreeipaserver > > Directory Server LDAP Port: 636 > > Directory User Context 1: cn=users,cn=accounts,dc=mydomain,dc=com > > Directory Groups: cn=sys_admins,cn=groups,cn=accounts,dc=mydomain,dc=com > > ....but only if I login with my full dn.... > > Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com > > The test settings button in the ILO works only with the full dn. > > It doesn't work if I use the uid (less), or the cn (Les Stott). > > I can then login to ILO with .... > > Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com > > If I try to login with the cn, Les Stott I see an error in the logs... > > [13/Jan/2014:22:36:29 -0500] ipalockout_postop - [file ipa_lockout.c, > line 473]: Failed to retrieve entry "CN=Les > Stott,cn=users,cn=accounts,dc=mydomain,dc=com": 32 > > I've read a lot of things about getting this to work. Apparently there > are issues with HP ILO requiring the username in cn format but its in > uid format in freeipa. You should also be able to login with your cn, > but that doesn't work. > > I had a crack at trying Kerberos authentication as well, but it > doesn't work and errors with "Additional Pre-authentication required". > > Has anyone successfully been able to get HP ILO to work with FreeIPA > such that you can login with just the username (i.e. "less") or the CN > (i.e. "Les Stott")? > > Are schema changes required? > > Alternatively has anyone been able to get HP ILO to work with Kerberos > auth to FreeIPA? > > Any help would be greatly appreciated. > > Regards, > > Les > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > Have you searched freeipa-users archives? The issue sounds familiar > and I vaguely recalled there was a workaround. > This is the thread > https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html > > I think you can use compat plugin on the IPA to expose the tree in the > way HP ILO expects. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From Less at imagine-sw.com Wed Jan 15 04:12:48 2014 From: Less at imagine-sw.com (Les Stott) Date: Wed, 15 Jan 2014 04:12:48 +0000 Subject: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos) In-Reply-To: <52D5FCAA.4020407@redhat.com> References: <4ED173A868981548967B4FCA2707222605488D@AACMBXP04.exchserver.com>, <52D56642.7040506@redhat.com> <4ED173A868981548967B4FCA27072226054E59@AACMBXP04.exchserver.com> <52D5ADB8.8030504@redhat.com> <4ED173A868981548967B4FCA270722260550F0@AACMBXP04.exchserver.com> <52D5FCAA.4020407@redhat.com> Message-ID: <4ED173A868981548967B4FCA270722260553CD@AACMBXP04.exchserver.com> I can confirm that the password was typed in correctly. Maybe its not matching the account because it's the compat tree? Also, each authentication tries multiple bind combinations, 3 or 4 different combinations show up in the logs for 1 authentication attempt. >From the ILO help.."iLO attempts to contact the directory service by distinguished name, and then applies the search contexts in order until successful." I'm beginning to think this is too hard....would hate to have to fall back to AD instead for central auth for ILO. Regards, Les From: Rich Megginson [mailto:rmeggins at redhat.com] Sent: Wednesday, 15 January 2014 2:13 PM To: Les Stott; freeipa-users at redhat.com Subject: Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos) On 01/14/2014 07:57 PM, Les Stott wrote: Still no joy. Although I don't profess to be a schema changing expert. Compat plugin was already enabled. Ipa version is 3.0.0-37.el6 So I modified /etc/dirsrv/slapd-MYDOMAIN-COM/dse.ldif... Under dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config I set the following... schema-compat-entry-attribute: cn=%{cn} schema-compat-entry-rdn: cn=%{cn} Left the rest as default. When I ldapsearch against the compat tree, I see it working the way I want (i.e. dn starts with cn instead of uid). ldapsearch -x -b "cn=compat,dc=mydomain,dc=com" "cn=Les Stott" # Les Stott, users, compat, mydomain.com dn: cn=Les Stott,cn=users,cn=compat,dc=mydomain,dc=com ILO Search context was set as: cn=users,cn=compat,dc=mydomain,dc=com So it looks good, but when I test from ILO it fails still. Try.. Les Stott ...It cant bind [14/Jan/2014:21:52:31 -0500] conn=47 op=0 BIND dn="CN=Les Stott,cn=users,cn=compat,dc=mydomain,dc=com" method=128 version=2 [14/Jan/2014:21:52:31 -0500] conn=47 op=0 RESULT err=49 tag=97 nentries=0 etime=0 [14/Jan/2014:21:52:31 -0500] conn=47 op=1 UNBIND [14/Jan/2014:21:52:31 -0500] conn=48 op=0 BIND dn="Les Stott" authzid="(null)", invalid bind dn [14/Jan/2014:21:52:31 -0500] conn=48 op=0 RESULT err=34 tag=97 nentries=0 etime=0 [14/Jan/2014:21:52:31 -0500] conn=48 op=1 BIND dn="CN=Les Stott,cn=users,cn=compat,dc=mydomain,dc=com" method=128 version=2 [14/Jan/2014:21:52:31 -0500] conn=48 op=1 RESULT err=49 tag=97 nentries=0 etime=0 [14/Jan/2014:21:52:31 -0500] conn=48 op=2 UNBIND [14/Jan/2014:21:52:31 -0500] conn=50 op=0 BIND dn="CN=Les Stott,cn=users,cn=compat,dc=mydomain,dc=com" method=128 version=2 [14/Jan/2014:21:52:31 -0500] conn=50 op=0 RESULT err=49 tag=97 nentries=0 etime=0 [14/Jan/2014:21:52:31 -0500] conn=50 op=1 UNBIND Is it just not supporting to bind against the compat tree in 3.0.0.37? or am I doing something wrong? Not sure, but err=49 means wrong password, and err=34 means invalid DN ("Les Stott" is not a DN). Regards, Les From: Dmitri Pal [mailto:dpal at redhat.com] Sent: Wednesday, 15 January 2014 8:36 AM To: Les Stott Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos) On 01/14/2014 04:01 PM, Les Stott wrote: I had seen that thread... https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html all it says is... On 11/05/2013 02:51 PM, KodaK wrote: If I use the whole connection string: uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com I can authenticate. Which i can do successfully, but its not great to have to tell everyone your username for ilo is uid=blah,cn=users,cn=accounts..etc There is also mentioned in that thread... "The HP iLO documentation doesn't list using the uid value as a supported form of specifying the login. You can use the CN value or the full DN. They say that "DOMAIN\user" and "user domain" forms are also accepted, but that likely only works against Active Directory." CN doesn't work. full DN does. I don't see any reference to a workaround via compat plugin in that thread. Have you got any more info on the compat workaround? You can create a compat tree using compat plugin of IPA. It is used for NIS, support of Solaris clients and for AD trusts in latest IPA. As a simple test you can enable the plugin: ipa-compat-manage enable That will expose the tree on the cn=compat hive but using 2307 schema. You can then change the configuration of the plugin to use uid value instead of CN in this view, i.e expose CN as uid. Then you can point your HP ILO to that tree. AFAIU in the past it was not possible because we did not allow bind against compat tree but now we allow it so it should work with the latest IPA 3.3.x bits. Details on how to change compat configuration can be found in the plugin configuration here: https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc I am not sure that would 100% work but IMO worth a shot. Thanks, Les ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Wednesday, January 15, 2014 3:30 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos) On 01/13/2014 10:44 PM, Les Stott wrote: Been banging my head against the wall on this one for a few days, trying to get a workable configuration for HP ILO to authenticate via FreeIPA. I have a standard rhel6 environment (64 bit 6.4) with freeipa server (ipa-3.0.0-37.el6). The following works for me...... HP ILO4 Firmware 1.22 Default Directory Schema Directory Server Address: fqdn_of_myfreeipaserver Directory Server LDAP Port: 636 Directory User Context 1: cn=users,cn=accounts,dc=mydomain,dc=com Directory Groups: cn=sys_admins,cn=groups,cn=accounts,dc=mydomain,dc=com ....but only if I login with my full dn.... Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com The test settings button in the ILO works only with the full dn. It doesn't work if I use the uid (less), or the cn (Les Stott). I can then login to ILO with .... Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com If I try to login with the cn, Les Stott I see an error in the logs... [13/Jan/2014:22:36:29 -0500] ipalockout_postop - [file ipa_lockout.c, line 473]: Failed to retrieve entry "CN=Les Stott,cn=users,cn=accounts,dc=mydomain,dc=com": 32 I've read a lot of things about getting this to work. Apparently there are issues with HP ILO requiring the username in cn format but its in uid format in freeipa. You should also be able to login with your cn, but that doesn't work. I had a crack at trying Kerberos authentication as well, but it doesn't work and errors with "Additional Pre-authentication required". Has anyone successfully been able to get HP ILO to work with FreeIPA such that you can login with just the username (i.e. "less") or the CN (i.e. "Les Stott")? Are schema changes required? Alternatively has anyone been able to get HP ILO to work with Kerberos auth to FreeIPA? Any help would be greatly appreciated. Regards, Les _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Have you searched freeipa-users archives? The issue sounds familiar and I vaguely recalled there was a workaround. This is the thread https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html I think you can use compat plugin on the IPA to expose the tree in the way HP ILO expects. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Jan 15 05:49:12 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Jan 2014 07:49:12 +0200 Subject: [Freeipa-users] One way trusts In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E66C358@001FSN2MPN1-044.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E66C085@001FSN2MPN1-044.001f.mgd2.msft.net> <52D48555.4040008@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E66C0D3@001FSN2MPN1-044.001f.mgd2.msft.net> <20140114045025.GG12003@redhat.com> <52D56433.9060703@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E66C358@001FSN2MPN1-044.001f.mgd2.msft.net> Message-ID: <20140115054912.GP12003@redhat.com> On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote: > >> Both AD integration solutions we have (synchronization and >> cross-forest domain trusts) assume having higher level access >> privileges at the time integration is set up. > >My problem here is that I'm too ignorable. :) There's over 15000 users >in our AD; I'm in Montana, the admins are in DC. Worse, our agency's AD >is being absorbed into the next level up the chain (Forest Service AD >is going to become a part of the overall USDA AD). Then I'm an even >smaller fish, relatively speaking. > >> I'm unaware of other >> mechanisms that would give you the same flexibility and level of >> privilege separation between the AD and IPA domains. > >?? The current solution using the LDAP interface to AD (and a >metadirectory to merge "external users") provides privilege separation >and the flexibility to add external users. I don't need more; I just >need it to be less clunky. It weakens security, of course, as my AD >password is stored in various plaintext configuration files for each >application needing binding credentials to search for users in AD. I >also have an index to which files contain my password, as it forms a >"password-change-checklist" which I need to run thru every 60 days. You got me confused on this. You cannot run FreeIPA in such mode because FreeIPA is not a client-only solution, it is server and client solution. If you want to stay with an approach where AD is the data source, IPA server part will not be usable to you and what left is SSSD on the client side. SSSD is capable to work as an AD client. However, if you want all your Linux machines to be enrolled to IPA, they cannot be enrolled to AD at the same time, this will not work. >If I might try to repeat the problem back to you to see if I got it >right...the factor which requires access to the corporate AD is setting >up a Kerberos cross realm trust. This is required so that machines in >IPA can connect directly to AD for authentication. This in turn is >necessary so that identities in the AD Kerberos Realm are correctly and >consistently identified as being sourced from AD. And of course, this >requirement is necessary for services in AD to recognize users and >groups in AD. > >Let me ask what is probably a series of dumb questions: What do I lose >if my FreeIPA server is set up as one of the 10 machines I can join to >the network as a regular user, and all the machines in IPA connect >directly to IPA? Could FreeIPA (current or future) be configured to >relay the credentials to AD either via Kerberos or using AD's LDAP >interface (binding as itself because it's joined to the AD domain)? If >AD accepts the provided credentials can FreeIPA issue the user a ticket >in the FreeIPA realm? Would this look to AD like a bunch of users are >logging into the FreeIPA server machine? FreeIPA as a server provides own Kerberos realm. AD as a server provides its own Kerberos realm. In addition, FreeIPA cannot be made a part of AD forest due to implementation limitations which are not solved yet. We choose to go with cross-realm trust in which FreeIPA and AD belong to different forests and trust each other through cross-forest domain trust in AD speak. One of implementation details of Kerberos in Active Directory is the fact that it assumes Kerberos realm is governing DNS namespace. At one DNS namespace level there could be only one Kerberos realm. If you have example.com DNS namespace under AD control, no machine in .example.com can belong to another Kerberos realm -- AD will not issue tickets for services in that realm even though it would trust it. .ipa.example.com can be used along with .example.com but there is no way to have foo.example.com in AD and bar.example.com in IPA and communicate over Kerberos. What you are talking about is living in AD namespace (both Kerberos and DNS) and yet somehow have FreeIPA working with AD users. This is not possible. If you want to use Linux clients in AD environments you can use SSSD on Linux directly connected to AD, without FreeIPA. This way, of course, you will not get any of FreeIPA benefits like access controls through HBAC rules and sudo rules. Dmitri had a talk last week outlining AD integration options we have: http://www.freeipa.org/images/1/1e/Devconf2013-linux-ad-integration-options.pdf http://www.youtube.com/watch?v=cS6EJ1L7fRI >I know this arrangement would sacrifice access to any of the AD >services by AD-users-on-the-IPA network. That's fine. If it's >technically feasible, tho, it gives me one server that can authenticate >both "corporate users" and "external users", and a central >administration point for the external network. It also plainly >differentiates between corporate users logged in on the corporate >network, and corporate users logged in on the "external network". I'd >consider that a good thing. Finally, if this is possible, it seems to >me that this stands a chance of reducing the number of places my >password is stored in plaintext. I wish it could be so simple... -- / Alexander Bokovoy From simo at redhat.com Wed Jan 15 05:49:41 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 15 Jan 2014 00:49:41 -0500 Subject: [Freeipa-users] sudo log errors In-Reply-To: <52D566FC.2070108@redhat.com> References: <52D566FC.2070108@redhat.com> Message-ID: <1389764981.26102.469.camel@willson.li.ssimo.org> On Tue, 2014-01-14 at 11:34 -0500, Dmitri Pal wrote: > On 01/14/2014 06:17 AM, Natxo Asenjo wrote: > > hi, > > > > after using sudo from ipa extensively I needed to configure a local > > user to also use sudo. > > > > This is for monitoring, we use nagios. > > > > It works but now I have lots of error messages in /var/log/messages > > like this one: > > > > sudo: GSSAPI Error: Unspecified GSS failure. Minor code may provide > > more information (Credentials cache file '/tmp/krb5cc_0' not found) > > > > Well, yes, obviously the nagios local user does not have a kerberos > > ticket. Why the error? > > > > I modified /etc/sudoers to allow the nagios user to not use a tty: > > > > Defaults:nagios !requiretty > > > > And have added nagios config files for sudo in /etc/sudoers.d/ > > > > nagios ALL=NOPASSWD: /usr/lib/nagios/plugins/check_logfiles > > > > In /etc/nsswitch.conf, sudo looks like this: > > > > sudoers: files ldap > > > > Is there anything else I can do or do I just have to live with the > > error on syslog? > I wonder if putting this user into the local sssd provider would silence > it... Just a thought... Probably not, the question is, why is sudo trying to use roots kerberos credentials ? On what platform are you ? With sudo-sssd integration you shouldn't use directly ldap anymore. However if you need, what you can do is to have a cronjob generate the /tmp/krb5cc_0 ccache from the machine keytab. This will silence the error, although it will turn into a full bind and search of data in LDAP. Not sure which you prefer. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Wed Jan 15 05:53:46 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Jan 2014 07:53:46 +0200 Subject: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos) In-Reply-To: <4ED173A868981548967B4FCA270722260553CD@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222605488D@AACMBXP04.exchserver.com> <52D56642.7040506@redhat.com> <4ED173A868981548967B4FCA27072226054E59@AACMBXP04.exchserver.com> <52D5ADB8.8030504@redhat.com> <4ED173A868981548967B4FCA270722260550F0@AACMBXP04.exchserver.com> <52D5FCAA.4020407@redhat.com> <4ED173A868981548967B4FCA270722260553CD@AACMBXP04.exchserver.com> Message-ID: <20140115055346.GQ12003@redhat.com> On Wed, 15 Jan 2014, Les Stott wrote: >I can confirm that the password was typed in correctly. Maybe its not >matching the account because it's the compat tree? No, it is not matching because BIND over compat tree is only supported with slapi-nis 0.48+ which is not RHEL 6.x feature. As Dmitri said, it is feature available with FreeIPA 3.3.x, not 3.0. -- / Alexander Bokovoy From simo at redhat.com Wed Jan 15 05:53:55 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 15 Jan 2014 00:53:55 -0500 Subject: [Freeipa-users] Odd problem with SSSD and SSH keys In-Reply-To: <52D523AB.1030808@damascusgrp.com> References: <52D43AFA.1010207@damascusgrp.com> <52D44025.1020800@redhat.com> <52D4421D.6040109@damascusgrp.com> <52D443E7.3000300@redhat.com> <52D523AB.1030808@damascusgrp.com> Message-ID: <1389765235.26102.471.camel@willson.li.ssimo.org> On Tue, 2014-01-14 at 06:46 -0500, Bret Wortman wrote: > I was assuming that the key was being re-inserted by the ssh > authentication request, but to eliminate puppet, I just tried this sequence: > > # puppet agent --disable > # rm -f /var/lib/sss/pubconf/known_hosts > # ls -l /var/lib/sss/pubconf/known_hosts > # ssh zw131 > : > : (errors about the key being incorrect) > : > # cat /var/lib/sss/pubconf/known_hosts > : > > it now contained the bad key again. Just a shot in the dark. Your log files say ' host "rs512" ', are you having reverse DNS issues ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Wed Jan 15 07:26:33 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 15 Jan 2014 08:26:33 +0100 Subject: [Freeipa-users] One way trusts In-Reply-To: <20140115054912.GP12003@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E66C085@001FSN2MPN1-044.001f.mgd2.msft.net> <52D48555.4040008@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E66C0D3@001FSN2MPN1-044.001f.mgd2.msft.net> <20140114045025.GG12003@redhat.com> <52D56433.9060703@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E66C358@001FSN2MPN1-044.001f.mgd2.msft.net> <20140115054912.GP12003@redhat.com> Message-ID: <52D63829.8000702@redhat.com> On 15.1.2014 06:49, Alexander Bokovoy wrote: > On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote: >> >>> Both AD integration solutions we have (synchronization and >>> cross-forest domain trusts) assume having higher level access >>> privileges at the time integration is set up. >> >> My problem here is that I'm too ignorable. :) There's over 15000 users >> in our AD; I'm in Montana, the admins are in DC. Worse, our agency's AD >> is being absorbed into the next level up the chain (Forest Service AD >> is going to become a part of the overall USDA AD). Then I'm an even >> smaller fish, relatively speaking. >> >>> I'm unaware of other >>> mechanisms that would give you the same flexibility and level of >>> privilege separation between the AD and IPA domains. >> >> ?? The current solution using the LDAP interface to AD (and a >> metadirectory to merge "external users") provides privilege separation >> and the flexibility to add external users. I don't need more; I just >> need it to be less clunky. It weakens security, of course, as my AD >> password is stored in various plaintext configuration files for each >> application needing binding credentials to search for users in AD. I >> also have an index to which files contain my password, as it forms a >> "password-change-checklist" which I need to run thru every 60 days. > You got me confused on this. You cannot run FreeIPA in such mode because > FreeIPA is not a client-only solution, it is server and client solution. > If you want to stay with an approach where AD is the data source, IPA > server part will not be usable to you and what left is SSSD on the > client side. > > SSSD is capable to work as an AD client. > > However, if you want all your Linux machines to be enrolled to IPA, they > cannot be enrolled to AD at the same time, this will not work. Alexander and Jakub, would it be possible to enroll a machine as IPA client and then manually add AD domain do SSSD configuration? I guess that this configuration theoretically allows to use one set of users ("external" users) from IPA and also use another set of users ("internal" users) from AD at the same time. The obvious disadvantage is that you have to carefully type username at DOMAIN. This naturally does 'separation' of external and internal users because AD would know nothing about IPA users and the other way around. Could it work? I'm just theorizing ... :-) Petr^2 Spacek >> If I might try to repeat the problem back to you to see if I got it >> right...the factor which requires access to the corporate AD is setting >> up a Kerberos cross realm trust. This is required so that machines in >> IPA can connect directly to AD for authentication. This in turn is >> necessary so that identities in the AD Kerberos Realm are correctly and >> consistently identified as being sourced from AD. And of course, this >> requirement is necessary for services in AD to recognize users and >> groups in AD. >> >> Let me ask what is probably a series of dumb questions: What do I lose >> if my FreeIPA server is set up as one of the 10 machines I can join to >> the network as a regular user, and all the machines in IPA connect >> directly to IPA? Could FreeIPA (current or future) be configured to >> relay the credentials to AD either via Kerberos or using AD's LDAP >> interface (binding as itself because it's joined to the AD domain)? If >> AD accepts the provided credentials can FreeIPA issue the user a ticket >> in the FreeIPA realm? Would this look to AD like a bunch of users are >> logging into the FreeIPA server machine? > FreeIPA as a server provides own Kerberos realm. AD as a server provides > its own Kerberos realm. In addition, FreeIPA cannot be made a part of > AD forest due to implementation limitations which are not solved yet. We > choose to go with cross-realm trust in which FreeIPA and AD belong to > different forests and trust each other through cross-forest domain trust > in AD speak. > > One of implementation details of Kerberos in Active Directory is the > fact that it assumes Kerberos realm is governing DNS namespace. At one > DNS namespace level there could be only one Kerberos realm. If you have > example.com DNS namespace under AD control, no machine in .example.com > can belong to another Kerberos realm -- AD will not issue tickets for > services in that realm even though it would trust it. .ipa.example.com > can be used along with .example.com but there is no way to have > foo.example.com in AD and bar.example.com in IPA and communicate over > Kerberos. > > What you are talking about is living in AD namespace (both Kerberos and > DNS) and yet somehow have FreeIPA working with AD users. This is not > possible. > > If you want to use Linux clients in AD environments you can use SSSD on > Linux directly connected to AD, without FreeIPA. This way, of course, > you will not get any of FreeIPA benefits like access controls through > HBAC rules and sudo rules. > > Dmitri had a talk last week outlining AD integration options we have: > http://www.freeipa.org/images/1/1e/Devconf2013-linux-ad-integration-options.pdf > http://www.youtube.com/watch?v=cS6EJ1L7fRI > >> I know this arrangement would sacrifice access to any of the AD >> services by AD-users-on-the-IPA network. That's fine. If it's >> technically feasible, tho, it gives me one server that can authenticate >> both "corporate users" and "external users", and a central >> administration point for the external network. It also plainly >> differentiates between corporate users logged in on the corporate >> network, and corporate users logged in on the "external network". I'd >> consider that a good thing. Finally, if this is possible, it seems to >> me that this stands a chance of reducing the number of places my >> password is stored in plaintext. > I wish it could be so simple... From abokovoy at redhat.com Wed Jan 15 07:52:22 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Jan 2014 09:52:22 +0200 Subject: [Freeipa-users] One way trusts In-Reply-To: <52D63829.8000702@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E66C085@001FSN2MPN1-044.001f.mgd2.msft.net> <52D48555.4040008@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E66C0D3@001FSN2MPN1-044.001f.mgd2.msft.net> <20140114045025.GG12003@redhat.com> <52D56433.9060703@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E66C358@001FSN2MPN1-044.001f.mgd2.msft.net> <20140115054912.GP12003@redhat.com> <52D63829.8000702@redhat.com> Message-ID: <20140115075222.GR12003@redhat.com> On Wed, 15 Jan 2014, Petr Spacek wrote: >On 15.1.2014 06:49, Alexander Bokovoy wrote: >>On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote: >>> >>>>Both AD integration solutions we have (synchronization and >>>>cross-forest domain trusts) assume having higher level access >>>>privileges at the time integration is set up. >>> >>>My problem here is that I'm too ignorable. :) There's over 15000 users >>>in our AD; I'm in Montana, the admins are in DC. Worse, our agency's AD >>>is being absorbed into the next level up the chain (Forest Service AD >>>is going to become a part of the overall USDA AD). Then I'm an even >>>smaller fish, relatively speaking. >>> >>>>I'm unaware of other >>>>mechanisms that would give you the same flexibility and level of >>>>privilege separation between the AD and IPA domains. >>> >>>?? The current solution using the LDAP interface to AD (and a >>>metadirectory to merge "external users") provides privilege separation >>>and the flexibility to add external users. I don't need more; I just >>>need it to be less clunky. It weakens security, of course, as my AD >>>password is stored in various plaintext configuration files for each >>>application needing binding credentials to search for users in AD. I >>>also have an index to which files contain my password, as it forms a >>>"password-change-checklist" which I need to run thru every 60 days. >>You got me confused on this. You cannot run FreeIPA in such mode because >>FreeIPA is not a client-only solution, it is server and client solution. >>If you want to stay with an approach where AD is the data source, IPA >>server part will not be usable to you and what left is SSSD on the >>client side. >> >>SSSD is capable to work as an AD client. >> >>However, if you want all your Linux machines to be enrolled to IPA, they >>cannot be enrolled to AD at the same time, this will not work. > >Alexander and Jakub, would it be possible to enroll a machine as IPA >client and then manually add AD domain do SSSD configuration? > >I guess that this configuration theoretically allows to use one set >of users ("external" users) from IPA and also use another set of >users ("internal" users) from AD at the same time. The obvious >disadvantage is that you have to carefully type username at DOMAIN. > >This naturally does 'separation' of external and internal users >because AD would know nothing about IPA users and the other way >around. > >Could it work? I'm just theorizing ... :-) You can setup SSSD to use multiple sources and you can setup krb5.conf to serve multiple realms. What you cannot do is to mix and match within the same DNS namespace over multiple Kerberos realms without being prepared to things not working now and then. Suppose you have example.com DNS namespace and four machines: dc.example.com, win.example.com, lnx.example.com, and ipa.example.com. They are AD DC, Windows machine, Linux server, and IPA master. dc.example.com would host Active Directory and own example.com DNS namespace, including DNS server which hosts example.com zone. Kerberos realm for AD will be EXAMPLE.COM ipa.example.com would host IPA master: LDAP server, KDC for IPA realm, DNS server for example.com with IPA entries. You'd need to define different Kerberos realm name since you'll need to have different configurations in krb5.conf on your lnx.example.com. Let's say, it is IPA-EXAMPLE.COM. win.example.com is enrolled to AD. It consults dc.example.com for DNS and Kerberos on logon. It will attempt to get Kerberos tickets to any service in .example.com through Active Directory domain controller dc.example.com. lnx.example.com is enrolled to IPA. You can either manually set up configuration to point to ipa.example.com everywhere where needed (through /etc/hosts, /etc/krb5.conf, /etc/sssd/sssd.conf, ...) or point /etc/resolv.conf to ipa.example.com and assume that split-brain DNS will work when communicating with win.example.com. lnx.example.com could be configured to have a second domain in /etc/sssd/sssd.conf that points to dc.example.com. You need to create a computer object for lnx.example.com in AD, you need to fetch service key for host/lnx.example.com at EXAMPLE.COM from AD, and later maintain it refresh over time but it is possible. The very same is needed for IPA side. I think we already had discussion on this list how to setup SSSD with two different domains pointing to different Kerberos realms last week but in that case there were non-overlapping DNS namespaces for both Kerberos realms. Now, when an SSH client (PuTTY) on win.example.com will want to connect to lnx.example.com, AD DC on dc.example.com would issue Kerberos ticket to service host/lnx.example.com at EXAMPLE.COM based on own AD credentials. One will be able to login with this ticket to lnx.example.com but nothing from IPA side will apply here: sudo and HBAC rules don't know anything about these users and authentication source. In such situation what I question is the need for IPA deployment at all. If all users will be coming from AD and they are not visible to IPA and not using IPA features, why to spend time with FreeIPA at all? -- / Alexander Bokovoy From pspacek at redhat.com Wed Jan 15 08:26:37 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 15 Jan 2014 09:26:37 +0100 Subject: [Freeipa-users] One way trusts In-Reply-To: <20140115075222.GR12003@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E66C085@001FSN2MPN1-044.001f.mgd2.msft.net> <52D48555.4040008@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E66C0D3@001FSN2MPN1-044.001f.mgd2.msft.net> <20140114045025.GG12003@redhat.com> <52D56433.9060703@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E66C358@001FSN2MPN1-044.001f.mgd2.msft.net> <20140115054912.GP12003@redhat.com> <52D63829.8000702@redhat.com> <20140115075222.GR12003@redhat.com> Message-ID: <52D6463D.2000006@redhat.com> On 15.1.2014 08:52, Alexander Bokovoy wrote: > On Wed, 15 Jan 2014, Petr Spacek wrote: >> On 15.1.2014 06:49, Alexander Bokovoy wrote: >>> On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote: >>>> >>>>> Both AD integration solutions we have (synchronization and >>>>> cross-forest domain trusts) assume having higher level access >>>>> privileges at the time integration is set up. >>>> >>>> My problem here is that I'm too ignorable. :) There's over 15000 users >>>> in our AD; I'm in Montana, the admins are in DC. Worse, our agency's AD >>>> is being absorbed into the next level up the chain (Forest Service AD >>>> is going to become a part of the overall USDA AD). Then I'm an even >>>> smaller fish, relatively speaking. >>>> >>>>> I'm unaware of other >>>>> mechanisms that would give you the same flexibility and level of >>>>> privilege separation between the AD and IPA domains. >>>> >>>> ?? The current solution using the LDAP interface to AD (and a >>>> metadirectory to merge "external users") provides privilege separation >>>> and the flexibility to add external users. I don't need more; I just >>>> need it to be less clunky. It weakens security, of course, as my AD >>>> password is stored in various plaintext configuration files for each >>>> application needing binding credentials to search for users in AD. I >>>> also have an index to which files contain my password, as it forms a >>>> "password-change-checklist" which I need to run thru every 60 days. >>> You got me confused on this. You cannot run FreeIPA in such mode because >>> FreeIPA is not a client-only solution, it is server and client solution. >>> If you want to stay with an approach where AD is the data source, IPA >>> server part will not be usable to you and what left is SSSD on the >>> client side. >>> >>> SSSD is capable to work as an AD client. >>> >>> However, if you want all your Linux machines to be enrolled to IPA, they >>> cannot be enrolled to AD at the same time, this will not work. >> >> Alexander and Jakub, would it be possible to enroll a machine as IPA client >> and then manually add AD domain do SSSD configuration? >> >> I guess that this configuration theoretically allows to use one set of users >> ("external" users) from IPA and also use another set of users ("internal" >> users) from AD at the same time. The obvious disadvantage is that you have >> to carefully type username at DOMAIN. >> >> This naturally does 'separation' of external and internal users because AD >> would know nothing about IPA users and the other way around. >> >> Could it work? I'm just theorizing ... :-) > You can setup SSSD to use multiple sources and you can setup krb5.conf > to serve multiple realms. What you cannot do is to mix and match within > the same DNS namespace over multiple Kerberos realms without being > prepared to things not working now and then. > > Suppose you have example.com DNS namespace and four machines: > dc.example.com, win.example.com, lnx.example.com, and ipa.example.com. > They are AD DC, Windows machine, Linux server, and IPA master. > > dc.example.com would host Active Directory and own example.com DNS > namespace, including DNS server which hosts example.com zone. Kerberos > realm for AD will be EXAMPLE.COM > > ipa.example.com would host IPA master: LDAP server, KDC for IPA realm, > DNS server for example.com with IPA entries. You'd need to define > different Kerberos realm name since you'll need to have different > configurations in krb5.conf on your lnx.example.com. Let's say, it is > IPA-EXAMPLE.COM. > > win.example.com is enrolled to AD. It consults dc.example.com for DNS > and Kerberos on logon. It will attempt to get Kerberos tickets to any > service in .example.com through Active Directory domain controller > dc.example.com. > > lnx.example.com is enrolled to IPA. You can either manually set up > configuration to point to ipa.example.com everywhere where needed > (through /etc/hosts, /etc/krb5.conf, /etc/sssd/sssd.conf, ...) or point > /etc/resolv.conf to ipa.example.com and assume that split-brain DNS will > work when communicating with win.example.com. > > lnx.example.com could be configured to have a second domain in > /etc/sssd/sssd.conf that points to dc.example.com. You need to create a > computer object for lnx.example.com in AD, you need to fetch service > key for host/lnx.example.com at EXAMPLE.COM from AD, and later > maintain it refresh over time but it is possible. > > The very same is needed for IPA side. I think we already had discussion > on this list how to setup SSSD with two different domains pointing to > different Kerberos realms last week but in that case there were > non-overlapping DNS namespaces for both Kerberos realms. > > Now, when an SSH client (PuTTY) on win.example.com will want to connect > to lnx.example.com, AD DC on dc.example.com would issue Kerberos ticket > to service host/lnx.example.com at EXAMPLE.COM based on own AD credentials. > One will be able to login with this ticket to lnx.example.com but > nothing from IPA side will apply here: sudo and HBAC rules don't know > anything about these users and authentication source. > > In such situation what I question is the need for IPA deployment at all. > If all users will be coming from AD and they are not visible to IPA and > not using IPA features, why to spend time with FreeIPA at all? I think that the requirement is to have two distinct sets of users while you don't have control over one set (AD users) but you have to manage the other set (IPA users) somehow. -- Petr^2 Spacek From jcholast at redhat.com Wed Jan 15 08:33:39 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 15 Jan 2014 09:33:39 +0100 Subject: [Freeipa-users] Odd problem with SSSD and SSH keys In-Reply-To: <52D520A9.2080003@damascusgrp.com> References: <52D43AFA.1010207@damascusgrp.com> <52D44025.1020800@redhat.com> <52D4421D.6040109@damascusgrp.com> <20140113211844.GA31257@hendrix.redhat.com> <52D514D8.2000908@redhat.com> <52D520A9.2080003@damascusgrp.com> Message-ID: <52D647E3.4010706@redhat.com> On 14.1.2014 12:34, Bret Wortman wrote: > The key in /etc/ssh/ssh_host_rsa_key.pub matches what's in IPA for the > host in question. It should not have had any connectivity issues; it's > co-located with several of our IPA masters. Can you also check if the MD5 fingerprint reported by ssh (e.g. 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab in your original post) matches the MD5 fingerprint for the host in IPA? > > I'd be happy to run sss_ssh_knownhostsproxy manually but haven't been > able to locate the proxy command to use via Google yet. Any guidance? I don't think you need to do that, it will just update /var/lib/sss/pubconf/known_hosts again. > > > On 01/14/2014 05:43 AM, Jan Cholasta wrote: >> On 13.1.2014 22:18, Jakub Hrozek wrote: >>> On Mon, Jan 13, 2014 at 02:44:29PM -0500, Bret Wortman wrote: >>>> They're definitely different. I deleted the one in the file, then >>>> tried again. It put the bad key back in the file. I blew the whole >>>> file away and the same thing happened. Where is this key coming from >>>> if not from IPA? >>> >>> Can you try running sss_ssh_knownhostsproxy manually to see what key >>> does it return? >>> >>> The keys are propagated to the file from the sssd database. If the >>> client >>> was offline, the client could use stale records. Can you verify the >>> client >>> has no connectivity issues? >>> >>> Honza (CC-ed) might have some more hints. >>> >> >> Compare the public key in /etc/ssh/ssh_host_rsa_key.pub on the host >> with the public key for that host in IPA. If they do not match, the >> host key was changed after IPA client was installed and the host >> record in IPA must be manually updated with the new key. >> >> Honza >> -- Jan Cholasta From abokovoy at redhat.com Wed Jan 15 08:44:16 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Jan 2014 10:44:16 +0200 Subject: [Freeipa-users] One way trusts In-Reply-To: <52D6463D.2000006@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E66C085@001FSN2MPN1-044.001f.mgd2.msft.net> <52D48555.4040008@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E66C0D3@001FSN2MPN1-044.001f.mgd2.msft.net> <20140114045025.GG12003@redhat.com> <52D56433.9060703@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E66C358@001FSN2MPN1-044.001f.mgd2.msft.net> <20140115054912.GP12003@redhat.com> <52D63829.8000702@redhat.com> <20140115075222.GR12003@redhat.com> <52D6463D.2000006@redhat.com> Message-ID: <20140115084416.GS12003@redhat.com> On Wed, 15 Jan 2014, Petr Spacek wrote: >>The very same is needed for IPA side. I think we already had discussion >>on this list how to setup SSSD with two different domains pointing to >>different Kerberos realms last week but in that case there were >>non-overlapping DNS namespaces for both Kerberos realms. >> >>Now, when an SSH client (PuTTY) on win.example.com will want to connect >>to lnx.example.com, AD DC on dc.example.com would issue Kerberos ticket >>to service host/lnx.example.com at EXAMPLE.COM based on own AD credentials. >>One will be able to login with this ticket to lnx.example.com but >>nothing from IPA side will apply here: sudo and HBAC rules don't know >>anything about these users and authentication source. >> >>In such situation what I question is the need for IPA deployment at all. >>If all users will be coming from AD and they are not visible to IPA and >>not using IPA features, why to spend time with FreeIPA at all? > >I think that the requirement is to have two distinct sets of users >while you don't have control over one set (AD users) but you have to >manage the other set (IPA users) somehow. I'm yet to see what is the benefit over having only IPA users. Given single sign-on wasn't a concern, it makes no difference then to specify IPA's user name during logon from AD machines, so no integration would really be needed. An attempt to keep users in AD but use IPA features is really asking for collaboration between the two infrastructure setups. -- / Alexander Bokovoy From natxo.asenjo at gmail.com Wed Jan 15 09:09:20 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 15 Jan 2014 10:09:20 +0100 Subject: [Freeipa-users] sudo log errors In-Reply-To: <1389764981.26102.469.camel@willson.li.ssimo.org> References: <52D566FC.2070108@redhat.com> <1389764981.26102.469.camel@willson.li.ssimo.org> Message-ID: On Wed, Jan 15, 2014 at 6:49 AM, Simo Sorce wrote: > On Tue, 2014-01-14 at 11:34 -0500, Dmitri Pal wrote: >> On 01/14/2014 06:17 AM, Natxo Asenjo wrote: >> > Is there anything else I can do or do I just have to live with the >> > error on syslog? > >> I wonder if putting this user into the local sssd provider would silence >> it... Just a thought... > > Probably not, the question is, why is sudo trying to use roots kerberos > credentials ? no idea. According to /etc/nsswitch.conf, it should read local sudoers first: $ grep sudo /etc/nsswitch.conf sudoers: files ldap The nagios user is a local user that gets installed when installing nrpe (the nagios agent). This is what gets polled remote by the nagios server. > On what platform are you ? With sudo-sssd integration you shouldn't use > directly ldap anymore. centos 6.5 on these hosts. So if I use sssd insted of ldap for sudo this could go away? > However if you need, what you can do is to have a cronjob generate the > /tmp/krb5cc_0 ccache from the machine keytab. This will silence the > error, although it will turn into a full bind and search of data in > LDAP. Not sure which you prefer. yes, I had thought of that. Is that a potential risk in your opinion? I mean, in order to use it, they need root rights and if they have, well, it could be generated as well. What do you think? Besides, it should not have to bind because files comes first. Thanks for taking the time to look into this. Regards, -- natxo From jhrozek at redhat.com Wed Jan 15 09:59:14 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 15 Jan 2014 10:59:14 +0100 Subject: [Freeipa-users] sudo log errors In-Reply-To: References: <52D566FC.2070108@redhat.com> <1389764981.26102.469.camel@willson.li.ssimo.org> Message-ID: <20140115095914.GC22627@hendrix.brq.redhat.com> On Wed, Jan 15, 2014 at 10:09:20AM +0100, Natxo Asenjo wrote: > > On what platform are you ? With sudo-sssd integration you shouldn't use > > directly ldap anymore. > > centos 6.5 on these hosts. So if I use sssd insted of ldap for sudo > this could go away? I believe so, with the sssd integration, the sudo fetches all data from the SSSD. One catch though, there is no "sudo_provider=ipa" in 6.5, but man sssd-sudo should contain an example of setting up "sudo_provider=ldap" on an IPA client. From natxo.asenjo at gmail.com Wed Jan 15 10:45:58 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 15 Jan 2014 11:45:58 +0100 Subject: [Freeipa-users] sudo log errors In-Reply-To: <20140115095914.GC22627@hendrix.brq.redhat.com> References: <52D566FC.2070108@redhat.com> <1389764981.26102.469.camel@willson.li.ssimo.org> <20140115095914.GC22627@hendrix.brq.redhat.com> Message-ID: On Wed, Jan 15, 2014 at 10:59 AM, Jakub Hrozek wrote: > On Wed, Jan 15, 2014 at 10:09:20AM +0100, Natxo Asenjo wrote: >> > On what platform are you ? With sudo-sssd integration you shouldn't use >> > directly ldap anymore. >> >> centos 6.5 on these hosts. So if I use sssd insted of ldap for sudo >> this could go away? > > I believe so, with the sssd integration, the sudo fetches all data from > the SSSD. One catch though, there is no "sudo_provider=ipa" in 6.5, but > man sssd-sudo should contain an example of setting up > "sudo_provider=ldap" on an IPA client. ok. If I configure sssd.conf like that, do I need to configure anything in /etc/sudo-ldap.conf or are those mutually exclusive? I have now this in /etc/sudo-ldap.conf: TLS_CACERT /etc/ipa/ca.crt TLS_REQCERT demand SASL_MECH GSSAPI BASE dc=sub,dc=domain,dc=tld URI ldaps://kdc01.sub.domain.tld ldaps://kdc02.sub.domain.tld ROOTUSE_SASL on SUDOERS_BASE ou=sudoers,dc=sub,dc=domain,dc=tld SUDOERS_DEBUG 0 and this in sssd.conf [sssd] domains = sub.domain.tld services = nss, pam, ssh config_file_version = 2 [nss] [pam] [domain/sub.domain.tld] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = sub.domain.tld id_provider = ipa auth_provider = ipa access_provider = ipa chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, kdc01.sub.domain.tld ldap_tls_cacert = /etc/ipa/ca.crt entry_cache_netgroup_timeout = 300 [sudo] [autofs] [ssh] -- Groeten, natxo > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From bret.wortman at damascusgrp.com Wed Jan 15 12:56:49 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 15 Jan 2014 07:56:49 -0500 Subject: [Freeipa-users] Odd problem with SSSD and SSH keys In-Reply-To: <52D647E3.4010706@redhat.com> References: <52D43AFA.1010207@damascusgrp.com> <52D44025.1020800@redhat.com> <52D4421D.6040109@damascusgrp.com> <20140113211844.GA31257@hendrix.redhat.com> <52D514D8.2000908@redhat.com> <52D520A9.2080003@damascusgrp.com> <52D647E3.4010706@redhat.com> Message-ID: <52D68591.5090404@damascusgrp.com> The fingerprint does match. On 01/15/2014 03:33 AM, Jan Cholasta wrote: > > > On 14.1.2014 12:34, Bret Wortman wrote: >> The key in /etc/ssh/ssh_host_rsa_key.pub matches what's in IPA for the >> host in question. It should not have had any connectivity issues; it's >> co-located with several of our IPA masters. > > Can you also check if the MD5 fingerprint reported by ssh (e.g. > 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab in your original post) > matches the MD5 fingerprint for the host in IPA? > >> >> I'd be happy to run sss_ssh_knownhostsproxy manually but haven't been >> able to locate the proxy command to use via Google yet. Any guidance? > > I don't think you need to do that, it will just update > /var/lib/sss/pubconf/known_hosts again. > >> >> >> On 01/14/2014 05:43 AM, Jan Cholasta wrote: >>> On 13.1.2014 22:18, Jakub Hrozek wrote: >>>> On Mon, Jan 13, 2014 at 02:44:29PM -0500, Bret Wortman wrote: >>>>> They're definitely different. I deleted the one in the file, then >>>>> tried again. It put the bad key back in the file. I blew the whole >>>>> file away and the same thing happened. Where is this key coming from >>>>> if not from IPA? >>>> >>>> Can you try running sss_ssh_knownhostsproxy manually to see what key >>>> does it return? >>>> >>>> The keys are propagated to the file from the sssd database. If the >>>> client >>>> was offline, the client could use stale records. Can you verify the >>>> client >>>> has no connectivity issues? >>>> >>>> Honza (CC-ed) might have some more hints. >>>> >>> >>> Compare the public key in /etc/ssh/ssh_host_rsa_key.pub on the host >>> with the public key for that host in IPA. If they do not match, the >>> host key was changed after IPA client was installed and the host >>> record in IPA must be manually updated with the new key. >>> >>> Honza >>> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From bret.wortman at damascusgrp.com Wed Jan 15 12:57:56 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 15 Jan 2014 07:57:56 -0500 Subject: [Freeipa-users] Odd problem with SSSD and SSH keys In-Reply-To: <1389765235.26102.471.camel@willson.li.ssimo.org> References: <52D43AFA.1010207@damascusgrp.com> <52D44025.1020800@redhat.com> <52D4421D.6040109@damascusgrp.com> <52D443E7.3000300@redhat.com> <52D523AB.1030808@damascusgrp.com> <1389765235.26102.471.camel@willson.li.ssimo.org> Message-ID: <52D685D4.7010402@damascusgrp.com> No, that was me conflating this problem on two different machines, rs512 and zw131. Sorry about that. Bret On 01/15/2014 12:53 AM, Simo Sorce wrote: > On Tue, 2014-01-14 at 06:46 -0500, Bret Wortman wrote: >> I was assuming that the key was being re-inserted by the ssh >> authentication request, but to eliminate puppet, I just tried this sequence: >> >> # puppet agent --disable >> # rm -f /var/lib/sss/pubconf/known_hosts >> # ls -l /var/lib/sss/pubconf/known_hosts >> # ssh zw131 >> : >> : (errors about the key being incorrect) >> : >> # cat /var/lib/sss/pubconf/known_hosts >> : >> >> it now contained the bad key again. > Just a shot in the dark. > Your log files say ' host "rs512" ', are you having reverse DNS issues ? > > Simo. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From mitkany at gmail.com Wed Jan 15 21:52:03 2014 From: mitkany at gmail.com (Dimitar Georgievski) Date: Wed, 15 Jan 2014 16:52:03 -0500 Subject: [Freeipa-users] Sudo policy not working with group of servers In-Reply-To: <52D55AC1.1090707@redhat.com> References: <52D55AC1.1090707@redhat.com> Message-ID: Setting the nis domain resolved the issue with the host groups. Thanks Dimitar On Tue, Jan 14, 2014 at 10:41 AM, Martin Kosek wrote: > On 01/14/2014 04:27 PM, Dimitar Georgievski wrote: > > Hi, > > > > I've been trying to create a simple sudo policy, that would grant certain > > privileges to a group of users on a group of hosts. The policy would not > > work unless I specify the hosts individually in the *Sudo Rule* > definition > > page under *Access this hos*t section. > > > > I am using FreeIPA v3.0 and SSSD v1.9.2 on CentOS 6.5 > > > > Thanks, > > > > Dimitar > > Hello Dimitar, > > I would recommend starting investigation by following this article: > > http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups > > Martin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sakodak at gmail.com Wed Jan 15 22:13:05 2014 From: sakodak at gmail.com (KodaK) Date: Wed, 15 Jan 2014 16:13:05 -0600 Subject: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos) In-Reply-To: <20140115055346.GQ12003@redhat.com> References: <4ED173A868981548967B4FCA2707222605488D@AACMBXP04.exchserver.com> <52D56642.7040506@redhat.com> <4ED173A868981548967B4FCA27072226054E59@AACMBXP04.exchserver.com> <52D5ADB8.8030504@redhat.com> <4ED173A868981548967B4FCA270722260550F0@AACMBXP04.exchserver.com> <52D5FCAA.4020407@redhat.com> <4ED173A868981548967B4FCA270722260553CD@AACMBXP04.exchserver.com> <20140115055346.GQ12003@redhat.com> Message-ID: For the record, I spent quite a long time on this and finally gave up. I never found a work-around other than providing the entire DN, which I wasn't about to do. On Tue, Jan 14, 2014 at 11:53 PM, Alexander Bokovoy wrote: > On Wed, 15 Jan 2014, Les Stott wrote: > >> I can confirm that the password was typed in correctly. Maybe its not >> matching the account because it's the compat tree? >> > No, it is not matching because BIND over compat tree is only supported > with slapi-nis 0.48+ which is not RHEL 6.x feature. As Dmitri said, it > is feature available with FreeIPA 3.3.x, not 3.0. > > -- > / Alexander Bokovoy > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Thu Jan 16 00:35:32 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Thu, 16 Jan 2014 00:35:32 +0000 Subject: [Freeipa-users] One way trusts In-Reply-To: <20140115084416.GS12003@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E66C085@001FSN2MPN1-044.001f.mgd2.msft.net> <52D48555.4040008@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E66C0D3@001FSN2MPN1-044.001f.mgd2.msft.net> <20140114045025.GG12003@redhat.com> <52D56433.9060703@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E66C358@001FSN2MPN1-044.001f.mgd2.msft.net> <20140115054912.GP12003@redhat.com> <52D63829.8000702@redhat.com> <20140115075222.GR12003@redhat.com> <52D6463D.2000006@redhat.com> <20140115084416.GS12003@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E66C6B9@001FSN2MPN1-044.001f.mgd2.msft.net> >>I think that the requirement is to have two distinct sets of users >>while you don't have control over one set (AD users) but you have to >>manage the other set (IPA users) somehow. Yup. >I'm yet to see what is the benefit over having only IPA users. Given single sign-on wasn't a concern, it makes no difference then to specify IPA's user name during logon from AD machines, so no integration would really be needed. Difference #1 (user experience): Users in AD do not have a new password to remember and/or manage. Difference #2 (administration overhead): I don't have to create users which are already in AD. Difference #3 (political): I'm not duplicating effort of our IT division, I'm serving an un-served community, so there's less "turf" violation. >An attempt to keep users in AD but use IPA features is really asking for collaboration between the two infrastructure setups. Well, part of the confusion may lie in the fact that much of the functionality in IPA and AD is unfamiliar to me, particularly at the beginning. First and foremost, I'm viewing both AD and IPA as identity stores which can provide Authentication services and store some information about the users which can be used by clients for various purposes: access decisions being a big one. I've been using the LDAP interface to AD because it's easier to understand, and because I can "graft in" my external users via an LDAP metadirectory. This can be done without any infrastructure collaboration, and it provides support for applications which do not allow you to configure more than one domain. Then I started looking at trying to authenticate using Kerberos. Didn't know much about Kerberos when I started. It's supposed to have all sorts of good features. But it also seems to be the layer that introduces the need to collaborate, where before there was none. Early testing seems to indicate that I can in fact "kinit" against AD using a machine not joined to the domain. This gets me a no-address, forwardable TGT, and should suffice to tell the machine that the AD server believes I'm me. I suspect I will run into problems if I then try to use my TGT to get a login ticket for this "host-unknown-to-AD". I'm in the middle of trying to configure sssd on my test VM to use krb5/ldap authentication. It appears I cannot have sssd bind against AD's LDAP interface using Kerberos, or I just haven't figured out how, so the next step is to type my DN and password into another plain text file. Once this works, I'll configure IPA as a second domain on this host. If machines on my research network (which does not share DNS namespace with AD) are joined to any domain, it would be to the FreeIPA domain. I do not quite understand the implications of this with regard to user principles from AD. It seems like it should be possible for me to make groups in FreeIPA which name members from other directories. It also seems like sssd should be capable of making access decisions based on a user principle from one domain and a group from another. But if I understand Kerberos correctly, it will be impossible for the FreeIPA TGS to issue a cross-realm ticket without the required cross realm trust and the associated "remote" principle entries in both directories. I think my ability to make use of FreeIPA's extra (beyond authentication) functionality may depend on exactly where the access control decision is made, and how the information to support that decision is gathered. I'm hoping that sssd can be convinced to make these decisions based on information returned from an LDAP query on the freeIPA server and the TGT from the AD server. Contrary-wise, I'm hoping that I don't need a cross-realm Kerberos ticket from either domain. Thanks for your patience. Sorry its taking so long to come up to speed. 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 pspacek at redhat.com Thu Jan 16 07:37:56 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 16 Jan 2014 08:37:56 +0100 Subject: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos) In-Reply-To: References: <4ED173A868981548967B4FCA2707222605488D@AACMBXP04.exchserver.com> <52D56642.7040506@redhat.com> <4ED173A868981548967B4FCA27072226054E59@AACMBXP04.exchserver.com> <52D5ADB8.8030504@redhat.com> <4ED173A868981548967B4FCA270722260550F0@AACMBXP04.exchserver.com> <52D5FCAA.4020407@redhat.com> <4ED173A868981548967B4FCA270722260553CD@AACMBXP04.exchserver.com> <20140115055346.GQ12003@redhat.com> Message-ID: <52D78C54.8020802@redhat.com> On 15.1.2014 23:13, KodaK wrote: > For the record, I spent quite a long time on this and finally gave up. I > never found a work-around other than providing the entire DN, which I > wasn't about to do. Did you try the slapi-nis from FreeIPA 3.3.3? Just for the record, so we will know if it works or not. Petr^2 Spacek > On Tue, Jan 14, 2014 at 11:53 PM, Alexander Bokovoy wrote: > >> On Wed, 15 Jan 2014, Les Stott wrote: >> >>> I can confirm that the password was typed in correctly. Maybe its not >>> matching the account because it's the compat tree? >>> >> No, it is not matching because BIND over compat tree is only supported >> with slapi-nis 0.48+ which is not RHEL 6.x feature. As Dmitri said, it >> is feature available with FreeIPA 3.3.x, not 3.0. >> >> -- >> / Alexander Bokovoy From abokovoy at redhat.com Thu Jan 16 08:11:16 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 16 Jan 2014 10:11:16 +0200 Subject: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos) In-Reply-To: <52D78C54.8020802@redhat.com> References: <4ED173A868981548967B4FCA2707222605488D@AACMBXP04.exchserver.com> <52D56642.7040506@redhat.com> <4ED173A868981548967B4FCA27072226054E59@AACMBXP04.exchserver.com> <52D5ADB8.8030504@redhat.com> <4ED173A868981548967B4FCA270722260550F0@AACMBXP04.exchserver.com> <52D5FCAA.4020407@redhat.com> <4ED173A868981548967B4FCA270722260553CD@AACMBXP04.exchserver.com> <20140115055346.GQ12003@redhat.com> <52D78C54.8020802@redhat.com> Message-ID: <20140116081116.GB13701@redhat.com> On Thu, 16 Jan 2014, Petr Spacek wrote: >On 15.1.2014 23:13, KodaK wrote: >>For the record, I spent quite a long time on this and finally gave up. I >>never found a work-around other than providing the entire DN, which I >>wasn't about to do. > >Did you try the slapi-nis from FreeIPA 3.3.3? Just for the record, so >we will know if it works or not. Note that it might not build or work well on RHEL 6.x. -- / Alexander Bokovoy From jcholast at redhat.com Thu Jan 16 09:42:13 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 16 Jan 2014 10:42:13 +0100 Subject: [Freeipa-users] Odd problem with SSSD and SSH keys In-Reply-To: <52D68591.5090404@damascusgrp.com> References: <52D43AFA.1010207@damascusgrp.com> <52D44025.1020800@redhat.com> <52D4421D.6040109@damascusgrp.com> <20140113211844.GA31257@hendrix.redhat.com> <52D514D8.2000908@redhat.com> <52D520A9.2080003@damascusgrp.com> <52D647E3.4010706@redhat.com> <52D68591.5090404@damascusgrp.com> Message-ID: <52D7A975.100@redhat.com> OK, there is definitely something going on in the client then. Are there multiple domains configured in sssd.conf? On 15.1.2014 13:56, Bret Wortman wrote: > The fingerprint does match. > > On 01/15/2014 03:33 AM, Jan Cholasta wrote: >> >> >> On 14.1.2014 12:34, Bret Wortman wrote: >>> The key in /etc/ssh/ssh_host_rsa_key.pub matches what's in IPA for the >>> host in question. It should not have had any connectivity issues; it's >>> co-located with several of our IPA masters. >> >> Can you also check if the MD5 fingerprint reported by ssh (e.g. >> 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab in your original post) >> matches the MD5 fingerprint for the host in IPA? -- Jan Cholasta From bret.wortman at damascusgrp.com Thu Jan 16 10:21:12 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Thu, 16 Jan 2014 05:21:12 -0500 Subject: [Freeipa-users] Odd problem with SSSD and SSH keys In-Reply-To: <52D7A975.100@redhat.com> References: <52D43AFA.1010207@damascusgrp.com> <52D44025.1020800@redhat.com> <52D4421D.6040109@damascusgrp.com> <20140113211844.GA31257@hendrix.redhat.com> <52D514D8.2000908@redhat.com> <52D520A9.2080003@damascusgrp.com> <52D647E3.4010706@redhat.com> <52D68591.5090404@damascusgrp.com> <52D7A975.100@redhat.com> Message-ID: <5C480C19-8C5D-46DD-957B-9089F67F1289@damascusgrp.com> Yes, though there should be only one. We ended up somehow with foo.com and .foo.com and I'm not sure how to reduce us properly to just foo.com. Bret Wortman http://bretwortman.com/ http://twitter.com/BretWortman > On Jan 16, 2014, at 4:42 AM, Jan Cholasta wrote: > > OK, there is definitely something going on in the client then. Are there multiple domains configured in sssd.conf? > >> On 15.1.2014 13:56, Bret Wortman wrote: >> The fingerprint does match. >> >>> On 01/15/2014 03:33 AM, Jan Cholasta wrote: >>> >>> >>>> On 14.1.2014 12:34, Bret Wortman wrote: >>>> The key in /etc/ssh/ssh_host_rsa_key.pub matches what's in IPA for the >>>> host in question. It should not have had any connectivity issues; it's >>>> co-located with several of our IPA masters. >>> >>> Can you also check if the MD5 fingerprint reported by ssh (e.g. >>> 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab in your original post) >>> matches the MD5 fingerprint for the host in IPA? > > -- > Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2346 bytes Desc: not available URL: From jcholast at redhat.com Thu Jan 16 16:52:03 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 16 Jan 2014 17:52:03 +0100 Subject: [Freeipa-users] Odd problem with SSSD and SSH keys In-Reply-To: <5C480C19-8C5D-46DD-957B-9089F67F1289@damascusgrp.com> References: <52D43AFA.1010207@damascusgrp.com> <52D44025.1020800@redhat.com> <52D4421D.6040109@damascusgrp.com> <20140113211844.GA31257@hendrix.redhat.com> <52D514D8.2000908@redhat.com> <52D520A9.2080003@damascusgrp.com> <52D647E3.4010706@redhat.com> <52D68591.5090404@damascusgrp.com> <52D7A975.100@redhat.com> <5C480C19-8C5D-46DD-957B-9089F67F1289@damascusgrp.com> Message-ID: <52D80E33.2080908@redhat.com> I think you can just comment out the whole [domain/] section in sssd.conf and restart sssd. Does that solve the problem? If not, could you please post your sssd.conf here? On 16.1.2014 11:21, Bret Wortman wrote: > Yes, though there should be only one. We ended up somehow with foo.com and .foo.com and I'm not sure how to reduce us properly to just foo.com. > > > Bret Wortman > http://bretwortman.com/ > http://twitter.com/BretWortman > >> On Jan 16, 2014, at 4:42 AM, Jan Cholasta wrote: >> >> OK, there is definitely something going on in the client then. Are there multiple domains configured in sssd.conf? >> >>> On 15.1.2014 13:56, Bret Wortman wrote: >>> The fingerprint does match. >>> >>>> On 01/15/2014 03:33 AM, Jan Cholasta wrote: >>>> >>>> >>>>> On 14.1.2014 12:34, Bret Wortman wrote: >>>>> The key in /etc/ssh/ssh_host_rsa_key.pub matches what's in IPA for the >>>>> host in question. It should not have had any connectivity issues; it's >>>>> co-located with several of our IPA masters. >>>> >>>> Can you also check if the MD5 fingerprint reported by ssh (e.g. >>>> 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab in your original post) >>>> matches the MD5 fingerprint for the host in IPA? >> >> -- >> Jan Cholasta -- Jan Cholasta From bret.wortman at damascusgrp.com Thu Jan 16 17:19:39 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Thu, 16 Jan 2014 12:19:39 -0500 Subject: [Freeipa-users] Odd problem with SSSD and SSH keys In-Reply-To: <52D80E33.2080908@redhat.com> References: <52D43AFA.1010207@damascusgrp.com> <52D44025.1020800@redhat.com> <52D4421D.6040109@damascusgrp.com> <20140113211844.GA31257@hendrix.redhat.com> <52D514D8.2000908@redhat.com> <52D520A9.2080003@damascusgrp.com> <52D647E3.4010706@redhat.com> <52D68591.5090404@damascusgrp.com> <52D7A975.100@redhat.com> <5C480C19-8C5D-46DD-957B-9089F67F1289@damascusgrp.com> <52D80E33.2080908@redhat.com> Message-ID: <52D814AB.5050500@damascusgrp.com> It did. I just needed the motivation to figure out which version was correct. So I experimented on my own workstation this morning before anyone else got in and rolled out a corrected version. Thanks for your help, everyone! On 01/16/2014 11:52 AM, Jan Cholasta wrote: > I think you can just comment out the whole [domain/] section in > sssd.conf and restart sssd. Does that solve the problem? If not, could > you please post your sssd.conf here? > > On 16.1.2014 11:21, Bret Wortman wrote: >> Yes, though there should be only one. We ended up somehow with >> foo.com and .foo.com and I'm not sure how to reduce us properly to >> just foo.com. >> >> >> Bret Wortman >> http://bretwortman.com/ >> http://twitter.com/BretWortman >> >>> On Jan 16, 2014, at 4:42 AM, Jan Cholasta wrote: >>> >>> OK, there is definitely something going on in the client then. Are >>> there multiple domains configured in sssd.conf? >>> >>>> On 15.1.2014 13:56, Bret Wortman wrote: >>>> The fingerprint does match. >>>> >>>>> On 01/15/2014 03:33 AM, Jan Cholasta wrote: >>>>> >>>>> >>>>>> On 14.1.2014 12:34, Bret Wortman wrote: >>>>>> The key in /etc/ssh/ssh_host_rsa_key.pub matches what's in IPA >>>>>> for the >>>>>> host in question. It should not have had any connectivity issues; >>>>>> it's >>>>>> co-located with several of our IPA masters. >>>>> >>>>> Can you also check if the MD5 fingerprint reported by ssh (e.g. >>>>> 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab in your original >>>>> post) >>>>> matches the MD5 fingerprint for the host in IPA? >>> >>> -- >>> Jan Cholasta > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From jcholast at redhat.com Thu Jan 16 17:47:44 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 16 Jan 2014 18:47:44 +0100 Subject: [Freeipa-users] Odd problem with SSSD and SSH keys In-Reply-To: <52D814AB.5050500@damascusgrp.com> References: <52D43AFA.1010207@damascusgrp.com> <52D44025.1020800@redhat.com> <52D4421D.6040109@damascusgrp.com> <20140113211844.GA31257@hendrix.redhat.com> <52D514D8.2000908@redhat.com> <52D520A9.2080003@damascusgrp.com> <52D647E3.4010706@redhat.com> <52D68591.5090404@damascusgrp.com> <52D7A975.100@redhat.com> <5C480C19-8C5D-46DD-957B-9089F67F1289@damascusgrp.com> <52D80E33.2080908@redhat.com> <52D814AB.5050500@damascusgrp.com> Message-ID: <52D81B40.2080801@redhat.com> I'm glad that fixed it, but I would still be interested in what went wrong. Could you tell me what was the difference between foo.com and .foo.com domain configuration? I'm also curious how did such configuration got into sssd.conf in the first place, ipa-client-install should have created only one domain. On 16.1.2014 18:19, Bret Wortman wrote: > It did. I just needed the motivation to figure out which version was > correct. So I experimented on my own workstation this morning before > anyone else got in and rolled out a corrected version. > > Thanks for your help, everyone! > > > On 01/16/2014 11:52 AM, Jan Cholasta wrote: >> I think you can just comment out the whole [domain/] section in >> sssd.conf and restart sssd. Does that solve the problem? If not, could >> you please post your sssd.conf here? >> >> On 16.1.2014 11:21, Bret Wortman wrote: >>> Yes, though there should be only one. We ended up somehow with >>> foo.com and .foo.com and I'm not sure how to reduce us properly to >>> just foo.com. >>> >>> >>> Bret Wortman >>> http://bretwortman.com/ >>> http://twitter.com/BretWortman >>> >>>> On Jan 16, 2014, at 4:42 AM, Jan Cholasta wrote: >>>> >>>> OK, there is definitely something going on in the client then. Are >>>> there multiple domains configured in sssd.conf? >>>> >>>>> On 15.1.2014 13:56, Bret Wortman wrote: >>>>> The fingerprint does match. >>>>> >>>>>> On 01/15/2014 03:33 AM, Jan Cholasta wrote: >>>>>> >>>>>> >>>>>>> On 14.1.2014 12:34, Bret Wortman wrote: >>>>>>> The key in /etc/ssh/ssh_host_rsa_key.pub matches what's in IPA >>>>>>> for the >>>>>>> host in question. It should not have had any connectivity issues; >>>>>>> it's >>>>>>> co-located with several of our IPA masters. >>>>>> >>>>>> Can you also check if the MD5 fingerprint reported by ssh (e.g. >>>>>> 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab in your original >>>>>> post) >>>>>> matches the MD5 fingerprint for the host in IPA? >>>> >>>> -- >>>> Jan Cholasta >> >> > > -- Jan Cholasta From bret.wortman at damascusgrp.com Thu Jan 16 17:57:03 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Thu, 16 Jan 2014 12:57:03 -0500 Subject: [Freeipa-users] Odd problem with SSSD and SSH keys In-Reply-To: <52D81B40.2080801@redhat.com> References: <52D43AFA.1010207@damascusgrp.com> <52D44025.1020800@redhat.com> <52D4421D.6040109@damascusgrp.com> <20140113211844.GA31257@hendrix.redhat.com> <52D514D8.2000908@redhat.com> <52D520A9.2080003@damascusgrp.com> <52D647E3.4010706@redhat.com> <52D68591.5090404@damascusgrp.com> <52D7A975.100@redhat.com> <5C480C19-8C5D-46DD-957B-9089F67F1289@damascusgrp.com> <52D80E33.2080908@redhat.com> <52D814AB.5050500@damascusgrp.com> <52D81B40.2080801@redhat.com> Message-ID: <52D81D6F.3030502@damascusgrp.com> Here was the original sssd.conf. IPA created one, and I think in our early confusion over IPA, we created the other accidentally, and as we were trying to get puppet to enforce our system configs (we have a lot of developers who love to tinker with things they don't understand, which at this point includes me, I guess) we ended up postponing figuring out whether we could do away with the ".foo.net" one until today: ------- [domain/foo.com] cach_credentials = True krb5_store_password_if_offline = True ipa_domain = foo.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = zw129.foo.com chpass_provider = ipa ipa_dyndns_update = True ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49 ldap_tls_cacert = /etc/ipa/ca.crt [domain/.foo.com] cache_credentials = True krb5_store_password_if_offline = True krb5_realm = FOO.COM ipa_domain = .foo.com id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt chpass_provider = ipa ipa_dyndns_update = True ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49 ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=com dns_discovery_domain = .foo.com [sssd] services = nss, pam, ssh config_file_version = 2 domains = .foo.com, foo.com [nss] [pam] [sudo] [autofs] [ssh] ----------- Bret On 01/16/2014 12:47 PM, Jan Cholasta wrote: > I'm glad that fixed it, but I would still be interested in what went > wrong. Could you tell me what was the difference between foo.com and > .foo.com domain configuration? I'm also curious how did such > configuration got into sssd.conf in the first place, > ipa-client-install should have created only one domain. > > On 16.1.2014 18:19, Bret Wortman wrote: >> It did. I just needed the motivation to figure out which version was >> correct. So I experimented on my own workstation this morning before >> anyone else got in and rolled out a corrected version. >> >> Thanks for your help, everyone! >> >> >> On 01/16/2014 11:52 AM, Jan Cholasta wrote: >>> I think you can just comment out the whole [domain/] section in >>> sssd.conf and restart sssd. Does that solve the problem? If not, could >>> you please post your sssd.conf here? >>> >>> On 16.1.2014 11:21, Bret Wortman wrote: >>>> Yes, though there should be only one. We ended up somehow with >>>> foo.com and .foo.com and I'm not sure how to reduce us properly to >>>> just foo.com. >>>> >>>> >>>> Bret Wortman >>>> http://bretwortman.com/ >>>> http://twitter.com/BretWortman >>>> >>>>> On Jan 16, 2014, at 4:42 AM, Jan Cholasta >>>>> wrote: >>>>> >>>>> OK, there is definitely something going on in the client then. Are >>>>> there multiple domains configured in sssd.conf? >>>>> >>>>>> On 15.1.2014 13:56, Bret Wortman wrote: >>>>>> The fingerprint does match. >>>>>> >>>>>>> On 01/15/2014 03:33 AM, Jan Cholasta wrote: >>>>>>> >>>>>>> >>>>>>>> On 14.1.2014 12:34, Bret Wortman wrote: >>>>>>>> The key in /etc/ssh/ssh_host_rsa_key.pub matches what's in IPA >>>>>>>> for the >>>>>>>> host in question. It should not have had any connectivity issues; >>>>>>>> it's >>>>>>>> co-located with several of our IPA masters. >>>>>>> >>>>>>> Can you also check if the MD5 fingerprint reported by ssh (e.g. >>>>>>> 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab in your original >>>>>>> post) >>>>>>> matches the MD5 fingerprint for the host in IPA? >>>>> >>>>> -- >>>>> Jan Cholasta >>> >>> >> >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From Less at imagine-sw.com Fri Jan 17 06:24:49 2014 From: Less at imagine-sw.com (Les Stott) Date: Fri, 17 Jan 2014 06:24:49 +0000 Subject: [Freeipa-users] export users/groups from one ipa server to another Message-ID: <4ED173A868981548967B4FCA2707222605696C@AACMBXP04.exchserver.com> Hi All, Looking for the quickest and easiest way to export users from one freeipa server and install on another. I have an existing freeipa server, 3.0.0 standard rhel6 in a DR environment. I am setting up an identical freeipa server in a Production Environment. The two environments will not be configured to talk to each other. They will both have there own replicas. I simply want to export the users and groups I created in freeipa in DR, and import them (preserving details and passwords) into the freeipa server in Production. What is the recommendation? Is there an ipa tool? Or will ldif exports suffice? Thanks in advance, Les -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Jan 17 07:27:24 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 17 Jan 2014 08:27:24 +0100 Subject: [Freeipa-users] export users/groups from one ipa server to another In-Reply-To: <4ED173A868981548967B4FCA2707222605696C@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222605696C@AACMBXP04.exchserver.com> Message-ID: <52D8DB5C.3090005@redhat.com> On 17.1.2014 07:24, Les Stott wrote: > Hi All, > > Looking for the quickest and easiest way to export users from one freeipa server and install on another. > > I have an existing freeipa server, 3.0.0 standard rhel6 in a DR environment. > I am setting up an identical freeipa server in a Production Environment. > > The two environments will not be configured to talk to each other. They will both have there own replicas. > > I simply want to export the users and groups I created in freeipa in DR, and import them (preserving details and passwords) into the freeipa server in Production. > > What is the recommendation? Is there an ipa tool? Or will ldif exports suffice? IMHO you can create a replica (including CA and DNS if you have CA and DNS on the original master) and then disconnect this new replica from the original master and move it to production. -- Petr^2 Spacek From mkosek at redhat.com Fri Jan 17 07:46:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 17 Jan 2014 08:46:19 +0100 Subject: [Freeipa-users] export users/groups from one ipa server to another In-Reply-To: <4ED173A868981548967B4FCA2707222605696C@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222605696C@AACMBXP04.exchserver.com> Message-ID: <52D8DFCB.6050700@redhat.com> On 01/17/2014 07:24 AM, Les Stott wrote: > Hi All, > > Looking for the quickest and easiest way to export users from one freeipa server and install on another. > > I have an existing freeipa server, 3.0.0 standard rhel6 in a DR environment. > I am setting up an identical freeipa server in a Production Environment. > > The two environments will not be configured to talk to each other. They will both have there own replicas. > > I simply want to export the users and groups I created in freeipa in DR, and import them (preserving details and passwords) into the freeipa server in Production. > > What is the recommendation? Is there an ipa tool? Or will ldif exports suffice? > > Thanks in advance, > > Les I think the best way would be to use the "ipa migrate-ds" command. It should work both with stand alone Directory Servers and IPA too. You may just need to play with --userignoreobjectclass amd userignoreattribute to not migrate Kerberos related attributes and objectclasses if for example your other DS has a different realm. Martin From Less at imagine-sw.com Fri Jan 17 08:54:07 2014 From: Less at imagine-sw.com (Les Stott) Date: Fri, 17 Jan 2014 08:54:07 +0000 Subject: [Freeipa-users] export users/groups from one ipa server to another In-Reply-To: <52D8DFCB.6050700@redhat.com> References: <4ED173A868981548967B4FCA2707222605696C@AACMBXP04.exchserver.com>, <52D8DFCB.6050700@redhat.com> Message-ID: <4ED173A868981548967B4FCA27072226056A66@AACMBXP04.exchserver.com> Petr, Martin, thanks for the suggestions, i will try next week. fyi... it will be the same domain so i'll have a look at "ipa migrate-ds". Regards, Les ________________________________________ From: Martin Kosek [mkosek at redhat.com] Sent: Friday, January 17, 2014 6:46 PM To: Les Stott; freeipa-users at redhat.com Subject: Re: [Freeipa-users] export users/groups from one ipa server to another On 01/17/2014 07:24 AM, Les Stott wrote: > Hi All, > > Looking for the quickest and easiest way to export users from one freeipa server and install on another. > > I have an existing freeipa server, 3.0.0 standard rhel6 in a DR environment. > I am setting up an identical freeipa server in a Production Environment. > > The two environments will not be configured to talk to each other. They will both have there own replicas. > > I simply want to export the users and groups I created in freeipa in DR, and import them (preserving details and passwords) into the freeipa server in Production. > > What is the recommendation? Is there an ipa tool? Or will ldif exports suffice? > > Thanks in advance, > > Les I think the best way would be to use the "ipa migrate-ds" command. It should work both with stand alone Directory Servers and IPA too. You may just need to play with --userignoreobjectclass amd userignoreattribute to not migrate Kerberos related attributes and objectclasses if for example your other DS has a different realm. Martin From t.sailer at alumni.ethz.ch Fri Jan 17 11:44:24 2014 From: t.sailer at alumni.ethz.ch (Thomas Sailer) Date: Fri, 17 Jan 2014 12:44:24 +0100 Subject: [Freeipa-users] replica installation issue Message-ID: <52D91798.4080206@alumni.ethz.ch> After being unable to rescue my old freeipa installation, I installed a new machine from scratch and imported the user data from the old installation (so I could get rid of the separate PKI dirserv, too). That worked fine. Then I prepared a replica, and installed the replica on the old machine (after first running ipa-server-install --uninstall). The installation completed without error message. The replica however has a few issues: - GSSAPI authentication to the directory service doesn't work: # ldapsearch -D "cn=Directory Manager" -W \* returns a few hundred records, however # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin at XXXX.COM Valid starting Expires Service principal 01/16/2014 14:14:51 01/17/2014 14:14:47 krbtgt/XXXX.COM at XXXX.COM 01/16/2014 14:14:54 01/17/2014 14:14:47 HTTP/replica.xxxx.com at XXXX.COM 01/16/2014 14:15:22 01/17/2014 14:14:47 ldap/replica.xxxx.com at XXXX.COM # ldapsearch -Y GSSAPI \* SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server krbtgt/LOCALDOMAIN at XXXX.COM not found in Kerberos database) The localdomain apparently comes from /etc/hosts: 127.0.0.1 localhost.localdomain localhost localhost4 ::1 localhost6.localdomain6 localhost6 192.168.1.2 replica.xxxx.com replica 192.168.1.3 master.xxxx.com master I tried to comment out the first two entries, which made it want to use ldap/localhost at XXXX.COM, which failed too. krb5.keytab looks the same on both the master and the replica, with the exception that the replica lacks the host key for the camellia*-cts-cmac cypher. - When I use the web server of the replica and click on Identity->Certificates, I get: IPA Error 4301: Certificate operation cannot be completed: Unable to communicate with CMS ([Errno 113] No route to host) This same operation on the master works. Is this supposed to be like this? - Is there a more up to date description of how to make a replica a master? The fedora15 documentation seems to have gathered some dust... Thanks, Tom From pspacek at redhat.com Fri Jan 17 12:12:31 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 17 Jan 2014 13:12:31 +0100 Subject: [Freeipa-users] replica installation issue In-Reply-To: <52D91798.4080206@alumni.ethz.ch> References: <52D91798.4080206@alumni.ethz.ch> Message-ID: <52D91E2F.6070504@redhat.com> On 17.1.2014 12:44, Thomas Sailer wrote: > After being unable to rescue my old freeipa installation, I installed a new > machine from scratch and imported the user data from the old installation (so > I could get rid of the separate PKI dirserv, too). That worked fine. > > Then I prepared a replica, and installed the replica on the old machine (after > first running ipa-server-install --uninstall). The installation completed > without error message. > > The replica however has a few issues: > > - GSSAPI authentication to the directory service doesn't work: > > # ldapsearch -D "cn=Directory Manager" -W \* > returns a few hundred records, however > # klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin at XXXX.COM > > Valid starting Expires Service principal > 01/16/2014 14:14:51 01/17/2014 14:14:47 krbtgt/XXXX.COM at XXXX.COM > 01/16/2014 14:14:54 01/17/2014 14:14:47 HTTP/replica.xxxx.com at XXXX.COM > 01/16/2014 14:15:22 01/17/2014 14:14:47 ldap/replica.xxxx.com at XXXX.COM > > # ldapsearch -Y GSSAPI \* > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified > GSS failure. Minor code may provide more information (Server > krbtgt/LOCALDOMAIN at XXXX.COM not found in Kerberos database) The LOCALDOMAIN part should equal to the REALM (after @). Is it the same and the difference came from your obfuscation or not? Does kdestroy && kinit work? Anyway, I would double check DNS (including reverse records for all involved machines) and the data in /etc/krb5.conf. > The localdomain apparently comes from /etc/hosts: > 127.0.0.1 localhost.localdomain localhost localhost4 > ::1 localhost6.localdomain6 localhost6 > 192.168.1.2 replica.xxxx.com replica > 192.168.1.3 master.xxxx.com master > > I tried to comment out the first two entries, which made it want to use > ldap/localhost at XXXX.COM, which failed too. > > krb5.keytab looks the same on both the master and the replica, with the > exception that the replica lacks the host key for the camellia*-cts-cmac cypher. > > - When I use the web server of the replica and click on > Identity->Certificates, I get: > IPA Error 4301: Certificate operation cannot be completed: Unable to > communicate with CMS ([Errno 113] No route to host) > > This same operation on the master works. Is this supposed to be like this? I suspect firewall on the replica. Did you opened all the ports in the same was as on the first server? See http://adam.younglogic.com/2013/03/iptables-rules-for-freeipa/ > - Is there a more up to date description of how to make a replica a master? > The fedora15 documentation seems to have gathered some dust... Replicas will be equal if you install CA to all servers. The only difference is that one of them generates CRL and renews CA certificates. You can move CRL generation from one server to another, see: http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master Have a nice day! -- Petr^2 Spacek From zidek at kajot.cz Fri Jan 17 14:13:44 2014 From: zidek at kajot.cz (Stanislav Zidek) Date: Fri, 17 Jan 2014 15:13:44 +0100 Subject: [Freeipa-users] Failover does not work Message-ID: <52D93A98.2050000@kajot.cz> Hi everybody, I'm struggling with IPA failover and would be grateful for any advice. I've setup a IPA server, added some client machines and users, then created a replica, added replica address to /etc/sssd/sssd.conf on clients. Everything fine so far. But when I simulate problem with first IPA server (by issuing "service ipa stop"). Then things start to get weird to me. I cannot login to clients, until I make a "service sssd restart" on them and wait few minutes. Am I doing something wrong? Is this expected behaviour? S. From pspacek at redhat.com Fri Jan 17 14:35:03 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 17 Jan 2014 15:35:03 +0100 Subject: [Freeipa-users] SSSD Failover does not work In-Reply-To: <52D93A98.2050000@kajot.cz> References: <52D93A98.2050000@kajot.cz> Message-ID: <52D93F97.4000100@redhat.com> On 17.1.2014 15:13, Stanislav Zidek wrote: > Hi everybody, > > I'm struggling with IPA failover and would be grateful for any advice. > > I've setup a IPA server, added some client machines and users, then > created a replica, added replica address to /etc/sssd/sssd.conf on BTW the best approach is to use SRV records in DNS so clients will automatically pick up new replicas. You will not need to touch sssd.conf at all. > clients. Everything fine so far. But when I simulate problem with first > IPA server (by issuing "service ipa stop"). Then things start to get > weird to me. I cannot login to clients, until I make a "service sssd > restart" on them and wait few minutes. > > Am I doing something wrong? Is this expected behaviour? I will let SSSD guys to comment on this. -- Petr^2 Spacek From rcritten at redhat.com Fri Jan 17 14:36:30 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 17 Jan 2014 09:36:30 -0500 Subject: [Freeipa-users] export users/groups from one ipa server to another In-Reply-To: <52D8DFCB.6050700@redhat.com> References: <4ED173A868981548967B4FCA2707222605696C@AACMBXP04.exchserver.com> <52D8DFCB.6050700@redhat.com> Message-ID: <52D93FEE.4040200@redhat.com> Martin Kosek wrote: > On 01/17/2014 07:24 AM, Les Stott wrote: >> Hi All, >> >> Looking for the quickest and easiest way to export users from one freeipa server and install on another. >> >> I have an existing freeipa server, 3.0.0 standard rhel6 in a DR environment. >> I am setting up an identical freeipa server in a Production Environment. >> >> The two environments will not be configured to talk to each other. They will both have there own replicas. >> >> I simply want to export the users and groups I created in freeipa in DR, and import them (preserving details and passwords) into the freeipa server in Production. >> >> What is the recommendation? Is there an ipa tool? Or will ldif exports suffice? >> >> Thanks in advance, >> >> Les > > I think the best way would be to use the "ipa migrate-ds" command. It should > work both with stand alone Directory Servers and IPA too. You may just need to > play with --userignoreobjectclass amd userignoreattribute to not migrate > Kerberos related attributes and objectclasses if for example your other DS has > a different realm. Kerberos attributes are already excluded by default. You'll need to enable password migration mode on the production IPA server, ipa config-mod --enable-migration=true The first time your migrated production users authenticate with their password their Kerberos credentials will be generated. rob From dpal at redhat.com Fri Jan 17 14:46:08 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 17 Jan 2014 09:46:08 -0500 Subject: [Freeipa-users] SSSD Failover does not work In-Reply-To: <52D93F97.4000100@redhat.com> References: <52D93A98.2050000@kajot.cz> <52D93F97.4000100@redhat.com> Message-ID: <52D94230.6080108@redhat.com> On 01/17/2014 09:35 AM, Petr Spacek wrote: > On 17.1.2014 15:13, Stanislav Zidek wrote: >> Hi everybody, >> >> I'm struggling with IPA failover and would be grateful for any advice. >> >> I've setup a IPA server, added some client machines and users, then >> created a replica, added replica address to /etc/sssd/sssd.conf on > BTW the best approach is to use SRV records in DNS so clients will > automatically pick up new replicas. You will not need to touch > sssd.conf at all. > >> clients. Everything fine so far. But when I simulate problem with first >> IPA server (by issuing "service ipa stop"). Then things start to get >> weird to me. I cannot login to clients, until I make a "service sssd >> restart" on them and wait few minutes. >> >> Am I doing something wrong? Is this expected behaviour? > I will let SSSD guys to comment on this. > You would need to up the debug_level to 6 on SSSD, restart it, then simulate the situation and provide sanitized logs and sssd configuration file. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jhrozek at redhat.com Fri Jan 17 14:53:04 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 17 Jan 2014 15:53:04 +0100 Subject: [Freeipa-users] SSSD Failover does not work In-Reply-To: <52D93F97.4000100@redhat.com> References: <52D93A98.2050000@kajot.cz> <52D93F97.4000100@redhat.com> Message-ID: <20140117145304.GH13011@hendrix.redhat.com> On Fri, Jan 17, 2014 at 03:35:03PM +0100, Petr Spacek wrote: > On 17.1.2014 15:13, Stanislav Zidek wrote: > >Hi everybody, > > > >I'm struggling with IPA failover and would be grateful for any advice. > > > >I've setup a IPA server, added some client machines and users, then > >created a replica, added replica address to /etc/sssd/sssd.conf on > BTW the best approach is to use SRV records in DNS so clients will > automatically pick up new replicas. You will not need to touch > sssd.conf at all. +1 I would recommend the SRV records as well if your DNS is managed by the IPA server. No need to touch the client config. > > >clients. Everything fine so far. But when I simulate problem with first > >IPA server (by issuing "service ipa stop"). Then things start to get > >weird to me. I cannot login to clients, until I make a "service sssd > >restart" on them and wait few minutes. > > > >Am I doing something wrong? Is this expected behaviour? > I will let SSSD guys to comment on this. As Dmitri commented in the other thread, logs and config would be useful. From dpal at redhat.com Fri Jan 17 14:58:50 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 17 Jan 2014 09:58:50 -0500 Subject: [Freeipa-users] export users/groups from one ipa server to another In-Reply-To: <52D93FEE.4040200@redhat.com> References: <4ED173A868981548967B4FCA2707222605696C@AACMBXP04.exchserver.com> <52D8DFCB.6050700@redhat.com> <52D93FEE.4040200@redhat.com> Message-ID: <52D9452A.6070900@redhat.com> On 01/17/2014 09:36 AM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 01/17/2014 07:24 AM, Les Stott wrote: >>> Hi All, >>> >>> Looking for the quickest and easiest way to export users from one >>> freeipa server and install on another. >>> >>> I have an existing freeipa server, 3.0.0 standard rhel6 in a DR >>> environment. >>> I am setting up an identical freeipa server in a Production >>> Environment. >>> >>> The two environments will not be configured to talk to each other. >>> They will both have there own replicas. >>> >>> I simply want to export the users and groups I created in freeipa in >>> DR, and import them (preserving details and passwords) into the >>> freeipa server in Production. >>> >>> What is the recommendation? Is there an ipa tool? Or will ldif >>> exports suffice? >>> >>> Thanks in advance, >>> >>> Les >> >> I think the best way would be to use the "ipa migrate-ds" command. It >> should >> work both with stand alone Directory Servers and IPA too. You may >> just need to >> play with --userignoreobjectclass amd userignoreattribute to not migrate >> Kerberos related attributes and objectclasses if for example your >> other DS has >> a different realm. > > Kerberos attributes are already excluded by default. > > You'll need to enable password migration mode on the production IPA > server, ipa config-mod --enable-migration=true > > The first time your migrated production users authenticate with their > password their Kerberos credentials will be generated. If users authenticate using sssd. ^ > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Fri Jan 17 15:02:33 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 17 Jan 2014 16:02:33 +0100 Subject: [Freeipa-users] export users/groups from one ipa server to another In-Reply-To: <52D9452A.6070900@redhat.com> References: <4ED173A868981548967B4FCA2707222605696C@AACMBXP04.exchserver.com> <52D8DFCB.6050700@redhat.com> <52D93FEE.4040200@redhat.com> <52D9452A.6070900@redhat.com> Message-ID: <52D94609.7000701@redhat.com> On 01/17/2014 03:58 PM, Dmitri Pal wrote: > On 01/17/2014 09:36 AM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 01/17/2014 07:24 AM, Les Stott wrote: >>>> Hi All, >>>> >>>> Looking for the quickest and easiest way to export users from one >>>> freeipa server and install on another. >>>> >>>> I have an existing freeipa server, 3.0.0 standard rhel6 in a DR >>>> environment. >>>> I am setting up an identical freeipa server in a Production >>>> Environment. >>>> >>>> The two environments will not be configured to talk to each other. >>>> They will both have there own replicas. >>>> >>>> I simply want to export the users and groups I created in freeipa in >>>> DR, and import them (preserving details and passwords) into the >>>> freeipa server in Production. >>>> >>>> What is the recommendation? Is there an ipa tool? Or will ldif >>>> exports suffice? >>>> >>>> Thanks in advance, >>>> >>>> Les >>> >>> I think the best way would be to use the "ipa migrate-ds" command. It >>> should >>> work both with stand alone Directory Servers and IPA too. You may >>> just need to >>> play with --userignoreobjectclass amd userignoreattribute to not migrate >>> Kerberos related attributes and objectclasses if for example your >>> other DS has >>> a different realm. >> >> Kerberos attributes are already excluded by default. >> >> You'll need to enable password migration mode on the production IPA >> server, ipa config-mod --enable-migration=true >> >> The first time your migrated production users authenticate with their >> password their Kerberos credentials will be generated. > > If users authenticate using sssd. ^ If they do not use SSSD, they can also use a special page for password migration: https://ipa.example.com/ipa/migration/ Martin From rcritten at redhat.com Fri Jan 17 15:37:06 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 17 Jan 2014 10:37:06 -0500 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <52D463E4.2080006@nixtra.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> Message-ID: <52D94E22.2060207@redhat.com> Sigbjorn Lie wrote: > > This worked better than expected. Thank you! :) > > ipa01 and ipa02 seem to be happy again, "getcert list" no longer > displays any certificates out of date, and all certificates in need of > renewal within 28 days has been renewed. The webui also started working > again and things seem to be back to normal. > > ipa03 however is still having issues. I could not renew any certificates > on this server to begin with, but I managed to renew the certificates > for the directory servers by changing the xmlrpc url to another ipa > server in /etc/ipa/default.conf and resubmitting these requests. > > "getcert resubmit -i NEED_GUIDANCE after a short while for the certificates for the PKI service. > > /var/log/messages says: "certmonger: #033[?1034h28800" and "python: > Updated certificate for ipaCert not available". > > There is a lot of information in the /var/log/pki-ca/debug, but nothing > that I can easily distinguish as an error from all the other output. > Anything in particular I should look for? Ok, so this is a bug in IPA related to python readline. Garbage is getting inserted and causing bad things to happen, https://fedorahosted.org/freeipa/ticket/4064 So the question is, are the certs available or not. A number of the same certificates are shared amongst all the CAs. One does the renewal and stuffs the result into cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX. The other CAs refer to that location for an updated cert and will load them if they are updated. Look to see if the certs are updated there. Given that you have 2 working masters I'm assuming that is the case, so it may just be a matter of fixing the python. rob From t.sailer at alumni.ethz.ch Fri Jan 17 16:18:16 2014 From: t.sailer at alumni.ethz.ch (Thomas Sailer) Date: Fri, 17 Jan 2014 17:18:16 +0100 Subject: [Freeipa-users] replica installation issue In-Reply-To: <52D91E2F.6070504@redhat.com> References: <52D91798.4080206@alumni.ethz.ch> <52D91E2F.6070504@redhat.com> Message-ID: <52D957C8.60304@alumni.ethz.ch> On 01/17/2014 01:12 PM, Petr Spacek wrote: > On 17.1.2014 12:44, Thomas Sailer wrote: >> # ldapsearch -Y GSSAPI \* >> SASL/GSSAPI authentication started >> ldap_sasl_interactive_bind_s: Local error (-2) >> additional info: SASL(-1): generic failure: GSSAPI Error: >> Unspecified >> GSS failure. Minor code may provide more information (Server >> krbtgt/LOCALDOMAIN at XXXX.COM not found in Kerberos database) > > The LOCALDOMAIN part should equal to the REALM (after @). Is it the > same and the difference came from your obfuscation or not? No it's not my obfuscation, it's really LOCALDOMAIN. It turned out that: /etc/openldap/ldap.conf contained: URI ldap://localhost instead of URI ldaps://replica.xxxx.com > See > http://adam.younglogic.com/2013/03/iptables-rules-for-freeipa/ Urgh embarassing. Indeed, it turned out that I need to open port 8080 on the master (it is connected by the replica). Port 8080 doesn't feature on the list in the above blog post, so I posted a comment... > Replicas will be equal if you install CA to all servers. Great to hear! > Have a nice day! Thank you, and same to you! From jhrozek at redhat.com Fri Jan 17 18:42:09 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 17 Jan 2014 19:42:09 +0100 Subject: [Freeipa-users] sudo log errors In-Reply-To: References: <52D566FC.2070108@redhat.com> <1389764981.26102.469.camel@willson.li.ssimo.org> <20140115095914.GC22627@hendrix.brq.redhat.com> Message-ID: <20140117184209.GB29266@hendrix.redhat.com> On Wed, Jan 15, 2014 at 11:45:58AM +0100, Natxo Asenjo wrote: > On Wed, Jan 15, 2014 at 10:59 AM, Jakub Hrozek wrote: > > On Wed, Jan 15, 2014 at 10:09:20AM +0100, Natxo Asenjo wrote: > >> > On what platform are you ? With sudo-sssd integration you shouldn't use > >> > directly ldap anymore. > >> > >> centos 6.5 on these hosts. So if I use sssd insted of ldap for sudo > >> this could go away? > > > > I believe so, with the sssd integration, the sudo fetches all data from > > the SSSD. One catch though, there is no "sudo_provider=ipa" in 6.5, but > > man sssd-sudo should contain an example of setting up > > "sudo_provider=ldap" on an IPA client. > > ok. If I configure sssd.conf like that, do I need to configure > anything in /etc/sudo-ldap.conf or are those mutually exclusive? Sorry for the late reply. Not mutually exclusive, but they do the same thing :-) It's the same as having both sssd and nss_ldap configured for passwd lookups. In order for the sudo binary to be able to talk to sssd you need to install libsss_sudo. (This is only applicable to RHEL6, in later upstream versions we folded the binary back to sssd proper) > > I have now this in /etc/sudo-ldap.conf: > > TLS_CACERT /etc/ipa/ca.crt > TLS_REQCERT demand > SASL_MECH GSSAPI > BASE dc=sub,dc=domain,dc=tld > URI ldaps://kdc01.sub.domain.tld ldaps://kdc02.sub.domain.tld > ROOTUSE_SASL on > SUDOERS_BASE ou=sudoers,dc=sub,dc=domain,dc=tld > SUDOERS_DEBUG 0 You should include "sss" as the data source in /etc/nsswitch.conf # grep sudo /etc/nsswitch.conf sudoers: files sss > > and this in sssd.conf > > [sssd] > domains = sub.domain.tld > services = nss, pam, ssh 'sudo' needs to be included as one of the services. > config_file_version = 2 > > [nss] > > [pam] > > [domain/sub.domain.tld] > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = sub.domain.tld > id_provider = ipa > auth_provider = ipa > access_provider = ipa > chpass_provider = ipa > ipa_dyndns_update = True > ipa_server = _srv_, kdc01.sub.domain.tld > ldap_tls_cacert = /etc/ipa/ca.crt > entry_cache_netgroup_timeout = 300 Unfortunately with 6.5 there is still no sudo ipa provider, there might be with one in 6.6. So in order to download the sudo rules you need to configure the LDAP sudo provider manually. It would look something like: sudo_provider = ldap ldap_uri = ldap://kdc01.sub.domain.tld ldap_sudo_search_base = ou=sudoers,dc=sub,dc=domain,dc=tld ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/client.sub.domain.tld ldap_sasl_realm = SUB.DOMAIN.TLD krb5_server = kdc01.sub.domain.tld From Less at imagine-sw.com Fri Jan 17 20:36:50 2014 From: Less at imagine-sw.com (Les Stott) Date: Fri, 17 Jan 2014 20:36:50 +0000 Subject: [Freeipa-users] export users/groups from one ipa server to another In-Reply-To: <52D93FEE.4040200@redhat.com> References: <4ED173A868981548967B4FCA2707222605696C@AACMBXP04.exchserver.com> <52D8DFCB.6050700@redhat.com>,<52D93FEE.4040200@redhat.com> Message-ID: <4ED173A868981548967B4FCA27072226056E41@AACMBXP04.exchserver.com> > The first time your migrated production users authenticate with their > password their Kerberos credentials will be generated. Is there a way to avoid this? I had to do that for importing shadow files originally in DR. now, i'm going from freeipa to freeipa. if i export kerberos attributes will that avoid users having to regenerate the kerberos credentials? Thanks, Les ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Saturday, January 18, 2014 1:36 AM To: Martin Kosek; Les Stott; freeipa-users at redhat.com Subject: Re: [Freeipa-users] export users/groups from one ipa server to another Martin Kosek wrote: > On 01/17/2014 07:24 AM, Les Stott wrote: >> Hi All, >> >> Looking for the quickest and easiest way to export users from one freeipa server and install on another. >> >> I have an existing freeipa server, 3.0.0 standard rhel6 in a DR environment. >> I am setting up an identical freeipa server in a Production Environment. >> >> The two environments will not be configured to talk to each other. They will both have there own replicas. >> >> I simply want to export the users and groups I created in freeipa in DR, and import them (preserving details and passwords) into the freeipa server in Production. >> >> What is the recommendation? Is there an ipa tool? Or will ldif exports suffice? >> >> Thanks in advance, >> >> Les > > I think the best way would be to use the "ipa migrate-ds" command. It should > work both with stand alone Directory Servers and IPA too. You may just need to > play with --userignoreobjectclass amd userignoreattribute to not migrate > Kerberos related attributes and objectclasses if for example your other DS has > a different realm. Kerberos attributes are already excluded by default. You'll need to enable password migration mode on the production IPA server, ipa config-mod --enable-migration=true The first time your migrated production users authenticate with their password their Kerberos credentials will be generated. rob From rcritten at redhat.com Fri Jan 17 20:59:04 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 17 Jan 2014 15:59:04 -0500 Subject: [Freeipa-users] export users/groups from one ipa server to another In-Reply-To: <4ED173A868981548967B4FCA27072226056E41@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222605696C@AACMBXP04.exchserver.com> <52D8DFCB.6050700@redhat.com>, <52D93FEE.4040200@redhat.com> <4ED173A868981548967B4FCA27072226056E41@AACMBXP04.exchserver.com> Message-ID: <52D99998.4090508@redhat.com> Les Stott wrote: >> The first time your migrated production users authenticate with their >> password their Kerberos credentials will be generated. > > Is there a way to avoid this? > > I had to do that for importing shadow files originally in DR. now, i'm going from freeipa to freeipa. if i export kerberos attributes will that avoid users having to regenerate the kerberos credentials? No. The kerberos master keys are different. rob From dpal at redhat.com Fri Jan 17 22:06:23 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 17 Jan 2014 17:06:23 -0500 Subject: [Freeipa-users] export users/groups from one ipa server to another In-Reply-To: <52D99998.4090508@redhat.com> References: <4ED173A868981548967B4FCA2707222605696C@AACMBXP04.exchserver.com> <52D8DFCB.6050700@redhat.com>, <52D93FEE.4040200@redhat.com> <4ED173A868981548967B4FCA27072226056E41@AACMBXP04.exchserver.com> <52D99998.4090508@redhat.com> Message-ID: <52D9A95F.3050307@redhat.com> On 01/17/2014 03:59 PM, Rob Crittenden wrote: > Les Stott wrote: >>> The first time your migrated production users authenticate with their >>> password their Kerberos credentials will be generated. >> >> Is there a way to avoid this? >> >> I had to do that for importing shadow files originally in DR. now, >> i'm going from freeipa to freeipa. if i export kerberos attributes >> will that avoid users having to regenerate the kerberos credentials? > > No. The kerberos master keys are different. Unless you want to copy master keys over. This is a complex manual procedure. You can probably find it in the archives as we helped people with it couple times but it is not recommended. May be we should open an RFE to develop a tool that would do ipa-migrate-ipa and can be used to move data from POC to production. > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From kifal75 at hotmail.com Fri Jan 17 23:29:15 2014 From: kifal75 at hotmail.com (Zulkifal Ahmad) Date: Fri, 17 Jan 2014 23:29:15 +0000 Subject: [Freeipa-users] ipa AD trust issue In-Reply-To: References: Message-ID: Hi List , Just wanted to find out if anyone has setup an ipa-AD trust successfully, According to the instructions in the following link https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-ipa-subdomain.html everything went well until I hit the point where I had to check the samba configuration, by typing the command root at ipaserver# smbclient -L ipaserver.ipaexample.com -k smbclient: command not found and similar for root at ipaserver# wbinfo --online-status wbinfo: command not found I am pretty sure that the command "ipa-trust-install" command did install samba4 packages as dependencies, anyways I thought these packages were not necessary and went forward until I got really stuck when I typed the command . root at ipaserver# ipa trust-add --type=ad adexample.com --admin Administrator --password This gave me a very cruel message ipa: ERROR: CIFS server communication error: code "-1073741801", message "Memory allocation error" (both may be "None") If its this bug " https://bugzilla.redhat.com/show_bug.cgi?id=878168 " has anyone worked it out. Secondly cifs-utils has dependency on samba3 packages and ipa-ad-trust needs samba4 but samba3 and samba4 don't like each other , so this is the story of my experience with ipa. Any suggestions ? My ipa server server OS : CentOS 6.5 ipa server version : 3 Active directory: server 2008 R2 Standard Thank you Best Regards Sahibzada .Z. Ahmad System Administrator -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Jan 17 23:42:15 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 17 Jan 2014 18:42:15 -0500 Subject: [Freeipa-users] ipa AD trust issue In-Reply-To: References: Message-ID: <52D9BFD7.30406@redhat.com> On 01/17/2014 06:29 PM, Zulkifal Ahmad wrote: > Hi List , Just wanted to find out if anyone has setup an ipa-AD trust > successfully, According to the instructions in the following link > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-ipa-subdomain.html > everything went well until I hit the point where I had to check the > samba configuration, by typing the command > root at ipaserver # smbclient -L > ipaserver.ipaexample.com -k > smbclient: command not found > and similar for > root at ipaserver # wbinfo --online-status > wbinfo: command not found > > I am pretty sure that the command "ipa-trust-install" command did > install samba4 packages as dependencies, anyways I thought these > packages were not necessary and went forward until I got really stuck > when I typed the command . > root at ipaserver # ipa trust-add --type=ad > adexample.com --admin Administrator --password > This gave me a very cruel message > ipa: ERROR: CIFS server communication error: code "-1073741801", > message "Memory allocation error" (both may be "None") > If its this bug " https://bugzilla.redhat.com/show_bug.cgi?id=878168 " Yes. The solution is: If configured, the Active Directory (AD) DNS server returns IPv4 and IPv6 addresses of an AD server. If the FreeIPA server cannot connect to the AD server with an IPv6 address, running the ipa trust-add command will fail even if it would be possible to use IPv4. To work around this problem, add the IPv4 address of the AD server to the /etc/hosts file. In this case, the FreeIPA server will use only the IPv4 address and executing ipa trust-add will be successful. > has anyone worked it out. Secondly cifs-utils has dependency on samba3 > packages and ipa-ad-trust needs samba4 but samba3 and samba4 don't > like each other , so this is the story of my experience with ipa. Any > suggestions ? Why do you need cifs-utils on the same server? cifs-utils to make a system a client to MSFT file server, AFAIU you cant make IPA server to be a cifs client. SSSD 1.12 (in works) if going to be capable to work with cifs-utils instead of samba winbind thus the limitation will be lifted. > My ipa server server OS : CentOS 6.5 > ipa server version : 3 > Active directory: server 2008 R2 Standard > > Thank you > */ Best Regards/* > // > /Sahibzada .Z. Ahmad/ > /System Administrator/* > * > > > > > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Less at imagine-sw.com Mon Jan 20 04:21:51 2014 From: Less at imagine-sw.com (Les Stott) Date: Mon, 20 Jan 2014 04:21:51 +0000 Subject: [Freeipa-users] export users/groups from one ipa server to another In-Reply-To: <52D8DFCB.6050700@redhat.com> References: <4ED173A868981548967B4FCA2707222605696C@AACMBXP04.exchserver.com> <52D8DFCB.6050700@redhat.com> Message-ID: <4ED173A868981548967B4FCA27072226058008@AACMBXP04.exchserver.com> Thanks Martin. Ipa migrate-ds worked a treat. I'll get users to login to an ipa client so that it generates the Kerberos hash (like I had to originally) For reference I did have to specify the correct containers for users and groups... ipa migrate-ds --user-container=cn=users,cn=accounts --group-container=cn=groups,cn=accounts --with-compat ldap://dr-ipa.mydomain.com:389 I still would like a way to dump users out to a file, for backup purposes, such as an ldif file. If anyone has a script to do that I'd appreciate it. Regards, Les -----Original Message----- From: Martin Kosek [mailto:mkosek at redhat.com] Sent: Friday, 17 January 2014 6:46 PM To: Les Stott; freeipa-users at redhat.com Subject: Re: [Freeipa-users] export users/groups from one ipa server to another On 01/17/2014 07:24 AM, Les Stott wrote: > Hi All, > > Looking for the quickest and easiest way to export users from one freeipa server and install on another. > > I have an existing freeipa server, 3.0.0 standard rhel6 in a DR environment. > I am setting up an identical freeipa server in a Production Environment. > > The two environments will not be configured to talk to each other. They will both have there own replicas. > > I simply want to export the users and groups I created in freeipa in DR, and import them (preserving details and passwords) into the freeipa server in Production. > > What is the recommendation? Is there an ipa tool? Or will ldif exports suffice? > > Thanks in advance, > > Les I think the best way would be to use the "ipa migrate-ds" command. It should work both with stand alone Directory Servers and IPA too. You may just need to play with --userignoreobjectclass amd userignoreattribute to not migrate Kerberos related attributes and objectclasses if for example your other DS has a different realm. Martin From sramling at redhat.com Mon Jan 20 05:09:21 2014 From: sramling at redhat.com (Sankar Ramlingam) Date: Mon, 20 Jan 2014 10:39:21 +0530 Subject: [Freeipa-users] export users/groups from one ipa server to another In-Reply-To: <4ED173A868981548967B4FCA27072226058008@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222605696C@AACMBXP04.exchserver.com> <52D8DFCB.6050700@redhat.com> <4ED173A868981548967B4FCA27072226058008@AACMBXP04.exchserver.com> Message-ID: <52DCAF81.4050007@redhat.com> On 01/20/2014 09:51 AM, Les Stott wrote: > Thanks Martin. > > Ipa migrate-ds worked a treat. I'll get users to login to an ipa client so that it generates the Kerberos hash (like I had to originally) > > For reference I did have to specify the correct containers for users and groups... > > ipa migrate-ds --user-container=cn=users,cn=accounts --group-container=cn=groups,cn=accounts --with-compat ldap://dr-ipa.mydomain.com:389 > > I still would like a way to dump users out to a file, for backup purposes, such as an ldif file. If anyone has a script to do that I'd appreciate it. Please refer to this link - http://documentation-devel.engineering.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Populating_Directory_Databases-Exporting_Data.html#Exporting_Data-Exporting_to_LDIF_from_the_Command_Line Thanks, -Sankar R > > Regards, > > Les > > > -----Original Message----- > From: Martin Kosek [mailto:mkosek at redhat.com] > Sent: Friday, 17 January 2014 6:46 PM > To: Les Stott; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] export users/groups from one ipa server to another > > On 01/17/2014 07:24 AM, Les Stott wrote: >> Hi All, >> >> Looking for the quickest and easiest way to export users from one freeipa server and install on another. >> >> I have an existing freeipa server, 3.0.0 standard rhel6 in a DR environment. >> I am setting up an identical freeipa server in a Production Environment. >> >> The two environments will not be configured to talk to each other. They will both have there own replicas. >> >> I simply want to export the users and groups I created in freeipa in DR, and import them (preserving details and passwords) into the freeipa server in Production. >> >> What is the recommendation? Is there an ipa tool? Or will ldif exports suffice? >> >> Thanks in advance, >> >> Les > I think the best way would be to use the "ipa migrate-ds" command. It should work both with stand alone Directory Servers and IPA too. You may just need to play with --userignoreobjectclass amd userignoreattribute to not migrate Kerberos related attributes and objectclasses if for example your other DS has a different realm. > > Martin > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From mkosek at redhat.com Mon Jan 20 08:21:27 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 20 Jan 2014 09:21:27 +0100 Subject: [Freeipa-users] export users/groups from one ipa server to another In-Reply-To: <52D9A95F.3050307@redhat.com> References: <4ED173A868981548967B4FCA2707222605696C@AACMBXP04.exchserver.com> <52D8DFCB.6050700@redhat.com>, <52D93FEE.4040200@redhat.com> <4ED173A868981548967B4FCA27072226056E41@AACMBXP04.exchserver.com> <52D99998.4090508@redhat.com> <52D9A95F.3050307@redhat.com> Message-ID: <52DCDC87.9040105@redhat.com> On 01/17/2014 11:06 PM, Dmitri Pal wrote: > On 01/17/2014 03:59 PM, Rob Crittenden wrote: >> Les Stott wrote: >>>> The first time your migrated production users authenticate with their >>>> password their Kerberos credentials will be generated. >>> >>> Is there a way to avoid this? >>> >>> I had to do that for importing shadow files originally in DR. now, >>> i'm going from freeipa to freeipa. if i export kerberos attributes >>> will that avoid users having to regenerate the kerberos credentials? >> >> No. The kerberos master keys are different. > > Unless you want to copy master keys over. > This is a complex manual procedure. You can probably find it in the > archives as we helped people with it couple times but it is not recommended. > > May be we should open an RFE to develop a tool that would do > ipa-migrate-ipa and can be used to move data from POC to production. We have a RFE open for that feature already: https://fedorahosted.org/freeipa/ticket/3656 I added a reference to this discussion on the list. Contributions or other ideas are very welcome! Martin From pspacek at redhat.com Mon Jan 20 11:27:17 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 20 Jan 2014 12:27:17 +0100 Subject: [Freeipa-users] export users/groups from one ipa server to another In-Reply-To: <52DCDC87.9040105@redhat.com> References: <4ED173A868981548967B4FCA2707222605696C@AACMBXP04.exchserver.com> <52D8DFCB.6050700@redhat.com>, <52D93FEE.4040200@redhat.com> <4ED173A868981548967B4FCA27072226056E41@AACMBXP04.exchserver.com> <52D99998.4090508@redhat.com> <52D9A95F.3050307@redhat.com> <52DCDC87.9040105@redhat.com> Message-ID: <52DD0815.6020108@redhat.com> On 20.1.2014 09:21, Martin Kosek wrote: > On 01/17/2014 11:06 PM, Dmitri Pal wrote: >> On 01/17/2014 03:59 PM, Rob Crittenden wrote: >>> Les Stott wrote: >>>>> The first time your migrated production users authenticate with their >>>>> password their Kerberos credentials will be generated. >>>> >>>> Is there a way to avoid this? >>>> >>>> I had to do that for importing shadow files originally in DR. now, >>>> i'm going from freeipa to freeipa. if i export kerberos attributes >>>> will that avoid users having to regenerate the kerberos credentials? >>> >>> No. The kerberos master keys are different. >> >> Unless you want to copy master keys over. >> This is a complex manual procedure. You can probably find it in the >> archives as we helped people with it couple times but it is not recommended. >> >> May be we should open an RFE to develop a tool that would do >> ipa-migrate-ipa and can be used to move data from POC to production. > > We have a RFE open for that feature already: > > https://fedorahosted.org/freeipa/ticket/3656 > > I added a reference to this discussion on the list. Contributions or other > ideas are very welcome! It sounds like creating a new replica and then disconnecting the new replica from the old replica. This procedure will copy all keys etc., so be sure you understand security implications for your environment! (Who can get root access to old environment? Who can get root access to the new environment? What will you do if one of them was compromised...?) -- Petr^2 Spacek From pspacek at redhat.com Mon Jan 20 11:31:40 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 20 Jan 2014 12:31:40 +0100 Subject: [Freeipa-users] export users/groups from one ipa server to another In-Reply-To: <52DD0815.6020108@redhat.com> References: <4ED173A868981548967B4FCA2707222605696C@AACMBXP04.exchserver.com> <52D8DFCB.6050700@redhat.com>, <52D93FEE.4040200@redhat.com> <4ED173A868981548967B4FCA27072226056E41@AACMBXP04.exchserver.com> <52D99998.4090508@redhat.com> <52D9A95F.3050307@redhat.com> <52DCDC87.9040105@redhat.com> <52DD0815.6020108@redhat.com> Message-ID: <52DD091C.20607@redhat.com> On 20.1.2014 12:27, Petr Spacek wrote: > On 20.1.2014 09:21, Martin Kosek wrote: >> On 01/17/2014 11:06 PM, Dmitri Pal wrote: >>> On 01/17/2014 03:59 PM, Rob Crittenden wrote: >>>> Les Stott wrote: >>>>>> The first time your migrated production users authenticate with their >>>>>> password their Kerberos credentials will be generated. >>>>> >>>>> Is there a way to avoid this? >>>>> >>>>> I had to do that for importing shadow files originally in DR. now, >>>>> i'm going from freeipa to freeipa. if i export kerberos attributes >>>>> will that avoid users having to regenerate the kerberos credentials? >>>> >>>> No. The kerberos master keys are different. >>> >>> Unless you want to copy master keys over. >>> This is a complex manual procedure. You can probably find it in the >>> archives as we helped people with it couple times but it is not recommended. >>> >>> May be we should open an RFE to develop a tool that would do >>> ipa-migrate-ipa and can be used to move data from POC to production. >> >> We have a RFE open for that feature already: >> >> https://fedorahosted.org/freeipa/ticket/3656 >> >> I added a reference to this discussion on the list. Contributions or other >> ideas are very welcome! > > It sounds like creating a new replica and then disconnecting the new replica > from the old replica. > > This procedure will copy all keys etc., so be sure you understand security > implications for your environment! (Who can get root access to old > environment? Who can get root access to the new environment? What will you do > if one of them was compromised...?) I should clarify this: May be that we could provide a tool for FreeIPA domain rename, so you can create replica, disconnect the replica and then rename the FreeIPA domain to something else (renaming would include master-key regeneration etc.). This solves two problems at once: - FreeIPA-to-FreeIPA migration - FreeIPA domain renaming -- Petr^2 Spacek From rcritten at redhat.com Mon Jan 20 16:12:49 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 20 Jan 2014 11:12:49 -0500 Subject: [Freeipa-users] export users/groups from one ipa server to another In-Reply-To: <52DD091C.20607@redhat.com> References: <4ED173A868981548967B4FCA2707222605696C@AACMBXP04.exchserver.com> <52D8DFCB.6050700@redhat.com>, <52D93FEE.4040200@redhat.com> <4ED173A868981548967B4FCA27072226056E41@AACMBXP04.exchserver.com> <52D99998.4090508@redhat.com> <52D9A95F.3050307@redhat.com> <52DCDC87.9040105@redhat.com> <52DD0815.6020108@redhat.com> <52DD091C.20607@redhat.com> Message-ID: <52DD4B01.7070004@redhat.com> Petr Spacek wrote: > On 20.1.2014 12:27, Petr Spacek wrote: >> On 20.1.2014 09:21, Martin Kosek wrote: >>> On 01/17/2014 11:06 PM, Dmitri Pal wrote: >>>> On 01/17/2014 03:59 PM, Rob Crittenden wrote: >>>>> Les Stott wrote: >>>>>>> The first time your migrated production users authenticate with >>>>>>> their >>>>>>> password their Kerberos credentials will be generated. >>>>>> >>>>>> Is there a way to avoid this? >>>>>> >>>>>> I had to do that for importing shadow files originally in DR. now, >>>>>> i'm going from freeipa to freeipa. if i export kerberos attributes >>>>>> will that avoid users having to regenerate the kerberos credentials? >>>>> >>>>> No. The kerberos master keys are different. >>>> >>>> Unless you want to copy master keys over. >>>> This is a complex manual procedure. You can probably find it in the >>>> archives as we helped people with it couple times but it is not >>>> recommended. >>>> >>>> May be we should open an RFE to develop a tool that would do >>>> ipa-migrate-ipa and can be used to move data from POC to production. >>> >>> We have a RFE open for that feature already: >>> >>> https://fedorahosted.org/freeipa/ticket/3656 >>> >>> I added a reference to this discussion on the list. Contributions or >>> other >>> ideas are very welcome! >> >> It sounds like creating a new replica and then disconnecting the new >> replica >> from the old replica. >> >> This procedure will copy all keys etc., so be sure you understand >> security >> implications for your environment! (Who can get root access to old >> environment? Who can get root access to the new environment? What will >> you do >> if one of them was compromised...?) > > I should clarify this: > > May be that we could provide a tool for FreeIPA domain rename, so you > can create replica, disconnect the replica and then rename the FreeIPA > domain to something else (renaming would include master-key regeneration > etc.). > > This solves two problems at once: > - FreeIPA-to-FreeIPA migration > - FreeIPA domain renaming > There could be some weird side-effects. The certificate subject base is not changable post-install so you could end up issuing certs with the subject of the old realm. rob From dpal at redhat.com Mon Jan 20 16:37:18 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 20 Jan 2014 11:37:18 -0500 Subject: [Freeipa-users] export users/groups from one ipa server to another In-Reply-To: <52DD4B01.7070004@redhat.com> References: <4ED173A868981548967B4FCA2707222605696C@AACMBXP04.exchserver.com> <52D8DFCB.6050700@redhat.com>, <52D93FEE.4040200@redhat.com> <4ED173A868981548967B4FCA27072226056E41@AACMBXP04.exchserver.com> <52D99998.4090508@redhat.com> <52D9A95F.3050307@redhat.com> <52DCDC87.9040105@redhat.com> <52DD0815.6020108@redhat.com> <52DD091C.20607@redhat.com> <52DD4B01.7070004@redhat.com> Message-ID: <52DD50BE.8090700@redhat.com> On 01/20/2014 11:12 AM, Rob Crittenden wrote: > Petr Spacek wrote: >> On 20.1.2014 12:27, Petr Spacek wrote: >>> On 20.1.2014 09:21, Martin Kosek wrote: >>>> On 01/17/2014 11:06 PM, Dmitri Pal wrote: >>>>> On 01/17/2014 03:59 PM, Rob Crittenden wrote: >>>>>> Les Stott wrote: >>>>>>>> The first time your migrated production users authenticate with >>>>>>>> their >>>>>>>> password their Kerberos credentials will be generated. >>>>>>> >>>>>>> Is there a way to avoid this? >>>>>>> >>>>>>> I had to do that for importing shadow files originally in DR. now, >>>>>>> i'm going from freeipa to freeipa. if i export kerberos attributes >>>>>>> will that avoid users having to regenerate the kerberos >>>>>>> credentials? >>>>>> >>>>>> No. The kerberos master keys are different. >>>>> >>>>> Unless you want to copy master keys over. >>>>> This is a complex manual procedure. You can probably find it in the >>>>> archives as we helped people with it couple times but it is not >>>>> recommended. >>>>> >>>>> May be we should open an RFE to develop a tool that would do >>>>> ipa-migrate-ipa and can be used to move data from POC to production. >>>> >>>> We have a RFE open for that feature already: >>>> >>>> https://fedorahosted.org/freeipa/ticket/3656 >>>> >>>> I added a reference to this discussion on the list. Contributions or >>>> other >>>> ideas are very welcome! >>> >>> It sounds like creating a new replica and then disconnecting the new >>> replica >>> from the old replica. >>> >>> This procedure will copy all keys etc., so be sure you understand >>> security >>> implications for your environment! (Who can get root access to old >>> environment? Who can get root access to the new environment? What will >>> you do >>> if one of them was compromised...?) >> >> I should clarify this: >> >> May be that we could provide a tool for FreeIPA domain rename, so you >> can create replica, disconnect the replica and then rename the FreeIPA >> domain to something else (renaming would include master-key regeneration >> etc.). >> >> This solves two problems at once: >> - FreeIPA-to-FreeIPA migration >> - FreeIPA domain renaming >> > > There could be some weird side-effects. The certificate subject base > is not changable post-install so you could end up issuing certs with > the subject of the old realm. > > rob There is a set of tickets to be able to change the chaining and rename the root CA. Once this is available I guess we would need to call that too to change the subject and chaining. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Suhail.Choudhury at bskyb.com Mon Jan 20 16:54:08 2014 From: Suhail.Choudhury at bskyb.com (Choudhury, Suhail) Date: Mon, 20 Jan 2014 16:54:08 +0000 Subject: [Freeipa-users] Connecting hosts & DNS from 1 IPA master/domain to another Message-ID: <9769CCE57C8E5A44B968BAB66185113394DC06@WPMBX060.bskyb.com> Hi guys, Nice to meet you all. I need to migrate hosts(host1.domain1.com, host2.domain1.com) and DNS from one IPA master(ipa.domain1.com) to another IPA master(ipa.domain2.com), which will then hold the DNS for both domains(domain1.com and domain2.com) and will become the IPA master for all hosts(host1.domain1.com, host1.domain2.com). Would you say the easiest and hassle-free method of doing this would be to uninstall the IPA client on all hosts on "ipa.domain1.com" and run fresh ipa-client-installs on them to connect them to "ipa.domain2.com" ? I'm following the other "export users/groups" thread on the FreeIPA mailing list but it's not applicable as we currently hold duplicate users/groups on both IPAs. -- Regards, Suhail. DevOps(Recs), BSkyB. Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of British Sky Broadcasting Group plc and Sky International AG and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. From mkosek at redhat.com Mon Jan 20 17:37:46 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 20 Jan 2014 18:37:46 +0100 Subject: [Freeipa-users] Connecting hosts & DNS from 1 IPA master/domain to another In-Reply-To: <9769CCE57C8E5A44B968BAB66185113394DC06@WPMBX060.bskyb.com> References: <9769CCE57C8E5A44B968BAB66185113394DC06@WPMBX060.bskyb.com> Message-ID: <52DD5EEA.4040409@redhat.com> On 01/20/2014 05:54 PM, Choudhury, Suhail wrote: > Hi guys, > > Nice to meet you all. > > I need to migrate hosts(host1.domain1.com, host2.domain1.com) and DNS > from one IPA master(ipa.domain1.com) to another IPA > master(ipa.domain2.com), which will then hold the DNS for both > domains(domain1.com and domain2.com) and will become the IPA master for > all hosts(host1.domain1.com, host1.domain2.com). > > Would you say the easiest and hassle-free method of doing this would be > to uninstall the IPA client on all hosts on "ipa.domain1.com" and run > fresh ipa-client-installs on them to connect them to "ipa.domain2.com" ? Yes, I think this will be indeed the easiest way to go. You will be then able to get all the client configuration updated without risk of forgetting some configuration in case you would try to do it manually. Martin From andrew.tranquada at mailtrust.com Sun Jan 19 02:38:35 2014 From: andrew.tranquada at mailtrust.com (andrew.tranquada at mailtrust.com) Date: Sat, 18 Jan 2014 21:38:35 -0500 (EST) Subject: [Freeipa-users] named unresponsive at seemingly random times Message-ID: <1390099115.03258252@beta.apps.rackspace.com> It seems to be at random and on different servers, but I will see the following in named.run: update_zone (psearch) failed for 'idnsname=example.com,cn=dns,dc=example,dc=com'. Zones can be outdated, run `rndc reload`: bad zone When I see this, I cannot do any dns lookup for records in example.com. In addition, named will not restart, I have to manually kill it and then start it again. Once it is restarted, everything is fine, I can lookup records again. I am looking for suggestions on troubleshooting or if anyone has seen this before and found a resolution. I am running Centos 6.5: 389-ds-base-1.2.11.15-30 bind-dyndb-ldap-2.3-5 bind-libs-9.8.2-0.17.rc1 bind-utils-9.8.2-0.17.rc1 bind-9.8.2-0.17.rc1 Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Jan 21 15:29:38 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 21 Jan 2014 16:29:38 +0100 Subject: [Freeipa-users] named unresponsive at seemingly random times In-Reply-To: <1390099115.03258252@beta.apps.rackspace.com> References: <1390099115.03258252@beta.apps.rackspace.com> Message-ID: <52DE9262.8050008@redhat.com> On 19.1.2014 03:38, andrew.tranquada at mailtrust.com wrote: > It seems to be at random and on different servers, but I will see the following in named.run: > > update_zone (psearch) failed for 'idnsname=example.com,cn=dns,dc=example,dc=com'. Zones can be outdated, run `rndc reload`: bad zone This typically mean that your zone is missing NS or glue records. Did you do some changes in the zone at time when the message appeared? Do you see any errors related to connection between LDAP server and named? Look carefully to /var/log/messages for any other messages from named. > When I see this, I cannot do any dns lookup for records in example.com. In addition, named will not restart, I have to manually kill it and then start it again. Once it is restarted, everything is fine, I can lookup records again. This is really weird. Could you capture stacks at the time when the problem manifests? You can use following commands: $ yum install gdb $ debuginfo-install bind bind-dyndb-ldap $ gdb -ex 'set confirm off' -ex 'set pagination off' -ex 'thread apply all bt full' -ex 'quit' `which named` `pgrep named` > stacktrace.`date +%s`.log 2>&1 Please send the stracktrace file to this list of privately to me and I will look into it. Have a nice day! Petr^2 Spacek > I am looking for suggestions on troubleshooting or if anyone has seen this before and found a resolution. > > I am running Centos 6.5: > 389-ds-base-1.2.11.15-30 > bind-dyndb-ldap-2.3-5 > bind-libs-9.8.2-0.17.rc1 > bind-utils-9.8.2-0.17.rc1 > > bind-9.8.2-0.17.rc1 From andrew.tranquada at mailtrust.com Tue Jan 21 17:13:46 2014 From: andrew.tranquada at mailtrust.com (andrew.tranquada at mailtrust.com) Date: Tue, 21 Jan 2014 12:13:46 -0500 (EST) Subject: [Freeipa-users] named unresponsive at seemingly random times In-Reply-To: <52DE9262.8050008@redhat.com> References: <1390099115.03258252@beta.apps.rackspace.com> <52DE9262.8050008@redhat.com> Message-ID: <1390324426.715712684@beta.apps.rackspace.com> The only thing I see that could be related is: Jan 21 10:31:05 freeipa2 named[20660]: LDAP query timed out. Try to adjust "timeout" parameter and then the message: Jan 21 10:31:05 freeipa2 named[20660]:update_zone (psearch) failed for 'idnsname=example.com,cn=dns,dc=example,dc=com'. Zones can be outdated, run `rndc reload`: timed out However in errors/access log for that 389 instance, I do not see anything around that time. When this happens again I will do what you suggested below (already have the debug packages installed) and will email you. Thanks a TON for your help on this! -----Original Message----- From: "Petr Spacek" Sent: Tuesday, January 21, 2014 10:29am To: andrew.tranquada at mailtrust.com, freeipa-users at redhat.com Subject: Re: [Freeipa-users] named unresponsive at seemingly random times On 19.1.2014 03:38, andrew.tranquada at mailtrust.com wrote: > It seems to be at random and on different servers, but I will see the following in named.run: > > update_zone (psearch) failed for 'idnsname=example.com,cn=dns,dc=example,dc=com'. Zones can be outdated, run `rndc reload`: bad zone This typically mean that your zone is missing NS or glue records. Did you do some changes in the zone at time when the message appeared? Do you see any errors related to connection between LDAP server and named? Look carefully to /var/log/messages for any other messages from named. > When I see this, I cannot do any dns lookup for records in example.com. In addition, named will not restart, I have to manually kill it and then start it again. Once it is restarted, everything is fine, I can lookup records again. This is really weird. Could you capture stacks at the time when the problem manifests? You can use following commands: $ yum install gdb $ debuginfo-install bind bind-dyndb-ldap $ gdb -ex 'set confirm off' -ex 'set pagination off' -ex 'thread apply all bt full' -ex 'quit' `which named` `pgrep named` > stacktrace.`date +%s`.log 2>&1 Please send the stracktrace file to this list of privately to me and I will look into it. Have a nice day! Petr^2 Spacek > I am looking for suggestions on troubleshooting or if anyone has seen this before and found a resolution. > > I am running Centos 6.5: > 389-ds-base-1.2.11.15-30 > bind-dyndb-ldap-2.3-5 > bind-libs-9.8.2-0.17.rc1 > bind-utils-9.8.2-0.17.rc1 > > bind-9.8.2-0.17.rc1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Suhail.Choudhury at bskyb.com Wed Jan 22 12:48:42 2014 From: Suhail.Choudhury at bskyb.com (Choudhury, Suhail) Date: Wed, 22 Jan 2014 12:48:42 +0000 Subject: [Freeipa-users] Export data Message-ID: <9769CCE57C8E5A44B968BAB66185113394E556@WPMBX060.bskyb.com> Hi guys, I trying to get a dump of all users, hosts and DNS entries from IPA so we can run scripts/Puppet against them. Tried searching for it but cannot find anything, so was hoping someone can give some hints on how best to do this please. -- Regards, Suhail. DevOps(Recs), BSkyB. Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of British Sky Broadcasting Group plc and Sky International AG and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. From mkosek at redhat.com Wed Jan 22 13:30:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 22 Jan 2014 14:30:58 +0100 Subject: [Freeipa-users] Export data In-Reply-To: <9769CCE57C8E5A44B968BAB66185113394E556@WPMBX060.bskyb.com> References: <9769CCE57C8E5A44B968BAB66185113394E556@WPMBX060.bskyb.com> Message-ID: <52DFC812.4090907@redhat.com> On 01/22/2014 01:48 PM, Choudhury, Suhail wrote: > Hi guys, > > I trying to get a dump of all users, hosts and DNS entries from IPA so > we can run scripts/Puppet against them. > > Tried searching for it but cannot find anything, so was hoping someone > can give some hints on how best to do this please. > You can either export them via ldapsearch: $ kinit admin $ ldapsearch -h `hostname` -Y GSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com' ... or for write a Python script to do what you want. Very simple example: $ kinit admin $ python >>> from ipalib import api >>> api.bootstrap() >>> api.finalize() >>> api.Backend.xmlclient.connect() >>> users = api.Command.user_find() >>> for user in users['result']:... print "%s:%s:%s" % (user['uid'][0], user['uidnumber'][0], user['gidnumber'][0]) ... admin:1913600000:1913600000 tuser:1913600001:1913600001 Martin From rcritten at redhat.com Wed Jan 22 13:40:02 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 22 Jan 2014 08:40:02 -0500 Subject: [Freeipa-users] Export data In-Reply-To: <52DFC812.4090907@redhat.com> References: <9769CCE57C8E5A44B968BAB66185113394E556@WPMBX060.bskyb.com> <52DFC812.4090907@redhat.com> Message-ID: <52DFCA32.7050005@redhat.com> Martin Kosek wrote: > On 01/22/2014 01:48 PM, Choudhury, Suhail wrote: >> Hi guys, >> >> I trying to get a dump of all users, hosts and DNS entries from IPA so >> we can run scripts/Puppet against them. >> >> Tried searching for it but cannot find anything, so was hoping someone >> can give some hints on how best to do this please. >> > > You can either export them via ldapsearch: > > $ kinit admin > $ ldapsearch -h `hostname` -Y GSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com' > > > ... or for write a Python script to do what you want. Very simple example: > > $ kinit admin > $ python >>>> from ipalib import api >>>> api.bootstrap() >>>> api.finalize() >>>> api.Backend.xmlclient.connect() >>>> users = api.Command.user_find() >>>> for user in users['result']:... print "%s:%s:%s" % (user['uid'][0], > user['uidnumber'][0], user['gidnumber'][0]) > ... > admin:1913600000:1913600000 > tuser:1913600001:1913600001 Be aware that there are some search limits too, both in size and time. Some of this is configurable from the client side, some on the server. rob From pspacek at redhat.com Wed Jan 22 13:52:02 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 22 Jan 2014 14:52:02 +0100 Subject: [Freeipa-users] Export data In-Reply-To: <52DFCA32.7050005@redhat.com> References: <9769CCE57C8E5A44B968BAB66185113394E556@WPMBX060.bskyb.com> <52DFC812.4090907@redhat.com> <52DFCA32.7050005@redhat.com> Message-ID: <52DFCD02.7080607@redhat.com> On 22.1.2014 14:40, Rob Crittenden wrote: > Martin Kosek wrote: >> On 01/22/2014 01:48 PM, Choudhury, Suhail wrote: >>> Hi guys, >>> >>> I trying to get a dump of all users, hosts and DNS entries from IPA so >>> we can run scripts/Puppet against them. >>> >>> Tried searching for it but cannot find anything, so was hoping someone >>> can give some hints on how best to do this please. >>> >> >> You can either export them via ldapsearch: >> >> $ kinit admin >> $ ldapsearch -h `hostname` -Y GSSAPI -b >> 'cn=users,cn=accounts,dc=example,dc=com' >> >> >> ... or for write a Python script to do what you want. Very simple example: >> >> $ kinit admin >> $ python >>>>> from ipalib import api >>>>> api.bootstrap() >>>>> api.finalize() >>>>> api.Backend.xmlclient.connect() >>>>> users = api.Command.user_find() >>>>> for user in users['result']:... print "%s:%s:%s" % (user['uid'][0], >> user['uidnumber'][0], user['gidnumber'][0]) >> ... >> admin:1913600000:1913600000 >> tuser:1913600001:1913600001 > > Be aware that there are some search limits too, both in size and time. Some of > this is configurable from the client side, some on the server. You can use standard zone transfer for DNS: See https://www.redhat.com/archives/freeipa-users/2013-September/msg00022.html https://www.redhat.com/archives/freeipa-users/2013-September/msg00047.html -- Petr^2 Spacek From mitkany at gmail.com Wed Jan 22 17:26:35 2014 From: mitkany at gmail.com (Dimitar Georgievski) Date: Wed, 22 Jan 2014 12:26:35 -0500 Subject: [Freeipa-users] Export data In-Reply-To: <52DFCD02.7080607@redhat.com> References: <9769CCE57C8E5A44B968BAB66185113394E556@WPMBX060.bskyb.com> <52DFC812.4090907@redhat.com> <52DFCA32.7050005@redhat.com> <52DFCD02.7080607@redhat.com> Message-ID: Would you use ldapmodify -f file-name-with-exported-data to import the data back to a new copy of FreeIPA? Thanks Dimitar On Wed, Jan 22, 2014 at 8:52 AM, Petr Spacek wrote: > On 22.1.2014 14:40, Rob Crittenden wrote: > >> Martin Kosek wrote: >> >>> On 01/22/2014 01:48 PM, Choudhury, Suhail wrote: >>> >>>> Hi guys, >>>> >>>> I trying to get a dump of all users, hosts and DNS entries from IPA so >>>> we can run scripts/Puppet against them. >>>> >>>> Tried searching for it but cannot find anything, so was hoping someone >>>> can give some hints on how best to do this please. >>>> >>>> >>> You can either export them via ldapsearch: >>> >>> $ kinit admin >>> $ ldapsearch -h `hostname` -Y GSSAPI -b >>> 'cn=users,cn=accounts,dc=example,dc=com' >>> >>> >>> ... or for write a Python script to do what you want. Very simple >>> example: >>> >>> $ kinit admin >>> $ python >>> >>>> from ipalib import api >>>>>> api.bootstrap() >>>>>> api.finalize() >>>>>> api.Backend.xmlclient.connect() >>>>>> users = api.Command.user_find() >>>>>> for user in users['result']:... print "%s:%s:%s" % >>>>>> (user['uid'][0], >>>>>> >>>>> user['uidnumber'][0], user['gidnumber'][0]) >>> ... >>> admin:1913600000:1913600000 >>> tuser:1913600001:1913600001 >>> >> >> Be aware that there are some search limits too, both in size and time. >> Some of >> this is configurable from the client side, some on the server. >> > > You can use standard zone transfer for DNS: > > See > https://www.redhat.com/archives/freeipa-users/2013-September/msg00022.html > https://www.redhat.com/archives/freeipa-users/2013-September/msg00047.html > > -- > Petr^2 Spacek > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Wed Jan 22 17:57:11 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 22 Jan 2014 18:57:11 +0100 Subject: [Freeipa-users] Export data In-Reply-To: References: <9769CCE57C8E5A44B968BAB66185113394E556@WPMBX060.bskyb.com> <52DFC812.4090907@redhat.com> <52DFCA32.7050005@redhat.com> <52DFCD02.7080607@redhat.com> Message-ID: <52E00677.20504@redhat.com> On 01/22/2014 06:26 PM, Dimitar Georgievski wrote: > Would you use ldapmodify -f file-name-with-exported-data to import the > data back to a new copy of FreeIPA? No, that generally won't work. There's more to IPA than the data in LDAP. Instead of copying data you should install the new server as a replica of the old one. > > Thanks > > Dimitar > > > On Wed, Jan 22, 2014 at 8:52 AM, Petr Spacek > wrote: > > On 22.1.2014 14:40, Rob Crittenden wrote: > > Martin Kosek wrote: > > On 01/22/2014 01:48 PM, Choudhury, Suhail wrote: > > Hi guys, > > I trying to get a dump of all users, hosts and DNS > entries from IPA so > we can run scripts/Puppet against them. > > Tried searching for it but cannot find anything, so was > hoping someone > can give some hints on how best to do this please. > > > You can either export them via ldapsearch: > > $ kinit admin > $ ldapsearch -h `hostname` -Y GSSAPI -b > 'cn=users,cn=accounts,dc=__example,dc=com' > > > ... or for write a Python script to do what you want. Very > simple example: > > $ kinit admin > $ python > > from ipalib import api > api.bootstrap() > api.finalize() > api.Backend.xmlclient.connect(__) > users = api.Command.user_find() > for user in users['result']:... print > "%s:%s:%s" % (user['uid'][0], > > user['uidnumber'][0], user['gidnumber'][0]) > ... > admin:1913600000:1913600000 > tuser:1913600001:1913600001 > > > Be aware that there are some search limits too, both in size and > time. Some of > this is configurable from the client side, some on the server. > > > You can use standard zone transfer for DNS: > > See > https://www.redhat.com/__archives/freeipa-users/2013-__September/msg00022.html > > https://www.redhat.com/__archives/freeipa-users/2013-__September/msg00047.html > > -- Petr? From Steven.Jones at vuw.ac.nz Thu Jan 23 00:11:14 2014 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 23 Jan 2014 00:11:14 +0000 Subject: [Freeipa-users] Staus of RSA and IPA Message-ID: <833D8E48405E064EBC54C84EC6B36E407FBB9290@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, We want to do 2 factor authentication using RSA keys and via IPA. I seem to recall that there was a problem / limitation with Kerberos? Has that been fixed in RHEL6.5? regards Steven Jones Technical Specialist - Linux RHCE Victoria University ITS, Level 8 Rankin Brown Building, Wellington, NZ 6012 0064 4 463 6272 From dpal at redhat.com Thu Jan 23 05:41:59 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 23 Jan 2014 00:41:59 -0500 Subject: [Freeipa-users] Staus of RSA and IPA In-Reply-To: <833D8E48405E064EBC54C84EC6B36E407FBB9290@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E407FBB9290@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <52E0ABA7.6010006@redhat.com> On 01/22/2014 07:11 PM, Steven Jones wrote: > Hi, > > We want to do 2 factor authentication using RSA keys and via IPA. I seem to recall that there was a problem / limitation with Kerberos? Has that been fixed in RHEL6.5? It is coming in 7.1. Upstream in Fedora 21 already has most of support of the OTP workflows. > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University ITS, > > Level 8 Rankin Brown Building, > > Wellington, NZ > > 6012 > > 0064 4 463 6272 > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Thu Jan 23 06:32:07 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 23 Jan 2014 07:32:07 +0100 Subject: [Freeipa-users] Export data In-Reply-To: <52E00677.20504@redhat.com> References: <9769CCE57C8E5A44B968BAB66185113394E556@WPMBX060.bskyb.com> <52DFC812.4090907@redhat.com> <52DFCA32.7050005@redhat.com> <52DFCD02.7080607@redhat.com> <52E00677.20504@redhat.com> Message-ID: <52E0B767.6040908@redhat.com> On 01/22/2014 06:57 PM, Petr Viktorin wrote: > On 01/22/2014 06:26 PM, Dimitar Georgievski wrote: >> Would you use ldapmodify -f file-name-with-exported-data to import the >> data back to a new copy of FreeIPA? > > No, that generally won't work. There's more to IPA than the data in LDAP. > Instead of copying data you should install the new server as a replica of the > old one. That would give you FreeIPA with the same domain, realm or certificate subject name. If you want to start with different settings, I would recommend: 1) Installing new IPA server 2) Using "ipa migrate-ds" command to migrate users and groups 3) Use the ldapsearch&ldapmodify to migrate DNS (you may need to change the DN in the LDIF file to use correct SUFFIX if the realm changed) 4) For all hosts - unenroll and enroll again against the new IPA. This is needed to regenerate the new certificates or host keytab HTH, Martin From craig.freeipa at noboost.org Thu Jan 23 07:05:59 2014 From: craig.freeipa at noboost.org (craig.freeipa at noboost.org) Date: Thu, 23 Jan 2014 18:05:59 +1100 Subject: [Freeipa-users] Certificate format error: [Errno -8018] Message-ID: <20140123070559.GA19915@noboost.org> Hi Guys, I'm sure this is an easy issue to fix! First the specs; Red Hat Enterprise Linux Server release 6.3 (Santiago) ipa-client-2.2.0-16.el6.x86_64 ipa-server-2.2.0-16.el6.x86_64 Issue: When I click on the hosts TAB from inside the Identity Managemnt GUI, I get the following error; * Certificate format error: [Errno -8018] None (repeated many times) * Cannot connect to 'https://sysvm-ipa.teratext.saic.com.au:443/ca/agent/ca/displayBySerial': [Errno -8018] None Also seen this error; cannot connect to 'https://sysvm-ipa.teratext.saic.com.au:443/ca/agent/ca/displayBySerial': [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired. Any advise would be greatly appreciated! cya Craig From abokovoy at redhat.com Thu Jan 23 07:21:07 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 23 Jan 2014 09:21:07 +0200 Subject: [Freeipa-users] Certificate format error: [Errno -8018] In-Reply-To: <20140123070559.GA19915@noboost.org> References: <20140123070559.GA19915@noboost.org> Message-ID: <20140123072107.GG12003@redhat.com> On Thu, 23 Jan 2014, craig.freeipa at noboost.org wrote: >Hi Guys, > >I'm sure this is an easy issue to fix! > >First the specs; >Red Hat Enterprise Linux Server release 6.3 (Santiago) >ipa-client-2.2.0-16.el6.x86_64 >ipa-server-2.2.0-16.el6.x86_64 > > >Issue: >When I click on the hosts TAB from inside the Identity Managemnt GUI, I >get the following error; >* Certificate format error: [Errno -8018] None (repeated many times) > >* Cannot connect to > 'https://sysvm-ipa.teratext.saic.com.au:443/ca/agent/ca/displayBySerial': > [Errno -8018] None > >Also seen this error; >cannot connect to >'https://sysvm-ipa.teratext.saic.com.au:443/ca/agent/ca/displayBySerial': >[Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your >certificate as expired. > > >Any advise would be greatly appreciated! http://www.freeipa.org/page/Howto/CA_Certificate_Renewal Since you have FreeIPA before 3.4, you need to follow manual procedure outlined on that page. 2.2 might also be a bit different than 3.x but this is a starting point. -- / Alexander Bokovoy From rcritten at redhat.com Thu Jan 23 14:21:54 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 23 Jan 2014 09:21:54 -0500 Subject: [Freeipa-users] Certificate format error: [Errno -8018] In-Reply-To: <20140123072107.GG12003@redhat.com> References: <20140123070559.GA19915@noboost.org> <20140123072107.GG12003@redhat.com> Message-ID: <52E12582.6000308@redhat.com> Alexander Bokovoy wrote: > On Thu, 23 Jan 2014, craig.freeipa at noboost.org wrote: >> Hi Guys, >> >> I'm sure this is an easy issue to fix! >> >> First the specs; >> Red Hat Enterprise Linux Server release 6.3 (Santiago) >> ipa-client-2.2.0-16.el6.x86_64 >> ipa-server-2.2.0-16.el6.x86_64 >> >> >> Issue: >> When I click on the hosts TAB from inside the Identity Managemnt GUI, I >> get the following error; >> * Certificate format error: [Errno -8018] None (repeated many times) >> >> * Cannot connect to >> 'https://sysvm-ipa.teratext.saic.com.au:443/ca/agent/ca/displayBySerial': >> >> [Errno -8018] None >> >> Also seen this error; >> cannot connect to >> 'https://sysvm-ipa.teratext.saic.com.au:443/ca/agent/ca/displayBySerial': >> [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your >> certificate as expired. >> >> >> Any advise would be greatly appreciated! > http://www.freeipa.org/page/Howto/CA_Certificate_Renewal > > Since you have FreeIPA before 3.4, you need to follow manual procedure > outlined on that page. 2.2 might also be a bit different than 3.x but > this is a starting point. > > For 2.x you want http://www.freeipa.org/page/IPA_2x_Certificate_Renewal rob From mitkany at gmail.com Thu Jan 23 16:03:37 2014 From: mitkany at gmail.com (Dimitar Georgievski) Date: Thu, 23 Jan 2014 11:03:37 -0500 Subject: [Freeipa-users] Export data In-Reply-To: <52E0B767.6040908@redhat.com> References: <9769CCE57C8E5A44B968BAB66185113394E556@WPMBX060.bskyb.com> <52DFC812.4090907@redhat.com> <52DFCA32.7050005@redhat.com> <52DFCD02.7080607@redhat.com> <52E00677.20504@redhat.com> <52E0B767.6040908@redhat.com> Message-ID: In my case DNS is not an issue, FreeIPA is integrated with existing DNS servers. The above procedure would work for migrating the user's data to a new IPA server that has a new host name. What if I would like to restore the original IPA server ? Could I repeat the above steps with the exception of #4, in which I would restore backed-up certificates and keytab files. This should avoid the need to regenerate them, no? In short how would you perform a full back-up and restore of the Primary IPA server? I understand this is not a trivial task for the IPA server and from what I've learned it is probably not fully supported in the current ver 3.x Thanks, Dimitar On Thu, Jan 23, 2014 at 1:32 AM, Martin Kosek wrote: > On 01/22/2014 06:57 PM, Petr Viktorin wrote: > > On 01/22/2014 06:26 PM, Dimitar Georgievski wrote: > >> Would you use ldapmodify -f file-name-with-exported-data to import the > >> data back to a new copy of FreeIPA? > > > > No, that generally won't work. There's more to IPA than the data in LDAP. > > Instead of copying data you should install the new server as a replica > of the > > old one. > > That would give you FreeIPA with the same domain, realm or certificate > subject > name. > > If you want to start with different settings, I would recommend: > > 1) Installing new IPA server > 2) Using "ipa migrate-ds" command to migrate users and groups > 3) Use the ldapsearch&ldapmodify to migrate DNS (you may need to change > the DN > in the LDIF file to use correct SUFFIX if the realm changed) > 4) For all hosts - unenroll and enroll again against the new IPA. This is > needed to regenerate the new certificates or host keytab > > HTH, > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kifal75 at hotmail.com Thu Jan 23 20:00:15 2014 From: kifal75 at hotmail.com (Zulkifal Ahmad) Date: Thu, 23 Jan 2014 20:00:15 +0000 Subject: [Freeipa-users] ipa AD trust issue In-Reply-To: References: Message-ID: Hi , In reference to the following thread, I already have an entry for AD sever in the /etc/hosts file of ipaserver but the issue still remains. Both my DNS servers are resolving the records from the opposite side. Any other suggestionsto remove this error ? root at ipaserver # ipa trust-add --type=ad adexample.com --admin Administrator --password ipa: ERROR: CIFS server communication error: code "-1073741801", message "Memory allocation error" (both may be "None") Thanks Zulkifal Ahmad On 01/17/2014 06:29 PM, Zulkifal Ahmad wrote: > Hi List , Just wanted to find out if anyone has setup an ipa-AD trust > successfully, According to the instructions in the following link > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-ipa-subdomain.html > everything went well until I hit the point where I had to check the > samba configuration, by typing the command > root at ipaserver # smbclient -L > ipaserver.ipaexample.com -k > smbclient: command not found > and similar for > root at ipaserver # wbinfo --online-status > wbinfo: command not found > > I am pretty sure that the command "ipa-trust-install" command did > install samba4 packages as dependencies, anyways I thought these > packages were not necessary and went forward until I got really stuck > when I typed the command . > root at ipaserver # ipa trust-add --type=ad > adexample.com --admin Administrator --password > This gave me a very cruel message > ipa: ERROR: CIFS server communication error: code "-1073741801", > message "Memory allocation error" (both may be "None") > If its this bug " https://bugzilla.redhat.com/show_bug.cgi?id=878168 " Yes. The solution is: If configured, the Active Directory (AD) DNS server returns IPv4 and IPv6 addresses of an AD server. If the FreeIPA server cannot connect to the AD server with an IPv6 address, running the ipa trust-add command will fail even if it would be possible to use IPv4. To work around this problem, add the IPv4 address of the AD server to the /etc/hosts file. In this case, the FreeIPA server will use only the IPv4 address and executing ipa trust-add will be successful. > has anyone worked it out. Secondly cifs-utils has dependency on samba3 > packages and ipa-ad-trust needs samba4 but samba3 and samba4 don't > like each other , so this is the story of my experience with ipa. Any > suggestions ? Why do you need cifs-utils on the same server? cifs-utils to make a system a client to MSFT file server, AFAIU you cant make IPA server to be a cifs client. SSSD 1.12 (in works) if going to be capable to work with cifs-utils instead of samba winbind thus the limitation will be lifted. > My ipa server server OS : CentOS 6.5 > ipa server version : 3 > Active directory: server 2008 R2 Standard > > Thank you > */ Best Regards/* > // > /Sahibzada .Z. Ahmad/ > /System Administrator/* > * Best Regards Sahibzada .Z. Ahmad System Administrator cell: 1(678)267-0265 (US) cell: 1(647)339-5434 (Canada) -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Jan 23 20:17:01 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 23 Jan 2014 22:17:01 +0200 Subject: [Freeipa-users] ipa AD trust issue In-Reply-To: References: Message-ID: <20140123201701.GP12003@redhat.com> On Thu, 23 Jan 2014, Zulkifal Ahmad wrote: >Hi , In reference to the following thread, I already have an entry for AD sever in the /etc/hosts file of ipaserver but the issue still remains. Both my DNS servers are resolving the records from the opposite side. Any other suggestionsto remove this error ? > >root at ipaserver # ipa trust-add --type=ad > adexample.com --admin Administrator --password > > >ipa: ERROR: CIFS server communication error: code "-1073741801", >message "Memory allocation error" (both may be "None") Add 'log level = 100' to /usr/share/ipa/smb.conf.empty in [global] section and try again. You'll get SMB traffic debugging in /var/log/httpd/error_log. Adding and removing 'log level = 100' to /usr/share/ipa/smb.conf.empty does not require restarting httpd. > > > >Thanks > >Zulkifal Ahmad > > > > >On 01/17/2014 06:29 PM, Zulkifal Ahmad wrote: >> Hi List , Just wanted to find out if anyone has setup an ipa-AD trust >> successfully, According to the instructions in the following link >> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-ipa-subdomain.html >> everything went well until I hit the point where I had to check the >> samba configuration, by typing the command >> root at ipaserver # smbclient -L >> ipaserver.ipaexample.com -k >> smbclient: command not found >> and similar for >> root at ipaserver # wbinfo --online-status >> wbinfo: command not found >> >> I am pretty sure that the command "ipa-trust-install" command did >> install samba4 packages as dependencies, anyways I thought these >> packages were not necessary and went forward until I got really stuck >> when I typed the command . >> root at ipaserver # ipa trust-add --type=ad >> adexample.com --admin Administrator --password >> This gave me a very cruel message >> ipa: ERROR: CIFS server communication error: code "-1073741801", >> message "Memory allocation error" (both may be "None") >> If its this bug " https://bugzilla.redhat.com/show_bug.cgi?id=878168 " > >Yes. The solution is: > >If configured, the Active Directory (AD) DNS server returns IPv4 and >IPv6 addresses of an AD server. If the FreeIPA server cannot connect to >the AD server with an IPv6 address, running the ipa trust-add command >will fail even if it would be possible to use IPv4. To work around this >problem, add the IPv4 address of the AD server to the /etc/hosts file. >In this case, the FreeIPA server will use only the IPv4 address and >executing ipa trust-add will be successful. > >> has anyone worked it out. Secondly cifs-utils has dependency on samba3 >> packages and ipa-ad-trust needs samba4 but samba3 and samba4 don't >> like each other , so this is the story of my experience with ipa. Any >> suggestions ? > >Why do you need cifs-utils on the same server? >cifs-utils to make a system a client to MSFT file server, AFAIU you cant >make IPA server to be a cifs client. > >SSSD 1.12 (in works) if going to be capable to work with cifs-utils >instead of samba winbind thus the limitation will be lifted. > > >> My ipa server server OS : CentOS 6.5 >> ipa server version : 3 >> Active directory: server 2008 R2 Standard >> >> Thank you >> */ Best Regards/* >> // >> /Sahibzada .Z. Ahmad/ >> /System Administrator/* >> * > > > Best Regards > >Sahibzada .Z. Ahmad >System Administrator >cell: 1(678)267-0265 (US) >cell: 1(647)339-5434 (Canada) > > > > > > > > > >_______________________________________________ >Freeipa-users mailing list >Freeipa-users at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-users -- / Alexander Bokovoy From mkosek at redhat.com Fri Jan 24 08:12:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 24 Jan 2014 09:12:55 +0100 Subject: [Freeipa-users] Export data In-Reply-To: References: <9769CCE57C8E5A44B968BAB66185113394E556@WPMBX060.bskyb.com> <52DFC812.4090907@redhat.com> <52DFCA32.7050005@redhat.com> <52DFCD02.7080607@redhat.com> <52E00677.20504@redhat.com> <52E0B767.6040908@redhat.com> Message-ID: <52E22087.9000904@redhat.com> Dimitar, this is actually a very good question. Our team have been discussing the best way to back and restore a FreeIPA infrastructure for some time. In FreeIPA 3.2, we introduced ipa-backup and ipa-restore scripts which we are evaluating, but we still think that the best way to backup and restore may be simply creating replicas and/or system snapshots You can read full details in this article: http://www.freeipa.org/page/Backup_and_Restore Feedback welcome, Martin On 01/23/2014 05:03 PM, Dimitar Georgievski wrote: > In my case DNS is not an issue, FreeIPA is integrated with existing DNS > servers. > > The above procedure would work for migrating the user's data to a new IPA > server that has a new host name. What if I would like to restore the > original IPA server ? Could I repeat the above steps with the exception of > #4, in which I would restore backed-up certificates and keytab files. This > should avoid the need to regenerate them, no? > > In short how would you perform a full back-up and restore of the Primary > IPA server? I understand this is not a trivial task for the IPA server and > from what I've learned it is probably not fully supported in the current > ver 3.x > > > Thanks, > > Dimitar > > > > On Thu, Jan 23, 2014 at 1:32 AM, Martin Kosek wrote: > >> On 01/22/2014 06:57 PM, Petr Viktorin wrote: >>> On 01/22/2014 06:26 PM, Dimitar Georgievski wrote: >>>> Would you use ldapmodify -f file-name-with-exported-data to import the >>>> data back to a new copy of FreeIPA? >>> >>> No, that generally won't work. There's more to IPA than the data in LDAP. >>> Instead of copying data you should install the new server as a replica >> of the >>> old one. >> >> That would give you FreeIPA with the same domain, realm or certificate >> subject >> name. >> >> If you want to start with different settings, I would recommend: >> >> 1) Installing new IPA server >> 2) Using "ipa migrate-ds" command to migrate users and groups >> 3) Use the ldapsearch&ldapmodify to migrate DNS (you may need to change >> the DN >> in the LDIF file to use correct SUFFIX if the realm changed) >> 4) For all hosts - unenroll and enroll again against the new IPA. This is >> needed to regenerate the new certificates or host keytab >> >> HTH, >> Martin >> > From mkosek at redhat.com Fri Jan 24 08:17:59 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 24 Jan 2014 09:17:59 +0100 Subject: [Freeipa-users] Backup and restore article Message-ID: <52E221B7.1060403@redhat.com> Our team have been discussing the best way to back and restore a FreeIPA infrastructure for some time. In FreeIPA 3.2, we introduced ipa-backup and ipa-restore scripts which we are evaluating (and welcome feedback from real user deployments), but we still think that the best way to backup and restore may be simply creating multiple FreeIPA replicas and/or system snapshots. We have created an article on this subject, which discusses this topic, shows various backup and restore user cases and presents our recommendations: http://www.freeipa.org/page/Backup_and_Restore We welcome feedback and discussion on the topic of back up restore, how our users think that backup and restore should be done or if you do backup and restore in any custom way already. This input is useful for us to plan the next steps with backup and restore in FreeIPA. Thank you. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From matthew.symonds at switchconcepts.com Fri Jan 24 11:41:21 2014 From: matthew.symonds at switchconcepts.com (Matthew Symonds) Date: Fri, 24 Jan 2014 11:41:21 +0000 Subject: [Freeipa-users] Change FreeIPA Domain Message-ID: Hi All, Is it possible to change the Domain/Realm on FreeIPA v3.0.0 (Centos 6) If not is there any way to migrate users from one domain to another? Thanks in advance Matt Symonds -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Jan 24 14:20:25 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 24 Jan 2014 09:20:25 -0500 Subject: [Freeipa-users] Change FreeIPA Domain In-Reply-To: References: Message-ID: <52E276A9.7070302@redhat.com> Matthew Symonds wrote: > Hi All, > > Is it possible to change the Domain/Realm on FreeIPA v3.0.0 (Centos 6) Not currently. > > If not is there any way to migrate users from one domain to another? See ipa migrate-ds --help rob From matthew.symonds at switchconcepts.com Fri Jan 24 14:46:13 2014 From: matthew.symonds at switchconcepts.com (Matthew Symonds) Date: Fri, 24 Jan 2014 14:46:13 +0000 Subject: [Freeipa-users] Change FreeIPA Domain In-Reply-To: <52E276A9.7070302@redhat.com> References: <52E276A9.7070302@redhat.com> Message-ID: Thanks. I had spent quite some time looking without any luck. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kifal75 at hotmail.com Fri Jan 24 16:32:33 2014 From: kifal75 at hotmail.com (Zulkifal Ahmad) Date: Fri, 24 Jan 2014 16:32:33 +0000 Subject: [Freeipa-users] Ipa AD trust Message-ID: Hi List , I want an update on this bug . https://bugzilla.samba.org/show_bug.cgi?id=9618 Thanks Best Regards Sahibzada .Z. Ahmad System Administrator -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Fri Jan 24 17:03:38 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 24 Jan 2014 18:03:38 +0100 Subject: [Freeipa-users] Ipa AD trust In-Reply-To: References: Message-ID: <20140124170338.GH2834@localhost.localdomain> On Fri, Jan 24, 2014 at 04:32:33PM +0000, Zulkifal Ahmad wrote: > Hi List , I want an update on this bug . > > https://bugzilla.samba.org/show_bug.cgi?id=9618 I just re-tested with the python script from the ticket and Samba-4.1.3 and it seems to be fixed. HTH bye, Sumit > > Thanks > > > Best Regards > > Sahibzada .Z. Ahmad > System Administrator > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Fri Jan 24 17:28:00 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 24 Jan 2014 12:28:00 -0500 Subject: [Freeipa-users] Change FreeIPA Domain In-Reply-To: <52E276A9.7070302@redhat.com> References: <52E276A9.7070302@redhat.com> Message-ID: <52E2A2A0.1010409@redhat.com> On 01/24/2014 09:20 AM, Rob Crittenden wrote: > Matthew Symonds wrote: >> Hi All, >> >> Is it possible to change the Domain/Realm on FreeIPA v3.0.0 (Centos 6) > > Not currently. Should we consider RFE or it is easier to reinstall and import? I suspect the latter but wanted to double check. Ate least we should probably have a ticket to provide ipa migrate-ipa command to migrate all known data from one instance to another > >> >> If not is there any way to migrate users from one domain to another? > > See ipa migrate-ds --help > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From bret.wortman at damascusgrp.com Mon Jan 27 00:51:55 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Sun, 26 Jan 2014 19:51:55 -0500 Subject: [Freeipa-users] CS.cfg empty Message-ID: We had to reboot the IPA server on a standalone network recently, and this IPA server is the only one on that network; there are no replicas. Upon restarting, the IPA software refused to start because, after a couple hours of tracking things down, our /etc/pki-ca/CS.cfg file is zero-length. How can I most easily restore this file given that I doubt we have a backup (our bad)? Is there a way to basically reinstall the server without losing the data in the database? Our users and host definitions, anyway? Thanks! Bret -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4905 bytes Desc: not available URL: From mkosek at redhat.com Mon Jan 27 09:10:25 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 27 Jan 2014 10:10:25 +0100 Subject: [Freeipa-users] Change FreeIPA Domain In-Reply-To: <52E2A2A0.1010409@redhat.com> References: <52E276A9.7070302@redhat.com> <52E2A2A0.1010409@redhat.com> Message-ID: <52E62281.6070305@redhat.com> On 01/24/2014 06:28 PM, Dmitri Pal wrote: > On 01/24/2014 09:20 AM, Rob Crittenden wrote: >> Matthew Symonds wrote: ... > Ate least we should probably have a ticket to provide > ipa migrate-ipa command to migrate all known data from one instance to > another I think this existent ticket should suffice: https://fedorahosted.org/freeipa/ticket/3656 Martin From mkosek at redhat.com Mon Jan 27 09:14:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 27 Jan 2014 10:14:55 +0100 Subject: [Freeipa-users] CS.cfg empty In-Reply-To: References: Message-ID: <52E6238F.6080907@redhat.com> On 01/27/2014 01:51 AM, Bret Wortman wrote: > We had to reboot the IPA server on a standalone network recently, and this IPA server is the only one on that network; there are no replicas. Upon restarting, the IPA software refused to start because, after a couple hours of tracking things down, our /etc/pki-ca/CS.cfg file is zero-length. > > How can I most easily restore this file given that I doubt we have a backup (our bad)? Is there a way to basically reinstall the server without losing the data in the database? Our users and host definitions, anyway? > > Thanks! > > > Bret Hello Bret, Sorry to hear that. It looks like something (PKI?) was writing to the CS.cfg while the IPA server restarted. What version of IPA and PKI are we talking about? Do you have any other PKI server with CA you can use as a source of the CS.cfg file or as a replica to reinstall the IPA server with CA from (in the worst case)? I am adding PKI developers to the CC to advise. Martin From bret.wortman at damascusgrp.com Mon Jan 27 11:17:48 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 27 Jan 2014 06:17:48 -0500 Subject: [Freeipa-users] CS.cfg empty In-Reply-To: <52E6238F.6080907@redhat.com> References: <52E6238F.6080907@redhat.com> Message-ID: <52E6405C.6070205@damascusgrp.com> Martin, The only other systems I have running IPA are on another network. I could take their CS.cfg file and try to modify it to fit what this one should have had, but that's my only option. On the up side, this is a relatively small network, and reinstating the users and hosts won't be an enormous task. Big, but not enormous. And I should have had a backup, especially knowing there was a scheduled power outage coming up. Because those are always problem-free.... ;-) Bret On 01/27/2014 04:14 AM, Martin Kosek wrote: > On 01/27/2014 01:51 AM, Bret Wortman wrote: >> We had to reboot the IPA server on a standalone network recently, and this IPA server is the only one on that network; there are no replicas. Upon restarting, the IPA software refused to start because, after a couple hours of tracking things down, our /etc/pki-ca/CS.cfg file is zero-length. >> >> How can I most easily restore this file given that I doubt we have a backup (our bad)? Is there a way to basically reinstall the server without losing the data in the database? Our users and host definitions, anyway? >> >> Thanks! >> >> >> Bret > Hello Bret, > > Sorry to hear that. It looks like something (PKI?) was writing to the CS.cfg > while the IPA server restarted. What version of IPA and PKI are we talking about? > > Do you have any other PKI server with CA you can use as a source of the CS.cfg > file or as a replica to reinstall the IPA server with CA from (in the worst case)? > > I am adding PKI developers to the CC to advise. > > Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From alee at redhat.com Mon Jan 27 16:31:52 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 27 Jan 2014 11:31:52 -0500 Subject: [Freeipa-users] CS.cfg empty In-Reply-To: <52E6405C.6070205@damascusgrp.com> References: <52E6238F.6080907@redhat.com> <52E6405C.6070205@damascusgrp.com> Message-ID: <1390840312.24846.12.camel@aleeredhat.laptop> Bret, What version is the Dogtag instance on that server? (rpm -q pki-ca) We have seen cases when the CS.cfg has zero length - and have modified code to: 1) not write to CS.cfg on startup 2) backup the CS.cfg on upgrades. Under normal operations, unless you are configuring the Dogtag instance - which would not be happening during normal IPA operations, the CS.cfg should not be written to. Is there perhaps a backup of CS.cfg under /etc/pki/pki-tomcat/ca (assuming this is Dogtag 10) or under /var/log/pki/server/upgrade ? Ade On Mon, 2014-01-27 at 06:17 -0500, Bret Wortman wrote: > Martin, > > The only other systems I have running IPA are on another network. I > could take their CS.cfg file and try to modify it to fit what this one > should have had, but that's my only option. > > On the up side, this is a relatively small network, and reinstating the > users and hosts won't be an enormous task. Big, but not enormous. And I > should have had a backup, especially knowing there was a scheduled power > outage coming up. Because those are always problem-free.... ;-) > > > Bret > > On 01/27/2014 04:14 AM, Martin Kosek wrote: > > On 01/27/2014 01:51 AM, Bret Wortman wrote: > >> We had to reboot the IPA server on a standalone network recently, and this IPA server is the only one on that network; there are no replicas. Upon restarting, the IPA software refused to start because, after a couple hours of tracking things down, our /etc/pki-ca/CS.cfg file is zero-length. > >> > >> How can I most easily restore this file given that I doubt we have a backup (our bad)? Is there a way to basically reinstall the server without losing the data in the database? Our users and host definitions, anyway? > >> > >> Thanks! > >> > >> > >> Bret > > Hello Bret, > > > > Sorry to hear that. It looks like something (PKI?) was writing to the CS.cfg > > while the IPA server restarted. What version of IPA and PKI are we talking about? > > > > Do you have any other PKI server with CA you can use as a source of the CS.cfg > > file or as a replica to reinstall the IPA server with CA from (in the worst case)? > > > > I am adding PKI developers to the CC to advise. > > > > Martin > > From bret.wortman at damascusgrp.com Mon Jan 27 19:00:46 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 27 Jan 2014 14:00:46 -0500 Subject: [Freeipa-users] CS.cfg empty In-Reply-To: <1390840312.24846.12.camel@aleeredhat.laptop> References: <52E6238F.6080907@redhat.com> <52E6405C.6070205@damascusgrp.com> <1390840312.24846.12.camel@aleeredhat.laptop> Message-ID: <52E6ACDE.30206@damascusgrp.com> # rpm -q pki-ca pki-ca-10.0.6-1.fc18.noarch There were versions found under two other locations (it may have been these -- we had to nuke the box and start over, so the filesystem isn't in the same state it was when this began). I tried starting the service with each of them but neither worked. We've built a new server and will be replicating this one so that this doesn't happen again. We hope.... Bret On 01/27/2014 11:31 AM, Ade Lee wrote: > Bret, > > What version is the Dogtag instance on that server? (rpm -q pki-ca) > > We have seen cases when the CS.cfg has zero length - and have modified > code to: > 1) not write to CS.cfg on startup > 2) backup the CS.cfg on upgrades. > > Under normal operations, unless you are configuring the Dogtag instance > - which would not be happening during normal IPA operations, the CS.cfg > should not be written to. > > Is there perhaps a backup of CS.cfg under /etc/pki/pki-tomcat/ca > (assuming this is Dogtag 10) or under /var/log/pki/server/upgrade ? > > Ade > > On Mon, 2014-01-27 at 06:17 -0500, Bret Wortman wrote: >> Martin, >> >> The only other systems I have running IPA are on another network. I >> could take their CS.cfg file and try to modify it to fit what this one >> should have had, but that's my only option. >> >> On the up side, this is a relatively small network, and reinstating the >> users and hosts won't be an enormous task. Big, but not enormous. And I >> should have had a backup, especially knowing there was a scheduled power >> outage coming up. Because those are always problem-free.... ;-) >> >> >> Bret >> >> On 01/27/2014 04:14 AM, Martin Kosek wrote: >>> On 01/27/2014 01:51 AM, Bret Wortman wrote: >>>> We had to reboot the IPA server on a standalone network recently, and this IPA server is the only one on that network; there are no replicas. Upon restarting, the IPA software refused to start because, after a couple hours of tracking things down, our /etc/pki-ca/CS.cfg file is zero-length. >>>> >>>> How can I most easily restore this file given that I doubt we have a backup (our bad)? Is there a way to basically reinstall the server without losing the data in the database? Our users and host definitions, anyway? >>>> >>>> Thanks! >>>> >>>> >>>> Bret >>> Hello Bret, >>> >>> Sorry to hear that. It looks like something (PKI?) was writing to the CS.cfg >>> while the IPA server restarted. What version of IPA and PKI are we talking about? >>> >>> Do you have any other PKI server with CA you can use as a source of the CS.cfg >>> file or as a replica to reinstall the IPA server with CA from (in the worst case)? >>> >>> I am adding PKI developers to the CC to advise. >>> >>> Martin >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From craig.freeipa at noboost.org Tue Jan 28 06:56:28 2014 From: craig.freeipa at noboost.org (craig.freeipa at noboost.org) Date: Tue, 28 Jan 2014 17:56:28 +1100 Subject: [Freeipa-users] Certificate format error: [Errno -8018] In-Reply-To: <52E12582.6000308@redhat.com> References: <20140123070559.GA19915@noboost.org> <20140123072107.GG12003@redhat.com> <52E12582.6000308@redhat.com> Message-ID: <20140128065628.GA19297@noboost.org> On Thu, Jan 23, 2014 at 09:21:54AM -0500, Rob Crittenden wrote: > Alexander Bokovoy wrote: > >On Thu, 23 Jan 2014, craig.freeipa at noboost.org wrote: > >>Hi Guys, > >> > >>I'm sure this is an easy issue to fix! > >> > >>First the specs; > >>Red Hat Enterprise Linux Server release 6.3 (Santiago) > >>ipa-client-2.2.0-16.el6.x86_64 > >>ipa-server-2.2.0-16.el6.x86_64 > >> > >> > >>Issue: > >>When I click on the hosts TAB from inside the Identity Managemnt GUI, I > >>get the following error; > >>* Certificate format error: [Errno -8018] None (repeated many times) > >> > >>* Cannot connect to > >> 'https://sysvm-ipa.teratext.saic.com.au:443/ca/agent/ca/displayBySerial': > >> > >> [Errno -8018] None > >> > >>Also seen this error; > >>cannot connect to > >>'https://sysvm-ipa.teratext.saic.com.au:443/ca/agent/ca/displayBySerial': > >>[Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your > >>certificate as expired. > >> > >> > >>Any advise would be greatly appreciated! > >http://www.freeipa.org/page/Howto/CA_Certificate_Renewal > > > >Since you have FreeIPA before 3.4, you need to follow manual procedure > >outlined on that page. 2.2 might also be a bit different than 3.x but > >this is a starting point. > > > > > > For 2.x you want http://www.freeipa.org/page/IPA_2x_Certificate_Renewal > > rob > Just running into a couple of issues with then manual SSL cert process; 1) ERROR when telling certmonger about all the CA certificates #Command: for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" do echo $nickname certutil -L -d /var/lib/pki-ca/alias -n "${nickname}" | grep -i after done #Result: auditSigningCert cert-pki-ca Not After : Tue Jan 14 06:45:05 2014 ocspSigningCert cert-pki-ca Not After : Tue Jan 14 06:45:05 2014 subsystemCert cert-pki-ca Not After : Tue Jan 14 06:45:05 2014 Server-Cert cert-pki-ca Not After : Tue Jan 14 06:45:05 2014 #Command: for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" do /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n "${nickname}" -c dogtag-ipa-renew-agent -P 705114231111 done #Result: No CA with name "dogtag-ipa-renew-agent" found. No CA with name "dogtag-ipa-renew-agent" found. No CA with name "dogtag-ipa-renew-agent" found. No CA with name "dogtag-ipa-renew-agent" found. 2)Upgrade instead? I could potentionally upgrade the ipa-server to "3.0.0-37.el6", would this version be able to automatically update the certificates? cya Craig From mkosek at redhat.com Tue Jan 28 07:27:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 28 Jan 2014 08:27:43 +0100 Subject: [Freeipa-users] CS.cfg empty In-Reply-To: <52E6ACDE.30206@damascusgrp.com> References: <52E6238F.6080907@redhat.com> <52E6405C.6070205@damascusgrp.com> <1390840312.24846.12.camel@aleeredhat.laptop> <52E6ACDE.30206@damascusgrp.com> Message-ID: <52E75BEF.7050006@redhat.com> Ok, thanks for info. In case you find out the root cause that could help us fix IPA/PKI, please reach back to us. Martin On 01/27/2014 08:00 PM, Bret Wortman wrote: > # rpm -q pki-ca > pki-ca-10.0.6-1.fc18.noarch > > There were versions found under two other locations (it may have been these -- > we had to nuke the box and start over, so the filesystem isn't in the same > state it was when this began). I tried starting the service with each of them > but neither worked. > > We've built a new server and will be replicating this one so that this doesn't > happen again. We hope.... > > > Bret > > On 01/27/2014 11:31 AM, Ade Lee wrote: >> Bret, >> >> What version is the Dogtag instance on that server? (rpm -q pki-ca) >> >> We have seen cases when the CS.cfg has zero length - and have modified >> code to: >> 1) not write to CS.cfg on startup >> 2) backup the CS.cfg on upgrades. >> >> Under normal operations, unless you are configuring the Dogtag instance >> - which would not be happening during normal IPA operations, the CS.cfg >> should not be written to. >> >> Is there perhaps a backup of CS.cfg under /etc/pki/pki-tomcat/ca >> (assuming this is Dogtag 10) or under /var/log/pki/server/upgrade ? >> >> Ade >> >> On Mon, 2014-01-27 at 06:17 -0500, Bret Wortman wrote: >>> Martin, >>> >>> The only other systems I have running IPA are on another network. I >>> could take their CS.cfg file and try to modify it to fit what this one >>> should have had, but that's my only option. >>> >>> On the up side, this is a relatively small network, and reinstating the >>> users and hosts won't be an enormous task. Big, but not enormous. And I >>> should have had a backup, especially knowing there was a scheduled power >>> outage coming up. Because those are always problem-free.... ;-) >>> >>> >>> Bret >>> >>> On 01/27/2014 04:14 AM, Martin Kosek wrote: >>>> On 01/27/2014 01:51 AM, Bret Wortman wrote: >>>>> We had to reboot the IPA server on a standalone network recently, and this >>>>> IPA server is the only one on that network; there are no replicas. Upon >>>>> restarting, the IPA software refused to start because, after a couple >>>>> hours of tracking things down, our /etc/pki-ca/CS.cfg file is zero-length. >>>>> >>>>> How can I most easily restore this file given that I doubt we have a >>>>> backup (our bad)? Is there a way to basically reinstall the server without >>>>> losing the data in the database? Our users and host definitions, anyway? >>>>> >>>>> Thanks! >>>>> >>>>> >>>>> Bret >>>> Hello Bret, >>>> >>>> Sorry to hear that. It looks like something (PKI?) was writing to the CS.cfg >>>> while the IPA server restarted. What version of IPA and PKI are we talking >>>> about? >>>> >>>> Do you have any other PKI server with CA you can use as a source of the CS.cfg >>>> file or as a replica to reinstall the IPA server with CA from (in the worst >>>> case)? >>>> >>>> I am adding PKI developers to the CC to advise. >>>> >>>> Martin >>> >> > > From Suhail.Choudhury at bskyb.com Tue Jan 28 11:43:38 2014 From: Suhail.Choudhury at bskyb.com (Choudhury, Suhail) Date: Tue, 28 Jan 2014 11:43:38 +0000 Subject: [Freeipa-users] Export DNS to external Message-ID: <9769CCE57C8E5A44B968BAB6618511339507F7@WPMBX060.bskyb.com> Hi, We are looking at adding redundancy to our IPA setup by using DNS servers external to our IPA servers, so in the event of IPA dying we can still resolve against these external DNS servers. So I'm looking at how I can add a server running BIND as a DNS slave. Normally on a DNS slave we can set something like the following in named.conf: ========================================= // query-source address * port 53; allow-transfer {208.99.198.184/32;}; }; // // a caching only nameserver config // controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; }; }; zone "localhost" IN { type master; file "localhost.zone"; allow-update { none; }; }; zone "yourdomain.com" IN { type slave; file "/var/named/yourdomain.com.zone"; // allow-update { none; }; allow-transfer { 192.168.0.1/32; }; masters { 192.168.0.1; }; }; zone "0.168.192.in-addr.arpa" IN { type slave; file "/var/named/0.168.192.rev"; // allow-update { none; }; allow-transfer { 192.168.0.1/32; }; masters { 192.168.0.1; }; }; ========================================= In the IPA server's named.conf I see DNS entries are loaded up via LDAP: ========================================= include "/etc/named.rfc1912.zones"; dynamic-db "ipa" { library "ldap.so"; arg "uri ldapi://%2fvar%2frun%2fslapd-SUB-DOMAIN-COM.socket"; arg "base cn=dns, dc=sub,dc=domain,dc=com"; arg "fake_mname ipa01.sub.domain.com."; arg "auth_method sasl"; arg "sasl_mech GSSAPI"; arg "sasl_user DNS/ipa01.sub.domain.com"; arg "zone_refresh 0"; arg "psearch yes"; arg "connections 4"; arg "serial_autoincrement yes"; }; ========================================= Has anyone successfully pulled DNS zones out of IPA to BIND slaves? -- Regards, Suhail. DevOps(Recs), BSkyB. Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of British Sky Broadcasting Group plc and Sky International AG and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. From abokovoy at redhat.com Tue Jan 28 11:52:05 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 28 Jan 2014 13:52:05 +0200 Subject: [Freeipa-users] Export DNS to external In-Reply-To: <9769CCE57C8E5A44B968BAB6618511339507F7@WPMBX060.bskyb.com> References: <9769CCE57C8E5A44B968BAB6618511339507F7@WPMBX060.bskyb.com> Message-ID: <20140128115205.GE7586@redhat.com> On Tue, 28 Jan 2014, Choudhury, Suhail wrote: >Hi, > >We are looking at adding redundancy to our IPA setup by using DNS >servers external to our IPA servers, so in the event of IPA dying we can >still resolve against these external DNS servers. > >So I'm looking at how I can add a server running BIND as a DNS slave. We have this presentation: http://www.freeipa.org/images/b/b6/Freeipa30_DNS_zone_transfers.pdf -- / Alexander Bokovoy From tsoucy at salesforce.com Tue Jan 28 11:53:44 2014 From: tsoucy at salesforce.com (Terry Soucy) Date: Tue, 28 Jan 2014 07:53:44 -0400 Subject: [Freeipa-users] Export DNS to external In-Reply-To: <9769CCE57C8E5A44B968BAB6618511339507F7@WPMBX060.bskyb.com> References: <9769CCE57C8E5A44B968BAB6618511339507F7@WPMBX060.bskyb.com> Message-ID: <-7999143113367176717@unknownmsgid> A DNS slave here is no different. The slave does not get its information from IPA. It gets it from a basic zone update from the master. Configure your slave like you would configure any other DNS slave. Terry Sent from my iPhone > On Jan 28, 2014, at 7:48 AM, "Choudhury, Suhail" wrote: > > Hi, > > We are looking at adding redundancy to our IPA setup by using DNS > servers external to our IPA servers, so in the event of IPA dying we can > still resolve against these external DNS servers. > > So I'm looking at how I can add a server running BIND as a DNS slave. > > Normally on a DNS slave we can set something like the following in > named.conf: > > ========================================= > > // query-source address * port 53; > allow-transfer {208.99.198.184/32;}; > }; > > // > // a caching only nameserver config > // > > controls { > inet 127.0.0.1 allow { localhost; } keys { rndckey; }; > }; > > zone "localhost" IN { > type master; > file "localhost.zone"; > allow-update { none; }; > }; > > zone "yourdomain.com" IN { > type slave; > file "/var/named/yourdomain.com.zone"; > // allow-update { none; }; > allow-transfer { 192.168.0.1/32; }; > masters { 192.168.0.1; }; > }; > > zone "0.168.192.in-addr.arpa" IN { > type slave; > file "/var/named/0.168.192.rev"; > // allow-update { none; }; > allow-transfer { 192.168.0.1/32; }; > masters { 192.168.0.1; }; > }; > > ========================================= > > In the IPA server's named.conf I see DNS entries are loaded up via LDAP: > > ========================================= > > include "/etc/named.rfc1912.zones"; > > dynamic-db "ipa" { > library "ldap.so"; > arg "uri ldapi://%2fvar%2frun%2fslapd-SUB-DOMAIN-COM.socket"; > arg "base cn=dns, dc=sub,dc=domain,dc=com"; > arg "fake_mname ipa01.sub.domain.com."; > arg "auth_method sasl"; > arg "sasl_mech GSSAPI"; > arg "sasl_user DNS/ipa01.sub.domain.com"; > arg "zone_refresh 0"; > arg "psearch yes"; > arg "connections 4"; > arg "serial_autoincrement yes"; > }; > > ========================================= > > Has anyone successfully pulled DNS zones out of IPA to BIND slaves? > > -- > Regards, > Suhail. > DevOps(Recs), BSkyB. > > > Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of British Sky Broadcasting Group plc and Sky International AG and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this p! > aragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From mkosek at redhat.com Tue Jan 28 15:31:50 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 28 Jan 2014 16:31:50 +0100 Subject: [Freeipa-users] Announcing FreeIPA 3.3.4 Message-ID: <52E7CD66.4060706@redhat.com> The FreeIPA team is proud to announce FreeIPA v3.3.4! It can be downloaded from http://www.freeipa.org/page/Downloads. Fedora 19 and Fedora 20 builds are already on their way to updates-testing repo. == Highlights in 3.3.4 == === Enhancements === * New Web UI for trusted domain subdomain management * trustdomain-find now shows status (enabled/disabled) of trusted domain subdomains * group-show command now shows external user's name instead of raw SID * FreeIPA is now built with hardening enabled (PIE, RELRO) * Added support for kernel keyring CCACHEs === Bug fixes === * ipa-server-install no longer crashes when freeipa-server-trust-ad package is not installed on the system * ipa-replica-manage no longer crashes when winsync agreement is being created * CLDAP plugin now correctly handles long hostnames and does not create invalid NetBIOS name * FreeIPA now builds on PPC and s390 platforms * PKI subsystem certificate renewal no longer crash on FreeIPA replicas * hbac-test command works for external users again * sudoOrder attribute is now present in ou=sudoers LDAP tree * trust-fetch-domains command now creates ID ranges for child domains * Trust can be now re-established even when it contains subdomains * Default Kerberos password policy reference (krbpwdpolicyreference) is no longer added to new user's entry. The default policy is now rather hard coded in the Kerberos backend to achieve the same behavior for both standard FreeIPA users and winsync users * dnsrecord-mod no longer produces API version warning * ... and numerous other small fixes === Test improvements === * Support external names for hosts * Various small fixes related to legacy client feature testing === Interface changes === * trust-resolve command was hidden from CLI as internal, given that group-show command now shows external user's name instead of raw SID == 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-upgradeconfig # ipa-ldap-updater --upgrade 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 2.2.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 3.3.3 == === Alexander Bokovoy (10) === * Guard import of adtrustinstance for case without trusts * Map NT_STATUS_INVALID_PARAMETER to most likely error cause: clock skew * subdomains: Use AD admin credentials when trust is being established * trust: fix get_dn() to distinguish creating and re-adding trusts * trust-fetch-domains: create ranges for new child domains * trustdomain-find: report status of the (sub)domain * ipaserver/install/installutils: clean up properly after yield * group-show: resolve external members of the groups * ipa-adtrust-install: configure host netbios name by default * ipasam: delete trusted child domains before removing the trust === Ana Krivokapic (1) === * Fix regression which prevents creating a winsync agreement === Jan Cholasta (9) === * Remove mod_ssl port workaround. * Use hardening flags for ipa-optd. * Own /usr/share/ipa/ui/js/ in the spec file. * Prevent garbage from readline on standard output of dogtag-ipa-retrieve-agent. * PKI service restart after CA renewal failed * Fix ipa-client-automount uninstall when fstore is empty. * Do not start the service in stopped_service if it was not running before. * Increase service startup timeout default. * Fix ntpd config on clients. === Krzysztof Klimonda (1) === * Fix -Wformat-security warnings === Martin Basti (1) === * Added warning if cert '/etc/ipa/ca.crt' exists === Martin Kosek (12) === * Server does not detect different server and IPA domain * Allow kernel keyring CCACHE when supported * Increase Java stack size on PPC platforms * Increase Java stack size on s390 platforms * Revert restart scripts file permissions change * hbactest does not work for external users * sudoOrder missing in sudoers * Add missing example to sudorule * Remove missing VERSION warning in dnsrecord-mod * Hide trust-resolve command * ntpconf: remove redundant comment * Become IPA 3.3.4 === Petr Viktorin (5) === * Revert "Remove mod_ssl port workaround." * test_integration: Support external names for hosts * test_integration: Log external hostname in Host.ldap_connect * test_webui: Allow False values in configuration for no_ca, no_dns, has_trusts * cli.print_attribute: Convert values to strings === Petr Vobornik (4) === * Fix license in some Web UI files * Increase stack size for Web UI builder * Remove SID resolve call from Web UI * Trust domains Web UI === Rob Crittenden (1) === * Change the way we determine if the host has a password set. === Simo Sorce (3) === * Fix license tag in python setup files * Harmonize policy discovery to kdb driver * Stop adding a default password policy reference === Sumit Bose (3) === * CLDAP: do not prepend \\ * CLDAP: generate NetBIOS name like ipa-adtrust-install does * CLDAP: add unit tests for make_netbios_name === Tomas Babej (6) === * trusts: Do not pass base-id to the subdomain ranges * trusts: Always stop and disable smb service on uninstall * ipa-client-install: Always pass hostname to the ipa-join * ipa-cldap: Cut NetBIOS name after 15 characters * ipatests: Remove sudo calls from tasks * ipatests: Check for legacy_client attribute presence if unapplying fixes From rcritten at redhat.com Tue Jan 28 18:25:56 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 28 Jan 2014 13:25:56 -0500 Subject: [Freeipa-users] Certificate format error: [Errno -8018] In-Reply-To: <20140128065628.GA19297@noboost.org> References: <20140123070559.GA19915@noboost.org> <20140123072107.GG12003@redhat.com> <52E12582.6000308@redhat.com> <20140128065628.GA19297@noboost.org> Message-ID: <52E7F634.4060500@redhat.com> craig.freeipa at noboost.org wrote: > On Thu, Jan 23, 2014 at 09:21:54AM -0500, Rob Crittenden wrote: >> Alexander Bokovoy wrote: >>> On Thu, 23 Jan 2014, craig.freeipa at noboost.org wrote: >>>> Hi Guys, >>>> >>>> I'm sure this is an easy issue to fix! >>>> >>>> First the specs; >>>> Red Hat Enterprise Linux Server release 6.3 (Santiago) >>>> ipa-client-2.2.0-16.el6.x86_64 >>>> ipa-server-2.2.0-16.el6.x86_64 >>>> >>>> >>>> Issue: >>>> When I click on the hosts TAB from inside the Identity Managemnt GUI, I >>>> get the following error; >>>> * Certificate format error: [Errno -8018] None (repeated many times) >>>> >>>> * Cannot connect to >>>> 'https://sysvm-ipa.teratext.saic.com.au:443/ca/agent/ca/displayBySerial': >>>> >>>> [Errno -8018] None >>>> >>>> Also seen this error; >>>> cannot connect to >>>> 'https://sysvm-ipa.teratext.saic.com.au:443/ca/agent/ca/displayBySerial': >>>> [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your >>>> certificate as expired. >>>> >>>> >>>> Any advise would be greatly appreciated! >>> http://www.freeipa.org/page/Howto/CA_Certificate_Renewal >>> >>> Since you have FreeIPA before 3.4, you need to follow manual procedure >>> outlined on that page. 2.2 might also be a bit different than 3.x but >>> this is a starting point. >>> >>> >> >> For 2.x you want http://www.freeipa.org/page/IPA_2x_Certificate_Renewal >> >> rob >> > Just running into a couple of issues with then manual SSL cert process; > > 1) ERROR when telling certmonger about all the CA certificates > > #Command: > for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" > do > echo $nickname > certutil -L -d /var/lib/pki-ca/alias -n "${nickname}" | grep -i after > done > > > #Result: > auditSigningCert cert-pki-ca > Not After : Tue Jan 14 06:45:05 2014 > ocspSigningCert cert-pki-ca > Not After : Tue Jan 14 06:45:05 2014 > subsystemCert cert-pki-ca > Not After : Tue Jan 14 06:45:05 2014 > Server-Cert cert-pki-ca > Not After : Tue Jan 14 06:45:05 2014 > > #Command: > for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" > do > /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n "${nickname}" -c dogtag-ipa-renew-agent -P 705114231111 > done > > #Result: > No CA with name "dogtag-ipa-renew-agent" found. > No CA with name "dogtag-ipa-renew-agent" found. > No CA with name "dogtag-ipa-renew-agent" found. > No CA with name "dogtag-ipa-renew-agent" found. > > > 2)Upgrade instead? > I could potentionally upgrade the ipa-server to "3.0.0-37.el6", would this version be able to automatically update the certificates? > > cya > > Craig > You need certmonger-0.58-1 or higher to get the dogtag-ipa-renew-agent CA and other fixed. I'll update the wiki with that, sorry for the oversight. You could try updating to 3.0. If you do decide to try upgrading I think I'd go back in time when all the certs are valid first as some services will be restarted during the upgrade and we don't want the upgrade blowing up in the middle because of expired certs. rob From guillermo.fuentes at modernizingmedicine.com Tue Jan 28 20:33:15 2014 From: guillermo.fuentes at modernizingmedicine.com (Guillermo Fuentes) Date: Tue, 28 Jan 2014 15:33:15 -0500 Subject: [Freeipa-users] Disabling anonymous binds breaks OS X (10.8.5 and 10.9.1) UI logins. Message-ID: Hello, We are deploying FreeIPA (which it's a great project BTW) as our Identity Management System. As we don't want any info from the directory to be publically available, we tried disabling anonymous binds but it breaks UI logins on Macs (10.8.5 and 10.9.1) FreeIPA logs show that OS X retrieves attributes using anonymous bind and when it's disabled it logs: ... authzid="(null)", anonymous search not allowed Has anyone been able to get this setup working properly? Thanks in advance, Guillermo -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at altosresearch.com Tue Jan 28 22:29:07 2014 From: steve at altosresearch.com (Steve Severance) Date: Tue, 28 Jan 2014 14:29:07 -0800 Subject: [Freeipa-users] Deploying freeipa behind nginx Message-ID: Hi Everyone, I have deployed freeipa inside our production network. I want to be able to access the web ui so I am attempting to add it to our nginx edge machine. I can pass the requests upstream just fine but I am unable to login using a username/password. I have enabled password authentication in the kerberos section of the freeipa httpd config file. In the logs it looks like the authentication succeeds and a ticket is issued. I assume that the cookie that is returned (ipa_session) has the authentication information in it. The subsequent call to get json data fails and I am prompted to login again. I found this thread ( https://www.redhat.com/archives/freeipa-users/2013-August/msg00080.html) which has instructions on adding ipa.mydomain.com to the keytab. When I call ipa-getkeytab it hangs for a bit before returning: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Digging into this if I run: ldapsearch -d 1 -v -H ldaps://ldap.mydomain.com I get: ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: So we seem to have a SASL problem. If I run ldapsearch with -x simple authentication works just fine. Do I need to do something special to enable SASL so I can get the keytab? The ipa-getkeytab command does not seem to have an option to use simple authentication. Thanks. Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.freeipa at noboost.org Wed Jan 29 06:41:44 2014 From: craig.freeipa at noboost.org (craig.freeipa at noboost.org) Date: Wed, 29 Jan 2014 17:41:44 +1100 Subject: [Freeipa-users] Certificate format error: [Errno -8018] In-Reply-To: <52E7F634.4060500@redhat.com> References: <20140123070559.GA19915@noboost.org> <20140123072107.GG12003@redhat.com> <52E12582.6000308@redhat.com> <20140128065628.GA19297@noboost.org> <52E7F634.4060500@redhat.com> Message-ID: <20140129064144.GA18678@noboost.org> On Tue, Jan 28, 2014 at 01:25:56PM -0500, Rob Crittenden wrote: > craig.freeipa at noboost.org wrote: > >On Thu, Jan 23, 2014 at 09:21:54AM -0500, Rob Crittenden wrote: > >>Alexander Bokovoy wrote: > >>>On Thu, 23 Jan 2014, craig.freeipa at noboost.org wrote: > >>>>Hi Guys, > >>>> > >>>>I'm sure this is an easy issue to fix! > >>>> > >>>>First the specs; > >>>>Red Hat Enterprise Linux Server release 6.3 (Santiago) > >>>>ipa-client-2.2.0-16.el6.x86_64 > >>>>ipa-server-2.2.0-16.el6.x86_64 > >>>> > >>>> > >>>>Issue: > >>>>When I click on the hosts TAB from inside the Identity Managemnt GUI, I > >>>>get the following error; > >>>>* Certificate format error: [Errno -8018] None (repeated many times) > >>>> > >>>>* Cannot connect to > >>>>'https://sysvm-ipa.teratext.saic.com.au:443/ca/agent/ca/displayBySerial': > >>>> > >>>>[Errno -8018] None > >>>> > >>>>Also seen this error; > >>>>cannot connect to > >>>>'https://sysvm-ipa.teratext.saic.com.au:443/ca/agent/ca/displayBySerial': > >>>>[Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your > >>>>certificate as expired. > >>>> > >>>> > >>>>Any advise would be greatly appreciated! > >>>http://www.freeipa.org/page/Howto/CA_Certificate_Renewal > >>> > >>>Since you have FreeIPA before 3.4, you need to follow manual procedure > >>>outlined on that page. 2.2 might also be a bit different than 3.x but > >>>this is a starting point. > >>> > >>> > >> > >>For 2.x you want http://www.freeipa.org/page/IPA_2x_Certificate_Renewal > >> > >>rob > >> > >Just running into a couple of issues with then manual SSL cert process; > > > >1) ERROR when telling certmonger about all the CA certificates > > > >#Command: > >for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" > >do > > echo $nickname > > certutil -L -d /var/lib/pki-ca/alias -n "${nickname}" | grep -i after > >done > > > > > >#Result: > >auditSigningCert cert-pki-ca > > Not After : Tue Jan 14 06:45:05 2014 > >ocspSigningCert cert-pki-ca > > Not After : Tue Jan 14 06:45:05 2014 > >subsystemCert cert-pki-ca > > Not After : Tue Jan 14 06:45:05 2014 > >Server-Cert cert-pki-ca > > Not After : Tue Jan 14 06:45:05 2014 > > > >#Command: > >for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" > >do > > /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n "${nickname}" -c dogtag-ipa-renew-agent -P 705114231111 > >done > > > >#Result: > >No CA with name "dogtag-ipa-renew-agent" found. > >No CA with name "dogtag-ipa-renew-agent" found. > >No CA with name "dogtag-ipa-renew-agent" found. > >No CA with name "dogtag-ipa-renew-agent" found. > > > > > >2)Upgrade instead? > >I could potentionally upgrade the ipa-server to "3.0.0-37.el6", would this version be able to automatically update the certificates? > > > >cya > > > >Craig > > > > You need certmonger-0.58-1 or higher to get the > dogtag-ipa-renew-agent CA and other fixed. I'll update the wiki with > that, sorry for the oversight. > > You could try updating to 3.0. If you do decide to try upgrading I > think I'd go back in time when all the certs are valid first as some > services will be restarted during the upgrade and we don't want the > upgrade blowing up in the middle because of expired certs. > > rob I'll give the upgrade a go, say I go back to the older date and IPA starts fine. Won't the certs still have a hard expiry date on them, so I'll need to follow the http://www.freeipa.org/page/IPA_2x_Certificate_Renewal procedure? cya Craig From sbose at redhat.com Wed Jan 29 08:11:56 2014 From: sbose at redhat.com (Sumit Bose) Date: Wed, 29 Jan 2014 09:11:56 +0100 Subject: [Freeipa-users] Deploying freeipa behind nginx In-Reply-To: References: Message-ID: <20140129081156.GW2834@localhost.localdomain> On Tue, Jan 28, 2014 at 02:29:07PM -0800, Steve Severance wrote: > Hi Everyone, > > I have deployed freeipa inside our production network. I want to be able to > access the web ui so I am attempting to add it to our nginx edge machine. I > can pass the requests upstream just fine but I am unable to login using a > username/password. I have enabled password authentication in the kerberos > section of the freeipa httpd config file. In the logs it looks like the > authentication succeeds and a ticket is issued. I assume that the cookie > that is returned (ipa_session) has the authentication information in it. > The subsequent call to get json data fails and I am prompted to login again. > > I found this thread ( > https://www.redhat.com/archives/freeipa-users/2013-August/msg00080.html) > which has instructions on adding ipa.mydomain.com to the keytab. When I > call ipa-getkeytab it hangs for a bit before returning: ldap_sasl_bind(SIMPLE): > Can't contact LDAP server (-1) > > Digging into this if I run: ldapsearch -d 1 -v -H ldaps://ldap.mydomain.com > > I get: > ldap_sasl_interactive_bind_s: Unknown authentication method (-6) > additional info: SASL(-4): no mechanism available: Does it work if you add the mechanism explicitly, e.g. 'ldapsearch -Y GSSAPI ....' ? bye, Sumit > > So we seem to have a SASL problem. If I run ldapsearch with -x simple > authentication works just fine. > > Do I need to do something special to enable SASL so I can get the keytab? > The ipa-getkeytab command does not seem to have an option to use simple > authentication. > > Thanks. > > Steve > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Wed Jan 29 12:12:28 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 29 Jan 2014 07:12:28 -0500 Subject: [Freeipa-users] Disabling anonymous binds breaks OS X (10.8.5 and 10.9.1) UI logins. In-Reply-To: References: Message-ID: <52E8F02C.9040808@redhat.com> On 01/28/2014 03:33 PM, Guillermo Fuentes wrote: > > Hello, > > > > We are deploying FreeIPA (which it's a great project BTW) as our > Identity Management System. As we don't want any info from the > directory to be publically available, we tried disabling anonymous > binds but it breaks UI logins on Macs (10.8.5 and 10.9.1) > > > > FreeIPA logs show that OS X retrieves attributes using anonymous bind > and when it's disabled it logs: > > ... authzid="(null)", anonymous search not allowed > > > > Has anyone been able to get this setup working properly? > You need to look on the Mac side. It seems that in the configuration you used Mac tries to do a lookup after anonymous bind. It might be that you need to configure a special account on Mac to be able to work around this issue. > > > Thanks in advance, > > Guillermo > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Jan 29 12:18:40 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 29 Jan 2014 07:18:40 -0500 Subject: [Freeipa-users] Deploying freeipa behind nginx In-Reply-To: References: Message-ID: <52E8F1A0.1070702@redhat.com> On 01/28/2014 05:29 PM, Steve Severance wrote: > Hi Everyone, > > I have deployed freeipa inside our production network. I want to be > able to access the web ui so I am attempting to add it to our nginx > edge machine. I can pass the requests upstream just fine but I am > unable to login using a username/password. I have enabled password > authentication in the kerberos section of the freeipa httpd config > file. In the logs it looks like the authentication succeeds and a > ticket is issued. I assume that the cookie that is returned > (ipa_session) has the authentication information in it. The subsequent > call to get json data fails and I am prompted to login again. > > I found this thread > (https://www.redhat.com/archives/freeipa-users/2013-August/msg00080.html) > which has instructions on adding ipa.mydomain.com > to the keytab. When I call ipa-getkeytab it > hangs for a bit before returning: ldap_sasl_bind(SIMPLE): Can't > contact LDAP server (-1) > > Digging into this if I run: ldapsearch -d 1 -v -H > ldaps://ldap.mydomain.com > > I get: > ldap_sasl_interactive_bind_s: Unknown authentication method (-6) > additional info: SASL(-4): no mechanism available: > > So we seem to have a SASL problem. If I run ldapsearch with -x simple > authentication works just fine. > > Do I need to do something special to enable SASL so I can get the > keytab? The ipa-getkeytab command does not seem to have an option to > use simple authentication. > > Thanks. > > Steve > > To be able to help a small diagram would be really helpful. The error above indicates that there is an entity that tries to connect to the LDAP using Kerberos GSSAPI and can't because it either does not have kerberos identity or keys or it is misconfigured and can't get to them. The diagram of request flow would help to troubleshoot the issue. What version of FreeIPA you are using? What platform? > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Jan 29 14:15:50 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 29 Jan 2014 09:15:50 -0500 Subject: [Freeipa-users] Certificate format error: [Errno -8018] In-Reply-To: <20140129064144.GA18678@noboost.org> References: <20140123070559.GA19915@noboost.org> <20140123072107.GG12003@redhat.com> <52E12582.6000308@redhat.com> <20140128065628.GA19297@noboost.org> <52E7F634.4060500@redhat.com> <20140129064144.GA18678@noboost.org> Message-ID: <52E90D16.8080600@redhat.com> craig.freeipa at noboost.org wrote: > On Tue, Jan 28, 2014 at 01:25:56PM -0500, Rob Crittenden wrote: >> craig.freeipa at noboost.org wrote: >>> On Thu, Jan 23, 2014 at 09:21:54AM -0500, Rob Crittenden wrote: >>>> Alexander Bokovoy wrote: >>>>> On Thu, 23 Jan 2014, craig.freeipa at noboost.org wrote: >>>>>> Hi Guys, >>>>>> >>>>>> I'm sure this is an easy issue to fix! >>>>>> >>>>>> First the specs; >>>>>> Red Hat Enterprise Linux Server release 6.3 (Santiago) >>>>>> ipa-client-2.2.0-16.el6.x86_64 >>>>>> ipa-server-2.2.0-16.el6.x86_64 >>>>>> >>>>>> >>>>>> Issue: >>>>>> When I click on the hosts TAB from inside the Identity Managemnt GUI, I >>>>>> get the following error; >>>>>> * Certificate format error: [Errno -8018] None (repeated many times) >>>>>> >>>>>> * Cannot connect to >>>>>> 'https://sysvm-ipa.teratext.saic.com.au:443/ca/agent/ca/displayBySerial': >>>>>> >>>>>> [Errno -8018] None >>>>>> >>>>>> Also seen this error; >>>>>> cannot connect to >>>>>> 'https://sysvm-ipa.teratext.saic.com.au:443/ca/agent/ca/displayBySerial': >>>>>> [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your >>>>>> certificate as expired. >>>>>> >>>>>> >>>>>> Any advise would be greatly appreciated! >>>>> http://www.freeipa.org/page/Howto/CA_Certificate_Renewal >>>>> >>>>> Since you have FreeIPA before 3.4, you need to follow manual procedure >>>>> outlined on that page. 2.2 might also be a bit different than 3.x but >>>>> this is a starting point. >>>>> >>>>> >>>> >>>> For 2.x you want http://www.freeipa.org/page/IPA_2x_Certificate_Renewal >>>> >>>> rob >>>> >>> Just running into a couple of issues with then manual SSL cert process; >>> >>> 1) ERROR when telling certmonger about all the CA certificates >>> >>> #Command: >>> for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" >>> do >>> echo $nickname >>> certutil -L -d /var/lib/pki-ca/alias -n "${nickname}" | grep -i after >>> done >>> >>> >>> #Result: >>> auditSigningCert cert-pki-ca >>> Not After : Tue Jan 14 06:45:05 2014 >>> ocspSigningCert cert-pki-ca >>> Not After : Tue Jan 14 06:45:05 2014 >>> subsystemCert cert-pki-ca >>> Not After : Tue Jan 14 06:45:05 2014 >>> Server-Cert cert-pki-ca >>> Not After : Tue Jan 14 06:45:05 2014 >>> >>> #Command: >>> for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" >>> do >>> /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n "${nickname}" -c dogtag-ipa-renew-agent -P 705114231111 >>> done >>> >>> #Result: >>> No CA with name "dogtag-ipa-renew-agent" found. >>> No CA with name "dogtag-ipa-renew-agent" found. >>> No CA with name "dogtag-ipa-renew-agent" found. >>> No CA with name "dogtag-ipa-renew-agent" found. >>> >>> >>> 2)Upgrade instead? >>> I could potentionally upgrade the ipa-server to "3.0.0-37.el6", would this version be able to automatically update the certificates? >>> >>> cya >>> >>> Craig >>> >> >> You need certmonger-0.58-1 or higher to get the >> dogtag-ipa-renew-agent CA and other fixed. I'll update the wiki with >> that, sorry for the oversight. >> >> You could try updating to 3.0. If you do decide to try upgrading I >> think I'd go back in time when all the certs are valid first as some >> services will be restarted during the upgrade and we don't want the >> upgrade blowing up in the middle because of expired certs. >> >> rob > I'll give the upgrade a go, say I go back to the older date and IPA > starts fine. Won't the certs still have a hard expiry date on them, so > I'll need to follow the > http://www.freeipa.org/page/IPA_2x_Certificate_Renewal procedure? It depends in part how far back in time you go. I'd go back a day or two before the oldest date (not all certs expire at the same time). The upgrade will configure automatic renewal. I think what I'd recommend is do the upgrade then restart the certmonger service on the machine. Run `getcert list` to check the status of the certs. After the restart they should all renew. rob From craig.freeipa at noboost.org Thu Jan 30 00:47:20 2014 From: craig.freeipa at noboost.org (craig.freeipa at noboost.org) Date: Thu, 30 Jan 2014 11:47:20 +1100 Subject: [Freeipa-users] Certificate format error: [Errno -8018] In-Reply-To: <52E90D16.8080600@redhat.com> References: <20140123070559.GA19915@noboost.org> <20140123072107.GG12003@redhat.com> <52E12582.6000308@redhat.com> <20140128065628.GA19297@noboost.org> <52E7F634.4060500@redhat.com> <20140129064144.GA18678@noboost.org> <52E90D16.8080600@redhat.com> Message-ID: <20140130004720.GA1863@noboost.org> On Wed, Jan 29, 2014 at 09:15:50AM -0500, Rob Crittenden wrote: > craig.freeipa at noboost.org wrote: > >On Tue, Jan 28, 2014 at 01:25:56PM -0500, Rob Crittenden wrote: > >>craig.freeipa at noboost.org wrote: > >>>On Thu, Jan 23, 2014 at 09:21:54AM -0500, Rob Crittenden wrote: > >>>>Alexander Bokovoy wrote: > >>>>>On Thu, 23 Jan 2014, craig.freeipa at noboost.org wrote: > >>>>>>Hi Guys, > >>>>>> > >>>>>>I'm sure this is an easy issue to fix! > >>>>>> > >>>>>>First the specs; > >>>>>>Red Hat Enterprise Linux Server release 6.3 (Santiago) > >>>>>>ipa-client-2.2.0-16.el6.x86_64 > >>>>>>ipa-server-2.2.0-16.el6.x86_64 > >>>>>> > >>>>>> > >>>>>>Issue: > >>>>>>When I click on the hosts TAB from inside the Identity Managemnt GUI, I > >>>>>>get the following error; > >>>>>>* Certificate format error: [Errno -8018] None (repeated many times) > >>>>>> > >>>>>>* Cannot connect to > >>>>>>'https://sysvm-ipa.teratext.saic.com.au:443/ca/agent/ca/displayBySerial': > >>>>>> > >>>>>>[Errno -8018] None > >>>>>> > >>>>>>Also seen this error; > >>>>>>cannot connect to > >>>>>>'https://sysvm-ipa.teratext.saic.com.au:443/ca/agent/ca/displayBySerial': > >>>>>>[Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your > >>>>>>certificate as expired. > >>>>>> > >>>>>> > >>>>>>Any advise would be greatly appreciated! > >>>>>http://www.freeipa.org/page/Howto/CA_Certificate_Renewal > >>>>> > >>>>>Since you have FreeIPA before 3.4, you need to follow manual procedure > >>>>>outlined on that page. 2.2 might also be a bit different than 3.x but > >>>>>this is a starting point. > >>>>> > >>>>> > >>>> > >>>>For 2.x you want http://www.freeipa.org/page/IPA_2x_Certificate_Renewal > >>>> > >>>>rob > >>>> > >>>Just running into a couple of issues with then manual SSL cert process; > >>> > >>>1) ERROR when telling certmonger about all the CA certificates > >>> > >>>#Command: > >>>for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" > >>>do > >>> echo $nickname > >>> certutil -L -d /var/lib/pki-ca/alias -n "${nickname}" | grep -i after > >>>done > >>> > >>> > >>>#Result: > >>>auditSigningCert cert-pki-ca > >>> Not After : Tue Jan 14 06:45:05 2014 > >>>ocspSigningCert cert-pki-ca > >>> Not After : Tue Jan 14 06:45:05 2014 > >>>subsystemCert cert-pki-ca > >>> Not After : Tue Jan 14 06:45:05 2014 > >>>Server-Cert cert-pki-ca > >>> Not After : Tue Jan 14 06:45:05 2014 > >>> > >>>#Command: > >>>for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" > >>>do > >>> /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n "${nickname}" -c dogtag-ipa-renew-agent -P 705114231111 > >>>done > >>> > >>>#Result: > >>>No CA with name "dogtag-ipa-renew-agent" found. > >>>No CA with name "dogtag-ipa-renew-agent" found. > >>>No CA with name "dogtag-ipa-renew-agent" found. > >>>No CA with name "dogtag-ipa-renew-agent" found. > >>> > >>> > >>>2)Upgrade instead? > >>>I could potentionally upgrade the ipa-server to "3.0.0-37.el6", would this version be able to automatically update the certificates? > >>> > >>>cya > >>> > >>>Craig > >>> > >> > >>You need certmonger-0.58-1 or higher to get the > >>dogtag-ipa-renew-agent CA and other fixed. I'll update the wiki with > >>that, sorry for the oversight. > >> > >>You could try updating to 3.0. If you do decide to try upgrading I > >>think I'd go back in time when all the certs are valid first as some > >>services will be restarted during the upgrade and we don't want the > >>upgrade blowing up in the middle because of expired certs. > >> > >>rob > >I'll give the upgrade a go, say I go back to the older date and IPA > >starts fine. Won't the certs still have a hard expiry date on them, so > >I'll need to follow the > >http://www.freeipa.org/page/IPA_2x_Certificate_Renewal procedure? > > It depends in part how far back in time you go. I'd go back a day or > two before the oldest date (not all certs expire at the same time). > > The upgrade will configure automatic renewal. I think what I'd > recommend is do the upgrade then restart the certmonger service on > the machine. > > Run `getcert list` to check the status of the certs. After the > restart they should all renew. > > rob Well progress :) just not quite fully fixed, seems three certificates have updated just not the others yet. Do I need to "tell them to update", or let the server roll over until it hits Jan 14? Server: Red Hat Enterprise Linux Server release 6.5 (Santiago) ipa-server-3.0.0-37.el6.x86_64 ipa-client-3.0.0-37.el6.x86_64 --- ~/Scripts>date Sat Jan 11 19:29:02 EST 2014 --- ~/Scripts>certutil -L -d /etc/httpd/alias -n ipaCert | grep After Not After : Fri Jan 01 07:44:45 2016 --- Ran script: for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" do echo $nickname certutil -L -d /var/lib/pki-ca/alias -n "${nickname}" | grep -i after done --- auditSigningCert cert-pki-ca Not After : Thu Jul 10 07:45:42 2014 Not After : Tue Jan 14 06:45:05 2014 ocspSigningCert cert-pki-ca Not After : Fri Jan 01 07:44:43 2016 subsystemCert cert-pki-ca Not After : Fri Jan 01 07:44:44 2016 Server-Cert cert-pki-ca Not After : Tue Jan 14 06:45:05 2014 --- The apache cert did update which is good! ~/Scripts>certutil -L -d /etc/httpd/alias -n ipaCert | grep After Not After : Fri Jan 01 07:44:45 2016 cya Craig From rcritten at redhat.com Thu Jan 30 02:22:35 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 29 Jan 2014 21:22:35 -0500 Subject: [Freeipa-users] Certificate format error: [Errno -8018] In-Reply-To: <20140130004720.GA1863@noboost.org> References: <20140123070559.GA19915@noboost.org> <20140123072107.GG12003@redhat.com> <52E12582.6000308@redhat.com> <20140128065628.GA19297@noboost.org> <52E7F634.4060500@redhat.com> <20140129064144.GA18678@noboost.org> <52E90D16.8080600@redhat.com> <20140130004720.GA1863@noboost.org> Message-ID: <52E9B76B.8030407@redhat.com> craig.freeipa at noboost.org wrote: > Well progress :) just not quite fully fixed, seems three certificates have updated just not the others yet. Do I need to "tell them to update", or let the server roll over until it hits Jan 14? > > Server: Red Hat Enterprise Linux Server release 6.5 (Santiago) > ipa-server-3.0.0-37.el6.x86_64 > ipa-client-3.0.0-37.el6.x86_64 > --- > ~/Scripts>date > Sat Jan 11 19:29:02 EST 2014 > --- > ~/Scripts>certutil -L -d /etc/httpd/alias -n ipaCert | grep After > Not After : Fri Jan 01 07:44:45 2016 > --- > Ran script: > for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" > do > echo $nickname > certutil -L -d /var/lib/pki-ca/alias -n "${nickname}" | grep -i after > done > > --- > auditSigningCert cert-pki-ca > Not After : Thu Jul 10 07:45:42 2014 > Not After : Tue Jan 14 06:45:05 2014 > ocspSigningCert cert-pki-ca > Not After : Fri Jan 01 07:44:43 2016 > subsystemCert cert-pki-ca > Not After : Fri Jan 01 07:44:44 2016 > Server-Cert cert-pki-ca > Not After : Tue Jan 14 06:45:05 2014 > --- > > The apache cert did update which is good! > ~/Scripts>certutil -L -d /etc/httpd/alias -n ipaCert | grep After > Not After : Fri Jan 01 07:44:45 2016 > > cya > > Craig > For those not yet renewed I'd do a getcert list to find them and getcert resubmit -i to force renewal. The CA won't start without a valid audit cert. rob From craig.freeipa at noboost.org Thu Jan 30 05:03:11 2014 From: craig.freeipa at noboost.org (craig.freeipa at noboost.org) Date: Thu, 30 Jan 2014 16:03:11 +1100 Subject: [Freeipa-users] Certificate format error: [Errno -8018] In-Reply-To: <52E9B76B.8030407@redhat.com> References: <20140123070559.GA19915@noboost.org> <20140123072107.GG12003@redhat.com> <52E12582.6000308@redhat.com> <20140128065628.GA19297@noboost.org> <52E7F634.4060500@redhat.com> <20140129064144.GA18678@noboost.org> <52E90D16.8080600@redhat.com> <20140130004720.GA1863@noboost.org> <52E9B76B.8030407@redhat.com> Message-ID: <20140130050311.GA12321@noboost.org> On Wed, Jan 29, 2014 at 09:22:35PM -0500, Rob Crittenden wrote: > craig.freeipa at noboost.org wrote: > >Well progress :) just not quite fully fixed, seems three certificates have updated just not the others yet. Do I need to "tell them to update", or let the server roll over until it hits Jan 14? > > > >Server: Red Hat Enterprise Linux Server release 6.5 (Santiago) > >ipa-server-3.0.0-37.el6.x86_64 > >ipa-client-3.0.0-37.el6.x86_64 > >--- > >~/Scripts>date > >Sat Jan 11 19:29:02 EST 2014 > >--- > >~/Scripts>certutil -L -d /etc/httpd/alias -n ipaCert | grep After > > Not After : Fri Jan 01 07:44:45 2016 > >--- > >Ran script: > >for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" > >do > > echo $nickname > > certutil -L -d /var/lib/pki-ca/alias -n "${nickname}" | grep -i after > >done > > > >--- > >auditSigningCert cert-pki-ca > > Not After : Thu Jul 10 07:45:42 2014 > > Not After : Tue Jan 14 06:45:05 2014 > >ocspSigningCert cert-pki-ca > > Not After : Fri Jan 01 07:44:43 2016 > >subsystemCert cert-pki-ca > > Not After : Fri Jan 01 07:44:44 2016 > >Server-Cert cert-pki-ca > > Not After : Tue Jan 14 06:45:05 2014 > >--- > > > >The apache cert did update which is good! > >~/Scripts>certutil -L -d /etc/httpd/alias -n ipaCert | grep After > > Not After : Fri Jan 01 07:44:45 2016 > > > >cya > > > >Craig > > > > For those not yet renewed I'd do a getcert list to find them and > getcert resubmit -i to force renewal. > > The CA won't start without a valid audit cert. > > rob Thanks for all the help, looks like all is fixed. I moved the dates back to normal and all the services are working :) I did notice the "auditSigningCert cert-pki-ca" has two certificates, one old one and a new one. The getcert list command is only showing the new one, so I figure all is well. auditSigningCert cert-pki-ca Certificate: Validity: Not Before: Sat Jan 11 07:45:42 2014 Not After : Thu Jul 10 07:45:42 2014 Data: Validity: Not Before: Wed Jan 25 06:45:05 2012 Not After : Tue Jan 14 06:45:05 2014 cya Craig From sigbjorn at nixtra.com Fri Jan 31 15:00:00 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 31 Jan 2014 16:00:00 +0100 (CET) Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <52D94E22.2060207@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> Message-ID: <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> On Fri, January 17, 2014 16:37, Rob Crittenden wrote: > Sigbjorn Lie wrote: > >> >> This worked better than expected. Thank you! :) >> >> >> ipa01 and ipa02 seem to be happy again, "getcert list" no longer displays any certificates out >> of date, and all certificates in need of renewal within 28 days has been renewed. The webui also >> started working again and things seem to be back to normal. >> >> ipa03 however is still having issues. I could not renew any certificates on this server to begin >> with, but I managed to renew the certificates for the directory servers by changing the xmlrpc >> url to another ipa server in /etc/ipa/default.conf and resubmitting these requests. >> >> "getcert resubmit -i > NEED_GUIDANCE after a short while for the certificates for the PKI service. >> >> >> /var/log/messages says: "certmonger: #033[?1034h28800" and "python: >> Updated certificate for ipaCert not available". >> >> >> There is a lot of information in the /var/log/pki-ca/debug, but nothing >> that I can easily distinguish as an error from all the other output. Anything in particular I >> should look for? > > Ok, so this is a bug in IPA related to python readline. Garbage is > getting inserted and causing bad things to happen, https://fedorahosted.org/freeipa/ticket/4064 > > > So the question is, are the certs available or not. > > > A number of the same certificates are shared amongst all the CAs. One > does the renewal and stuffs the result into cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX. The other CAs > refer to that location for an updated cert and will load them if they are updated. > > Look to see if the certs are updated there. Given that you have 2 > working masters I'm assuming that is the case, so it may just be a matter of fixing the python. > I could not get anywhere even after manually patching the python script as mentioned in the ticket you provided. I ended up removing and re-adding the replica during a maintenance window. For future reference, what I did was to remove the replica as per the Identity Management Guide on docs.redhat.com. I then re-created the replica installation file and installed the replica. At this point Certmonger managed to retrieve new certificates for the expired certificates, but it kept segfaulting when it attempted to save the certificate to disk. I restarted certmonger a few times, but certmonger just ended up segfaulting over and over. I decided to block the ipa server off the network and change the date back to before the certs expired. After the date was changed I restarted certmonger. Certmonger managed to save the certs successfully this time and a "getcert list" now displays only certificates with an expire date of 2015 or 2016 and a status of MONTORING. I changed the date back to correct date and time and removed the iptables rules. The replica now works just fine. Thank you for your assistance. Regards, Siggi From dpal at redhat.com Fri Jan 31 17:46:14 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 31 Jan 2014 12:46:14 -0500 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> Message-ID: <52EBE166.9010509@redhat.com> On 01/31/2014 10:00 AM, Sigbjorn Lie wrote: > > > On Fri, January 17, 2014 16:37, Rob Crittenden wrote: >> Sigbjorn Lie wrote: >> >>> This worked better than expected. Thank you! :) >>> >>> >>> ipa01 and ipa02 seem to be happy again, "getcert list" no longer displays any certificates out >>> of date, and all certificates in need of renewal within 28 days has been renewed. The webui also >>> started working again and things seem to be back to normal. >>> >>> ipa03 however is still having issues. I could not renew any certificates on this server to begin >>> with, but I managed to renew the certificates for the directory servers by changing the xmlrpc >>> url to another ipa server in /etc/ipa/default.conf and resubmitting these requests. >>> >>> "getcert resubmit -i >> NEED_GUIDANCE after a short while for the certificates for the PKI service. >>> >>> >>> /var/log/messages says: "certmonger: #033[?1034h28800" and "python: >>> Updated certificate for ipaCert not available". >>> >>> >>> There is a lot of information in the /var/log/pki-ca/debug, but nothing >>> that I can easily distinguish as an error from all the other output. Anything in particular I >>> should look for? >> Ok, so this is a bug in IPA related to python readline. Garbage is >> getting inserted and causing bad things to happen, https://fedorahosted.org/freeipa/ticket/4064 >> >> >> So the question is, are the certs available or not. >> >> >> A number of the same certificates are shared amongst all the CAs. One >> does the renewal and stuffs the result into cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX. The other CAs >> refer to that location for an updated cert and will load them if they are updated. >> >> Look to see if the certs are updated there. Given that you have 2 >> working masters I'm assuming that is the case, so it may just be a matter of fixing the python. >> > I could not get anywhere even after manually patching the python script as mentioned in the ticket > you provided. > > > I ended up removing and re-adding the replica during a maintenance window. For future reference, > what I did was to remove the replica as per the Identity Management Guide on docs.redhat.com. I > then re-created the replica installation file and installed the replica. > > At this point Certmonger managed to retrieve new certificates for the expired certificates, but it > kept segfaulting when it attempted to save the certificate to disk. I restarted certmonger a few > times, but certmonger just ended up segfaulting over and over. I decided to block the ipa server > off the network and change the date back to before the certs expired. After the date was changed I > restarted certmonger. Certmonger managed to save the certs successfully this time and a "getcert > list" now displays only certificates with an expire date of 2015 or 2016 and a status of > MONTORING. > > I changed the date back to correct date and time and removed the iptables rules. The replica now > works just fine. > > Thank you for your assistance. > Can you give us some core dumps from certmonger to see why it is crashing. We would like to fix crash bugs if we them. > Regards, > Siggi > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From tmaugh at boingo.com Fri Jan 31 17:59:41 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Fri, 31 Jan 2014 17:59:41 +0000 Subject: [Freeipa-users] cant create winsync reolication Message-ID: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local> please help im stuck trying to finish this winsync agreement [root at se-idm-01.boingo.com slapd-BOINGO-COM]$ ipa-replica-manage connect --winsync --binddn "cn=idm admin, cn=Users, dc=boingoqa, dc=local" --bindpw "*******" --passsync "********" --cacert=/etc/openldap/cacerts/boingoqaCA.cer qatestdc2.boingoqa.local -v Directory Manager password: Added CA certificate /etc/openldap/cacerts/boingoqaCA.cer to certificate database for se-idm-01.boingo.com ipa: INFO: AD Suffix is: DC=boingoqa,DC=local The user for the Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=boingo,dc=com 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: -11 - LDAP error: Connect error: start: 0: end: 0 ipa: INFO: Agreement is ready, starting replication . . . Starting replication, please wait until this has completed. [se-idm-01.boingo.com] reports: Update failed! Status: [-11 - LDAP error: Connect error] Failed to start replication -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Jan 31 18:15:44 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 31 Jan 2014 13:15:44 -0500 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local> Message-ID: <52EBE850.9070108@redhat.com> On 01/31/2014 12:59 PM, Todd Maugh wrote: > please help im stuck trying to finish this winsync agreement > > [root at se-idm-01.boingo.com slapd-BOINGO-COM]$ ipa-replica-manage > connect --winsync --binddn "cn=idm admin, cn=Users, dc=boingoqa, > dc=local" --bindpw "*******" --passsync "********" > --cacert=/etc/openldap/cacerts/boingoqaCA.cer qatestdc2.boingoqa.local -v > Directory Manager password: > > Added CA certificate /etc/openldap/cacerts/boingoqaCA.cer to > certificate database for se-idm-01.boingo.com > ipa: INFO: AD Suffix is: DC=boingoqa,DC=local > The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=boingo,dc=com > 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: -11 - LDAP > error: Connect error: start: 0: end: 0 > ipa: INFO: Agreement is ready, starting replication . . . > Starting replication, please wait until this has completed. > [se-idm-01.boingo.com] reports: Update failed! Status: [-11 - LDAP > error: Connect error] > Failed to start replication > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Some DS level logs might help. Also may it be a firewall issue? FW resetting connection or something like? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Fri Jan 31 18:22:49 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Fri, 31 Jan 2014 18:22:49 +0000 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <52EBE850.9070108@redhat.com> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local>, <52EBE850.9070108@redhat.com> Message-ID: <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com> [root at se-idm-01.boingo.com slapd-BOINGO-COM]$ cacertdir_rehash /etc/openldap/cacerts/ [root at se-idm-01.boingo.com slapd-BOINGO-COM]$ ldapsearch -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm admin,cn=users,dc=boingoqa,dc=local" -W Enter LDAP Password: dn: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: IDM ADMIN givenName: IDMADMIN distinguishedName: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local instanceType: 4 whenCreated: 20140128182537.0Z whenChanged: 20140131014315.0Z displayName: IDMADMIN uSNCreated: 31968 memberOf: CN=Domain Controllers,CN=Users,DC=boingoqa,DC=local memberOf: CN=Account Operators,CN=Builtin,DC=boingoqa,DC=local memberOf: CN=Enterprise Admins,CN=Users,DC=boingoqa,DC=local uSNChanged: 38786 name: IDM ADMIN objectGUID:: jai63JfDvUuOGcURntA7hg== userAccountControl: 66048 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 lastLogon: 0 pwdLastSet: 130356008006093750 primaryGroupID: 513 objectSid:: AQUAAAAAAAUVAAAA0+/GU55mz3h0hQ48RwYAAA== adminCount: 1 accountExpires: 9223372036854775807 logonCount: 0 sAMAccountName: idmadmin sAMAccountType: 805306368 userPrincipalName: idmadmin at boingoqa.local lockoutTime: 0 objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=boingoqa,DC=local dSCorePropagationData: 20140129224024.0Z dSCorePropagationData: 16010101000000.0Z lastLogonTimestamp: 130356060672110578 [root at se-idm-01.boingo.com slapd-BOINGO-COM]$ ldapsearch -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm admin,cn=users,dc=boingoqa,dc=local" -W -d3 ldap_url_parse_ext(ldap://qatestdc2.boingoqa.local) ldap_create ldap_url_parse_ext(ldap://qatestdc2.boingoqa.local:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP qatestdc2.boingoqa.local:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.194.55.48:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_write: want=31, written=31 0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 0....w...1.3.6.1 0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .4.1.1466.20037 ldap_result ld 0x1af3480 msgid 1 wait4msg ld 0x1af3480 msgid 1 (infinite timeout) wait4msg continue ld 0x1af3480 msgid 1 all 1 ** ld 0x1af3480 Connections: * host: qatestdc2.boingoqa.local port: 389 (default) refcnt: 2 status: Connected last used: Fri Jan 31 16:30:33 2014 ** ld 0x1af3480 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x1af3480 request count 1 (abandoned 0) ** ld 0x1af3480 Response Queue: Empty ld 0x1af3480 response count 0 ldap_chkResponseList ld 0x1af3480 msgid 1 all 1 ldap_chkResponseList returns ld 0x1af3480 NULL ldap_int_select read1msg: ld 0x1af3480 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 84 00 00 00 28 02 01 0....(.. ldap_read: want=38, got=38 0000: 01 78 84 00 00 00 1f 0a 01 00 04 00 04 00 8a 16 .x.............. 0010: 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 31 34 36 36 1.3.6.1.4.1.1466 0020: 2e 32 30 30 33 37 .20037 ber_get_next: tag 0x30 len 40 contents: read1msg: ld 0x1af3480 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x1af3480 0 new referrals read1msg: mark request completed, ld 0x1af3480 msgid 1 request done: ld 0x1af3480 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ber_scanf fmt (a) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (x) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS: certdb config: configDir='/etc/openldap/cacerts/' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: cannot open certdb '/etc/openldap/cacerts/', error -8018:Unknown PKCS #11 error. TLS: loaded CA certificate file /etc/ipa/ca.crt. TLS: skipping 'boingoqaCA.cer' - filename does not have expected format (certificate hash with numeric suffix) TLS: loaded CA certificate file /etc/openldap/cacerts//ad5923d2.0 from CA certificate directory /etc/openldap/cacerts/. TLS: loaded CA certificate file /etc/openldap/cacerts//36480d54.0 from CA certificate directory /etc/openldap/cacerts/. TLS: skipping 'ca.cer' - filename does not have expected format (certificate hash with numeric suffix) tls_write: want=154, written=154 0000: 16 03 01 00 95 01 00 00 91 03 01 52 eb cf a9 2a ...........R...* 0010: c5 33 57 b1 16 dc 40 d1 0b 71 21 d9 a8 b7 77 43 .3W... at ..q!...wC 0020: 2b d4 38 fa 94 9a ef 72 a7 1b ad 00 00 56 00 ff +.8....r.....V.. 0030: c0 0a c0 14 00 88 00 87 00 39 00 38 c0 0f c0 05 .........9.8.... 0040: 00 84 00 35 c0 09 c0 07 c0 13 c0 11 00 45 00 44 ...5.........E.D 0050: 00 33 00 32 00 66 c0 0e c0 0c c0 04 c0 02 00 96 .3.2.f.......... 0060: 00 41 00 2f 00 05 00 04 c0 08 c0 12 00 16 00 13 .A./............ 0070: c0 0d c0 03 00 0a 00 15 00 12 00 09 00 64 00 62 .............d.b 0080: 00 03 00 06 01 00 00 12 00 0a 00 08 00 06 00 17 ................ 0090: 00 18 00 19 00 0b 00 02 01 00 .......... tls_read: want=5, got=5 0000: 16 03 01 0b f4 ..... tls_read: want=3060, got=1443 0000: 02 00 00 4d 03 01 52 eb cf a0 77 19 29 c0 07 16 ...M..R...w.)... 0010: c8 fb 86 e8 e1 c4 53 c0 66 74 27 49 5c 28 08 82 ......S.ft'I\(.. 0020: a8 91 db 3c f3 65 20 c8 2e 00 00 6d 48 6b c4 12 ...<.e ....mHk.. 0030: 58 08 ec 6d 62 1d 5f 1c a6 e4 8a 27 da 64 93 0d X..mb._....'.d.. 0040: 96 a1 59 4d cd 30 1f 00 2f 00 00 05 ff 01 00 01 ..YM.0../....... 0050: 00 0b 00 06 65 00 06 62 00 06 5f 30 82 06 5b 30 ....e..b.._0..[0 0060: 82 04 43 a0 03 02 01 02 02 0a 15 27 15 8c 00 00 ..C........'.... 0070: 00 00 00 04 30 0d 06 09 2a 86 48 86 f7 0d 01 01 ....0...*.H..... 0080: 04 05 00 30 45 31 15 30 13 06 0a 09 92 26 89 93 ...0E1.0.....&.. 0090: f2 2c 64 01 19 16 05 6c 6f 63 61 6c 31 18 30 16 .,d....local1.0. 00a0: 06 0a 09 92 26 89 93 f2 2c 64 01 19 16 08 62 6f ....&...,d....bo 00b0: 69 6e 67 6f 71 61 31 12 30 10 06 03 55 04 03 13 ingoqa1.0...U... 00c0: 09 53 4b 59 57 41 52 50 43 41 30 1e 17 0d 31 34 .SKYWARPCA0...14 00d0: 30 31 33 30 32 32 33 33 35 39 5a 17 0d 31 35 30 0130223359Z..150 00e0: 31 33 30 32 32 33 33 35 39 5a 30 23 31 21 30 1f 130223359Z0#1!0. 00f0: 06 03 55 04 03 13 18 51 41 54 45 53 54 44 43 32 ..U....QATESTDC2 0100: 2e 62 6f 69 6e 67 6f 71 61 2e 6c 6f 63 61 6c 30 .boingoqa.local0 0110: 81 9f 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 ..0...*.H....... 0120: 00 03 81 8d 00 30 81 89 02 81 81 00 aa 30 bb 57 .....0.......0.W 0130: 09 87 1d 40 99 d7 c7 50 ba b4 d7 9d 6d 45 2c 68 ... at ...P....mE,h 0140: 19 d4 56 0e 9f 11 4b 8a dc 73 61 2c 9e a7 8b b8 ..V...K..sa,.... 0150: 7f b8 c7 e8 1b 08 79 b8 4a a0 b7 f4 6e 93 eb b1 ......y.J...n... 0160: 90 36 7a 21 a0 44 70 17 d0 dc 17 17 96 4e 5e 2a .6z!.Dp......N^* 0170: 77 6d 67 10 ed d8 1e 7a 40 a8 82 2f 91 d6 9a c2 wmg....z at ../.... 0180: 18 ce e3 d0 df 3f 7c f4 b1 df 50 81 4e bf 83 0b .....?|...P.N... 0190: 56 fc 26 13 44 23 f1 7b e8 7d d5 cf 29 54 97 13 V.&.D#.{.}..)T.. 01a0: 5f 0e ec e3 d9 16 fc de 01 82 78 bf 02 03 01 00 _.........x..... 01b0: 01 a3 82 02 f1 30 82 02 ed 30 2f 06 09 2b 06 01 .....0...0/..+.. 01c0: 04 01 82 37 14 02 04 22 1e 20 00 44 00 6f 00 6d ...7...". .D.o.m 01d0: 00 61 00 69 00 6e 00 43 00 6f 00 6e 00 74 00 72 .a.i.n.C.o.n.t.r 01e0: 00 6f 00 6c 00 6c 00 65 00 72 30 1d 06 03 55 1d .o.l.l.e.r0...U. 01f0: 25 04 16 30 14 06 08 2b 06 01 05 05 07 03 02 06 %..0...+........ 0200: 08 2b 06 01 05 05 07 03 01 30 0b 06 03 55 1d 0f .+.......0...U.. 0210: 04 04 03 02 05 a0 30 78 06 09 2a 86 48 86 f7 0d ......0x..*.H... 0220: 01 09 0f 04 6b 30 69 30 0e 06 08 2a 86 48 86 f7 ....k0i0...*.H.. 0230: 0d 03 02 02 02 00 80 30 0e 06 08 2a 86 48 86 f7 .......0...*.H.. 0240: 0d 03 04 02 02 00 80 30 0b 06 09 60 86 48 01 65 .......0...`.H.e 0250: 03 04 01 2a 30 0b 06 09 60 86 48 01 65 03 04 01 ...*0...`.H.e... 0260: 2d 30 0b 06 09 60 86 48 01 65 03 04 01 02 30 0b -0...`.H.e....0. 0270: 06 09 60 86 48 01 65 03 04 01 05 30 07 06 05 2b ..`.H.e....0...+ 0280: 0e 03 02 07 30 0a 06 08 2a 86 48 86 f7 0d 03 07 ....0...*.H..... 0290: 30 1d 06 03 55 1d 0e 04 16 04 14 6d 66 8e e6 c8 0...U......mf... 02a0: 48 ea f4 16 ff 4d 6f 72 2e bb 26 1d 45 a8 6f 30 H....Mor..&.E.o0 02b0: 1f 06 03 55 1d 23 04 18 30 16 80 14 7c 5f 71 5f ...U.#..0...|_q_ 02c0: 6b d3 83 3d 5b af d9 54 9d 7e 88 b1 ce a8 5c 83 k..=[..T.~....\. 02d0: 30 81 cc 06 03 55 1d 1f 04 81 c4 30 81 c1 30 81 0....U.....0..0. 02e0: be a0 81 bb a0 81 b8 86 81 b5 6c 64 61 70 3a 2f ..........ldap:/ 02f0: 2f 2f 43 4e 3d 53 4b 59 57 41 52 50 43 41 2c 43 //CN=SKYWARPCA,C 0300: 4e 3d 51 41 54 45 53 54 44 43 32 2c 43 4e 3d 43 N=QATESTDC2,CN=C 0310: 44 50 2c 43 4e 3d 50 75 62 6c 69 63 25 32 30 4b DP,CN=Public%20K 0320: 65 79 25 32 30 53 65 72 76 69 63 65 73 2c 43 4e ey%20Services,CN 0330: 3d 53 65 72 76 69 63 65 73 2c 43 4e 3d 43 6f 6e =Services,CN=Con 0340: 66 69 67 75 72 61 74 69 6f 6e 2c 44 43 3d 62 6f figuration,DC=bo 0350: 69 6e 67 6f 71 61 2c 44 43 3d 6c 6f 63 61 6c 3f ingoqa,DC=local? 0360: 63 65 72 74 69 66 69 63 61 74 65 52 65 76 6f 63 certificateRevoc 0370: 61 74 69 6f 6e 4c 69 73 74 3f 62 61 73 65 3f 6f ationList?base?o 0380: 62 6a 65 63 74 43 6c 61 73 73 3d 63 52 4c 44 69 bjectClass=cRLDi 0390: 73 74 72 69 62 75 74 69 6f 6e 50 6f 69 6e 74 30 stributionPoint0 03a0: 81 be 06 08 2b 06 01 05 05 07 01 01 04 81 b1 30 ....+..........0 03b0: 81 ae 30 81 ab 06 08 2b 06 01 05 05 07 30 02 86 ..0....+.....0.. 03c0: 81 9e 6c 64 61 70 3a 2f 2f 2f 43 4e 3d 53 4b 59 ..ldap:///CN=SKY 03d0: 57 41 52 50 43 41 2c 43 4e 3d 41 49 41 2c 43 4e WARPCA,CN=AIA,CN 03e0: 3d 50 75 62 6c 69 63 25 32 30 4b 65 79 25 32 30 =Public%20Key%20 03f0: 53 65 72 76 69 63 65 73 2c 43 4e 3d 53 65 72 76 Services,CN=Serv 0400: 69 63 65 73 2c 43 4e 3d 43 6f 6e 66 69 67 75 72 ices,CN=Configur 0410: 61 74 69 6f 6e 2c 44 43 3d 62 6f 69 6e 67 6f 71 ation,DC=boingoq 0420: 61 2c 44 43 3d 6c 6f 63 61 6c 3f 63 41 43 65 72 a,DC=local?cACer 0430: 74 69 66 69 63 61 74 65 3f 62 61 73 65 3f 6f 62 tificate?base?ob 0440: 6a 65 63 74 43 6c 61 73 73 3d 63 65 72 74 69 66 jectClass=certif 0450: 69 63 61 74 69 6f 6e 41 75 74 68 6f 72 69 74 79 icationAuthority 0460: 30 44 06 03 55 1d 11 04 3d 30 3b a0 1f 06 09 2b 0D..U...=0;....+ 0470: 06 01 04 01 82 37 19 01 a0 12 04 10 75 e8 a1 fe .....7......u... 0480: 6a 23 41 4c 92 f3 0f 8d 03 5e ea 10 82 18 51 41 j#AL.....^....QA 0490: 54 45 53 54 44 43 32 2e 62 6f 69 6e 67 6f 71 61 TESTDC2.boingoqa 04a0: 2e 6c 6f 63 61 6c 30 0d 06 09 2a 86 48 86 f7 0d .local0...*.H... 04b0: 01 01 04 05 00 03 82 02 01 00 a8 1e e9 8a 00 5d ...............] 04c0: 4c 40 3a d1 df b7 e1 3e 8e 97 e8 a5 c9 84 8e 7b L@:....>.......{ 04d0: 0d 38 01 83 39 b9 d1 8a e9 74 eb 01 f6 a3 23 54 .8..9....t....#T 04e0: d3 81 2c d9 31 50 d2 1f b7 5c 15 9d b9 18 d2 36 ..,.1P...\.....6 04f0: d4 18 34 26 5f ba d2 9d 8b d8 34 d9 2e f7 99 2e ..4&_.....4..... 0500: 5b 47 1a f6 26 55 fc 03 60 2c 63 4f e3 2a 65 5c [G..&U..`,cO.*e\ 0510: d0 90 69 8b 0b 4b 6a fc 83 9b d2 2d df ef 98 99 ..i..Kj....-.... 0520: bd b9 6c 17 79 1d 61 98 df 95 58 74 d3 ac e0 12 ..l.y.a...Xt.... 0530: 70 10 d3 02 e6 c6 32 7e d6 22 21 9e 5a a1 9b 13 p.....2~."!.Z... 0540: 60 82 2d 44 46 2f b2 16 02 8e 00 64 7f 45 04 e2 `.-DF/.....d.E.. 0550: 71 d7 19 ca 95 42 d9 bb a6 b3 4d e4 dc 95 06 c0 q....B....M..... 0560: e7 3a 5a 39 f0 aa fe 31 35 6d 34 e1 83 8f 79 0d .:Z9...15m4...y. 0570: b0 dd 3c 98 ef 0d 1d 66 8f 3f 54 b6 11 d2 30 a7 ..<....f.?T...0. 0580: 4d 2b e5 e3 b8 38 b1 d4 b7 92 73 21 3b 59 1b 9f M+...8....s!;Y.. 0590: cd e5 2b 93 3e 60 f2 02 58 02 db 7a f0 81 b6 8a ..+.>`..X..z.... 05a0: aa d8 bd ... tls_read: want=1617, got=1448 0000: 90 36 a9 a9 c7 28 ba 3c 05 a3 2a 4b 0c 51 e8 86 .6...(.<..*K.Q.. 0010: 82 35 29 7c 02 15 d3 84 99 6e 74 3a e3 c2 2b 36 .5)|.....nt:..+6 0020: f9 3a aa 7d b4 b6 5a a7 ff 34 2e 03 9d c3 f1 a5 .:.}..Z..4...... 0030: 02 55 5e 8d 12 bc b6 0f c1 07 75 76 59 58 b5 2b .U^.......uvYX.+ 0040: 9b 47 d6 5e 5e 8f 83 9e b0 50 ae 37 14 18 31 4e .G.^^....P.7..1N 0050: 50 eb 20 51 70 6d 96 e6 6e 63 d2 f7 ed 75 35 f0 P. Qpm..nc...u5. 0060: b3 ab 35 4d 34 f8 f2 6c 7a 69 78 67 21 cf c4 c7 ..5M4..lzixg!... 0070: 4c 0d 48 7b c3 4e de e1 07 a5 f4 d1 61 ce 12 5c L.H{.N......a..\ 0080: 8c 50 28 17 d3 6b ec cd 0d e5 d9 09 31 32 69 6d .P(..k......12im 0090: c5 a5 7b 3b 3e 23 fa 3e d6 05 39 13 5f 9a 77 29 ..{;>#.>..9._.w) 00a0: f0 ba 25 c1 42 9f 73 17 0a c5 71 9c 0a ec 6f 2f ..%.B.s...q...o/ 00b0: d5 cd 69 8c 87 c3 c8 f9 ab a0 8c 70 de 2c 94 84 ..i........p.,.. 00c0: ce 35 ff dd 56 6b 80 af 81 af 58 ee 7e 06 63 7e .5..Vk....X.~.c~ 00d0: 96 d1 a6 d0 b7 8c 0d 8b c4 e1 18 44 f4 8e 83 73 ...........D...s 00e0: 41 81 10 df a9 94 8d 9b 0c 84 d9 58 79 b0 a1 2d A..........Xy..- 00f0: ce 7b 75 8b b9 87 15 5e 33 5c 9b e5 b2 8f d3 3e .{u....^3\.....> 0100: f2 e5 f3 ec d6 ac ef f1 70 f3 92 4a 21 ab a4 4c ........p..J!..L 0110: 2f 98 77 b4 0b 98 1a 0d 00 05 32 03 01 02 40 05 /.w.......2... at . 0120: 2c 00 25 30 23 31 21 30 1f 06 03 55 04 03 13 18 ,.%0#1!0...U.... 0130: 51 41 54 45 53 54 44 43 32 2e 62 6f 69 6e 67 6f QATESTDC2.boingo 0140: 71 61 2e 6c 6f 63 61 6c 00 47 30 45 31 15 30 13 qa.local.G0E1.0. 0150: 06 0a 09 92 26 89 93 f2 2c 64 01 19 16 05 6c 6f ....&...,d....lo 0160: 63 61 6c 31 18 30 16 06 0a 09 92 26 89 93 f2 2c cal1.0.....&..., 0170: 64 01 19 16 08 62 6f 69 6e 67 6f 71 61 31 12 30 d....boingoqa1.0 0180: 10 06 03 55 04 03 13 09 53 4b 59 57 41 52 50 43 ...U....SKYWARPC 0190: 41 00 48 30 46 31 15 30 13 06 0a 09 92 26 89 93 A.H0F1.0.....&.. 01a0: f2 2c 64 01 19 16 05 6c 6f 63 61 6c 31 18 30 16 .,d....local1.0. 01b0: 06 0a 09 92 26 89 93 f2 2c 64 01 19 16 08 62 6f ....&...,d....bo 01c0: 69 6e 67 6f 71 61 31 13 30 11 06 03 55 04 03 13 ingoqa1.0...U... 01d0: 0a 62 6f 69 6e 67 6f 71 61 63 61 00 67 30 65 31 .boingoqaca.g0e1 01e0: 0b 30 09 06 03 55 04 06 13 02 55 53 31 15 30 13 .0...U....US1.0. 01f0: 06 03 55 04 0a 13 0c 44 69 67 69 43 65 72 74 20 ..U....DigiCert 0200: 49 6e 63 31 19 30 17 06 03 55 04 0b 13 10 77 77 Inc1.0...U....ww 0210: 77 2e 64 69 67 69 63 65 72 74 2e 63 6f 6d 31 24 w.digicert.com1$ 0220: 30 22 06 03 55 04 03 13 1b 44 69 67 69 43 65 72 0"..U....DigiCer 0230: 74 20 41 73 73 75 72 65 64 20 49 44 20 52 6f 6f t Assured ID Roo 0240: 74 20 43 41 00 cd 30 81 ca 31 0b 30 09 06 03 55 t CA..0..1.0...U 0250: 04 06 13 02 55 53 31 17 30 15 06 03 55 04 0a 13 ....US1.0...U... 0260: 0e 56 65 72 69 53 69 67 6e 2c 20 49 6e 63 2e 31 .VeriSign, Inc.1 0270: 1f 30 1d 06 03 55 04 0b 13 16 56 65 72 69 53 69 .0...U....VeriSi 0280: 67 6e 20 54 72 75 73 74 20 4e 65 74 77 6f 72 6b gn Trust Network 0290: 31 3a 30 38 06 03 55 04 0b 13 31 28 63 29 20 32 1:08..U...1(c) 2 02a0: 30 30 36 20 56 65 72 69 53 69 67 6e 2c 20 49 6e 006 VeriSign, In 02b0: 63 2e 20 2d 20 46 6f 72 20 61 75 74 68 6f 72 69 c. - For authori 02c0: 7a 65 64 20 75 73 65 20 6f 6e 6c 79 31 45 30 43 zed use only1E0C 02d0: 06 03 55 04 03 13 3c 56 65 72 69 53 69 67 6e 20 ..U... 75 62 6c 69 63 20 50 Class 3 Public P 02f0: 72 69 6d 61 72 79 20 43 65 72 74 69 66 69 63 61 rimary Certifica 0300: 74 69 6f 6e 20 41 75 74 68 6f 72 69 74 79 20 2d tion Authority - 0310: 20 47 35 00 61 30 5f 31 0b 30 09 06 03 55 04 06 G5.a0_1.0...U.. 0320: 13 02 55 53 31 17 30 15 06 03 55 04 0a 13 0e 56 ..US1.0...U....V 0330: 65 72 69 53 69 67 6e 2c 20 49 6e 63 2e 31 37 30 eriSign, Inc.170 0340: 35 06 03 55 04 0b 13 2e 43 6c 61 73 73 20 33 20 5..U....Class 3 0350: 50 75 62 6c 69 63 20 50 72 69 6d 61 72 79 20 43 Public Primary C 0360: 65 72 74 69 66 69 63 61 74 69 6f 6e 20 41 75 74 ertification Aut 0370: 68 6f 72 69 74 79 00 6e 30 6c 31 0b 30 09 06 03 hority.n0l1.0... 0380: 55 04 06 13 02 55 53 31 15 30 13 06 03 55 04 0a U....US1.0...U.. 0390: 13 0c 44 69 67 69 43 65 72 74 20 49 6e 63 31 19 ..DigiCert Inc1. 03a0: 30 17 06 03 55 04 0b 13 10 77 77 77 2e 64 69 67 0...U....www.dig 03b0: 69 63 65 72 74 2e 63 6f 6d 31 2b 30 29 06 03 55 icert.com1+0)..U 03c0: 04 03 13 22 44 69 67 69 43 65 72 74 20 48 69 67 ..."DigiCert Hig 03d0: 68 20 41 73 73 75 72 61 6e 63 65 20 45 56 20 52 h Assurance EV R 03e0: 6f 6f 74 20 43 41 00 77 30 75 31 0b 30 09 06 03 oot CA.w0u1.0... 03f0: 55 04 06 13 02 55 53 31 18 30 16 06 03 55 04 0a U....US1.0...U.. 0400: 13 0f 47 54 45 20 43 6f 72 70 6f 72 61 74 69 6f ..GTE Corporatio 0410: 6e 31 27 30 25 06 03 55 04 0b 13 1e 47 54 45 20 n1'0%..U....GTE 0420: 43 79 62 65 72 54 72 75 73 74 20 53 6f 6c 75 74 CyberTrust Solut 0430: 69 6f 6e 73 2c 20 49 6e 63 2e 31 23 30 21 06 03 ions, Inc.1#0!.. 0440: 55 04 03 13 1a 47 54 45 20 43 79 62 65 72 54 72 U....GTE CyberTr 0450: 75 73 74 20 47 6c 6f 62 61 6c 20 52 6f 6f 74 00 ust Global Root. 0460: 63 30 61 31 0b 30 09 06 03 55 04 06 13 02 55 53 c0a1.0...U....US 0470: 31 15 30 13 06 03 55 04 0a 13 0c 44 69 67 69 43 1.0...U....DigiC 0480: 65 72 74 20 49 6e 63 31 19 30 17 06 03 55 04 0b ert Inc1.0...U.. 0490: 13 10 77 77 77 2e 64 69 67 69 63 65 72 74 2e 63 ..www.digicert.c 04a0: 6f 6d 31 20 30 1e 06 03 55 04 03 13 17 44 69 67 om1 0...U....Dig 04b0: 69 43 65 72 74 20 47 6c 6f 62 61 6c 20 52 6f 6f iCert Global Roo 04c0: 74 20 43 41 00 5c 30 5a 31 0b 30 09 06 03 55 04 t CA.\0Z1.0...U. 04d0: 06 13 02 49 45 31 12 30 10 06 03 55 04 0a 13 09 ...IE1.0...U.... 04e0: 42 61 6c 74 69 6d 6f 72 65 31 13 30 11 06 03 55 Baltimore1.0...U 04f0: 04 0b 13 0a 43 79 62 65 72 54 72 75 73 74 31 22 ....CyberTrust1" 0500: 30 20 06 03 55 04 03 13 19 42 61 6c 74 69 6d 6f 0 ..U....Baltimo 0510: 72 65 20 43 79 62 65 72 54 72 75 73 74 20 52 6f re CyberTrust Ro 0520: 6f 74 00 37 30 35 31 13 30 11 06 03 55 04 0a 13 ot.7051.0...U... 0530: 0a 42 4f 49 4e 47 4f 2e 43 4f 4d 31 1e 30 1c 06 .BOINGO.COM1.0.. 0540: 03 55 04 03 13 15 43 65 72 74 69 66 69 63 61 74 .U....Certificat 0550: 65 20 41 75 74 68 6f 72 69 74 79 00 72 30 70 31 e Authority.r0p1 0560: 2b 30 29 06 03 55 04 0b 13 22 43 6f 70 79 72 69 +0)..U..."Copyri 0570: 67 68 74 20 28 63 29 20 31 39 39 37 20 4d 69 63 ght (c) 1997 Mic 0580: 72 6f 73 6f 66 74 20 43 6f 72 70 2e 31 1e 30 1c rosoft Corp.1.0. 0590: 06 03 55 04 0b 13 15 4d 69 63 72 6f 73 6f 66 74 ..U....Microsoft 05a0: 20 43 6f 72 70 6f 72 61 Corpora tls_read: want=169, got=169 0000: 74 69 6f 6e 31 21 30 1f 06 03 55 04 03 13 18 4d tion1!0...U....M 0010: 69 63 72 6f 73 6f 66 74 20 52 6f 6f 74 20 41 75 icrosoft Root Au 0020: 74 68 6f 72 69 74 79 00 61 30 5f 31 13 30 11 06 thority.a0_1.0.. 0030: 0a 09 92 26 89 93 f2 2c 64 01 19 16 03 63 6f 6d ...&...,d....com 0040: 31 19 30 17 06 0a 09 92 26 89 93 f2 2c 64 01 19 1.0.....&...,d.. 0050: 16 09 6d 69 63 72 6f 73 6f 66 74 31 2d 30 2b 06 ..microsoft1-0+. 0060: 03 55 04 03 13 24 4d 69 63 72 6f 73 6f 66 74 20 .U...$Microsoft 0070: 52 6f 6f 74 20 43 65 72 74 69 66 69 63 61 74 65 Root Certificate 0080: 20 41 75 74 68 6f 72 69 74 79 00 19 30 17 31 15 Authority..0.1. 0090: 30 13 06 03 55 04 03 13 0c 4e 54 20 41 55 54 48 0...U....NT AUTH 00a0: 4f 52 49 54 59 0e 00 00 00 ORITY.... TLS: certificate [CN=QATESTDC2.boingoqa.local] is not valid - error -8179:Peer's Certificate issuer is not recognized.. tls_write: want=205, written=205 0000: 16 03 01 00 8d 0b 00 00 03 00 00 00 10 00 00 82 ................ 0010: 00 80 51 77 d5 b2 c4 16 28 3f 82 11 3e 6c 03 b7 ..Qw....(?..>l.. 0020: 6e 32 cc f0 cd 91 fb 91 7b 1d 56 a1 c0 68 3d 5d n2......{.V..h=] 0030: 12 17 b0 28 8c 66 36 80 3b b0 a4 a5 a8 f5 bb cd ...(.f6.;....... 0040: cf c9 00 25 ce 30 20 e0 ae 3c 7e 5d e3 d9 7a ac ...%.0 ..<~]..z. 0050: 53 b9 3a fb c7 ed d1 30 0e 67 a0 75 57 5f 1a d8 S.:....0.g.uW_.. 0060: 83 21 b6 40 6a ef d3 3c af ec 4b 23 40 09 01 46 .!. at j..<..K#@..F 0070: f2 42 ff e9 b6 1b e9 0b 68 9b 1e ad dd 6b 50 ab .B......h....kP. 0080: 4b 1e 8e 20 c4 5b 5c ce c1 41 71 2d cc 89 07 03 K.. .[\..Aq-.... 0090: 3b b8 14 03 01 00 01 01 16 03 01 00 30 04 98 00 ;...........0... 00a0: 76 2c 80 06 50 3d 3e 40 c9 a9 7c aa 38 be 7a 88 v,..P=>@..|.8.z. 00b0: fe 82 46 0d a5 5d ef 52 3b af 52 2d 54 52 21 e1 ..F..].R;.R-TR!. 00c0: 43 23 6c 30 90 00 71 9b a6 84 d1 d5 e9 C#l0..q...... tls_read: want=5, got=5 0000: 14 03 01 00 01 ..... tls_read: want=1, got=1 0000: 01 . tls_read: want=5, got=5 0000: 16 03 01 00 30 ....0 tls_read: want=48, got=48 0000: 5e 06 20 97 b5 95 ed af 95 f7 e9 d4 dc 1c 9c 36 ^. ............6 0010: e4 09 16 8e 39 fe e1 55 52 68 d4 18 bd 05 59 8d ....9..URh....Y. 0020: f5 25 0f 95 01 70 ef 58 80 f8 47 a6 93 5f 1a d2 .%...p.X..G.._.. TLS certificate verification: subject: CN=QATESTDC2.boingoqa.local, issuer: CN=SKYWARPCA,DC=boingoqa,DC=local, cipher: AES-128, security level: high, secret key bits: 128, total key bits: 128, cache hits: 0, cache misses: 0, cache not reusable: 0 Enter LDAP Password: ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 65 bytes to sd 3 tls_write: want=101, written=101 0000: 17 03 01 00 60 37 2e 2c f3 b1 6a 3f 9e f7 30 eb ....`7.,..j?..0. 0010: 1d ad ed 7b 62 b2 43 43 fd dd de b9 0f 13 1d 79 ...{b.CC.......y 0020: fa 30 2c a5 96 03 04 22 61 18 b7 87 26 06 8c ba .0,...."a...&... 0030: fa 31 1f 12 f8 f9 b8 32 bb 96 ef 8d 75 98 04 e9 .1.....2....u... 0040: ff d8 d7 50 44 c2 ec 7c 03 26 fb 47 07 a8 a8 44 ...PD..|.&.G...D 0050: 98 22 c6 bb 95 d0 b1 4b 83 34 0a a0 79 7d 15 39 .".....K.4..y}.9 0060: f9 77 36 0d 86 .w6.. ldap_write: want=65, written=65 0000: 30 3f 02 01 02 60 3a 02 01 03 04 2a 63 6e 3d 69 0?...`:....*cn=i 0010: 64 6d 20 61 64 6d 69 6e 2c 63 6e 3d 75 73 65 72 dm admin,cn=user 0020: 73 2c 64 63 3d 62 6f 69 6e 67 6f 71 61 2c 64 63 s,dc=boingoqa,dc 0030: 3d 6c 6f 63 61 6c 80 09 67 30 5f 62 30 69 6e 67 =local..g0_b0ing 0040: 30 0 ldap_result ld 0x1af3480 msgid 2 wait4msg ld 0x1af3480 msgid 2 (infinite timeout) wait4msg continue ld 0x1af3480 msgid 2 all 1 ** ld 0x1af3480 Connections: * host: qatestdc2.boingoqa.local port: 389 (default) refcnt: 2 status: Connected last used: Fri Jan 31 16:30:43 2014 ** ld 0x1af3480 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x1af3480 request count 1 (abandoned 0) ** ld 0x1af3480 Response Queue: Empty ld 0x1af3480 response count 0 ldap_chkResponseList ld 0x1af3480 msgid 2 all 1 ldap_chkResponseList returns ld 0x1af3480 NULL ldap_int_select read1msg: ld 0x1af3480 msgid 2 all 1 ber_get_next tls_read: want=5, got=5 0000: 17 03 01 00 30 ....0 tls_read: want=48, got=48 0000: 23 47 ac 27 3e 60 2b 38 e2 0d 99 99 ce 3b f5 b1 #G.'>`+8.....;.. 0010: ae ae 7e 2a 18 40 53 b7 d2 06 7a e7 7f 7f 06 0e ..~*. at S...z..... 0020: eb ff 91 c4 76 30 8c 0c ed 5a 94 d2 32 14 d5 1d ....v0...Z..2... ldap_read: want=8, got=8 0000: 30 84 00 00 00 10 02 01 0....... ldap_read: want=14, got=14 0000: 02 61 84 00 00 00 07 0a 01 00 04 00 04 00 .a............ ber_get_next: tag 0x30 len 16 contents: read1msg: ld 0x1af3480 msgid 2 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 0x1af3480 0 new referrals read1msg: mark request completed, ld 0x1af3480 msgid 2 request done: ld 0x1af3480 msgid 2 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_search_ext put_filter: "(objectclass=*)" put_filter: simple put_simple_filter: "objectclass=*" ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 81 bytes to sd 3 tls_write: want=117, written=117 0000: 17 03 01 00 70 1e f0 51 eb f7 9e 45 2a 29 20 50 ....p..Q...E*) P 0010: 03 f2 88 b8 31 68 1d 0d 04 4d 5b c9 f3 e5 9c 6a ....1h...M[....j 0020: 32 b2 fc c2 0f 2d fa e4 c2 1d ae ce 17 15 75 e8 2....-........u. 0030: 63 47 44 ab 82 0f c9 9d 90 3f 16 60 7a 7b 6d c1 cGD......?.`z{m. 0040: 64 10 1e e8 01 14 f8 b4 7c 54 a9 4a 84 ac b2 dc d.......|T.J.... 0050: bd 47 07 4f b7 48 6d 54 87 2e 26 4a 84 c8 a5 b9 .G.O.HmT..&J.... 0060: 8e a3 68 80 10 50 02 70 34 72 83 b6 64 72 8b 70 ..h..P.p4r..dr.p 0070: 07 cd 8e c0 b9 ..... ldap_write: want=81, written=81 0000: 30 4f 02 01 03 63 4a 04 2a 63 6e 3d 69 64 6d 20 0O...cJ.*cn=idm 0010: 61 64 6d 69 6e 2c 63 6e 3d 75 73 65 72 73 2c 64 admin,cn=users,d 0020: 63 3d 62 6f 69 6e 67 6f 71 61 2c 64 63 3d 6c 6f c=boingoqa,dc=lo 0030: 63 61 6c 0a 01 02 0a 01 00 02 01 00 02 01 00 01 cal............. 0040: 01 00 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 30 ....objectclass0 0050: 00 . ldap_result ld 0x1af3480 msgid -1 wait4msg ld 0x1af3480 msgid -1 (infinite timeout) wait4msg continue ld 0x1af3480 msgid -1 all 0 ** ld 0x1af3480 Connections: * host: qatestdc2.boingoqa.local port: 389 (default) refcnt: 2 status: Connected last used: Fri Jan 31 16:30:43 2014 ** ld 0x1af3480 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x1af3480 request count 1 (abandoned 0) ** ld 0x1af3480 Response Queue: Empty ld 0x1af3480 response count 0 ldap_chkResponseList ld 0x1af3480 msgid -1 all 0 ldap_chkResponseList returns ld 0x1af3480 NULL ldap_int_select read1msg: ld 0x1af3480 msgid -1 all 0 ber_get_next tls_read: want=5, got=5 0000: 17 03 01 06 40 ....@ tls_read: want=1600, got=1600 0000: f0 a7 12 28 36 88 72 46 57 ea 69 d3 d5 dd f6 ee ...(6.rFW.i..... 0010: 58 58 ba f5 b2 d9 b4 57 7f 81 e4 fd 31 61 a9 2e XX.....W....1a.. 0020: 88 b7 7d da d6 98 b2 6e 8c 17 36 ff 9f a5 d7 d4 ..}....n..6..... 0030: fd de 24 2c 2c 5c 4e aa 02 1a e2 c8 cf b7 5d eb ..$,,\N.......]. 0040: 1f e2 3c 0a 8b dc 6a 26 25 0f 5a 27 4a 8e 27 b4 ..<...j&%.Z'J.'. 0050: b8 8d 98 2d 8a 62 23 be a0 61 a6 a3 01 63 40 ae ...-.b#..a...c at . 0060: 41 2e bf 8a 1f 53 4b d5 10 53 2c 64 07 0c 0d d8 A....SK..S,d.... 0070: 51 36 6b 75 b5 25 c3 87 21 df 5f 1a 13 82 19 90 Q6ku.%..!._..... 0080: 42 13 b1 d9 71 94 83 b7 74 00 95 66 b5 38 a0 85 B...q...t..f.8.. 0090: b3 82 92 e2 f0 f5 88 f4 06 78 c3 55 f0 ea 16 6b .........x.U...k 00a0: 77 2e 65 09 81 ce 8e 56 75 8f fe 91 d8 3f dc 53 w.e....Vu....?.S 00b0: 23 bf ab cd bb 6d 23 d7 88 14 b1 0b eb 6f ab 8a #....m#......o.. 00c0: 00 8b 4f 83 d7 22 17 71 cb 4f 65 67 a9 0e 41 95 ..O..".q.Oeg..A. 00d0: 1f 42 4c e0 68 17 13 9e 1a d4 64 88 ff e2 ee 52 .BL.h.....d....R 00e0: 60 a0 ce 36 80 b9 38 eb 8b 85 e7 3a b1 fa 4b 2c `..6..8....:..K, 00f0: 89 71 79 60 04 2c 6c 5c 8f 7f bb 7e c1 fd d0 c1 .qy`.,l\...~.... 0100: b9 7c 6f fb bc 70 06 f0 f9 11 ee 44 58 4f eb c2 .|o..p.....DXO.. 0110: 86 23 83 0c 49 e0 81 5d 4f 37 f5 70 70 af b9 ed .#..I..]O7.pp... 0120: dc 08 a9 77 4b 56 80 f0 c1 cc 55 87 3f 2a a1 63 ...wKV....U.?*.c 0130: 27 b5 c2 8c 9f ca ee 61 1b 5d 38 b5 df 80 39 f7 '......a.]8...9. 0140: e9 b5 6f b8 1d b0 ad d6 20 dd c6 f0 bd c8 fd 87 ..o..... ....... 0150: 4f ea 13 a7 11 09 ee 20 e5 68 f7 f1 10 ae 28 22 O...... .h....(" 0160: 79 55 5b 67 4f 3c 1b 36 eb 24 6d cc 5b 46 31 63 yU[gO<.6.$m.[F1c 0170: 45 ab 4a 50 66 43 80 aa 5c b1 0e cd f6 96 bc d4 E.JPfC..\....... 0180: ad d3 7e f9 48 2f 27 90 af 4e b1 eb c2 fb 81 0a ..~.H/'..N...... 0190: 6a e7 18 17 37 71 6c 42 b2 6a 81 ca e0 73 be 0f j...7qlB.j...s.. 01a0: 30 ab a3 aa 2a 12 23 54 ed f3 3e e2 a3 fd 5e f4 0...*.#T..>...^. 01b0: 70 0c 7f 32 bb b5 b5 98 25 4b fc a7 d6 ce 1e d9 p..2....%K...... 01c0: 29 03 ca 9a 2f 31 46 63 64 a8 9f 21 a2 0b e9 d6 ).../1Fcd..!.... 01d0: 2b d8 10 57 78 d0 ae fc 30 fd f5 92 f1 7d c4 7a +..Wx...0....}.z 01e0: 36 13 d0 67 0e 16 a4 13 b0 67 16 66 6f af 8c 0b 6..g.....g.fo... 01f0: bf 9f 59 c0 7b 1c 00 26 9f fa 87 f3 ae b0 4d 31 ..Y.{..&......M1 0200: 02 db 83 23 ed f9 3c bb 21 19 ea 47 0e 9f 39 3a ...#..<.!..G..9: 0210: 5b 7d bc 34 69 ff 5e cb 05 d5 32 b5 f2 d5 da f1 [}.4i.^...2..... 0220: 3c 56 c9 91 2e 71 ce d9 27 ec f7 93 97 f0 74 e1 .......t}.$ 0240: 58 2f d6 4b 50 a3 20 d3 0d c5 cd d1 9a 17 7f 12 X/.KP. ......... 0250: c5 b9 57 bf a0 7e a2 d3 29 08 00 07 78 52 dc 27 ..W..~..)...xR.' 0260: f7 9e e5 57 52 74 2b 5d 6c eb d6 b0 2c 07 08 84 ...WRt+]l...,... 0270: 87 39 7f a5 a2 d1 be 0e 02 42 b9 02 fe 01 69 78 .9.......B....ix 0280: c2 f7 26 6e 7e 3b ba 06 81 25 9d d3 8f ae 99 eb ..&n~;...%...... 0290: 44 37 c4 57 69 d9 c5 31 31 41 e8 49 70 07 34 95 D7.Wi..11A.Ip.4. 02a0: 50 cb fa 1b cd 3f d1 84 54 73 f6 69 0e ab 10 46 P....?..Ts.i...F 02b0: a8 1c cb e9 ad ab 80 f7 f4 3c 86 75 a4 de d1 7a .........<.u...z 02c0: d2 7a 47 02 ce ba 42 c8 53 05 76 ca 2e 1d 35 e6 .zG...B.S.v...5. 02d0: e6 23 70 ae e8 0f 2c 0f e6 ab 2a 65 8c ed 0a 7b .#p...,...*e...{ 02e0: ec 3a b5 4e 5b d9 b1 3d e5 4a 92 22 29 01 7e 11 .:.N[..=.J.").~. 02f0: 28 6a c2 48 3f 7f b8 c1 13 80 89 d3 e7 cb 19 7d (j.H?..........} 0300: e5 2e eb c9 b6 7b b0 dd 9f c0 4b ea 16 53 aa 11 .....{....K..S.. 0310: 24 17 c3 0c 5c 35 e2 fd 76 28 05 95 9d 40 a7 9b $...\5..v(... at .. 0320: 6b 3c 31 c0 2b a1 a2 68 ba 94 ec f7 12 51 85 1c k<1.+..h.....Q.. 0330: 96 18 2e 88 bd c8 d7 c2 04 fe 47 cc 73 9a af bd ..........G.s... 0340: 11 90 06 f6 9f e8 58 71 88 42 c9 e6 b8 0f 3f 70 ......Xq.B....?p 0350: a8 30 79 46 17 fa 2e ae 22 f8 b8 75 14 c0 7a e1 .0yF...."..u..z. 0360: 92 63 c0 62 4f 14 8e d9 78 30 e9 82 1f c4 df 2a .c.bO...x0.....* 0370: f2 13 5b c3 d3 3f 2b 2c 84 7e 9a d9 82 18 af 11 ..[..?+,.~...... 0380: 0f 7c 85 c8 e0 09 91 19 7a 56 cc 59 fc 0c da ca .|......zV.Y.... 0390: c8 84 8c cf 3e 18 e1 5a 07 5e 4e f0 b1 a9 14 88 ....>..Z.^N..... 03a0: e1 ee a2 a1 9b 98 7d f1 ac a0 61 06 ab 45 7e c5 ......}...a..E~. 03b0: 5e 0f 38 6f 75 5e 6e 9e d4 8a 29 6c 1a a5 62 06 ^.8ou^n...)l..b. 03c0: 0b cf 61 d6 b0 1d 48 4b f5 07 16 f6 d5 63 4c 23 ..a...HK.....cL# 03d0: 48 2e 35 b5 da e2 65 64 ab 9b 8d f3 5f 57 9a ec H.5...ed...._W.. 03e0: a4 b1 82 c1 7f 47 3e 4c 33 51 0d 25 05 7b 5c 3d .....G>L3Q.%.{\= 03f0: f2 6a 09 ab f8 52 d1 2f ac 48 ef 7a f7 44 d4 92 .j...R./.H.z.D.. 0400: 86 72 20 77 ff af e5 c8 3d 8e 34 4b d7 e2 3a 63 .r w....=.4K..:c 0410: 1a a2 d3 f0 50 86 61 1e 3c 8e ce f9 5d a9 b8 9d ....P.a.<...]... 0420: 00 9a 6d f2 3a c8 d7 b1 ea ad 96 cd 64 dd e0 83 ..m.:.......d... 0430: d3 b0 5b 84 bb c5 a5 fe fe 6e d9 85 fe a9 60 56 ..[......n....`V 0440: 01 8f ec 1e f6 d6 1b 1d 75 51 25 fb 6a 96 2d 02 ........uQ%.j.-. 0450: d2 fe fe 7b 33 48 7b d9 06 60 cc a4 e4 46 51 bb ...{3H{..`...FQ. 0460: 4f 21 ae 78 6a f6 cf 5a 81 6f 64 e7 bc 8f e5 63 O!.xj..Z.od....c 0470: 4b 31 a0 4b 2a 5d 0a 71 c3 fb d9 67 01 a3 03 14 K1.K*].q...g.... 0480: 5e 32 b1 4b 77 a2 03 47 07 da 9e 7c 0a 8a 40 5b ^2.Kw..G...|..@[ 0490: 28 bd 81 cf 1f 6c 7b 2e ae 21 1b 88 ce 72 08 02 (....l{..!...r.. 04a0: 1e 83 50 56 66 4b 0f 3e ca 6f 56 29 93 c2 1f 6f ..PVfK.>.oV)...o 04b0: 07 b9 0a d1 a1 f8 6b da 3b c6 20 8f 68 05 66 53 ......k.;. .h.fS 04c0: 61 3e 20 9a a4 05 13 15 b9 c0 55 f8 59 32 d8 3f a> .......U.Y2.? 04d0: 79 50 c0 2a 89 1d 3c 12 f1 64 d8 84 b4 f9 ed 95 yP.*..<..d...... 04e0: 25 39 b7 72 8f 53 cb 8a 6a f0 b8 76 bd 6d 42 30 %9.r.S..j..v.mB0 04f0: 96 e7 18 ee d9 6f 56 57 d2 e8 ee 68 a7 73 1c a5 .....oVW...h.s.. 0500: 02 31 b3 8f 29 c5 36 c0 ed 29 50 c1 19 da 45 7d .1..).6..)P...E} 0510: e1 be e3 7d 2e 54 20 93 94 a2 02 ab 42 e0 71 4b ...}.T .....B.qK 0520: 1d 14 98 6e 27 fc d6 7f 98 58 98 7a 30 2f 39 19 ...n'....X.z0/9. 0530: 62 e0 32 1a 8a 12 b8 b0 03 55 66 9b 72 b4 ac ff b.2......Uf.r... 0540: e4 7c eb 1d 80 b5 f6 b6 33 15 01 f8 bb aa 8e d0 .|......3....... 0550: 39 f4 2d e1 d1 79 3f 63 e0 61 02 d9 5b 1e 1f e7 9.-..y?c.a..[... 0560: c9 31 a8 5a cc d8 90 cc 78 3f 09 bd e3 20 e3 d3 .1.Z....x?... .. 0570: c2 bd 0d 5f 17 1b 4d 97 62 ca ed b6 37 95 12 ec ..._..M.b...7... 0580: d0 eb 6a 2a 34 64 77 16 08 82 5f ca 21 1a 7e cd ..j*4dw..._.!.~. 0590: a3 91 4d ce f6 7b a7 a9 00 03 8a b2 e9 05 a5 89 ..M..{.......... 05a0: 9a ef 05 24 a3 c9 ab 0b a6 1d ec 36 76 5f 9e b3 ...$.......6v_.. 05b0: d8 01 b8 29 e4 04 19 5e 36 84 3a a7 ac 56 bb 2f ...)...^6.:..V./ 05c0: 51 bf fc e0 46 cc d9 b1 7f ac 34 99 ea 8d ca 24 Q...F.....4....$ 05d0: 03 23 ec 71 d4 dc 13 fb a6 86 81 99 41 8b 7f dd .#.q........A... 05e0: 67 ec 02 a6 fc 21 f5 50 82 e6 3c 46 04 88 62 f6 g....!.P....A.a 0610: 7b 20 8a 5e 65 c3 d9 e1 42 d2 88 fe c5 4e cf fa { .^e...B....N.. 0620: c6 ea cc 43 52 bc 08 92 e5 c0 d1 21 4a b9 f7 aa ...CR......!J... 0630: 50 a7 61 c6 47 0c f0 f4 1c b1 ab cb 06 00 d1 0d P.a.G........... ldap_read: want=8, got=8 0000: 30 84 00 00 06 01 02 01 0....... ldap_read: want=1535, got=1535 0000: 03 64 84 00 00 05 f8 04 2a 43 4e 3d 49 44 4d 20 .d......*CN=IDM 0010: 41 44 4d 49 4e 2c 43 4e 3d 55 73 65 72 73 2c 44 ADMIN,CN=Users,D 0020: 43 3d 62 6f 69 6e 67 6f 71 61 2c 44 43 3d 6c 6f C=boingoqa,DC=lo 0030: 63 61 6c 30 84 00 00 05 c6 30 84 00 00 00 3c 04 cal0.....0....<. 0040: 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 84 00 00 .objectClass1... 0050: 00 29 04 03 74 6f 70 04 06 70 65 72 73 6f 6e 04 .)..top..person. 0060: 14 6f 72 67 61 6e 69 7a 61 74 69 6f 6e 61 6c 50 .organizationalP 0070: 65 72 73 6f 6e 04 04 75 73 65 72 30 84 00 00 00 erson..user0.... 0080: 15 04 02 63 6e 31 84 00 00 00 0b 04 09 49 44 4d ...cn1.......IDM 0090: 20 41 44 4d 49 4e 30 84 00 00 00 1b 04 09 67 69 ADMIN0.......gi 00a0: 76 65 6e 4e 61 6d 65 31 84 00 00 00 0a 04 08 49 venName1.......I 00b0: 44 4d 41 44 4d 49 4e 30 84 00 00 00 45 04 11 64 DMADMIN0....E..d 00c0: 69 73 74 69 6e 67 75 69 73 68 65 64 4e 61 6d 65 istinguishedName 00d0: 31 84 00 00 00 2c 04 2a 43 4e 3d 49 44 4d 20 41 1....,.*CN=IDM A 00e0: 44 4d 49 4e 2c 43 4e 3d 55 73 65 72 73 2c 44 43 DMIN,CN=Users,DC 00f0: 3d 62 6f 69 6e 67 6f 71 61 2c 44 43 3d 6c 6f 63 =boingoqa,DC=loc 0100: 61 6c 30 84 00 00 00 17 04 0c 69 6e 73 74 61 6e al0.......instan 0110: 63 65 54 79 70 65 31 84 00 00 00 03 04 01 34 30 ceType1.......40 0120: 84 00 00 00 26 04 0b 77 68 65 6e 43 72 65 61 74 ....&..whenCreat 0130: 65 64 31 84 00 00 00 13 04 11 32 30 31 34 30 31 ed1.......201401 0140: 32 38 31 38 32 35 33 37 2e 30 5a 30 84 00 00 00 28182537.0Z0.... 0150: 26 04 0b 77 68 65 6e 43 68 61 6e 67 65 64 31 84 &..whenChanged1. 0160: 00 00 00 13 04 11 32 30 31 34 30 31 33 31 30 31 ......2014013101 0170: 34 33 31 35 2e 30 5a 30 84 00 00 00 1d 04 0b 64 4315.0Z0.......d 0180: 69 73 70 6c 61 79 4e 61 6d 65 31 84 00 00 00 0a isplayName1..... 0190: 04 08 49 44 4d 41 44 4d 49 4e 30 84 00 00 00 19 ..IDMADMIN0..... 01a0: 04 0a 75 53 4e 43 72 65 61 74 65 64 31 84 00 00 ..uSNCreated1... 01b0: 00 07 04 05 33 31 39 36 38 30 84 00 00 00 af 04 ....319680...... 01c0: 08 6d 65 6d 62 65 72 4f 66 31 84 00 00 00 9f 04 .memberOf1...... 01d0: 33 43 4e 3d 44 6f 6d 61 69 6e 20 43 6f 6e 74 72 3CN=Domain Contr 01e0: 6f 6c 6c 65 72 73 2c 43 4e 3d 55 73 65 72 73 2c ollers,CN=Users, 01f0: 44 43 3d 62 6f 69 6e 67 6f 71 61 2c 44 43 3d 6c DC=boingoqa,DC=l 0200: 6f 63 61 6c 04 34 43 4e 3d 41 63 63 6f 75 6e 74 ocal.4CN=Account 0210: 20 4f 70 65 72 61 74 6f 72 73 2c 43 4e 3d 42 75 Operators,CN=Bu 0220: 69 6c 74 69 6e 2c 44 43 3d 62 6f 69 6e 67 6f 71 iltin,DC=boingoq 0230: 61 2c 44 43 3d 6c 6f 63 61 6c 04 32 43 4e 3d 45 a,DC=local.2CN=E 0240: 6e 74 65 72 70 72 69 73 65 20 41 64 6d 69 6e 73 nterprise Admins 0250: 2c 43 4e 3d 55 73 65 72 73 2c 44 43 3d 62 6f 69 ,CN=Users,DC=boi 0260: 6e 67 6f 71 61 2c 44 43 3d 6c 6f 63 61 6c 30 84 ngoqa,DC=local0. 0270: 00 00 00 19 04 0a 75 53 4e 43 68 61 6e 67 65 64 ......uSNChanged 0280: 31 84 00 00 00 07 04 05 33 38 37 38 36 30 84 00 1.......387860.. 0290: 00 00 17 04 04 6e 61 6d 65 31 84 00 00 00 0b 04 .....name1...... 02a0: 09 49 44 4d 20 41 44 4d 49 4e 30 84 00 00 00 24 .IDM ADMIN0....$ 02b0: 04 0a 6f 62 6a 65 63 74 47 55 49 44 31 84 00 00 ..objectGUID1... 02c0: 00 12 04 10 8d a8 ba dc 97 c3 bd 4b 8e 19 c5 11 ...........K.... 02d0: 9e d0 3b 86 30 84 00 00 00 21 04 12 75 73 65 72 ..;.0....!..user 02e0: 41 63 63 6f 75 6e 74 43 6f 6e 74 72 6f 6c 31 84 AccountControl1. 02f0: 00 00 00 07 04 05 36 36 30 34 38 30 84 00 00 00 ......660480.... 0300: 16 04 0b 62 61 64 50 77 64 43 6f 75 6e 74 31 84 ...badPwdCount1. 0310: 00 00 00 03 04 01 30 30 84 00 00 00 13 04 08 63 ......00.......c 0320: 6f 64 65 50 61 67 65 31 84 00 00 00 03 04 01 30 odePage1.......0 0330: 30 84 00 00 00 16 04 0b 63 6f 75 6e 74 72 79 43 0.......countryC 0340: 6f 64 65 31 84 00 00 00 03 04 01 30 30 84 00 00 ode1.......00... 0350: 00 1a 04 0f 62 61 64 50 61 73 73 77 6f 72 64 54 ....badPasswordT 0360: 69 6d 65 31 84 00 00 00 03 04 01 30 30 84 00 00 ime1.......00... 0370: 00 15 04 0a 6c 61 73 74 4c 6f 67 6f 66 66 31 84 ....lastLogoff1. 0380: 00 00 00 03 04 01 30 30 84 00 00 00 14 04 09 6c ......00.......l 0390: 61 73 74 4c 6f 67 6f 6e 31 84 00 00 00 03 04 01 astLogon1....... 03a0: 30 30 84 00 00 00 26 04 0a 70 77 64 4c 61 73 74 00....&..pwdLast 03b0: 53 65 74 31 84 00 00 00 14 04 12 31 33 30 33 35 Set1.......13035 03c0: 36 30 30 38 30 30 36 30 39 33 37 35 30 30 84 00 60080060937500.. 03d0: 00 00 1b 04 0e 70 72 69 6d 61 72 79 47 72 6f 75 .....primaryGrou 03e0: 70 49 44 31 84 00 00 00 05 04 03 35 31 33 30 84 pID1.......5130. 03f0: 00 00 00 2f 04 09 6f 62 6a 65 63 74 53 69 64 31 .../..objectSid1 0400: 84 00 00 00 1e 04 1c 01 05 00 00 00 00 00 05 15 ................ 0410: 00 00 00 d3 ef c6 53 9e 66 cf 78 74 85 0e 3c 47 ......S.f.xt.. 00 15 04 0a 61 64 6d 69 6e ...0.......admin 0430: 43 6f 75 6e 74 31 84 00 00 00 03 04 01 31 30 84 Count1.......10. 0440: 00 00 00 2b 04 0e 61 63 63 6f 75 6e 74 45 78 70 ...+..accountExp 0450: 69 72 65 73 31 84 00 00 00 15 04 13 39 32 32 33 ires1.......9223 0460: 33 37 32 30 33 36 38 35 34 37 37 35 38 30 37 30 3720368547758070 0470: 84 00 00 00 15 04 0a 6c 6f 67 6f 6e 43 6f 75 6e .......logonCoun 0480: 74 31 84 00 00 00 03 04 01 30 30 84 00 00 00 20 t1.......00.... 0490: 04 0e 73 41 4d 41 63 63 6f 75 6e 74 4e 61 6d 65 ..sAMAccountName 04a0: 31 84 00 00 00 0a 04 08 69 64 6d 61 64 6d 69 6e 1.......idmadmin 04b0: 30 84 00 00 00 21 04 0e 73 41 4d 41 63 63 6f 75 0....!..sAMAccou 04c0: 6e 74 54 79 70 65 31 84 00 00 00 0b 04 09 38 30 ntType1.......80 04d0: 35 33 30 36 33 36 38 30 84 00 00 00 32 04 11 75 53063680....2..u 04e0: 73 65 72 50 72 69 6e 63 69 70 61 6c 4e 61 6d 65 serPrincipalName 04f0: 31 84 00 00 00 19 04 17 69 64 6d 61 64 6d 69 6e 1.......idmadmin 0500: 40 62 6f 69 6e 67 6f 71 61 2e 6c 6f 63 61 6c 30 @boingoqa.local0 0510: 84 00 00 00 16 04 0b 6c 6f 63 6b 6f 75 74 54 69 .......lockoutTi 0520: 6d 65 31 84 00 00 00 03 04 01 30 30 84 00 00 00 me1.......00.... 0530: 51 04 0e 6f 62 6a 65 63 74 43 61 74 65 67 6f 72 Q..objectCategor 0540: 79 31 84 00 00 00 3b 04 39 43 4e 3d 50 65 72 73 y1....;.9CN=Pers 0550: 6f 6e 2c 43 4e 3d 53 63 68 65 6d 61 2c 43 4e 3d on,CN=Schema,CN= 0560: 43 6f 6e 66 69 67 75 72 61 74 69 6f 6e 2c 44 43 Configuration,DC 0570: 3d 62 6f 69 6e 67 6f 71 61 2c 44 43 3d 6c 6f 63 =boingoqa,DC=loc 0580: 61 6c 30 84 00 00 00 43 04 15 64 53 43 6f 72 65 al0....C..dSCore 0590: 50 72 6f 70 61 67 61 74 69 6f 6e 44 61 74 61 31 PropagationData1 05a0: 84 00 00 00 26 04 11 32 30 31 34 30 31 32 39 32 ....&..201401292 05b0: 32 34 30 32 34 2e 30 5a 04 11 31 36 30 31 30 31 24024.0Z..160101 05c0: 30 31 30 30 30 30 30 30 2e 30 5a 30 84 00 00 00 01000000.0Z0.... 05d0: 2e 04 12 6c 61 73 74 4c 6f 67 6f 6e 54 69 6d 65 ...lastLogonTime 05e0: 73 74 61 6d 70 31 84 00 00 00 14 04 12 31 33 30 stamp1.......130 05f0: 33 35 36 30 36 30 36 37 32 31 31 30 35 37 38 356060672110578 ber_get_next: tag 0x30 len 1537 contents: read1msg: ld 0x1af3480 msgid 3 message type search-entry ldap_get_dn_ber ber_scanf fmt ({ml{) ber: dn: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local ber_scanf fmt ({xx) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: cn: IDM ADMIN ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: givenName: IDMADMIN ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: distinguishedName: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: instanceType: 4 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: whenCreated: 20140128182537.0Z ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: whenChanged: 20140131014315.0Z ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: displayName: IDMADMIN ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: uSNCreated: 31968 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: memberOf: CN=Domain Controllers,CN=Users,DC=boingoqa,DC=local memberOf: CN=Account Operators,CN=Builtin,DC=boingoqa,DC=local memberOf: CN=Enterprise Admins,CN=Users,DC=boingoqa,DC=local ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: uSNChanged: 38786 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: name: IDM ADMIN ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: objectGUID:: jai63JfDvUuOGcURntA7hg== ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: userAccountControl: 66048 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: badPwdCount: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: codePage: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: countryCode: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: badPasswordTime: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: lastLogoff: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: lastLogon: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: pwdLastSet: 130356008006093750 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: primaryGroupID: 513 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: objectSid:: AQUAAAAAAAUVAAAA0+/GU55mz3h0hQ48RwYAAA== ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: adminCount: 1 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: accountExpires: 9223372036854775807 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: logonCount: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: sAMAccountName: idmadmin ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: sAMAccountType: 805306368 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: userPrincipalName: idmadmin at boingoqa.local ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: lockoutTime: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=boingoqa,DC=local ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: dSCorePropagationData: 20140129224024.0Z dSCorePropagationData: 16010101000000.0Z ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: lastLogonTimestamp: 130356060672110578 ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x1af3480 msgid -1 wait4msg ld 0x1af3480 msgid -1 (infinite timeout) wait4msg continue ld 0x1af3480 msgid -1 all 0 ** ld 0x1af3480 Connections: * host: qatestdc2.boingoqa.local port: 389 (default) refcnt: 2 status: Connected last used: Fri Jan 31 16:30:43 2014 ** ld 0x1af3480 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x1af3480 request count 1 (abandoned 0) ** ld 0x1af3480 Response Queue: Empty ld 0x1af3480 response count 0 ldap_chkResponseList ld 0x1af3480 msgid -1 all 0 ldap_chkResponseList returns ld 0x1af3480 NULL read1msg: ld 0x1af3480 msgid -1 all 0 ber_get_next ldap_read: want=8, got=8 0000: 30 84 00 00 00 10 02 01 0....... ldap_read: want=14, got=14 0000: 03 65 84 00 00 00 07 0a 01 00 04 00 04 00 .e............ ber_get_next: tag 0x30 len 16 contents: read1msg: ld 0x1af3480 msgid 3 message type search-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x1af3480 0 new referrals read1msg: mark request completed, ld 0x1af3480 msgid 3 request done: ld 0x1af3480 msgid 3 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 3, msgid 3) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 tls_write: want=37, written=37 0000: 17 03 01 00 20 a3 ef 55 d6 94 cc f5 97 4f fe c1 .... ..U.....O.. 0010: 09 95 0b 7a 4c 8f 6d b5 5f 9f 52 ca 5e a6 91 b6 ...zL.m._.R.^... 0020: 0f 9d c3 d6 b0 ..... ldap_write: want=7, written=7 0000: 30 05 02 01 04 42 00 0....B. tls_write: want=37, written=37 0000: 15 03 01 00 20 17 6f cd 57 b4 79 e3 ef 4f fb 1f .... .o.W.y..O.. 0010: 57 0b c5 c0 82 ba b4 b0 3e 7a de db 40 87 0d 32 W.......>z.. at ..2 0020: 4b ce 39 be 02 K.9.. ldap_free_connection: actually freed -Todd Maugh On Jan 31, 2014, at 10:16 AM, "Dmitri Pal" > wrote: On 01/31/2014 12:59 PM, Todd Maugh wrote: please help im stuck trying to finish this winsync agreement [root at se-idm-01.boingo.com slapd-BOINGO-COM]$ ipa-replica-manage connect --winsync --binddn "cn=idm admin, cn=Users, dc=boingoqa, dc=local" --bindpw "*******" --passsync "********" --cacert=/etc/openldap/cacerts/boingoqaCA.cer qatestdc2.boingoqa.local -v Directory Manager password: Added CA certificate /etc/openldap/cacerts/boingoqaCA.cer to certificate database for se-idm-01.boingo.com ipa: INFO: AD Suffix is: DC=boingoqa,DC=local The user for the Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=boingo,dc=com 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: -11 - LDAP error: Connect error: start: 0: end: 0 ipa: INFO: Agreement is ready, starting replication . . . Starting replication, please wait until this has completed. [se-idm-01.boingo.com] reports: Update failed! Status: [-11 - LDAP error: Connect error] Failed to start replication _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Some DS level logs might help. Also may it be a firewall issue? FW resetting connection or something like? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Fri Jan 31 18:25:26 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Fri, 31 Jan 2014 18:25:26 +0000 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local>, <52EBE850.9070108@redhat.com>, <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com> Message-ID: does that give any more info? -Todd Maugh On Jan 31, 2014, at 10:24 AM, "Todd Maugh" > wrote: [root at se-idm-01.boingo.com slapd-BOINGO-COM]$ cacertdir_rehash /etc/openldap/cacerts/ [root at se-idm-01.boingo.com slapd-BOINGO-COM]$ ldapsearch -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm admin,cn=users,dc=boingoqa,dc=local" -W Enter LDAP Password: dn: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: IDM ADMIN givenName: IDMADMIN distinguishedName: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local instanceType: 4 whenCreated: 20140128182537.0Z whenChanged: 20140131014315.0Z displayName: IDMADMIN uSNCreated: 31968 memberOf: CN=Domain Controllers,CN=Users,DC=boingoqa,DC=local memberOf: CN=Account Operators,CN=Builtin,DC=boingoqa,DC=local memberOf: CN=Enterprise Admins,CN=Users,DC=boingoqa,DC=local uSNChanged: 38786 name: IDM ADMIN objectGUID:: jai63JfDvUuOGcURntA7hg== userAccountControl: 66048 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 lastLogon: 0 pwdLastSet: 130356008006093750 primaryGroupID: 513 objectSid:: AQUAAAAAAAUVAAAA0+/GU55mz3h0hQ48RwYAAA== adminCount: 1 accountExpires: 9223372036854775807 logonCount: 0 sAMAccountName: idmadmin sAMAccountType: 805306368 userPrincipalName: idmadmin at boingoqa.local lockoutTime: 0 objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=boingoqa,DC=local dSCorePropagationData: 20140129224024.0Z dSCorePropagationData: 16010101000000.0Z lastLogonTimestamp: 130356060672110578 [root at se-idm-01.boingo.com slapd-BOINGO-COM]$ ldapsearch -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm admin,cn=users,dc=boingoqa,dc=local" -W -d3 ldap_url_parse_ext(ldap://qatestdc2.boingoqa.local) ldap_create ldap_url_parse_ext(ldap://qatestdc2.boingoqa.local:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP qatestdc2.boingoqa.local:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.194.55.48:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_write: want=31, written=31 0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 0....w...1.3.6.1 0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .4.1.1466.20037 ldap_result ld 0x1af3480 msgid 1 wait4msg ld 0x1af3480 msgid 1 (infinite timeout) wait4msg continue ld 0x1af3480 msgid 1 all 1 ** ld 0x1af3480 Connections: * host: qatestdc2.boingoqa.local port: 389 (default) refcnt: 2 status: Connected last used: Fri Jan 31 16:30:33 2014 ** ld 0x1af3480 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x1af3480 request count 1 (abandoned 0) ** ld 0x1af3480 Response Queue: Empty ld 0x1af3480 response count 0 ldap_chkResponseList ld 0x1af3480 msgid 1 all 1 ldap_chkResponseList returns ld 0x1af3480 NULL ldap_int_select read1msg: ld 0x1af3480 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 84 00 00 00 28 02 01 0....(.. ldap_read: want=38, got=38 0000: 01 78 84 00 00 00 1f 0a 01 00 04 00 04 00 8a 16 .x.............. 0010: 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 31 34 36 36 1.3.6.1.4.1.1466 0020: 2e 32 30 30 33 37 .20037 ber_get_next: tag 0x30 len 40 contents: read1msg: ld 0x1af3480 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x1af3480 0 new referrals read1msg: mark request completed, ld 0x1af3480 msgid 1 request done: ld 0x1af3480 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ber_scanf fmt (a) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (x) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS: certdb config: configDir='/etc/openldap/cacerts/' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: cannot open certdb '/etc/openldap/cacerts/', error -8018:Unknown PKCS #11 error. TLS: loaded CA certificate file /etc/ipa/ca.crt. TLS: skipping 'boingoqaCA.cer' - filename does not have expected format (certificate hash with numeric suffix) TLS: loaded CA certificate file /etc/openldap/cacerts//ad5923d2.0 from CA certificate directory /etc/openldap/cacerts/. TLS: loaded CA certificate file /etc/openldap/cacerts//36480d54.0 from CA certificate directory /etc/openldap/cacerts/. TLS: skipping 'ca.cer' - filename does not have expected format (certificate hash with numeric suffix) tls_write: want=154, written=154 0000: 16 03 01 00 95 01 00 00 91 03 01 52 eb cf a9 2a ...........R...* 0010: c5 33 57 b1 16 dc 40 d1 0b 71 21 d9 a8 b7 77 43 .3W... at ..q!...wC 0020: 2b d4 38 fa 94 9a ef 72 a7 1b ad 00 00 56 00 ff +.8....r.....V.. 0030: c0 0a c0 14 00 88 00 87 00 39 00 38 c0 0f c0 05 .........9.8.... 0040: 00 84 00 35 c0 09 c0 07 c0 13 c0 11 00 45 00 44 ...5.........E.D 0050: 00 33 00 32 00 66 c0 0e c0 0c c0 04 c0 02 00 96 .3.2.f.......... 0060: 00 41 00 2f 00 05 00 04 c0 08 c0 12 00 16 00 13 .A./............ 0070: c0 0d c0 03 00 0a 00 15 00 12 00 09 00 64 00 62 .............d.b 0080: 00 03 00 06 01 00 00 12 00 0a 00 08 00 06 00 17 ................ 0090: 00 18 00 19 00 0b 00 02 01 00 .......... tls_read: want=5, got=5 0000: 16 03 01 0b f4 ..... tls_read: want=3060, got=1443 0000: 02 00 00 4d 03 01 52 eb cf a0 77 19 29 c0 07 16 ...M..R...w.)... 0010: c8 fb 86 e8 e1 c4 53 c0 66 74 27 49 5c 28 08 82 ......S.ft'I\(.. 0020: a8 91 db 3c f3 65 20 c8 2e 00 00 6d 48 6b c4 12 ...<.e ....mHk.. 0030: 58 08 ec 6d 62 1d 5f 1c a6 e4 8a 27 da 64 93 0d X..mb._....'.d.. 0040: 96 a1 59 4d cd 30 1f 00 2f 00 00 05 ff 01 00 01 ..YM.0../....... 0050: 00 0b 00 06 65 00 06 62 00 06 5f 30 82 06 5b 30 ....e..b.._0..[0 0060: 82 04 43 a0 03 02 01 02 02 0a 15 27 15 8c 00 00 ..C........'.... 0070: 00 00 00 04 30 0d 06 09 2a 86 48 86 f7 0d 01 01 ....0...*.H..... 0080: 04 05 00 30 45 31 15 30 13 06 0a 09 92 26 89 93 ...0E1.0.....&.. 0090: f2 2c 64 01 19 16 05 6c 6f 63 61 6c 31 18 30 16 .,d....local1.0. 00a0: 06 0a 09 92 26 89 93 f2 2c 64 01 19 16 08 62 6f ....&...,d....bo 00b0: 69 6e 67 6f 71 61 31 12 30 10 06 03 55 04 03 13 ingoqa1.0...U... 00c0: 09 53 4b 59 57 41 52 50 43 41 30 1e 17 0d 31 34 .SKYWARPCA0...14 00d0: 30 31 33 30 32 32 33 33 35 39 5a 17 0d 31 35 30 0130223359Z..150 00e0: 31 33 30 32 32 33 33 35 39 5a 30 23 31 21 30 1f 130223359Z0#1!0. 00f0: 06 03 55 04 03 13 18 51 41 54 45 53 54 44 43 32 ..U....QATESTDC2 0100: 2e 62 6f 69 6e 67 6f 71 61 2e 6c 6f 63 61 6c 30 .boingoqa.local0 0110: 81 9f 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 ..0...*.H....... 0120: 00 03 81 8d 00 30 81 89 02 81 81 00 aa 30 bb 57 .....0.......0.W 0130: 09 87 1d 40 99 d7 c7 50 ba b4 d7 9d 6d 45 2c 68 ... at ...P....mE,h 0140: 19 d4 56 0e 9f 11 4b 8a dc 73 61 2c 9e a7 8b b8 ..V...K..sa,.... 0150: 7f b8 c7 e8 1b 08 79 b8 4a a0 b7 f4 6e 93 eb b1 ......y.J...n... 0160: 90 36 7a 21 a0 44 70 17 d0 dc 17 17 96 4e 5e 2a .6z!.Dp......N^* 0170: 77 6d 67 10 ed d8 1e 7a 40 a8 82 2f 91 d6 9a c2 wmg....z at ../.... 0180: 18 ce e3 d0 df 3f 7c f4 b1 df 50 81 4e bf 83 0b .....?|...P.N... 0190: 56 fc 26 13 44 23 f1 7b e8 7d d5 cf 29 54 97 13 V.&.D#.{.}..)T.. 01a0: 5f 0e ec e3 d9 16 fc de 01 82 78 bf 02 03 01 00 _.........x..... 01b0: 01 a3 82 02 f1 30 82 02 ed 30 2f 06 09 2b 06 01 .....0...0/..+.. 01c0: 04 01 82 37 14 02 04 22 1e 20 00 44 00 6f 00 6d ...7...". .D.o.m 01d0: 00 61 00 69 00 6e 00 43 00 6f 00 6e 00 74 00 72 .a.i.n.C.o.n.t.r 01e0: 00 6f 00 6c 00 6c 00 65 00 72 30 1d 06 03 55 1d .o.l.l.e.r0...U. 01f0: 25 04 16 30 14 06 08 2b 06 01 05 05 07 03 02 06 %..0...+........ 0200: 08 2b 06 01 05 05 07 03 01 30 0b 06 03 55 1d 0f .+.......0...U.. 0210: 04 04 03 02 05 a0 30 78 06 09 2a 86 48 86 f7 0d ......0x..*.H... 0220: 01 09 0f 04 6b 30 69 30 0e 06 08 2a 86 48 86 f7 ....k0i0...*.H.. 0230: 0d 03 02 02 02 00 80 30 0e 06 08 2a 86 48 86 f7 .......0...*.H.. 0240: 0d 03 04 02 02 00 80 30 0b 06 09 60 86 48 01 65 .......0...`.H.e 0250: 03 04 01 2a 30 0b 06 09 60 86 48 01 65 03 04 01 ...*0...`.H.e... 0260: 2d 30 0b 06 09 60 86 48 01 65 03 04 01 02 30 0b -0...`.H.e....0. 0270: 06 09 60 86 48 01 65 03 04 01 05 30 07 06 05 2b ..`.H.e....0...+ 0280: 0e 03 02 07 30 0a 06 08 2a 86 48 86 f7 0d 03 07 ....0...*.H..... 0290: 30 1d 06 03 55 1d 0e 04 16 04 14 6d 66 8e e6 c8 0...U......mf... 02a0: 48 ea f4 16 ff 4d 6f 72 2e bb 26 1d 45 a8 6f 30 H....Mor..&.E.o0 02b0: 1f 06 03 55 1d 23 04 18 30 16 80 14 7c 5f 71 5f ...U.#..0...|_q_ 02c0: 6b d3 83 3d 5b af d9 54 9d 7e 88 b1 ce a8 5c 83 k..=[..T.~....\. 02d0: 30 81 cc 06 03 55 1d 1f 04 81 c4 30 81 c1 30 81 0....U.....0..0. 02e0: be a0 81 bb a0 81 b8 86 81 b5 6c 64 61 70 3a 2f ..........ldap:/ 02f0: 2f 2f 43 4e 3d 53 4b 59 57 41 52 50 43 41 2c 43 //CN=SKYWARPCA,C 0300: 4e 3d 51 41 54 45 53 54 44 43 32 2c 43 4e 3d 43 N=QATESTDC2,CN=C 0310: 44 50 2c 43 4e 3d 50 75 62 6c 69 63 25 32 30 4b DP,CN=Public%20K 0320: 65 79 25 32 30 53 65 72 76 69 63 65 73 2c 43 4e ey%20Services,CN 0330: 3d 53 65 72 76 69 63 65 73 2c 43 4e 3d 43 6f 6e =Services,CN=Con 0340: 66 69 67 75 72 61 74 69 6f 6e 2c 44 43 3d 62 6f figuration,DC=bo 0350: 69 6e 67 6f 71 61 2c 44 43 3d 6c 6f 63 61 6c 3f ingoqa,DC=local? 0360: 63 65 72 74 69 66 69 63 61 74 65 52 65 76 6f 63 certificateRevoc 0370: 61 74 69 6f 6e 4c 69 73 74 3f 62 61 73 65 3f 6f ationList?base?o 0380: 62 6a 65 63 74 43 6c 61 73 73 3d 63 52 4c 44 69 bjectClass=cRLDi 0390: 73 74 72 69 62 75 74 69 6f 6e 50 6f 69 6e 74 30 stributionPoint0 03a0: 81 be 06 08 2b 06 01 05 05 07 01 01 04 81 b1 30 ....+..........0 03b0: 81 ae 30 81 ab 06 08 2b 06 01 05 05 07 30 02 86 ..0....+.....0.. 03c0: 81 9e 6c 64 61 70 3a 2f 2f 2f 43 4e 3d 53 4b 59 ..ldap:///CN=SKY 03d0: 57 41 52 50 43 41 2c 43 4e 3d 41 49 41 2c 43 4e WARPCA,CN=AIA,CN 03e0: 3d 50 75 62 6c 69 63 25 32 30 4b 65 79 25 32 30 =Public%20Key%20 03f0: 53 65 72 76 69 63 65 73 2c 43 4e 3d 53 65 72 76 Services,CN=Serv 0400: 69 63 65 73 2c 43 4e 3d 43 6f 6e 66 69 67 75 72 ices,CN=Configur 0410: 61 74 69 6f 6e 2c 44 43 3d 62 6f 69 6e 67 6f 71 ation,DC=boingoq 0420: 61 2c 44 43 3d 6c 6f 63 61 6c 3f 63 41 43 65 72 a,DC=local?cACer 0430: 74 69 66 69 63 61 74 65 3f 62 61 73 65 3f 6f 62 tificate?base?ob 0440: 6a 65 63 74 43 6c 61 73 73 3d 63 65 72 74 69 66 jectClass=certif 0450: 69 63 61 74 69 6f 6e 41 75 74 68 6f 72 69 74 79 icationAuthority 0460: 30 44 06 03 55 1d 11 04 3d 30 3b a0 1f 06 09 2b 0D..U...=0;....+ 0470: 06 01 04 01 82 37 19 01 a0 12 04 10 75 e8 a1 fe .....7......u... 0480: 6a 23 41 4c 92 f3 0f 8d 03 5e ea 10 82 18 51 41 j#AL.....^....QA 0490: 54 45 53 54 44 43 32 2e 62 6f 69 6e 67 6f 71 61 TESTDC2.boingoqa 04a0: 2e 6c 6f 63 61 6c 30 0d 06 09 2a 86 48 86 f7 0d .local0...*.H... 04b0: 01 01 04 05 00 03 82 02 01 00 a8 1e e9 8a 00 5d ...............] 04c0: 4c 40 3a d1 df b7 e1 3e 8e 97 e8 a5 c9 84 8e 7b L@:....>.......{ 04d0: 0d 38 01 83 39 b9 d1 8a e9 74 eb 01 f6 a3 23 54 .8..9....t....#T 04e0: d3 81 2c d9 31 50 d2 1f b7 5c 15 9d b9 18 d2 36 ..,.1P...\.....6 04f0: d4 18 34 26 5f ba d2 9d 8b d8 34 d9 2e f7 99 2e ..4&_.....4..... 0500: 5b 47 1a f6 26 55 fc 03 60 2c 63 4f e3 2a 65 5c [G..&U..`,cO.*e\ 0510: d0 90 69 8b 0b 4b 6a fc 83 9b d2 2d df ef 98 99 ..i..Kj....-.... 0520: bd b9 6c 17 79 1d 61 98 df 95 58 74 d3 ac e0 12 ..l.y.a...Xt.... 0530: 70 10 d3 02 e6 c6 32 7e d6 22 21 9e 5a a1 9b 13 p.....2~."!.Z... 0540: 60 82 2d 44 46 2f b2 16 02 8e 00 64 7f 45 04 e2 `.-DF/.....d.E.. 0550: 71 d7 19 ca 95 42 d9 bb a6 b3 4d e4 dc 95 06 c0 q....B....M..... 0560: e7 3a 5a 39 f0 aa fe 31 35 6d 34 e1 83 8f 79 0d .:Z9...15m4...y. 0570: b0 dd 3c 98 ef 0d 1d 66 8f 3f 54 b6 11 d2 30 a7 ..<....f.?T...0. 0580: 4d 2b e5 e3 b8 38 b1 d4 b7 92 73 21 3b 59 1b 9f M+...8....s!;Y.. 0590: cd e5 2b 93 3e 60 f2 02 58 02 db 7a f0 81 b6 8a ..+.>`..X..z.... 05a0: aa d8 bd ... tls_read: want=1617, got=1448 0000: 90 36 a9 a9 c7 28 ba 3c 05 a3 2a 4b 0c 51 e8 86 .6...(.<..*K.Q.. 0010: 82 35 29 7c 02 15 d3 84 99 6e 74 3a e3 c2 2b 36 .5)|.....nt:..+6 0020: f9 3a aa 7d b4 b6 5a a7 ff 34 2e 03 9d c3 f1 a5 .:.}..Z..4...... 0030: 02 55 5e 8d 12 bc b6 0f c1 07 75 76 59 58 b5 2b .U^.......uvYX.+ 0040: 9b 47 d6 5e 5e 8f 83 9e b0 50 ae 37 14 18 31 4e .G.^^....P.7..1N 0050: 50 eb 20 51 70 6d 96 e6 6e 63 d2 f7 ed 75 35 f0 P. Qpm..nc...u5. 0060: b3 ab 35 4d 34 f8 f2 6c 7a 69 78 67 21 cf c4 c7 ..5M4..lzixg!... 0070: 4c 0d 48 7b c3 4e de e1 07 a5 f4 d1 61 ce 12 5c L.H{.N......a..\ 0080: 8c 50 28 17 d3 6b ec cd 0d e5 d9 09 31 32 69 6d .P(..k......12im 0090: c5 a5 7b 3b 3e 23 fa 3e d6 05 39 13 5f 9a 77 29 ..{;>#.>..9._.w) 00a0: f0 ba 25 c1 42 9f 73 17 0a c5 71 9c 0a ec 6f 2f ..%.B.s...q...o/ 00b0: d5 cd 69 8c 87 c3 c8 f9 ab a0 8c 70 de 2c 94 84 ..i........p.,.. 00c0: ce 35 ff dd 56 6b 80 af 81 af 58 ee 7e 06 63 7e .5..Vk....X.~.c~ 00d0: 96 d1 a6 d0 b7 8c 0d 8b c4 e1 18 44 f4 8e 83 73 ...........D...s 00e0: 41 81 10 df a9 94 8d 9b 0c 84 d9 58 79 b0 a1 2d A..........Xy..- 00f0: ce 7b 75 8b b9 87 15 5e 33 5c 9b e5 b2 8f d3 3e .{u....^3\.....> 0100: f2 e5 f3 ec d6 ac ef f1 70 f3 92 4a 21 ab a4 4c ........p..J!..L 0110: 2f 98 77 b4 0b 98 1a 0d 00 05 32 03 01 02 40 05 /.w.......2... at . 0120: 2c 00 25 30 23 31 21 30 1f 06 03 55 04 03 13 18 ,.%0#1!0...U.... 0130: 51 41 54 45 53 54 44 43 32 2e 62 6f 69 6e 67 6f QATESTDC2.boingo 0140: 71 61 2e 6c 6f 63 61 6c 00 47 30 45 31 15 30 13 qa.local.G0E1.0. 0150: 06 0a 09 92 26 89 93 f2 2c 64 01 19 16 05 6c 6f ....&...,d....lo 0160: 63 61 6c 31 18 30 16 06 0a 09 92 26 89 93 f2 2c cal1.0.....&..., 0170: 64 01 19 16 08 62 6f 69 6e 67 6f 71 61 31 12 30 d....boingoqa1.0 0180: 10 06 03 55 04 03 13 09 53 4b 59 57 41 52 50 43 ...U....SKYWARPC 0190: 41 00 48 30 46 31 15 30 13 06 0a 09 92 26 89 93 A.H0F1.0.....&.. 01a0: f2 2c 64 01 19 16 05 6c 6f 63 61 6c 31 18 30 16 .,d....local1.0. 01b0: 06 0a 09 92 26 89 93 f2 2c 64 01 19 16 08 62 6f ....&...,d....bo 01c0: 69 6e 67 6f 71 61 31 13 30 11 06 03 55 04 03 13 ingoqa1.0...U... 01d0: 0a 62 6f 69 6e 67 6f 71 61 63 61 00 67 30 65 31 .boingoqaca.g0e1 01e0: 0b 30 09 06 03 55 04 06 13 02 55 53 31 15 30 13 .0...U....US1.0. 01f0: 06 03 55 04 0a 13 0c 44 69 67 69 43 65 72 74 20 ..U....DigiCert 0200: 49 6e 63 31 19 30 17 06 03 55 04 0b 13 10 77 77 Inc1.0...U....ww 0210: 77 2e 64 69 67 69 63 65 72 74 2e 63 6f 6d 31 24 w.digicert.com1$ 0220: 30 22 06 03 55 04 03 13 1b 44 69 67 69 43 65 72 0"..U....DigiCer 0230: 74 20 41 73 73 75 72 65 64 20 49 44 20 52 6f 6f t Assured ID Roo 0240: 74 20 43 41 00 cd 30 81 ca 31 0b 30 09 06 03 55 t CA..0..1.0...U 0250: 04 06 13 02 55 53 31 17 30 15 06 03 55 04 0a 13 ....US1.0...U... 0260: 0e 56 65 72 69 53 69 67 6e 2c 20 49 6e 63 2e 31 .VeriSign, Inc.1 0270: 1f 30 1d 06 03 55 04 0b 13 16 56 65 72 69 53 69 .0...U....VeriSi 0280: 67 6e 20 54 72 75 73 74 20 4e 65 74 77 6f 72 6b gn Trust Network 0290: 31 3a 30 38 06 03 55 04 0b 13 31 28 63 29 20 32 1:08..U...1(c) 2 02a0: 30 30 36 20 56 65 72 69 53 69 67 6e 2c 20 49 6e 006 VeriSign, In 02b0: 63 2e 20 2d 20 46 6f 72 20 61 75 74 68 6f 72 69 c. - For authori 02c0: 7a 65 64 20 75 73 65 20 6f 6e 6c 79 31 45 30 43 zed use only1E0C 02d0: 06 03 55 04 03 13 3c 56 65 72 69 53 69 67 6e 20 ..U... 75 62 6c 69 63 20 50 Class 3 Public P 02f0: 72 69 6d 61 72 79 20 43 65 72 74 69 66 69 63 61 rimary Certifica 0300: 74 69 6f 6e 20 41 75 74 68 6f 72 69 74 79 20 2d tion Authority - 0310: 20 47 35 00 61 30 5f 31 0b 30 09 06 03 55 04 06 G5.a0_1.0...U.. 0320: 13 02 55 53 31 17 30 15 06 03 55 04 0a 13 0e 56 ..US1.0...U....V 0330: 65 72 69 53 69 67 6e 2c 20 49 6e 63 2e 31 37 30 eriSign, Inc.170 0340: 35 06 03 55 04 0b 13 2e 43 6c 61 73 73 20 33 20 5..U....Class 3 0350: 50 75 62 6c 69 63 20 50 72 69 6d 61 72 79 20 43 Public Primary C 0360: 65 72 74 69 66 69 63 61 74 69 6f 6e 20 41 75 74 ertification Aut 0370: 68 6f 72 69 74 79 00 6e 30 6c 31 0b 30 09 06 03 hority.n0l1.0... 0380: 55 04 06 13 02 55 53 31 15 30 13 06 03 55 04 0a U....US1.0...U.. 0390: 13 0c 44 69 67 69 43 65 72 74 20 49 6e 63 31 19 ..DigiCert Inc1. 03a0: 30 17 06 03 55 04 0b 13 10 77 77 77 2e 64 69 67 0...U....www.dig 03b0: 69 63 65 72 74 2e 63 6f 6d 31 2b 30 29 06 03 55 icert.com1+0)..U 03c0: 04 03 13 22 44 69 67 69 43 65 72 74 20 48 69 67 ..."DigiCert Hig 03d0: 68 20 41 73 73 75 72 61 6e 63 65 20 45 56 20 52 h Assurance EV R 03e0: 6f 6f 74 20 43 41 00 77 30 75 31 0b 30 09 06 03 oot CA.w0u1.0... 03f0: 55 04 06 13 02 55 53 31 18 30 16 06 03 55 04 0a U....US1.0...U.. 0400: 13 0f 47 54 45 20 43 6f 72 70 6f 72 61 74 69 6f ..GTE Corporatio 0410: 6e 31 27 30 25 06 03 55 04 0b 13 1e 47 54 45 20 n1'0%..U....GTE 0420: 43 79 62 65 72 54 72 75 73 74 20 53 6f 6c 75 74 CyberTrust Solut 0430: 69 6f 6e 73 2c 20 49 6e 63 2e 31 23 30 21 06 03 ions, Inc.1#0!.. 0440: 55 04 03 13 1a 47 54 45 20 43 79 62 65 72 54 72 U....GTE CyberTr 0450: 75 73 74 20 47 6c 6f 62 61 6c 20 52 6f 6f 74 00 ust Global Root. 0460: 63 30 61 31 0b 30 09 06 03 55 04 06 13 02 55 53 c0a1.0...U....US 0470: 31 15 30 13 06 03 55 04 0a 13 0c 44 69 67 69 43 1.0...U....DigiC 0480: 65 72 74 20 49 6e 63 31 19 30 17 06 03 55 04 0b ert Inc1.0...U.. 0490: 13 10 77 77 77 2e 64 69 67 69 63 65 72 74 2e 63 ..www.digicert.c 04a0: 6f 6d 31 20 30 1e 06 03 55 04 03 13 17 44 69 67 om1 0...U....Dig 04b0: 69 43 65 72 74 20 47 6c 6f 62 61 6c 20 52 6f 6f iCert Global Roo 04c0: 74 20 43 41 00 5c 30 5a 31 0b 30 09 06 03 55 04 t CA.\0Z1.0...U. 04d0: 06 13 02 49 45 31 12 30 10 06 03 55 04 0a 13 09 ...IE1.0...U.... 04e0: 42 61 6c 74 69 6d 6f 72 65 31 13 30 11 06 03 55 Baltimore1.0...U 04f0: 04 0b 13 0a 43 79 62 65 72 54 72 75 73 74 31 22 ....CyberTrust1" 0500: 30 20 06 03 55 04 03 13 19 42 61 6c 74 69 6d 6f 0 ..U....Baltimo 0510: 72 65 20 43 79 62 65 72 54 72 75 73 74 20 52 6f re CyberTrust Ro 0520: 6f 74 00 37 30 35 31 13 30 11 06 03 55 04 0a 13 ot.7051.0...U... 0530: 0a 42 4f 49 4e 47 4f 2e 43 4f 4d 31 1e 30 1c 06 .BOINGO.COM1.0.. 0540: 03 55 04 03 13 15 43 65 72 74 69 66 69 63 61 74 .U....Certificat 0550: 65 20 41 75 74 68 6f 72 69 74 79 00 72 30 70 31 e Authority.r0p1 0560: 2b 30 29 06 03 55 04 0b 13 22 43 6f 70 79 72 69 +0)..U..."Copyri 0570: 67 68 74 20 28 63 29 20 31 39 39 37 20 4d 69 63 ght (c) 1997 Mic 0580: 72 6f 73 6f 66 74 20 43 6f 72 70 2e 31 1e 30 1c rosoft Corp.1.0. 0590: 06 03 55 04 0b 13 15 4d 69 63 72 6f 73 6f 66 74 ..U....Microsoft 05a0: 20 43 6f 72 70 6f 72 61 Corpora tls_read: want=169, got=169 0000: 74 69 6f 6e 31 21 30 1f 06 03 55 04 03 13 18 4d tion1!0...U....M 0010: 69 63 72 6f 73 6f 66 74 20 52 6f 6f 74 20 41 75 icrosoft Root Au 0020: 74 68 6f 72 69 74 79 00 61 30 5f 31 13 30 11 06 thority.a0_1.0.. 0030: 0a 09 92 26 89 93 f2 2c 64 01 19 16 03 63 6f 6d ...&...,d....com 0040: 31 19 30 17 06 0a 09 92 26 89 93 f2 2c 64 01 19 1.0.....&...,d.. 0050: 16 09 6d 69 63 72 6f 73 6f 66 74 31 2d 30 2b 06 ..microsoft1-0+. 0060: 03 55 04 03 13 24 4d 69 63 72 6f 73 6f 66 74 20 .U...$Microsoft 0070: 52 6f 6f 74 20 43 65 72 74 69 66 69 63 61 74 65 Root Certificate 0080: 20 41 75 74 68 6f 72 69 74 79 00 19 30 17 31 15 Authority..0.1. 0090: 30 13 06 03 55 04 03 13 0c 4e 54 20 41 55 54 48 0...U....NT AUTH 00a0: 4f 52 49 54 59 0e 00 00 00 ORITY.... TLS: certificate [CN=QATESTDC2.boingoqa.local] is not valid - error -8179:Peer's Certificate issuer is not recognized.. tls_write: want=205, written=205 0000: 16 03 01 00 8d 0b 00 00 03 00 00 00 10 00 00 82 ................ 0010: 00 80 51 77 d5 b2 c4 16 28 3f 82 11 3e 6c 03 b7 ..Qw....(?..>l.. 0020: 6e 32 cc f0 cd 91 fb 91 7b 1d 56 a1 c0 68 3d 5d n2......{.V..h=] 0030: 12 17 b0 28 8c 66 36 80 3b b0 a4 a5 a8 f5 bb cd ...(.f6.;....... 0040: cf c9 00 25 ce 30 20 e0 ae 3c 7e 5d e3 d9 7a ac ...%.0 ..<~]..z. 0050: 53 b9 3a fb c7 ed d1 30 0e 67 a0 75 57 5f 1a d8 S.:....0.g.uW_.. 0060: 83 21 b6 40 6a ef d3 3c af ec 4b 23 40 09 01 46 .!. at j..<..K#@..F 0070: f2 42 ff e9 b6 1b e9 0b 68 9b 1e ad dd 6b 50 ab .B......h....kP. 0080: 4b 1e 8e 20 c4 5b 5c ce c1 41 71 2d cc 89 07 03 K.. .[\..Aq-.... 0090: 3b b8 14 03 01 00 01 01 16 03 01 00 30 04 98 00 ;...........0... 00a0: 76 2c 80 06 50 3d 3e 40 c9 a9 7c aa 38 be 7a 88 v,..P=>@..|.8.z. 00b0: fe 82 46 0d a5 5d ef 52 3b af 52 2d 54 52 21 e1 ..F..].R;.R-TR!. 00c0: 43 23 6c 30 90 00 71 9b a6 84 d1 d5 e9 C#l0..q...... tls_read: want=5, got=5 0000: 14 03 01 00 01 ..... tls_read: want=1, got=1 0000: 01 . tls_read: want=5, got=5 0000: 16 03 01 00 30 ....0 tls_read: want=48, got=48 0000: 5e 06 20 97 b5 95 ed af 95 f7 e9 d4 dc 1c 9c 36 ^. ............6 0010: e4 09 16 8e 39 fe e1 55 52 68 d4 18 bd 05 59 8d ....9..URh....Y. 0020: f5 25 0f 95 01 70 ef 58 80 f8 47 a6 93 5f 1a d2 .%...p.X..G.._.. TLS certificate verification: subject: CN=QATESTDC2.boingoqa.local, issuer: CN=SKYWARPCA,DC=boingoqa,DC=local, cipher: AES-128, security level: high, secret key bits: 128, total key bits: 128, cache hits: 0, cache misses: 0, cache not reusable: 0 Enter LDAP Password: ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 65 bytes to sd 3 tls_write: want=101, written=101 0000: 17 03 01 00 60 37 2e 2c f3 b1 6a 3f 9e f7 30 eb ....`7.,..j?..0. 0010: 1d ad ed 7b 62 b2 43 43 fd dd de b9 0f 13 1d 79 ...{b.CC.......y 0020: fa 30 2c a5 96 03 04 22 61 18 b7 87 26 06 8c ba .0,...."a...&... 0030: fa 31 1f 12 f8 f9 b8 32 bb 96 ef 8d 75 98 04 e9 .1.....2....u... 0040: ff d8 d7 50 44 c2 ec 7c 03 26 fb 47 07 a8 a8 44 ...PD..|.&.G...D 0050: 98 22 c6 bb 95 d0 b1 4b 83 34 0a a0 79 7d 15 39 .".....K.4..y}.9 0060: f9 77 36 0d 86 .w6.. ldap_write: want=65, written=65 0000: 30 3f 02 01 02 60 3a 02 01 03 04 2a 63 6e 3d 69 0?...`:....*cn=i 0010: 64 6d 20 61 64 6d 69 6e 2c 63 6e 3d 75 73 65 72 dm admin,cn=user 0020: 73 2c 64 63 3d 62 6f 69 6e 67 6f 71 61 2c 64 63 s,dc=boingoqa,dc 0030: 3d 6c 6f 63 61 6c 80 09 67 30 5f 62 30 69 6e 67 =local..g0_b0ing 0040: 30 0 ldap_result ld 0x1af3480 msgid 2 wait4msg ld 0x1af3480 msgid 2 (infinite timeout) wait4msg continue ld 0x1af3480 msgid 2 all 1 ** ld 0x1af3480 Connections: * host: qatestdc2.boingoqa.local port: 389 (default) refcnt: 2 status: Connected last used: Fri Jan 31 16:30:43 2014 ** ld 0x1af3480 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x1af3480 request count 1 (abandoned 0) ** ld 0x1af3480 Response Queue: Empty ld 0x1af3480 response count 0 ldap_chkResponseList ld 0x1af3480 msgid 2 all 1 ldap_chkResponseList returns ld 0x1af3480 NULL ldap_int_select read1msg: ld 0x1af3480 msgid 2 all 1 ber_get_next tls_read: want=5, got=5 0000: 17 03 01 00 30 ....0 tls_read: want=48, got=48 0000: 23 47 ac 27 3e 60 2b 38 e2 0d 99 99 ce 3b f5 b1 #G.'>`+8.....;.. 0010: ae ae 7e 2a 18 40 53 b7 d2 06 7a e7 7f 7f 06 0e ..~*. at S...z..... 0020: eb ff 91 c4 76 30 8c 0c ed 5a 94 d2 32 14 d5 1d ....v0...Z..2... ldap_read: want=8, got=8 0000: 30 84 00 00 00 10 02 01 0....... ldap_read: want=14, got=14 0000: 02 61 84 00 00 00 07 0a 01 00 04 00 04 00 .a............ ber_get_next: tag 0x30 len 16 contents: read1msg: ld 0x1af3480 msgid 2 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 0x1af3480 0 new referrals read1msg: mark request completed, ld 0x1af3480 msgid 2 request done: ld 0x1af3480 msgid 2 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_search_ext put_filter: "(objectclass=*)" put_filter: simple put_simple_filter: "objectclass=*" ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 81 bytes to sd 3 tls_write: want=117, written=117 0000: 17 03 01 00 70 1e f0 51 eb f7 9e 45 2a 29 20 50 ....p..Q...E*) P 0010: 03 f2 88 b8 31 68 1d 0d 04 4d 5b c9 f3 e5 9c 6a ....1h...M[....j 0020: 32 b2 fc c2 0f 2d fa e4 c2 1d ae ce 17 15 75 e8 2....-........u. 0030: 63 47 44 ab 82 0f c9 9d 90 3f 16 60 7a 7b 6d c1 cGD......?.`z{m. 0040: 64 10 1e e8 01 14 f8 b4 7c 54 a9 4a 84 ac b2 dc d.......|T.J.... 0050: bd 47 07 4f b7 48 6d 54 87 2e 26 4a 84 c8 a5 b9 .G.O.HmT..&J.... 0060: 8e a3 68 80 10 50 02 70 34 72 83 b6 64 72 8b 70 ..h..P.p4r..dr.p 0070: 07 cd 8e c0 b9 ..... ldap_write: want=81, written=81 0000: 30 4f 02 01 03 63 4a 04 2a 63 6e 3d 69 64 6d 20 0O...cJ.*cn=idm 0010: 61 64 6d 69 6e 2c 63 6e 3d 75 73 65 72 73 2c 64 admin,cn=users,d 0020: 63 3d 62 6f 69 6e 67 6f 71 61 2c 64 63 3d 6c 6f c=boingoqa,dc=lo 0030: 63 61 6c 0a 01 02 0a 01 00 02 01 00 02 01 00 01 cal............. 0040: 01 00 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 30 ....objectclass0 0050: 00 . ldap_result ld 0x1af3480 msgid -1 wait4msg ld 0x1af3480 msgid -1 (infinite timeout) wait4msg continue ld 0x1af3480 msgid -1 all 0 ** ld 0x1af3480 Connections: * host: qatestdc2.boingoqa.local port: 389 (default) refcnt: 2 status: Connected last used: Fri Jan 31 16:30:43 2014 ** ld 0x1af3480 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x1af3480 request count 1 (abandoned 0) ** ld 0x1af3480 Response Queue: Empty ld 0x1af3480 response count 0 ldap_chkResponseList ld 0x1af3480 msgid -1 all 0 ldap_chkResponseList returns ld 0x1af3480 NULL ldap_int_select read1msg: ld 0x1af3480 msgid -1 all 0 ber_get_next tls_read: want=5, got=5 0000: 17 03 01 06 40 ....@ tls_read: want=1600, got=1600 0000: f0 a7 12 28 36 88 72 46 57 ea 69 d3 d5 dd f6 ee ...(6.rFW.i..... 0010: 58 58 ba f5 b2 d9 b4 57 7f 81 e4 fd 31 61 a9 2e XX.....W....1a.. 0020: 88 b7 7d da d6 98 b2 6e 8c 17 36 ff 9f a5 d7 d4 ..}....n..6..... 0030: fd de 24 2c 2c 5c 4e aa 02 1a e2 c8 cf b7 5d eb ..$,,\N.......]. 0040: 1f e2 3c 0a 8b dc 6a 26 25 0f 5a 27 4a 8e 27 b4 ..<...j&%.Z'J.'. 0050: b8 8d 98 2d 8a 62 23 be a0 61 a6 a3 01 63 40 ae ...-.b#..a...c at . 0060: 41 2e bf 8a 1f 53 4b d5 10 53 2c 64 07 0c 0d d8 A....SK..S,d.... 0070: 51 36 6b 75 b5 25 c3 87 21 df 5f 1a 13 82 19 90 Q6ku.%..!._..... 0080: 42 13 b1 d9 71 94 83 b7 74 00 95 66 b5 38 a0 85 B...q...t..f.8.. 0090: b3 82 92 e2 f0 f5 88 f4 06 78 c3 55 f0 ea 16 6b .........x.U...k 00a0: 77 2e 65 09 81 ce 8e 56 75 8f fe 91 d8 3f dc 53 w.e....Vu....?.S 00b0: 23 bf ab cd bb 6d 23 d7 88 14 b1 0b eb 6f ab 8a #....m#......o.. 00c0: 00 8b 4f 83 d7 22 17 71 cb 4f 65 67 a9 0e 41 95 ..O..".q.Oeg..A. 00d0: 1f 42 4c e0 68 17 13 9e 1a d4 64 88 ff e2 ee 52 .BL.h.....d....R 00e0: 60 a0 ce 36 80 b9 38 eb 8b 85 e7 3a b1 fa 4b 2c `..6..8....:..K, 00f0: 89 71 79 60 04 2c 6c 5c 8f 7f bb 7e c1 fd d0 c1 .qy`.,l\...~.... 0100: b9 7c 6f fb bc 70 06 f0 f9 11 ee 44 58 4f eb c2 .|o..p.....DXO.. 0110: 86 23 83 0c 49 e0 81 5d 4f 37 f5 70 70 af b9 ed .#..I..]O7.pp... 0120: dc 08 a9 77 4b 56 80 f0 c1 cc 55 87 3f 2a a1 63 ...wKV....U.?*.c 0130: 27 b5 c2 8c 9f ca ee 61 1b 5d 38 b5 df 80 39 f7 '......a.]8...9. 0140: e9 b5 6f b8 1d b0 ad d6 20 dd c6 f0 bd c8 fd 87 ..o..... ....... 0150: 4f ea 13 a7 11 09 ee 20 e5 68 f7 f1 10 ae 28 22 O...... .h....(" 0160: 79 55 5b 67 4f 3c 1b 36 eb 24 6d cc 5b 46 31 63 yU[gO<.6.$m.[F1c 0170: 45 ab 4a 50 66 43 80 aa 5c b1 0e cd f6 96 bc d4 E.JPfC..\....... 0180: ad d3 7e f9 48 2f 27 90 af 4e b1 eb c2 fb 81 0a ..~.H/'..N...... 0190: 6a e7 18 17 37 71 6c 42 b2 6a 81 ca e0 73 be 0f j...7qlB.j...s.. 01a0: 30 ab a3 aa 2a 12 23 54 ed f3 3e e2 a3 fd 5e f4 0...*.#T..>...^. 01b0: 70 0c 7f 32 bb b5 b5 98 25 4b fc a7 d6 ce 1e d9 p..2....%K...... 01c0: 29 03 ca 9a 2f 31 46 63 64 a8 9f 21 a2 0b e9 d6 ).../1Fcd..!.... 01d0: 2b d8 10 57 78 d0 ae fc 30 fd f5 92 f1 7d c4 7a +..Wx...0....}.z 01e0: 36 13 d0 67 0e 16 a4 13 b0 67 16 66 6f af 8c 0b 6..g.....g.fo... 01f0: bf 9f 59 c0 7b 1c 00 26 9f fa 87 f3 ae b0 4d 31 ..Y.{..&......M1 0200: 02 db 83 23 ed f9 3c bb 21 19 ea 47 0e 9f 39 3a ...#..<.!..G..9: 0210: 5b 7d bc 34 69 ff 5e cb 05 d5 32 b5 f2 d5 da f1 [}.4i.^...2..... 0220: 3c 56 c9 91 2e 71 ce d9 27 ec f7 93 97 f0 74 e1 .......t}.$ 0240: 58 2f d6 4b 50 a3 20 d3 0d c5 cd d1 9a 17 7f 12 X/.KP. ......... 0250: c5 b9 57 bf a0 7e a2 d3 29 08 00 07 78 52 dc 27 ..W..~..)...xR.' 0260: f7 9e e5 57 52 74 2b 5d 6c eb d6 b0 2c 07 08 84 ...WRt+]l...,... 0270: 87 39 7f a5 a2 d1 be 0e 02 42 b9 02 fe 01 69 78 .9.......B....ix 0280: c2 f7 26 6e 7e 3b ba 06 81 25 9d d3 8f ae 99 eb ..&n~;...%...... 0290: 44 37 c4 57 69 d9 c5 31 31 41 e8 49 70 07 34 95 D7.Wi..11A.Ip.4. 02a0: 50 cb fa 1b cd 3f d1 84 54 73 f6 69 0e ab 10 46 P....?..Ts.i...F 02b0: a8 1c cb e9 ad ab 80 f7 f4 3c 86 75 a4 de d1 7a .........<.u...z 02c0: d2 7a 47 02 ce ba 42 c8 53 05 76 ca 2e 1d 35 e6 .zG...B.S.v...5. 02d0: e6 23 70 ae e8 0f 2c 0f e6 ab 2a 65 8c ed 0a 7b .#p...,...*e...{ 02e0: ec 3a b5 4e 5b d9 b1 3d e5 4a 92 22 29 01 7e 11 .:.N[..=.J.").~. 02f0: 28 6a c2 48 3f 7f b8 c1 13 80 89 d3 e7 cb 19 7d (j.H?..........} 0300: e5 2e eb c9 b6 7b b0 dd 9f c0 4b ea 16 53 aa 11 .....{....K..S.. 0310: 24 17 c3 0c 5c 35 e2 fd 76 28 05 95 9d 40 a7 9b $...\5..v(... at .. 0320: 6b 3c 31 c0 2b a1 a2 68 ba 94 ec f7 12 51 85 1c k<1.+..h.....Q.. 0330: 96 18 2e 88 bd c8 d7 c2 04 fe 47 cc 73 9a af bd ..........G.s... 0340: 11 90 06 f6 9f e8 58 71 88 42 c9 e6 b8 0f 3f 70 ......Xq.B....?p 0350: a8 30 79 46 17 fa 2e ae 22 f8 b8 75 14 c0 7a e1 .0yF...."..u..z. 0360: 92 63 c0 62 4f 14 8e d9 78 30 e9 82 1f c4 df 2a .c.bO...x0.....* 0370: f2 13 5b c3 d3 3f 2b 2c 84 7e 9a d9 82 18 af 11 ..[..?+,.~...... 0380: 0f 7c 85 c8 e0 09 91 19 7a 56 cc 59 fc 0c da ca .|......zV.Y.... 0390: c8 84 8c cf 3e 18 e1 5a 07 5e 4e f0 b1 a9 14 88 ....>..Z.^N..... 03a0: e1 ee a2 a1 9b 98 7d f1 ac a0 61 06 ab 45 7e c5 ......}...a..E~. 03b0: 5e 0f 38 6f 75 5e 6e 9e d4 8a 29 6c 1a a5 62 06 ^.8ou^n...)l..b. 03c0: 0b cf 61 d6 b0 1d 48 4b f5 07 16 f6 d5 63 4c 23 ..a...HK.....cL# 03d0: 48 2e 35 b5 da e2 65 64 ab 9b 8d f3 5f 57 9a ec H.5...ed...._W.. 03e0: a4 b1 82 c1 7f 47 3e 4c 33 51 0d 25 05 7b 5c 3d .....G>L3Q.%.{\= 03f0: f2 6a 09 ab f8 52 d1 2f ac 48 ef 7a f7 44 d4 92 .j...R./.H.z.D.. 0400: 86 72 20 77 ff af e5 c8 3d 8e 34 4b d7 e2 3a 63 .r w....=.4K..:c 0410: 1a a2 d3 f0 50 86 61 1e 3c 8e ce f9 5d a9 b8 9d ....P.a.<...]... 0420: 00 9a 6d f2 3a c8 d7 b1 ea ad 96 cd 64 dd e0 83 ..m.:.......d... 0430: d3 b0 5b 84 bb c5 a5 fe fe 6e d9 85 fe a9 60 56 ..[......n....`V 0440: 01 8f ec 1e f6 d6 1b 1d 75 51 25 fb 6a 96 2d 02 ........uQ%.j.-. 0450: d2 fe fe 7b 33 48 7b d9 06 60 cc a4 e4 46 51 bb ...{3H{..`...FQ. 0460: 4f 21 ae 78 6a f6 cf 5a 81 6f 64 e7 bc 8f e5 63 O!.xj..Z.od....c 0470: 4b 31 a0 4b 2a 5d 0a 71 c3 fb d9 67 01 a3 03 14 K1.K*].q...g.... 0480: 5e 32 b1 4b 77 a2 03 47 07 da 9e 7c 0a 8a 40 5b ^2.Kw..G...|..@[ 0490: 28 bd 81 cf 1f 6c 7b 2e ae 21 1b 88 ce 72 08 02 (....l{..!...r.. 04a0: 1e 83 50 56 66 4b 0f 3e ca 6f 56 29 93 c2 1f 6f ..PVfK.>.oV)...o 04b0: 07 b9 0a d1 a1 f8 6b da 3b c6 20 8f 68 05 66 53 ......k.;. .h.fS 04c0: 61 3e 20 9a a4 05 13 15 b9 c0 55 f8 59 32 d8 3f a> .......U.Y2.? 04d0: 79 50 c0 2a 89 1d 3c 12 f1 64 d8 84 b4 f9 ed 95 yP.*..<..d...... 04e0: 25 39 b7 72 8f 53 cb 8a 6a f0 b8 76 bd 6d 42 30 %9.r.S..j..v.mB0 04f0: 96 e7 18 ee d9 6f 56 57 d2 e8 ee 68 a7 73 1c a5 .....oVW...h.s.. 0500: 02 31 b3 8f 29 c5 36 c0 ed 29 50 c1 19 da 45 7d .1..).6..)P...E} 0510: e1 be e3 7d 2e 54 20 93 94 a2 02 ab 42 e0 71 4b ...}.T .....B.qK 0520: 1d 14 98 6e 27 fc d6 7f 98 58 98 7a 30 2f 39 19 ...n'....X.z0/9. 0530: 62 e0 32 1a 8a 12 b8 b0 03 55 66 9b 72 b4 ac ff b.2......Uf.r... 0540: e4 7c eb 1d 80 b5 f6 b6 33 15 01 f8 bb aa 8e d0 .|......3....... 0550: 39 f4 2d e1 d1 79 3f 63 e0 61 02 d9 5b 1e 1f e7 9.-..y?c.a..[... 0560: c9 31 a8 5a cc d8 90 cc 78 3f 09 bd e3 20 e3 d3 .1.Z....x?... .. 0570: c2 bd 0d 5f 17 1b 4d 97 62 ca ed b6 37 95 12 ec ..._..M.b...7... 0580: d0 eb 6a 2a 34 64 77 16 08 82 5f ca 21 1a 7e cd ..j*4dw..._.!.~. 0590: a3 91 4d ce f6 7b a7 a9 00 03 8a b2 e9 05 a5 89 ..M..{.......... 05a0: 9a ef 05 24 a3 c9 ab 0b a6 1d ec 36 76 5f 9e b3 ...$.......6v_.. 05b0: d8 01 b8 29 e4 04 19 5e 36 84 3a a7 ac 56 bb 2f ...)...^6.:..V./ 05c0: 51 bf fc e0 46 cc d9 b1 7f ac 34 99 ea 8d ca 24 Q...F.....4....$ 05d0: 03 23 ec 71 d4 dc 13 fb a6 86 81 99 41 8b 7f dd .#.q........A... 05e0: 67 ec 02 a6 fc 21 f5 50 82 e6 3c 46 04 88 62 f6 g....!.P....A.a 0610: 7b 20 8a 5e 65 c3 d9 e1 42 d2 88 fe c5 4e cf fa { .^e...B....N.. 0620: c6 ea cc 43 52 bc 08 92 e5 c0 d1 21 4a b9 f7 aa ...CR......!J... 0630: 50 a7 61 c6 47 0c f0 f4 1c b1 ab cb 06 00 d1 0d P.a.G........... ldap_read: want=8, got=8 0000: 30 84 00 00 06 01 02 01 0....... ldap_read: want=1535, got=1535 0000: 03 64 84 00 00 05 f8 04 2a 43 4e 3d 49 44 4d 20 .d......*CN=IDM 0010: 41 44 4d 49 4e 2c 43 4e 3d 55 73 65 72 73 2c 44 ADMIN,CN=Users,D 0020: 43 3d 62 6f 69 6e 67 6f 71 61 2c 44 43 3d 6c 6f C=boingoqa,DC=lo 0030: 63 61 6c 30 84 00 00 05 c6 30 84 00 00 00 3c 04 cal0.....0....<. 0040: 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 84 00 00 .objectClass1... 0050: 00 29 04 03 74 6f 70 04 06 70 65 72 73 6f 6e 04 .)..top..person. 0060: 14 6f 72 67 61 6e 69 7a 61 74 69 6f 6e 61 6c 50 .organizationalP 0070: 65 72 73 6f 6e 04 04 75 73 65 72 30 84 00 00 00 erson..user0.... 0080: 15 04 02 63 6e 31 84 00 00 00 0b 04 09 49 44 4d ...cn1.......IDM 0090: 20 41 44 4d 49 4e 30 84 00 00 00 1b 04 09 67 69 ADMIN0.......gi 00a0: 76 65 6e 4e 61 6d 65 31 84 00 00 00 0a 04 08 49 venName1.......I 00b0: 44 4d 41 44 4d 49 4e 30 84 00 00 00 45 04 11 64 DMADMIN0....E..d 00c0: 69 73 74 69 6e 67 75 69 73 68 65 64 4e 61 6d 65 istinguishedName 00d0: 31 84 00 00 00 2c 04 2a 43 4e 3d 49 44 4d 20 41 1....,.*CN=IDM A 00e0: 44 4d 49 4e 2c 43 4e 3d 55 73 65 72 73 2c 44 43 DMIN,CN=Users,DC 00f0: 3d 62 6f 69 6e 67 6f 71 61 2c 44 43 3d 6c 6f 63 =boingoqa,DC=loc 0100: 61 6c 30 84 00 00 00 17 04 0c 69 6e 73 74 61 6e al0.......instan 0110: 63 65 54 79 70 65 31 84 00 00 00 03 04 01 34 30 ceType1.......40 0120: 84 00 00 00 26 04 0b 77 68 65 6e 43 72 65 61 74 ....&..whenCreat 0130: 65 64 31 84 00 00 00 13 04 11 32 30 31 34 30 31 ed1.......201401 0140: 32 38 31 38 32 35 33 37 2e 30 5a 30 84 00 00 00 28182537.0Z0.... 0150: 26 04 0b 77 68 65 6e 43 68 61 6e 67 65 64 31 84 &..whenChanged1. 0160: 00 00 00 13 04 11 32 30 31 34 30 31 33 31 30 31 ......2014013101 0170: 34 33 31 35 2e 30 5a 30 84 00 00 00 1d 04 0b 64 4315.0Z0.......d 0180: 69 73 70 6c 61 79 4e 61 6d 65 31 84 00 00 00 0a isplayName1..... 0190: 04 08 49 44 4d 41 44 4d 49 4e 30 84 00 00 00 19 ..IDMADMIN0..... 01a0: 04 0a 75 53 4e 43 72 65 61 74 65 64 31 84 00 00 ..uSNCreated1... 01b0: 00 07 04 05 33 31 39 36 38 30 84 00 00 00 af 04 ....319680...... 01c0: 08 6d 65 6d 62 65 72 4f 66 31 84 00 00 00 9f 04 .memberOf1...... 01d0: 33 43 4e 3d 44 6f 6d 61 69 6e 20 43 6f 6e 74 72 3CN=Domain Contr 01e0: 6f 6c 6c 65 72 73 2c 43 4e 3d 55 73 65 72 73 2c ollers,CN=Users, 01f0: 44 43 3d 62 6f 69 6e 67 6f 71 61 2c 44 43 3d 6c DC=boingoqa,DC=l 0200: 6f 63 61 6c 04 34 43 4e 3d 41 63 63 6f 75 6e 74 ocal.4CN=Account 0210: 20 4f 70 65 72 61 74 6f 72 73 2c 43 4e 3d 42 75 Operators,CN=Bu 0220: 69 6c 74 69 6e 2c 44 43 3d 62 6f 69 6e 67 6f 71 iltin,DC=boingoq 0230: 61 2c 44 43 3d 6c 6f 63 61 6c 04 32 43 4e 3d 45 a,DC=local.2CN=E 0240: 6e 74 65 72 70 72 69 73 65 20 41 64 6d 69 6e 73 nterprise Admins 0250: 2c 43 4e 3d 55 73 65 72 73 2c 44 43 3d 62 6f 69 ,CN=Users,DC=boi 0260: 6e 67 6f 71 61 2c 44 43 3d 6c 6f 63 61 6c 30 84 ngoqa,DC=local0. 0270: 00 00 00 19 04 0a 75 53 4e 43 68 61 6e 67 65 64 ......uSNChanged 0280: 31 84 00 00 00 07 04 05 33 38 37 38 36 30 84 00 1.......387860.. 0290: 00 00 17 04 04 6e 61 6d 65 31 84 00 00 00 0b 04 .....name1...... 02a0: 09 49 44 4d 20 41 44 4d 49 4e 30 84 00 00 00 24 .IDM ADMIN0....$ 02b0: 04 0a 6f 62 6a 65 63 74 47 55 49 44 31 84 00 00 ..objectGUID1... 02c0: 00 12 04 10 8d a8 ba dc 97 c3 bd 4b 8e 19 c5 11 ...........K.... 02d0: 9e d0 3b 86 30 84 00 00 00 21 04 12 75 73 65 72 ..;.0....!..user 02e0: 41 63 63 6f 75 6e 74 43 6f 6e 74 72 6f 6c 31 84 AccountControl1. 02f0: 00 00 00 07 04 05 36 36 30 34 38 30 84 00 00 00 ......660480.... 0300: 16 04 0b 62 61 64 50 77 64 43 6f 75 6e 74 31 84 ...badPwdCount1. 0310: 00 00 00 03 04 01 30 30 84 00 00 00 13 04 08 63 ......00.......c 0320: 6f 64 65 50 61 67 65 31 84 00 00 00 03 04 01 30 odePage1.......0 0330: 30 84 00 00 00 16 04 0b 63 6f 75 6e 74 72 79 43 0.......countryC 0340: 6f 64 65 31 84 00 00 00 03 04 01 30 30 84 00 00 ode1.......00... 0350: 00 1a 04 0f 62 61 64 50 61 73 73 77 6f 72 64 54 ....badPasswordT 0360: 69 6d 65 31 84 00 00 00 03 04 01 30 30 84 00 00 ime1.......00... 0370: 00 15 04 0a 6c 61 73 74 4c 6f 67 6f 66 66 31 84 ....lastLogoff1. 0380: 00 00 00 03 04 01 30 30 84 00 00 00 14 04 09 6c ......00.......l 0390: 61 73 74 4c 6f 67 6f 6e 31 84 00 00 00 03 04 01 astLogon1....... 03a0: 30 30 84 00 00 00 26 04 0a 70 77 64 4c 61 73 74 00....&..pwdLast 03b0: 53 65 74 31 84 00 00 00 14 04 12 31 33 30 33 35 Set1.......13035 03c0: 36 30 30 38 30 30 36 30 39 33 37 35 30 30 84 00 60080060937500.. 03d0: 00 00 1b 04 0e 70 72 69 6d 61 72 79 47 72 6f 75 .....primaryGrou 03e0: 70 49 44 31 84 00 00 00 05 04 03 35 31 33 30 84 pID1.......5130. 03f0: 00 00 00 2f 04 09 6f 62 6a 65 63 74 53 69 64 31 .../..objectSid1 0400: 84 00 00 00 1e 04 1c 01 05 00 00 00 00 00 05 15 ................ 0410: 00 00 00 d3 ef c6 53 9e 66 cf 78 74 85 0e 3c 47 ......S.f.xt.. 00 15 04 0a 61 64 6d 69 6e ...0.......admin 0430: 43 6f 75 6e 74 31 84 00 00 00 03 04 01 31 30 84 Count1.......10. 0440: 00 00 00 2b 04 0e 61 63 63 6f 75 6e 74 45 78 70 ...+..accountExp 0450: 69 72 65 73 31 84 00 00 00 15 04 13 39 32 32 33 ires1.......9223 0460: 33 37 32 30 33 36 38 35 34 37 37 35 38 30 37 30 3720368547758070 0470: 84 00 00 00 15 04 0a 6c 6f 67 6f 6e 43 6f 75 6e .......logonCoun 0480: 74 31 84 00 00 00 03 04 01 30 30 84 00 00 00 20 t1.......00.... 0490: 04 0e 73 41 4d 41 63 63 6f 75 6e 74 4e 61 6d 65 ..sAMAccountName 04a0: 31 84 00 00 00 0a 04 08 69 64 6d 61 64 6d 69 6e 1.......idmadmin 04b0: 30 84 00 00 00 21 04 0e 73 41 4d 41 63 63 6f 75 0....!..sAMAccou 04c0: 6e 74 54 79 70 65 31 84 00 00 00 0b 04 09 38 30 ntType1.......80 04d0: 35 33 30 36 33 36 38 30 84 00 00 00 32 04 11 75 53063680....2..u 04e0: 73 65 72 50 72 69 6e 63 69 70 61 6c 4e 61 6d 65 serPrincipalName 04f0: 31 84 00 00 00 19 04 17 69 64 6d 61 64 6d 69 6e 1.......idmadmin 0500: 40 62 6f 69 6e 67 6f 71 61 2e 6c 6f 63 61 6c 30 @boingoqa.local0 0510: 84 00 00 00 16 04 0b 6c 6f 63 6b 6f 75 74 54 69 .......lockoutTi 0520: 6d 65 31 84 00 00 00 03 04 01 30 30 84 00 00 00 me1.......00.... 0530: 51 04 0e 6f 62 6a 65 63 74 43 61 74 65 67 6f 72 Q..objectCategor 0540: 79 31 84 00 00 00 3b 04 39 43 4e 3d 50 65 72 73 y1....;.9CN=Pers 0550: 6f 6e 2c 43 4e 3d 53 63 68 65 6d 61 2c 43 4e 3d on,CN=Schema,CN= 0560: 43 6f 6e 66 69 67 75 72 61 74 69 6f 6e 2c 44 43 Configuration,DC 0570: 3d 62 6f 69 6e 67 6f 71 61 2c 44 43 3d 6c 6f 63 =boingoqa,DC=loc 0580: 61 6c 30 84 00 00 00 43 04 15 64 53 43 6f 72 65 al0....C..dSCore 0590: 50 72 6f 70 61 67 61 74 69 6f 6e 44 61 74 61 31 PropagationData1 05a0: 84 00 00 00 26 04 11 32 30 31 34 30 31 32 39 32 ....&..201401292 05b0: 32 34 30 32 34 2e 30 5a 04 11 31 36 30 31 30 31 24024.0Z..160101 05c0: 30 31 30 30 30 30 30 30 2e 30 5a 30 84 00 00 00 01000000.0Z0.... 05d0: 2e 04 12 6c 61 73 74 4c 6f 67 6f 6e 54 69 6d 65 ...lastLogonTime 05e0: 73 74 61 6d 70 31 84 00 00 00 14 04 12 31 33 30 stamp1.......130 05f0: 33 35 36 30 36 30 36 37 32 31 31 30 35 37 38 356060672110578 ber_get_next: tag 0x30 len 1537 contents: read1msg: ld 0x1af3480 msgid 3 message type search-entry ldap_get_dn_ber ber_scanf fmt ({ml{) ber: dn: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local ber_scanf fmt ({xx) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: cn: IDM ADMIN ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: givenName: IDMADMIN ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: distinguishedName: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: instanceType: 4 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: whenCreated: 20140128182537.0Z ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: whenChanged: 20140131014315.0Z ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: displayName: IDMADMIN ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: uSNCreated: 31968 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: memberOf: CN=Domain Controllers,CN=Users,DC=boingoqa,DC=local memberOf: CN=Account Operators,CN=Builtin,DC=boingoqa,DC=local memberOf: CN=Enterprise Admins,CN=Users,DC=boingoqa,DC=local ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: uSNChanged: 38786 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: name: IDM ADMIN ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: objectGUID:: jai63JfDvUuOGcURntA7hg== ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: userAccountControl: 66048 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: badPwdCount: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: codePage: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: countryCode: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: badPasswordTime: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: lastLogoff: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: lastLogon: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: pwdLastSet: 130356008006093750 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: primaryGroupID: 513 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: objectSid:: AQUAAAAAAAUVAAAA0+/GU55mz3h0hQ48RwYAAA== ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: adminCount: 1 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: accountExpires: 9223372036854775807 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: logonCount: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: sAMAccountName: idmadmin ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: sAMAccountType: 805306368 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: userPrincipalName: idmadmin at boingoqa.local ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: lockoutTime: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=boingoqa,DC=local ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: dSCorePropagationData: 20140129224024.0Z dSCorePropagationData: 16010101000000.0Z ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: lastLogonTimestamp: 130356060672110578 ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x1af3480 msgid -1 wait4msg ld 0x1af3480 msgid -1 (infinite timeout) wait4msg continue ld 0x1af3480 msgid -1 all 0 ** ld 0x1af3480 Connections: * host: qatestdc2.boingoqa.local port: 389 (default) refcnt: 2 status: Connected last used: Fri Jan 31 16:30:43 2014 ** ld 0x1af3480 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x1af3480 request count 1 (abandoned 0) ** ld 0x1af3480 Response Queue: Empty ld 0x1af3480 response count 0 ldap_chkResponseList ld 0x1af3480 msgid -1 all 0 ldap_chkResponseList returns ld 0x1af3480 NULL read1msg: ld 0x1af3480 msgid -1 all 0 ber_get_next ldap_read: want=8, got=8 0000: 30 84 00 00 00 10 02 01 0....... ldap_read: want=14, got=14 0000: 03 65 84 00 00 00 07 0a 01 00 04 00 04 00 .e............ ber_get_next: tag 0x30 len 16 contents: read1msg: ld 0x1af3480 msgid 3 message type search-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x1af3480 0 new referrals read1msg: mark request completed, ld 0x1af3480 msgid 3 request done: ld 0x1af3480 msgid 3 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 3, msgid 3) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 tls_write: want=37, written=37 0000: 17 03 01 00 20 a3 ef 55 d6 94 cc f5 97 4f fe c1 .... ..U.....O.. 0010: 09 95 0b 7a 4c 8f 6d b5 5f 9f 52 ca 5e a6 91 b6 ...zL.m._.R.^... 0020: 0f 9d c3 d6 b0 ..... ldap_write: want=7, written=7 0000: 30 05 02 01 04 42 00 0....B. tls_write: want=37, written=37 0000: 15 03 01 00 20 17 6f cd 57 b4 79 e3 ef 4f fb 1f .... .o.W.y..O.. 0010: 57 0b c5 c0 82 ba b4 b0 3e 7a de db 40 87 0d 32 W.......>z.. at ..2 0020: 4b ce 39 be 02 K.9.. ldap_free_connection: actually freed -Todd Maugh On Jan 31, 2014, at 10:16 AM, "Dmitri Pal" > wrote: On 01/31/2014 12:59 PM, Todd Maugh wrote: please help im stuck trying to finish this winsync agreement [root at se-idm-01.boingo.com slapd-BOINGO-COM]$ ipa-replica-manage connect --winsync --binddn "cn=idm admin, cn=Users, dc=boingoqa, dc=local" --bindpw "*******" --passsync "********" --cacert=/etc/openldap/cacerts/boingoqaCA.cer qatestdc2.boingoqa.local -v Directory Manager password: Added CA certificate /etc/openldap/cacerts/boingoqaCA.cer to certificate database for se-idm-01.boingo.com ipa: INFO: AD Suffix is: DC=boingoqa,DC=local The user for the Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=boingo,dc=com 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: -11 - LDAP error: Connect error: start: 0: end: 0 ipa: INFO: Agreement is ready, starting replication . . . Starting replication, please wait until this has completed. [se-idm-01.boingo.com] reports: Update failed! Status: [-11 - LDAP error: Connect error] Failed to start replication _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Some DS level logs might help. Also may it be a firewall issue? FW resetting connection or something like? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Jan 31 18:29:08 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 31 Jan 2014 13:29:08 -0500 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local>, <52EBE850.9070108@redhat.com> <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com> Message-ID: <52EBEB74.5000100@redhat.com> On 01/31/2014 01:22 PM, Todd Maugh wrote: > [root at se-idm-01.boingo.com > slapd-BOINGO-COM]$ cacertdir_rehash > /etc/openldap/cacerts/ > [root at se-idm-01.boingo.com > slapd-BOINGO-COM]$ ldapsearch -LLLx > -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm > admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm > admin,cn=users,dc=boingoqa,dc=local" -W > Enter LDAP Password: > dn: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: user > cn: IDM ADMIN > givenName: IDMADMIN > distinguishedName: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local > instanceType: 4 > whenCreated: 20140128182537.0Z > whenChanged: 20140131014315.0Z > displayName: IDMADMIN > uSNCreated: 31968 > memberOf: CN=Domain Controllers,CN=Users,DC=boingoqa,DC=local > memberOf: CN=Account Operators,CN=Builtin,DC=boingoqa,DC=local > memberOf: CN=Enterprise Admins,CN=Users,DC=boingoqa,DC=local > uSNChanged: 38786 > name: IDM ADMIN > objectGUID:: jai63JfDvUuOGcURntA7hg== > userAccountControl: 66048 > badPwdCount: 0 > codePage: 0 > countryCode: 0 > badPasswordTime: 0 > lastLogoff: 0 > lastLogon: 0 > pwdLastSet: 130356008006093750 > primaryGroupID: 513 > objectSid:: AQUAAAAAAAUVAAAA0+/GU55mz3h0hQ48RwYAAA== > adminCount: 1 > accountExpires: 9223372036854775807 > logonCount: 0 > sAMAccountName: idmadmin > sAMAccountType: 805306368 > userPrincipalName: idmadmin at boingoqa.local > > lockoutTime: 0 > objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=boingoqa,DC=local > dSCorePropagationData: 20140129224024.0Z > dSCorePropagationData: 16010101000000.0Z > lastLogonTimestamp: 130356060672110578 > > [root at se-idm-01.boingo.com > slapd-BOINGO-COM]$ ldapsearch -LLLx > -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm > admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm > admin,cn=users,dc=boingoqa,dc=local" -W -d3 > ldap_url_parse_ext(ldap://qatestdc2.boingoqa.local) > ldap_create > ldap_url_parse_ext(ldap://qatestdc2.boingoqa.local:389/??base) > ldap_extended_operation_s > ldap_extended_operation > ldap_send_initial_request > ldap_new_connection 1 1 0 > ldap_int_open_connection > ldap_connect_to_host: TCP qatestdc2.boingoqa.local:389 > ldap_new_socket: 3 > ldap_prepare_socket: 3 > ldap_connect_to_host: Trying 10.194.55.48:389 > ldap_pvt_connect: fd: 3 tm: -1 async: 0 > ldap_open_defconn: successful > ldap_send_server_request > ber_scanf fmt ({it) ber: > ber_scanf fmt ({) ber: > ber_flush2: 31 bytes to sd 3 > ldap_write: want=31, written=31 > 0000: 30 1d 02 01 01 77 18 80 16 > 31 2e 33 2e 36 2e 31 > 0....w...1.3.6.1 > 0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 > .4.1.1466.20037 > ldap_result ld 0x1af3480 msgid 1 > wait4msg ld 0x1af3480 msgid 1 (infinite timeout) > wait4msg continue ld 0x1af3480 msgid 1 all 1 > ** ld 0x1af3480 Connections: > * host: qatestdc2.boingoqa.local port: 389 (default) > refcnt: 2 status: Connected > last used: Fri Jan 31 16:30:33 2014 > > > ** ld 0x1af3480 Outstanding Requests: > * msgid 1, origid 1, status InProgress > outstanding referrals 0, parent count 0 > ld 0x1af3480 request count 1 (abandoned 0) > ** ld 0x1af3480 Response Queue: > Empty > ld 0x1af3480 response count 0 > ldap_chkResponseList ld 0x1af3480 msgid 1 all 1 > ldap_chkResponseList returns ld 0x1af3480 NULL > ldap_int_select > read1msg: ld 0x1af3480 msgid 1 all 1 > ber_get_next > ldap_read: want=8, got=8 > 0000: 30 84 00 00 00 28 02 > 01 > 0....(.. > ldap_read: want=38, got=38 > 0000: 01 78 84 00 00 00 1f 0a 01 > 00 04 00 04 00 8a 16 > .x.............. > 0010: 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 31 34 36 36 > 1.3.6.1.4.1.1466 > 0020: 2e 32 30 30 33 37 > > .20037 > ber_get_next: tag 0x30 len 40 contents: > read1msg: ld 0x1af3480 msgid 1 message type extended-result > ber_scanf fmt ({eAA) ber: > read1msg: ld 0x1af3480 0 new referrals > read1msg: mark request completed, ld 0x1af3480 msgid 1 > request done: ld 0x1af3480 msgid 1 > res_errno: 0, res_error: <>, res_matched: <> > ldap_free_request (origid 1, msgid 1) > ldap_parse_extended_result > ber_scanf fmt ({eAA) ber: > ber_scanf fmt (a) ber: > ldap_parse_result > ber_scanf fmt ({iAA) ber: > ber_scanf fmt (x) ber: > ber_scanf fmt (}) ber: > ldap_msgfree > TLS: certdb config: configDir='/etc/openldap/cacerts/' > tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly > TLS: cannot open certdb '/etc/openldap/cacerts/', error -8018:Unknown > PKCS #11 error. > TLS: loaded CA certificate file /etc/ipa/ca.crt. > TLS: skipping 'boingoqaCA.cer' - filename does not have expected > format (certificate hash with numeric suffix) > TLS: loaded CA certificate file /etc/openldap/cacerts//ad5923d2.0 from > CA certificate directory /etc/openldap/cacerts/. > TLS: loaded CA certificate file /etc/openldap/cacerts//36480d54.0 from > CA certificate directory /etc/openldap/cacerts/. > TLS: skipping 'ca.cer' - filename does not have expected format > (certificate hash with numeric suffix) > tls_write: want=154, written=154 > 0000: 16 03 01 00 95 01 00 > 00 91 03 01 52 > eb cf a9 2a ...........R...* > 0010: c5 33 57 b1 16 dc 40 d1 0b 71 21 d9 a8 b7 77 43 > .3W... at ..q!...wC > 0020: 2b d4 38 fa 94 9a ef 72 a7 1b ad 00 00 56 00 > ff +.8....r.....V.. > 0030: c0 0a c0 14 00 88 00 87 00 39 > 00 38 c0 0f c0 05 > .........9.8.... > 0040: 00 84 00 35 c0 09 c0 07 c0 13 c0 11 > 00 45 00 44 ...5.........E.D > 0050: 00 33 00 32 00 66 c0 0e c0 > 0c c0 04 c0 02 00 96 .3.2.f.......... > 0060: 00 41 00 2f 00 05 00 04 c0 08 c0 12 > 00 16 00 13 .A./............ > 0070: c0 0d c0 03 00 0a 00 15 00 12 00 09 00 64 > 00 62 .............d.b > 0080: 00 03 00 06 01 00 00 > 12 00 0a 00 08 00 06 00 17 > ................ > 0090: 00 18 00 19 00 0b 00 02 01 > 00 .......... > tls_read: want=5, got=5 > 0000: 16 03 01 0b f4 > ..... > tls_read: want=3060, got=1443 > 0000: 02 00 00 4d 03 01 52 eb cf a0 77 19 29 c0 07 16 > ...M..R...w.)... > 0010: c8 fb 86 e8 e1 c4 53 c0 66 74 27 49 > 5c 28 08 82 ......S.ft'I\(.. > 0020: a8 91 db 3c f3 65 20 c8 2e 00 00 6d 48 6b c4 12 ...<.e > ....mHk.. > 0030: 58 08 ec 6d 62 1d 5f 1c a6 e4 8a 27 da 64 93 0d > X..mb._....'.d.. > 0040: 96 a1 59 4d cd 30 1f 00 2f 00 00 05 ff 01 00 01 > ..YM.0../....... > 0050: 00 0b 00 06 65 00 06 62 00 > 06 5f 30 82 06 5b 30 > ....e..b.._0..[0 > 0060: 82 04 43 a0 03 02 01 02 02 > 0a 15 27 15 8c 00 00 > ..C........'.... > 0070: 00 00 00 04 30 0d 06 09 2a 86 > 48 86 f7 0d 01 01 ....0...*.H..... > 0080: 04 05 00 30 45 31 15 > 30 13 06 0a 09 92 26 89 93 > ...0E1.0.....&.. > 0090: f2 2c 64 01 19 16 05 6c 6f 63 > 61 6c 31 18 30 16 .,d....local1.0. > 00a0: 06 0a 09 92 26 89 93 f2 2c 64 > 01 19 16 08 62 6f ....&...,d....bo > 00b0: 69 6e 67 6f 71 61 31 12 30 10 06 > 03 55 04 03 13 > ingoqa1.0...U... > 00c0: 09 53 4b 59 57 41 52 50 43 41 > 30 1e 17 0d 31 34 > .SKYWARPCA0...14 > 00d0: 30 31 33 30 32 32 33 > 33 35 39 5a 17 0d 31 35 30 > 0130223359Z..150 > 00e0: 31 33 30 32 32 33 33 > 35 39 5a 30 23 31 21 30 > 1f 130223359Z0#1!0. > 00f0: 06 03 55 04 03 13 18 > 51 41 54 45 53 54 44 > 43 32 ..U....QATESTDC2 > 0100: 2e 62 6f 69 6e 67 6f 71 61 2e 6c 6f 63 61 6c 30 > .boingoqa.local0 > 0110: 81 9f 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 > ..0...*.H....... > 0120: 00 03 81 8d 00 30 81 89 02 81 81 > 00 aa 30 bb 57 > .....0.......0.W > 0130: 09 87 1d 40 99 d7 c7 50 ba b4 d7 9d 6d 45 2c 68 > ... at ...P....mE,h > 0140: 19 d4 56 0e 9f 11 4b 8a dc 73 61 2c 9e a7 8b b8 > ..V...K..sa,.... > 0150: 7f b8 c7 e8 1b 08 79 b8 4a a0 b7 f4 6e 93 eb b1 > ......y.J...n... > 0160: 90 36 7a 21 a0 44 70 17 d0 dc 17 17 96 4e 5e 2a > .6z!.Dp......N^* > 0170: 77 6d 67 10 ed d8 1e 7a 40 a8 82 2f 91 d6 9a c2 > wmg....z at ../.... > 0180: 18 ce e3 d0 df 3f 7c f4 b1 df 50 81 4e bf 83 0b > .....?|...P.N... > 0190: 56 fc 26 13 44 23 f1 7b e8 7d d5 > cf 29 54 97 13 V.&.D#.{.}..)T.. > 01a0: 5f 0e ec e3 d9 16 fc de 01 82 78 bf 02 03 01 00 > _.........x..... > 01b0: 01 a3 82 02 f1 30 82 02 ed 30 2f 06 09 2b 06 01 > .....0...0/..+.. > 01c0: 04 01 82 37 14 02 04 > 22 1e 20 00 44 00 > 6f 00 6d ...7...". .D.o.m > 01d0: 00 61 00 69 00 6e 00 43 00 6f > 00 6e 00 74 00 72 .a.i.n.C.o.n.t.r > 01e0: 00 6f 00 6c 00 6c 00 65 00 72 30 > 1d 06 03 55 1d .o.l.l.e.r0...U. > 01f0: 25 04 16 30 14 06 08 > 2b 06 01 05 05 07 03 02 > 06 %..0...+........ > 0200: 08 2b 06 01 05 05 07 03 01 > 30 0b 06 03 55 1d 0f > .+.......0...U.. > 0210: 04 04 03 02 05 a0 30 78 06 09 > 2a 86 48 86 f7 0d ......0x..*.H... > 0220: 01 09 0f 04 6b 30 69 30 0e 06 08 2a 86 48 86 f7 > ....k0i0...*.H.. > 0230: 0d 03 02 02 02 00 80 30 > 0e 06 08 2a 86 48 86 f7 > .......0...*.H.. > 0240: 0d 03 04 02 02 00 80 30 > 0b 06 09 60 86 48 01 65 > .......0...`.H.e > 0250: 03 04 01 2a 30 0b 06 09 60 86 48 01 65 03 > 04 01 ...*0...`.H.e... > 0260: 2d 30 0b 06 09 60 86 48 01 65 > 03 04 01 02 30 0b > -0...`.H.e....0. > 0270: 06 09 60 86 48 01 65 > 03 04 01 05 30 07 06 > 05 2b ..`.H.e....0...+ > 0280: 0e 03 02 07 30 0a 06 08 2a 86 48 86 > f7 0d 03 07 ....0...*.H..... > 0290: 30 1d 06 03 55 1d 0e 04 16 04 14 > 6d 66 8e e6 c8 0...U......mf... > 02a0: 48 ea f4 16 ff 4d 6f 72 2e bb 26 1d 45 a8 6f 30 > H....Mor..&.E.o0 > 02b0: 1f 06 03 55 1d 23 04 18 30 16 80 14 > 7c 5f 71 5f ...U.#..0...|_q_ > 02c0: 6b d3 83 3d 5b af d9 54 9d 7e 88 b1 ce a8 5c 83 > k..=[..T.~....\. > 02d0: 30 81 cc 06 03 55 1d 1f 04 81 c4 30 81 c1 30 81 > 0....U.....0..0. > 02e0: be a0 81 bb a0 81 b8 86 81 b5 6c 64 61 70 3a 2f > ..........ldap:/ > 02f0: 2f 2f 43 4e 3d 53 4b 59 57 41 52 50 43 41 > 2c 43 //CN=SKYWARPCA,C > 0300: 4e 3d 51 41 54 45 53 54 44 > 43 32 2c 43 4e 3d 43 > N=QATESTDC2,CN=C > 0310: 44 50 2c 43 4e 3d 50 75 62 6c 69 63 25 32 30 > 4b DP,CN=Public%20K > 0320: 65 79 25 32 30 53 65 > 72 76 69 63 65 73 > 2c 43 4e ey%20Services,CN > 0330: 3d 53 65 72 76 69 63 65 > 73 2c 43 4e 3d 43 6f 6e > =Services,CN=Con > 0340: 66 69 67 75 72 61 74 > 69 6f 6e 2c 44 43 3d 62 6f > figuration,DC=bo > 0350: 69 6e 67 6f 71 61 2c 44 43 3d 6c 6f 63 61 6c 3f > ingoqa,DC=local? > 0360: 63 65 72 74 69 66 69 > 63 61 74 65 52 65 76 > 6f 63 certificateRevoc > 0370: 61 74 69 6f 6e 4c 69 73 74 3f 62 61 73 65 > 3f 6f ationList?base?o > 0380: 62 6a 65 63 74 43 6c 61 73 73 3d 63 > 52 4c 44 69 bjectClass=cRLDi > 0390: 73 74 72 69 62 75 74 > 69 6f 6e 50 6f 69 6e 74 30 > stributionPoint0 > 03a0: 81 be 06 08 2b 06 01 05 05 07 01 01 04 81 > b1 30 ....+..........0 > 03b0: 81 ae 30 81 ab 06 08 2b 06 01 05 05 07 30 02 > 86 ..0....+.....0.. > 03c0: 81 9e 6c 64 61 70 3a 2f 2f 2f 43 4e 3d 53 4b 59 > ..ldap:///CN=SKY > 03d0: 57 41 52 50 43 41 2c 43 4e > 3d 41 49 41 2c 43 4e WARPCA,CN=AIA,CN > 03e0: 3d 50 75 62 6c 69 63 25 32 30 4b 65 79 25 32 30 > =Public%20Key%20 > 03f0: 53 65 72 76 69 63 65 > 73 2c 43 4e 3d 53 65 72 76 > Services,CN=Serv > 0400: 69 63 65 73 2c 43 4e 3d 43 6f 6e 66 > 69 67 75 72 ices,CN=Configur > 0410: 61 74 69 6f 6e 2c 44 43 3d 62 6f 69 6e 67 6f 71 > ation,DC=boingoq > 0420: 61 2c 44 43 3d 6c 6f 63 61 6c 3f 63 41 43 65 72 > a,DC=local?cACer > 0430: 74 69 66 69 63 61 74 > 65 3f 62 61 73 65 > 3f 6f 62 tificate?base?ob > 0440: 6a 65 63 74 43 6c 61 73 73 3d 63 65 > 72 74 69 66 jectClass=certif > 0450: 69 63 61 74 69 6f 6e 41 75 74 > 68 6f 72 69 74 79 > icationAuthority > 0460: 30 44 06 03 55 1d 11 04 3d 30 > 3b a0 1f 06 09 2b 0D..U...=0;....+ > 0470: 06 01 04 01 82 37 19 > 01 a0 12 04 10 75 > e8 a1 fe .....7......u... > 0480: 6a 23 41 4c 92 f3 0f 8d 03 5e ea 10 82 18 51 41 > j#AL.....^....QA > 0490: 54 45 53 54 44 43 32 > 2e 62 6f 69 6e 67 6f 71 61 > TESTDC2.boingoqa > 04a0: 2e 6c 6f 63 61 6c 30 0d 06 09 2a 86 48 86 f7 0d > .local0...*.H... > 04b0: 01 01 04 05 00 03 82 > 02 01 00 a8 1e e9 8a 00 5d > ...............] > 04c0: 4c 40 3a d1 df b7 e1 3e 8e 97 e8 a5 c9 84 8e 7b > L@:....>.......{ > 04d0: 0d 38 01 83 39 b9 d1 8a e9 74 eb 01 > f6 a3 23 54 .8..9....t....#T > 04e0: d3 81 2c d9 31 50 d2 1f b7 5c 15 9d b9 18 d2 36 > ..,.1P...\.....6 > 04f0: d4 18 34 26 5f ba d2 9d 8b d8 34 d9 2e f7 99 2e > ..4&_.....4..... > 0500: 5b 47 1a f6 26 55 fc 03 60 2c 63 4f e3 2a 65 5c > [G..&U..`,cO.*e\ > 0510: d0 90 69 8b 0b 4b 6a fc 83 9b d2 2d df ef 98 99 > ..i..Kj....-.... > 0520: bd b9 6c 17 79 1d 61 98 df 95 58 74 d3 ac e0 12 > ..l.y.a...Xt.... > 0530: 70 10 d3 02 e6 c6 32 7e d6 22 21 9e 5a a1 9b 13 > p.....2~."!.Z... > 0540: 60 82 2d 44 46 2f b2 16 02 8e 00 64 7f 45 04 e2 > `.-DF/.....d.E.. > 0550: 71 d7 19 ca 95 42 d9 bb a6 b3 4d e4 dc 95 06 c0 > q....B....M..... > 0560: e7 3a 5a 39 f0 aa fe 31 35 6d 34 e1 83 8f 79 0d > .:Z9...15m4...y. > 0570: b0 dd 3c 98 ef 0d 1d 66 8f 3f 54 b6 11 d2 30 a7 > ..<....f.?T...0. > 0580: 4d 2b e5 e3 b8 38 b1 d4 b7 92 73 21 3b 59 1b 9f > M+...8....s!;Y.. > 0590: cd e5 2b 93 3e 60 f2 02 58 02 db 7a f0 81 b6 8a > ..+.>`..X..z.... > 05a0: aa d8 bd > ... > tls_read: want=1617, got=1448 > 0000: 90 36 a9 a9 c7 28 ba 3c 05 a3 2a 4b 0c 51 e8 86 > .6...(.<..*K.Q.. > 0010: 82 35 29 7c 02 15 d3 84 99 6e 74 3a e3 c2 2b 36 > .5)|.....nt:..+6 > 0020: f9 3a aa 7d b4 b6 5a a7 ff 34 2e 03 9d c3 f1 a5 > .:.}..Z..4...... > 0030: 02 55 5e 8d 12 bc b6 0f c1 07 75 76 59 58 > b5 2b .U^.......uvYX.+ > 0040: 9b 47 d6 5e 5e 8f 83 9e b0 50 ae 37 14 18 31 > 4e .G.^^....P.7..1N > 0050: 50 eb 20 51 70 6d 96 e6 6e 63 d2 f7 ed 75 35 f0 P. > Qpm..nc...u5. > 0060: b3 ab 35 4d 34 f8 f2 6c 7a 69 78 67 21 > cf c4 c7 ..5M4..lzixg!... > 0070: 4c 0d 48 7b c3 4e de e1 07 a5 f4 d1 61 ce 12 5c > L.H{.N......a..\ > 0080: 8c 50 28 17 d3 6b ec cd 0d e5 d9 09 31 32 69 > 6d .P(..k......12im > 0090: c5 a5 7b 3b 3e 23 fa 3e d6 05 39 13 5f 9a 77 29 > ..{;>#.>..9._.w) > 00a0: f0 ba 25 c1 42 9f 73 17 0a c5 71 9c 0a ec 6f 2f > ..%.B.s...q...o/ > 00b0: d5 cd 69 8c 87 c3 c8 f9 ab a0 8c 70 de 2c 94 84 > ..i........p.,.. > 00c0: ce 35 ff dd 56 6b 80 af 81 af 58 ee 7e 06 63 7e > .5..Vk....X.~.c~ > 00d0: 96 d1 a6 d0 b7 8c 0d 8b c4 e1 18 44 f4 8e 83 73 > ...........D...s > 00e0: 41 81 10 df a9 94 8d 9b 0c 84 d9 58 79 b0 a1 2d > A..........Xy..- > 00f0: ce 7b 75 8b b9 87 15 5e 33 5c 9b e5 b2 8f d3 3e > .{u....^3\.....> > 0100: f2 e5 f3 ec d6 ac ef f1 70 f3 92 4a 21 ab a4 4c > ........p..J!..L > 0110: 2f 98 77 b4 0b 98 1a 0d 00 05 32 03 01 02 40 > 05 /.w.......2... at . > 0120: 2c 00 25 30 23 31 21 30 > 1f 06 03 55 04 03 13 18 > ,.%0#1!0...U.... > 0130: 51 41 54 45 53 54 44 > 43 32 2e 62 6f 69 6e 67 6f > QATESTDC2.boingo > 0140: 71 61 2e 6c 6f 63 61 6c 00 47 30 45 31 15 30 13 > qa.local.G0E1.0. > 0150: 06 0a 09 92 26 89 93 f2 2c 64 > 01 19 16 05 6c 6f ....&...,d....lo > 0160: 63 61 6c 31 18 30 16 06 0a 09 > 92 26 89 93 f2 2c cal1.0.....&..., > 0170: 64 01 19 16 08 62 6f 69 6e > 67 6f 71 61 31 12 30 d....boingoqa1.0 > 0180: 10 06 03 55 04 03 13 > 09 53 4b 59 57 41 52 50 43 > ...U....SKYWARPC > 0190: 41 00 48 30 46 31 15 > 30 13 06 0a 09 92 26 89 93 > A.H0F1.0.....&.. > 01a0: f2 2c 64 01 19 16 05 6c 6f 63 > 61 6c 31 18 30 16 .,d....local1.0. > 01b0: 06 0a 09 92 26 89 93 f2 2c 64 > 01 19 16 08 62 6f ....&...,d....bo > 01c0: 69 6e 67 6f 71 61 31 13 30 11 06 > 03 55 04 03 13 > ingoqa1.0...U... > 01d0: 0a 62 6f 69 6e 67 6f 71 61 63 61 00 67 30 > 65 31 .boingoqaca.g0e1 > 01e0: 0b 30 09 06 03 55 04 06 > 13 02 55 53 31 15 30 > 13 .0...U....US1.0. > 01f0: 06 03 55 04 0a 13 0c 44 69 67 69 43 > 65 72 74 20 > ..U....DigiCert > 0200: 49 6e 63 31 19 30 17 06 03 > 55 04 0b 13 10 77 77 > Inc1.0...U....ww > 0210: 77 2e 64 69 67 69 63 65 72 > 74 2e 63 6f 6d 31 24 > w.digicert.com1$ > 0220: 30 22 06 03 55 04 03 > 13 1b 44 69 67 69 43 65 72 > 0"..U....DigiCer > 0230: 74 20 41 73 73 75 72 > 65 64 20 49 44 20 52 > 6f 6f t Assured ID Roo > 0240: 74 20 43 41 00 cd 30 81 ca 31 > 0b 30 09 06 03 55 t CA..0..1.0...U > 0250: 04 06 13 02 55 53 31 > 17 30 15 06 03 55 04 > 0a 13 ....US1.0...U... > 0260: 0e 56 65 72 69 53 69 67 > 6e 2c 20 49 6e 63 2e 31 > .VeriSign, Inc.1 > 0270: 1f 30 1d 06 03 55 04 0b 13 16 56 65 > 72 69 53 69 .0...U....VeriSi > 0280: 67 6e 20 54 72 75 73 74 20 > 4e 65 74 77 6f 72 6b gn > Trust Network > 0290: 31 3a 30 38 06 03 55 04 > 0b 13 31 28 63 29 20 32 1:08 > ..U...1(c) 2 > 02a0: 30 30 36 20 56 65 72 > 69 53 69 67 6e 2c 20 49 6e > 006 VeriSign, In > 02b0: 63 2e 20 2d 20 46 6f 72 20 61 75 74 68 > 6f 72 69 c. - For authori > 02c0: 7a 65 64 20 75 73 65 20 > 6f 6e 6c 79 31 45 30 43 > zed use only1E0C > 02d0: 06 03 55 04 03 13 3c 56 65 > 72 69 53 69 67 6e 20 > ..U... 02e0: 43 6c 61 73 73 20 33 20 50 > 75 62 6c 69 63 20 50 > Class 3 Public P > 02f0: 72 69 6d 61 72 79 20 43 65 72 > 74 69 66 69 63 61 > rimary Certifica > 0300: 74 69 6f 6e 20 41 75 74 68 > 6f 72 69 74 79 20 > 2d tion Authority - > 0310: 20 47 35 00 61 30 5f 31 > 0b 30 09 06 03 55 04 06 > G5.a0_1.0...U.. > 0320: 13 02 55 53 31 17 30 > 15 06 03 55 04 > 0a 13 0e 56 ..US1.0...U....V > 0330: 65 72 69 53 69 67 6e 2c 20 > 49 6e 63 2e 31 37 30 eriSign, Inc.170 > 0340: 35 06 03 55 04 0b 13 2e 43 > 6c 61 73 73 20 33 20 5..U....Class > 3 > 0350: 50 75 62 6c 69 63 20 50 72 69 > 6d 61 72 79 20 43 > Public Primary C > 0360: 65 72 74 69 66 69 63 > 61 74 69 6f 6e 20 41 75 74 > ertification Aut > 0370: 68 6f 72 69 74 79 00 6e 30 6c > 31 0b 30 09 06 03 hority.n0l1.0... > 0380: 55 04 06 13 02 55 53 > 31 15 30 13 06 03 55 > 04 0a U....US1.0...U.. > 0390: 13 0c 44 69 67 69 43 65 72 > 74 20 49 6e 63 31 19 > ..DigiCert Inc1. > 03a0: 30 17 06 03 55 04 0b 13 10 > 77 77 77 2e 64 69 67 > 0...U....www.dig > 03b0: 69 63 65 72 74 2e 63 6f 6d 31 > 2b 30 29 06 03 55 icert.com1+0)..U > 03c0: 04 03 13 22 44 69 67 > 69 43 65 72 74 20 48 > 69 67 ..."DigiCert Hig > 03d0: 68 20 41 73 73 75 72 > 61 6e 63 65 20 45 56 20 52 > h Assurance EV R > 03e0: 6f 6f 74 20 43 41 00 77 30 > 75 31 0b 30 09 06 03 > oot CA.w0u1.0... > 03f0: 55 04 06 13 02 55 53 > 31 18 30 16 06 03 55 > 04 0a U....US1.0...U.. > 0400: 13 0f 47 54 45 20 43 6f 72 70 > 6f 72 61 74 69 6f ..GTE Corporatio > 0410: 6e 31 27 30 25 06 03 55 > 04 0b 13 1e 47 54 45 20 > n1'0%..U....GTE > 0420: 43 79 62 65 72 54 72 > 75 73 74 20 53 > 6f 6c 75 74 CyberTrust Solut > 0430: 69 6f 6e 73 2c 20 49 6e 63 2e 31 23 30 21 06 03 > ions, Inc.1#0!.. > 0440: 55 04 03 13 1a 47 54 45 20 43 79 62 > 65 72 54 72 U....GTE > CyberTr > 0450: 75 73 74 20 47 6c 6f 62 61 6c > 20 52 6f 6f 74 00 ust Global Root. > 0460: 63 30 61 31 0b 30 09 06 03 55 04 06 > 13 02 55 53 > c0a1.0...U....US > 0470: 31 15 30 13 06 03 55 > 04 0a 13 0c 44 69 67 69 43 > 1.0...U....DigiC > 0480: 65 72 74 20 49 6e 63 31 19 30 > 17 06 03 55 04 0b ert > Inc1.0...U.. > 0490: 13 10 77 77 77 2e 64 69 67 69 > 63 65 72 74 2e 63 > ..www.digicert.c > 04a0: 6f 6d 31 20 30 1e 06 03 55 04 03 13 17 44 > 69 67 om1 0...U....Dig > 04b0: 69 43 65 72 74 20 47 > 6c 6f 62 61 6c 20 52 6f 6f > iCert Global Roo > 04c0: 74 20 43 41 00 5c 30 5a 31 > 0b 30 09 06 03 55 04 t > CA.\0Z1.0...U. > 04d0: 06 13 02 49 45 31 12 > 30 10 06 03 55 04 > 0a 13 09 ...IE1.0...U.... > 04e0: 42 61 6c 74 69 6d 6f 72 65 31 13 30 11 06 > 03 55 Baltimore1.0...U > 04f0: 04 0b 13 0a 43 79 62 65 72 54 72 > 75 73 74 31 22 > ....CyberTrust1" > 0500: 30 20 06 03 55 04 03 > 13 19 42 61 6c 74 69 6d 6f 0 > ..U....Baltimo > 0510: 72 65 20 43 79 62 65 > 72 54 72 75 73 74 20 > 52 6f re CyberTrust Ro > 0520: 6f 74 00 37 30 35 31 13 > 30 11 06 03 55 04 0a 13 > ot.7051.0...U... > 0530: 0a 42 4f 49 4e 47 4f 2e 43 4f 4d 31 1e 30 1c 06 > .BOINGO.COM1.0.. > 0540: 03 55 04 03 13 15 43 > 65 72 74 69 66 69 63 > 61 74 .U....Certificat > 0550: 65 20 41 75 74 68 6f 72 69 > 74 79 00 72 30 70 31 e > Authority.r0p1 > 0560: 2b 30 29 06 03 55 04 0b 13 > 22 43 6f 70 79 72 69 +0)..U..."Copyri > 0570: 67 68 74 20 28 63 29 > 20 31 39 39 37 20 > 4d 69 63 ght (c) 1997 Mic > 0580: 72 6f 73 6f 66 74 20 43 6f 72 70 2e > 31 1e 30 1c rosoft Corp.1.0. > 0590: 06 03 55 04 0b 13 15 4d 69 63 72 6f > 73 6f 66 74 ..U....Microsoft > 05a0: 20 43 6f 72 70 6f 72 61 > Corpora > tls_read: want=169, got=169 > 0000: 74 69 6f 6e 31 21 30 1f 06 03 55 04 03 13 18 > 4d tion1!0...U....M > 0010: 69 63 72 6f 73 6f 66 74 20 52 6f 6f 74 20 41 75 > icrosoft Root Au > 0020: 74 68 6f 72 69 74 79 00 61 30 > 5f 31 13 30 11 06 > thority.a0_1.0.. > 0030: 0a 09 92 26 89 93 f2 2c 64 01 > 19 16 03 63 6f 6d ...&...,d....com > 0040: 31 19 30 17 06 0a 09 92 26 89 > 93 f2 2c 64 01 19 1.0.....&...,d.. > 0050: 16 09 6d 69 63 72 6f 73 6f 66 74 31 2d 30 2b 06 > ..microsoft1-0+. > 0060: 03 55 04 03 13 24 4d 69 63 > 72 6f 73 6f 66 74 20 .U...$Microsoft > 0070: 52 6f 6f 74 20 43 65 72 74 69 > 66 69 63 61 74 65 Root > Certificate > 0080: 20 41 75 74 68 6f 72 69 74 79 > 00 19 30 17 31 15 > Authority..0.1. > 0090: 30 13 06 03 55 04 03 > 13 0c 4e 54 20 41 55 54 48 > 0...U....NT AUTH > 00a0: 4f 52 49 54 59 0e 00 00 > 00 ORITY.... > TLS: certificate [CN=QATESTDC2.boingoqa.local] is not valid - error > -8179:Peer's Certificate issuer is not recognized.. > tls_write: want=205, written=205 > 0000: 16 03 01 00 8d 0b 00 00 03 00 00 00 > 10 00 00 82 > ................ > 0010: 00 80 51 77 d5 b2 c4 16 28 3f 82 11 > 3e 6c 03 b7 ..Qw....(?..>l.. > 0020: 6e 32 cc f0 cd 91 fb 91 7b 1d 56 a1 c0 68 3d 5d > n2......{.V..h=] > 0030: 12 17 b0 28 8c 66 36 80 3b b0 a4 a5 a8 f5 bb cd > ...(.f6.;....... > 0040: cf c9 00 25 ce 30 20 e0 ae 3c 7e 5d e3 d9 7a ac ...%.0 > ..<~]..z. > 0050: 53 b9 3a fb c7 ed d1 30 0e 67 a0 75 57 5f 1a d8 > S.:....0.g.uW_.. > 0060: 83 21 b6 40 6a ef d3 3c af ec 4b 23 40 09 01 46 > .!. at j..<..K#@..F > 0070: f2 42 ff e9 b6 1b e9 0b 68 9b 1e ad dd 6b 50 ab > .B......h....kP. > 0080: 4b 1e 8e 20 c4 5b 5c ce c1 41 71 2d cc 89 07 03 K.. > .[\..Aq-.... > 0090: 3b b8 14 03 01 00 01 01 16 > 03 01 00 30 04 98 00 > ;...........0... > 00a0: 76 2c 80 06 50 3d 3e 40 c9 a9 7c aa 38 be 7a 88 > v,..P=>@..|.8.z. > 00b0: fe 82 46 0d a5 5d ef 52 3b af 52 2d 54 52 21 e1 > ..F..].R;.R-TR!. > 00c0: 43 23 6c 30 90 00 71 9b a6 84 d1 d5 > e9 C#l0..q...... > tls_read: want=5, got=5 > 0000: 14 03 01 00 01 > > ..... > tls_read: want=1, got=1 > 0000: 01 > . > tls_read: want=5, got=5 > 0000: 16 03 01 00 30 > > ....0 > tls_read: want=48, got=48 > 0000: 5e 06 20 97 b5 95 ed af 95 f7 e9 d4 dc 1c 9c 36 ^. > ............6 > 0010: e4 09 16 8e 39 fe e1 55 52 68 d4 18 bd 05 > 59 8d ....9..URh....Y. > 0020: f5 25 0f 95 01 70 ef 58 80 f8 47 a6 93 5f 1a d2 > .%...p.X..G.._.. > TLS certificate verification: subject: CN=QATESTDC2.boingoqa.local, > issuer: CN=SKYWARPCA,DC=boingoqa,DC=local, cipher: AES-128, security > level: high, secret key bits: 128, total key bits: 128, cache hits: 0, > cache misses: 0, cache not reusable: 0 > Enter LDAP Password: > ldap_sasl_bind > ldap_send_initial_request > ldap_send_server_request > ber_scanf fmt ({it) ber: > ber_scanf fmt ({i) ber: > ber_flush2: 65 bytes to sd 3 > tls_write: want=101, written=101 > 0000: 17 03 01 00 60 37 2e 2c f3 > b1 6a 3f 9e f7 30 eb ....`7.,..j?..0. > 0010: 1d ad ed 7b 62 b2 43 43 fd dd de b9 0f 13 1d 79 > ...{b.CC.......y > 0020: fa 30 2c a5 96 03 04 22 61 18 > b7 87 26 06 8c ba > .0,...."a...&... > 0030: fa 31 1f 12 f8 f9 b8 32 bb 96 ef 8d 75 98 04 e9 > .1.....2....u... > 0040: ff d8 d7 50 44 c2 ec 7c 03 26 fb 47 07 a8 a8 44 > ...PD..|.&.G...D > 0050: 98 22 c6 bb 95 d0 b1 4b 83 34 0a a0 79 7d 15 39 > .".....K.4..y}.9 > 0060: f9 77 36 0d 86 > .w6.. > ldap_write: want=65, written=65 > 0000: 30 3f 02 01 02 60 3a 02 01 03 04 > 2a 63 6e 3d 69 0?...`:....*cn=i > 0010: 64 6d 20 61 64 6d 69 6e 2c 63 6e 3d 75 73 65 72 > dm admin,cn=user > 0020: 73 2c 64 63 3d 62 6f 69 6e 67 6f 71 61 2c 64 63 > s,dc=boingoqa,dc > 0030: 3d 6c 6f 63 61 6c 80 09 67 30 5f 62 30 69 6e 67 > =local..g0_b0ing > 0040: 30 > 0 > ldap_result ld 0x1af3480 msgid 2 > wait4msg ld 0x1af3480 msgid 2 (infinite timeout) > wait4msg continue ld 0x1af3480 msgid 2 all 1 > ** ld 0x1af3480 Connections: > * host: qatestdc2.boingoqa.local port: 389 (default) > refcnt: 2 status: Connected > last used: Fri Jan 31 16:30:43 2014 > > > ** ld 0x1af3480 Outstanding Requests: > * msgid 2, origid 2, status InProgress > outstanding referrals 0, parent count 0 > ld 0x1af3480 request count 1 (abandoned 0) > ** ld 0x1af3480 Response Queue: > Empty > ld 0x1af3480 response count 0 > ldap_chkResponseList ld 0x1af3480 msgid 2 all 1 > ldap_chkResponseList returns ld 0x1af3480 NULL > ldap_int_select > read1msg: ld 0x1af3480 msgid 2 all 1 > ber_get_next > tls_read: want=5, got=5 > 0000: 17 03 01 00 30 > > ....0 > tls_read: want=48, got=48 > 0000: 23 47 ac 27 3e 60 2b 38 e2 0d 99 99 ce 3b f5 b1 > #G.'>`+8.....;.. > 0010: ae ae 7e 2a 18 40 53 b7 d2 06 7a e7 7f 7f 06 0e > ..~*. at S...z..... > 0020: eb ff 91 c4 76 30 8c 0c ed 5a 94 d2 32 14 d5 1d > ....v0...Z..2... > ldap_read: want=8, got=8 > 0000: 30 84 00 00 00 10 02 > 01 > 0....... > ldap_read: want=14, got=14 > 0000: 02 61 84 00 00 00 07 > 0a 01 00 04 00 04 00 > .a............ > ber_get_next: tag 0x30 len 16 contents: > read1msg: ld 0x1af3480 msgid 2 message type bind > ber_scanf fmt ({eAA) ber: > read1msg: ld 0x1af3480 0 new referrals > read1msg: mark request completed, ld 0x1af3480 msgid 2 > request done: ld 0x1af3480 msgid 2 > res_errno: 0, res_error: <>, res_matched: <> > ldap_free_request (origid 2, msgid 2) > ldap_parse_result > ber_scanf fmt ({iAA) ber: > ber_scanf fmt (}) ber: > ldap_msgfree > ldap_search_ext > put_filter: "(objectclass=*)" > put_filter: simple > put_simple_filter: "objectclass=*" > ldap_send_initial_request > ldap_send_server_request > ber_scanf fmt ({it) ber: > ber_scanf fmt ({) ber: > ber_flush2: 81 bytes to sd 3 > tls_write: want=117, written=117 > 0000: 17 03 01 00 70 1e f0 51 eb f7 > 9e 45 2a 29 20 50 ....p..Q...E*) P > 0010: 03 f2 88 b8 31 68 1d 0d 04 4d 5b c9 f3 e5 9c 6a > ....1h...M[....j > 0020: 32 b2 fc c2 0f 2d fa e4 c2 1d ae ce 17 15 75 e8 > 2....-........u. > 0030: 63 47 44 ab 82 0f c9 9d 90 3f 16 60 7a 7b 6d c1 > cGD......?.`z{m. > 0040: 64 10 1e e8 01 14 f8 b4 7c 54 a9 4a 84 ac b2 dc > d.......|T.J.... > 0050: bd 47 07 4f b7 48 6d 54 87 2e 26 4a 84 c8 a5 b9 > .G.O.HmT..&J.... > 0060: 8e a3 68 80 10 50 02 70 34 > 72 83 b6 64 72 8b 70 > ..h..P.p4r..dr.p > 0070: 07 cd 8e c0 b9 > ..... > ldap_write: want=81, written=81 > 0000: 30 4f 02 01 03 63 4a 04 2a 63 6e 3d > 69 64 6d 20 0O...cJ.*cn=idm > 0010: 61 64 6d 69 6e 2c 63 6e 3d 75 73 65 72 73 > 2c 64 admin,cn=users,d > 0020: 63 3d 62 6f 69 6e 67 6f 71 61 2c 64 63 3d 6c 6f > c=boingoqa,dc=lo > 0030: 63 61 6c 0a 01 02 0a 01 00 02 01 00 02 01 > 00 01 cal............. > 0040: 01 00 87 0b 6f 62 6a 65 63 74 63 > 6c 61 73 73 30 > ....objectclass0 > 0050: 00 > . > ldap_result ld 0x1af3480 msgid -1 > wait4msg ld 0x1af3480 msgid -1 (infinite timeout) > wait4msg continue ld 0x1af3480 msgid -1 all 0 > ** ld 0x1af3480 Connections: > * host: qatestdc2.boingoqa.local port: 389 (default) > refcnt: 2 status: Connected > last used: Fri Jan 31 16:30:43 2014 > > > ** ld 0x1af3480 Outstanding Requests: > * msgid 3, origid 3, status InProgress > outstanding referrals 0, parent count 0 > ld 0x1af3480 request count 1 (abandoned 0) > ** ld 0x1af3480 Response Queue: > Empty > ld 0x1af3480 response count 0 > ldap_chkResponseList ld 0x1af3480 msgid -1 all 0 > ldap_chkResponseList returns ld 0x1af3480 NULL > ldap_int_select > read1msg: ld 0x1af3480 msgid -1 all 0 > ber_get_next > tls_read: want=5, got=5 > 0000: 17 03 01 06 40 > > ....@ > tls_read: want=1600, got=1600 > 0000: f0 a7 12 28 36 88 72 46 57 > ea 69 d3 d5 dd f6 ee > ...(6.rFW.i..... > 0010: 58 58 ba f5 b2 d9 b4 57 7f 81 e4 fd 31 61 a9 2e > XX.....W....1a.. > 0020: 88 b7 7d da d6 98 b2 6e 8c 17 36 ff 9f a5 d7 d4 > ..}....n..6..... > 0030: fd de 24 2c 2c 5c 4e aa 02 1a e2 c8 cf b7 5d eb > ..$,,\N.......]. > 0040: 1f e2 3c 0a 8b dc 6a 26 25 0f 5a 27 4a 8e 27 b4 > ..<...j&%.Z'J.'. > 0050: b8 8d 98 2d 8a 62 23 be a0 61 a6 a3 01 63 40 ae > ...-.b#..a...c at . > 0060: 41 2e bf 8a 1f 53 4b d5 10 53 2c 64 07 0c 0d d8 > A....SK..S,d.... > 0070: 51 36 6b 75 b5 25 c3 87 21 df 5f 1a 13 82 19 90 > Q6ku.%..!._..... > 0080: 42 13 b1 d9 71 94 83 b7 74 00 95 66 > b5 38 a0 85 B...q...t..f.8.. > 0090: b3 82 92 e2 f0 f5 88 f4 06 78 c3 55 f0 ea 16 6b > .........x.U...k > 00a0: 77 2e 65 09 81 ce 8e 56 75 8f fe 91 d8 3f dc 53 > w.e....Vu....?.S > 00b0: 23 bf ab cd bb 6d 23 d7 88 14 b1 0b eb 6f ab 8a > #....m#......o.. > 00c0: 00 8b 4f 83 d7 22 17 71 cb 4f 65 67 a9 0e 41 95 > ..O..".q.Oeg..A. > 00d0: 1f 42 4c e0 68 17 13 9e 1a d4 64 88 ff e2 ee 52 > .BL.h.....d....R > 00e0: 60 a0 ce 36 80 b9 38 eb 8b 85 e7 3a b1 fa 4b 2c > `..6..8....:..K, > 00f0: 89 71 79 60 04 2c 6c 5c 8f 7f > bb 7e c1 fd d0 c1 .qy`.,l\...~.... > 0100: b9 7c 6f fb bc 70 06 f0 f9 11 ee 44 58 4f eb c2 > .|o..p.....DXO.. > 0110: 86 23 83 0c 49 e0 81 5d 4f 37 f5 70 70 af b9 ed > .#..I..]O7.pp... > 0120: dc 08 a9 77 4b 56 80 f0 c1 cc 55 87 3f 2a a1 63 > ...wKV....U.?*.c > 0130: 27 b5 c2 8c 9f ca ee 61 1b 5d 38 b5 df 80 39 f7 > '......a.]8...9. > 0140: e9 b5 6f b8 1d b0 ad d6 20 dd c6 f0 bd c8 fd 87 ..o..... > ....... > 0150: 4f ea 13 a7 11 09 ee 20 e5 68 f7 f1 10 ae 28 22 O...... > .h....(" > 0160: 79 55 5b 67 4f 3c 1b 36 eb 24 6d cc 5b 46 31 63 > yU[gO<.6.$m.[F1c > 0170: 45 ab 4a 50 66 43 80 aa 5c b1 0e cd > f6 96 bc d4 E.JPfC..\....... > 0180: ad d3 7e f9 48 2f 27 90 af 4e b1 eb c2 fb 81 0a > ..~.H/'..N...... > 0190: 6a e7 18 17 37 71 6c 42 b2 6a 81 ca > e0 73 be 0f j...7qlB.j...s.. > 01a0: 30 ab a3 aa 2a 12 23 54 ed f3 3e e2 a3 fd 5e f4 > 0...*.#T..>...^. > 01b0: 70 0c 7f 32 bb b5 b5 98 25 4b fc a7 d6 ce 1e d9 > p..2....%K...... > 01c0: 29 03 ca 9a 2f 31 46 63 64 a8 9f 21 a2 0b e9 d6 > ).../1Fcd..!.... > 01d0: 2b d8 10 57 78 d0 ae fc 30 fd f5 92 f1 7d c4 7a > +..Wx...0....}.z > 01e0: 36 13 d0 67 0e 16 a4 13 b0 67 16 66 6f af 8c 0b > 6..g.....g.fo... > 01f0: bf 9f 59 c0 7b 1c 00 26 9f fa 87 f3 ae b0 4d 31 > ..Y.{..&......M1 > 0200: 02 db 83 23 ed f9 3c bb 21 19 ea 47 0e 9f 39 3a > ...#..<.!..G..9: > 0210: 5b 7d bc 34 69 ff 5e cb 05 d5 32 b5 f2 d5 da f1 > [}.4i.^...2..... > 0220: 3c 56 c9 91 2e 71 ce d9 27 ec f7 93 97 f0 74 e1 > 0230: cb ca 75 24 3e b3 e4 d3 8b 0c b3 df 74 7d 9e 24 > ..u$>.......t}.$ > 0240: 58 2f d6 4b 50 a3 20 d3 0d c5 cd d1 9a 17 7f 12 X/.KP. > ......... > 0250: c5 b9 57 bf a0 7e a2 d3 29 08 00 07 78 52 > dc 27 ..W..~..)...xR.' > 0260: f7 9e e5 57 52 74 2b 5d 6c eb d6 b0 2c 07 08 84 > ...WRt+]l...,... > 0270: 87 39 7f a5 a2 d1 be 0e 02 42 b9 02 fe 01 69 78 > .9.......B....ix > 0280: c2 f7 26 6e 7e 3b ba 06 81 25 9d d3 8f ae 99 eb > ..&n~;...%...... > 0290: 44 37 c4 57 69 d9 c5 31 31 41 e8 49 70 07 34 95 > D7.Wi..11A.Ip.4. > 02a0: 50 cb fa 1b cd 3f d1 84 54 73 f6 69 0e ab 10 46 > P....?..Ts.i...F > 02b0: a8 1c cb e9 ad ab 80 f7 f4 3c 86 75 a4 de d1 7a > .........<.u...z > 02c0: d2 7a 47 02 ce ba 42 c8 53 05 76 ca 2e 1d 35 e6 > .zG...B.S.v...5. > 02d0: e6 23 70 ae e8 0f 2c 0f e6 ab 2a 65 8c ed 0a 7b > .#p...,...*e...{ > 02e0: ec 3a b5 4e 5b d9 b1 3d e5 4a 92 22 29 01 > 7e 11 .:.N[..=.J.").~. > 02f0: 28 6a c2 48 3f 7f b8 c1 13 80 89 d3 e7 cb 19 7d > (j.H?..........} > 0300: e5 2e eb c9 b6 7b b0 dd 9f c0 4b ea 16 53 aa 11 > .....{....K..S.. > 0310: 24 17 c3 0c 5c 35 e2 fd 76 28 05 95 > 9d 40 a7 9b $...\5..v(... at .. > 0320: 6b 3c 31 c0 2b a1 a2 68 ba 94 ec f7 12 51 85 1c > k<1.+..h.....Q.. > 0330: 96 18 2e 88 bd c8 d7 c2 04 fe > 47 cc 73 9a af bd ..........G.s... > 0340: 11 90 06 f6 9f e8 58 71 88 42 c9 e6 b8 0f 3f 70 > ......Xq.B....?p > 0350: a8 30 79 46 17 fa 2e ae 22 f8 b8 75 > 14 c0 7a e1 .0yF...."..u..z. > 0360: 92 63 c0 62 4f 14 8e d9 78 30 e9 82 1f c4 df 2a > .c.bO...x0.....* > 0370: f2 13 5b c3 d3 3f 2b 2c 84 7e 9a d9 82 18 af 11 > ..[..?+,.~...... > 0380: 0f 7c 85 c8 e0 09 91 19 7a 56 cc 59 fc 0c da ca > .|......zV.Y.... > 0390: c8 84 8c cf 3e 18 e1 5a 07 5e 4e f0 b1 a9 14 88 > ....>..Z.^N..... > 03a0: e1 ee a2 a1 9b 98 7d f1 ac a0 61 06 ab 45 7e c5 > ......}...a..E~. > 03b0: 5e 0f 38 6f 75 5e 6e 9e d4 8a 29 6c 1a a5 62 06 > ^.8ou^n...)l..b. > 03c0: 0b cf 61 d6 b0 1d 48 4b f5 07 16 f6 d5 63 4c 23 > ..a...HK.....cL# > 03d0: 48 2e 35 b5 da e2 65 64 ab 9b 8d f3 5f 57 9a ec > H.5...ed...._W.. > 03e0: a4 b1 82 c1 7f 47 3e 4c 33 51 0d 25 05 7b 5c 3d > .....G>L3Q.%.{\= > 03f0: f2 6a 09 ab f8 52 d1 2f ac 48 ef 7a f7 44 d4 92 > .j...R./.H.z.D.. > 0400: 86 72 20 77 ff af e5 c8 3d 8e 34 4b > d7 e2 3a 63 .r w....=.4K..:c > 0410: 1a a2 d3 f0 50 86 61 1e 3c 8e ce f9 5d a9 b8 9d > ....P.a.<...]... > 0420: 00 9a 6d f2 3a c8 d7 b1 ea ad 96 cd 64 dd e0 83 > ..m.:.......d... > 0430: d3 b0 5b 84 bb c5 a5 fe fe 6e d9 85 fe a9 60 56 > ..[......n....`V > 0440: 01 8f ec 1e f6 d6 1b 1d 75 51 25 fb 6a 96 2d 02 > ........uQ%.j.-. > 0450: d2 fe fe 7b 33 48 7b d9 06 60 cc a4 e4 46 51 bb > ...{3H{..`...FQ. > 0460: 4f 21 ae 78 6a f6 cf 5a 81 6f 64 e7 bc 8f e5 63 > O!.xj..Z.od....c > 0470: 4b 31 a0 4b 2a 5d 0a 71 c3 fb d9 67 01 a3 03 14 > K1.K*].q...g.... > 0480: 5e 32 b1 4b 77 a2 03 47 07 da 9e 7c 0a 8a 40 5b > ^2.Kw..G...|..@[ > 0490: 28 bd 81 cf 1f 6c 7b 2e ae 21 1b 88 ce 72 08 02 > (....l{..!...r.. > 04a0: 1e 83 50 56 66 4b 0f 3e ca 6f 56 29 > 93 c2 1f 6f ..PVfK.>.oV)...o > 04b0: 07 b9 0a d1 a1 f8 6b da 3b c6 20 8f 68 05 66 53 > ......k.;. .h.fS > 04c0: 61 3e 20 9a a4 05 13 15 b9 c0 55 f8 59 32 d8 3f a> > .......U.Y2.? > 04d0: 79 50 c0 2a 89 1d 3c 12 f1 64 d8 84 b4 f9 ed 95 > yP.*..<..d...... > 04e0: 25 39 b7 72 8f 53 cb 8a 6a f0 b8 76 bd 6d 42 30 > %9.r.S..j..v.mB0 > 04f0: 96 e7 18 ee d9 6f 56 57 d2 e8 ee 68 a7 73 1c a5 > .....oVW...h.s.. > 0500: 02 31 b3 8f 29 c5 36 c0 ed 29 50 c1 19 da 45 7d > .1..).6..)P...E} > 0510: e1 be e3 7d 2e 54 20 93 94 a2 02 ab 42 e0 71 4b ...}.T > .....B.qK > 0520: 1d 14 98 6e 27 fc d6 7f 98 58 98 7a 30 2f 39 19 > ...n'....X.z0/9. > 0530: 62 e0 32 1a 8a 12 b8 b0 03 55 66 9b 72 b4 ac ff > b.2......Uf.r... > 0540: e4 7c eb 1d 80 b5 f6 b6 33 15 01 f8 bb aa 8e d0 > .|......3....... > 0550: 39 f4 2d e1 d1 79 3f 63 e0 61 02 d9 5b 1e 1f e7 > 9.-..y?c.a..[... > 0560: c9 31 a8 5a cc d8 90 cc 78 3f 09 bd > e3 20 e3 d3 .1.Z....x?... .. > 0570: c2 bd 0d 5f 17 1b 4d 97 62 ca ed b6 37 95 12 ec > ..._..M.b...7... > 0580: d0 eb 6a 2a 34 64 77 16 08 82 > 5f ca 21 1a 7e cd > ..j*4dw..._.!.~. > 0590: a3 91 4d ce f6 7b a7 a9 00 03 8a b2 e9 05 a5 89 > ..M..{.......... > 05a0: 9a ef 05 24 a3 c9 ab 0b a6 1d ec 36 76 5f 9e b3 > ...$.......6v_.. > 05b0: d8 01 b8 29 e4 04 19 5e 36 84 3a a7 ac 56 bb 2f > ...)...^6.:..V./ > 05c0: 51 bf fc e0 46 cc d9 b1 7f ac 34 99 ea 8d ca 24 > Q...F.....4....$ > 05d0: 03 23 ec 71 d4 dc 13 fb a6 86 81 99 41 > 8b 7f dd .#.q........A... > 05e0: 67 ec 02 a6 fc 21 f5 50 82 e6 3c 46 04 88 62 > f6 g....!.P.. 05f0: 77 a3 07 08 44 7f 8d 9d 14 d5 41 90 17 5d 93 e0 > w...D.....A..].. > 0600: ba 1c 7b 7a 2f 0d cc 25 9d 44 3e 09 f8 41 19 61 > ..{z/..%.D>..A.a > 0610: 7b 20 8a 5e 65 c3 d9 e1 42 d2 88 fe c5 4e cf fa { > .^e...B....N.. > 0620: c6 ea cc 43 52 bc 08 92 e5 c0 d1 21 4a b9 f7 aa > ...CR......!J... > 0630: 50 a7 61 c6 47 0c f0 f4 1c b1 ab cb 06 00 d1 0d > P.a.G........... > ldap_read: want=8, got=8 > 0000: 30 84 00 00 06 01 02 > 01 > 0....... > ldap_read: want=1535, got=1535 > 0000: 03 64 84 00 00 05 f8 04 2a > 43 4e 3d 49 44 4d 20 .d......*CN=IDM > 0010: 41 44 4d 49 4e 2c 43 4e 3d 55 73 65 72 73 > 2c 44 ADMIN,CN=Users,D > 0020: 43 3d 62 6f 69 6e 67 6f 71 61 2c 44 43 3d 6c 6f > C=boingoqa,DC=lo > 0030: 63 61 6c 30 84 00 00 05 c6 30 > 84 00 00 00 3c 04 cal0.....0....<. > 0040: 0b 6f 62 6a 65 63 74 43 6c 61 73 73 > 31 84 00 00 .objectClass1... > 0050: 00 29 04 03 74 6f 70 04 06 70 > 65 72 73 6f 6e 04 > .)..top..person. > 0060: 14 6f 72 67 61 6e 69 7a 61 74 69 6f 6e 61 6c 50 > .organizationalP > 0070: 65 72 73 6f 6e 04 04 75 73 65 72 30 84 00 > 00 00 erson..user0.... > 0080: 15 04 02 63 6e 31 84 00 00 00 0b 04 > 09 49 44 4d ...cn1.......IDM > 0090: 20 41 44 4d 49 4e 30 84 00 00 00 > 1b 04 09 67 69 > ADMIN0.......gi > 00a0: 76 65 6e 4e 61 6d 65 31 84 00 00 00 > 0a 04 08 49 venName1.......I > 00b0: 44 4d 41 44 4d 49 4e 30 84 00 00 00 45 04 > 11 64 DMADMIN0....E..d > 00c0: 69 73 74 69 6e 67 75 69 73 68 65 64 > 4e 61 6d 65 istinguishedName > 00d0: 31 84 00 00 00 2c 04 2a 43 4e > 3d 49 44 4d 20 41 1....,.*CN=IDM A > 00e0: 44 4d 49 4e 2c 43 4e 3d 55 73 65 72 73 > 2c 44 43 DMIN,CN=Users,DC > 00f0: 3d 62 6f 69 6e 67 6f 71 61 2c 44 43 3d 6c 6f 63 > =boingoqa,DC=loc > 0100: 61 6c 30 84 00 00 00 17 04 > 0c 69 6e 73 74 61 6e > al0.......instan > 0110: 63 65 54 79 70 65 31 > 84 00 00 00 03 04 01 > 34 30 ceType1.......40 > 0120: 84 00 00 00 26 04 0b 77 68 > 65 6e 43 72 65 61 74 ....&..whenCreat > 0130: 65 64 31 84 00 00 00 > 13 04 11 32 30 31 34 > 30 31 ed1.......201401 > 0140: 32 38 31 38 32 35 33 > 37 2e 30 5a 30 84 00 00 00 > 28182537.0Z0.... > 0150: 26 04 0b 77 68 65 6e 43 68 61 6e 67 65 64 31 84 > &..whenChanged1. > 0160: 00 00 00 13 04 11 32 > 30 31 34 30 31 33 31 > 30 31 ......2014013101 > 0170: 34 33 31 35 2e 30 5a 30 84 00 00 00 > 1d 04 0b 64 4315.0Z0.......d > 0180: 69 73 70 6c 61 79 4e 61 6d 65 31 84 00 00 00 > 0a isplayName1..... > 0190: 04 08 49 44 4d 41 44 4d 49 4e 30 84 > 00 00 00 19 ..IDMADMIN0..... > 01a0: 04 0a 75 53 4e 43 72 65 61 74 65 64 31 84 > 00 00 ..uSNCreated1... > 01b0: 00 07 04 05 33 31 39 > 36 38 30 84 00 00 00 > af 04 ....319680...... > 01c0: 08 6d 65 6d 62 65 72 4f 66 31 84 00 00 00 > 9f 04 .memberOf1...... > 01d0: 33 43 4e 3d 44 6f 6d 61 69 6e 20 43 6f 6e 74 72 3CN=Domain > Contr > 01e0: 6f 6c 6c 65 72 73 2c 43 4e 3d 55 73 65 72 73 > 2c ollers,CN=Users, > 01f0: 44 43 3d 62 6f 69 6e 67 6f 71 61 2c 44 43 3d 6c > DC=boingoqa,DC=l > 0200: 6f 63 61 6c 04 34 43 4e 3d 41 63 63 6f 75 6e 74 > ocal.4CN=Account > 0210: 20 4f 70 65 72 61 74 6f 72 73 > 2c 43 4e 3d 42 75 Operators,CN=Bu > 0220: 69 6c 74 69 6e 2c 44 43 3d 62 6f 69 6e 67 6f 71 > iltin,DC=boingoq > 0230: 61 2c 44 43 3d 6c 6f 63 61 6c 04 32 43 4e 3d 45 > a,DC=local.2CN=E > 0240: 6e 74 65 72 70 72 69 73 > 65 20 41 64 6d 69 6e 73 > nterprise Admins > 0250: 2c 43 4e 3d 55 73 65 72 73 > 2c 44 43 3d 62 6f 69 > ,CN=Users,DC=boi > 0260: 6e 67 6f 71 61 2c 44 43 3d 6c 6f 63 61 6c 30 84 > ngoqa,DC=local0. > 0270: 00 00 00 19 04 0a 75 53 4e 43 > 68 61 6e 67 65 64 ......uSNChanged > 0280: 31 84 00 00 00 07 04 > 05 33 38 37 38 36 30 > 84 00 1.......387860.. > 0290: 00 00 17 04 04 6e 61 6d 65 31 > 84 00 00 00 0b 04 .....name1...... > 02a0: 09 49 44 4d 20 41 44 4d 49 4e 30 84 00 00 00 24 > .IDM ADMIN0....$ > 02b0: 04 0a 6f 62 6a 65 63 74 47 55 49 44 31 84 > 00 00 ..objectGUID1... > 02c0: 00 12 04 10 8d a8 ba dc 97 c3 bd 4b > 8e 19 c5 11 ...........K.... > 02d0: 9e d0 3b 86 30 84 00 00 00 21 > 04 12 75 73 65 72 > ..;.0....!..user > 02e0: 41 63 63 6f 75 6e 74 43 6f 6e 74 72 6f 6c 31 84 > AccountControl1. > 02f0: 00 00 00 07 04 05 36 > 36 30 34 38 30 84 00 > 00 00 ......660480.... > 0300: 16 04 0b 62 61 64 50 77 64 43 > 6f 75 6e 74 31 84 > ...badPwdCount1. > 0310: 00 00 00 03 04 01 30 > 30 84 00 00 00 13 04 > 08 63 ......00.......c > 0320: 6f 64 65 50 61 67 65 31 > 84 00 00 00 03 04 01 > 30 odePage1.......0 > 0330: 30 84 00 00 00 16 04 > 0b 63 6f 75 6e 74 72 79 43 > 0.......countryC > 0340: 6f 64 65 31 84 00 00 00 > 03 04 01 30 30 84 00 > 00 ode1.......00... > 0350: 00 1a 04 0f 62 61 64 50 61 73 73 > 77 6f 72 64 54 > ....badPasswordT > 0360: 69 6d 65 31 84 00 00 00 03 > 04 01 30 30 84 00 00 > ime1.......00... > 0370: 00 15 04 0a 6c 61 73 74 4c 6f 67 6f 66 66 31 84 > ....lastLogoff1. > 0380: 00 00 00 03 04 01 30 > 30 84 00 00 00 14 04 > 09 6c ......00.......l > 0390: 61 73 74 4c 6f 67 6f 6e 31 84 00 00 00 03 04 > 01 astLogon1....... > 03a0: 30 30 84 00 00 00 26 > 04 0a 70 77 64 4c 61 73 74 > 00....&..pwdLast > 03b0: 53 65 74 31 84 00 00 > 00 14 04 12 31 33 30 > 33 35 Set1.......13035 > 03c0: 36 30 30 38 30 30 36 > 30 39 33 37 35 30 30 > 84 00 60080060937500 > .. > 03d0: 00 00 1b 04 0e 70 72 69 6d 61 72 79 47 72 > 6f 75 .....primaryGrou > 03e0: 70 49 44 31 84 00 00 > 00 05 04 03 35 31 33 > 30 84 pID1.......5130. > 03f0: 00 00 00 2f 04 09 6f 62 6a 65 63 74 53 69 64 31 > .../..objectSid1 > 0400: 84 00 00 00 1e 04 1c 01 05 00 00 00 > 00 00 05 15 > ................ > 0410: 00 00 00 d3 ef c6 53 9e 66 cf 78 74 85 0e 3c 47 > ......S.f.xt.. 0420: 06 00 00 30 84 00 00 > 00 15 04 0a 61 64 6d 69 6e > ...0.......admin > 0430: 43 6f 75 6e 74 31 84 00 00 00 03 > 04 01 31 30 84 > Count1.......10. > 0440: 00 00 00 2b 04 0e 61 63 63 6f 75 6e 74 45 78 70 > ...+..accountExp > 0450: 69 72 65 73 31 84 00 > 00 00 15 04 13 39 32 > 32 33 ires1.......9223 > 0460: 33 37 32 30 33 36 38 > 35 34 37 37 35 38 30 > 37 30 3720368547758070 > 0470: 84 00 00 00 15 04 0a 6c 6f > 67 6f 6e 43 6f 75 6e .......logonCoun > 0480: 74 31 84 00 00 00 03 > 04 01 30 30 84 00 00 > 00 20 t1.......00.... > 0490: 04 0e 73 41 4d 41 63 63 6f 75 6e 74 4e 61 6d 65 > ..sAMAccountName > 04a0: 31 84 00 00 00 0a 04 08 69 64 > 6d 61 64 6d 69 6e 1.......idmadmin > 04b0: 30 84 00 00 00 21 04 > 0e 73 41 4d 41 63 63 6f 75 > 0....!..sAMAccou > 04c0: 6e 74 54 79 70 65 31 84 > 00 00 00 0b 04 09 38 30 > ntType1.......80 > 04d0: 35 33 30 36 33 36 38 > 30 84 00 00 00 32 04 > 11 75 53063680 > ....2..u > 04e0: 73 65 72 50 72 69 6e 63 69 > 70 61 6c 4e 61 6d 65 serPrincipalName > 04f0: 31 84 00 00 00 19 04 > 17 69 64 6d 61 64 6d 69 6e > 1.......idmadmin > 0500: 40 62 6f 69 6e 67 6f 71 61 2e 6c 6f 63 61 6c 30 > @boingoqa.local0 > 0510: 84 00 00 00 16 04 0b 6c 6f > 63 6b 6f 75 74 54 69 .......lockoutTi > 0520: 6d 65 31 84 00 00 00 03 > 04 01 30 30 84 00 00 > 00 me1.......00.... > 0530: 51 04 0e 6f 62 6a 65 63 74 43 61 74 65 67 > 6f 72 Q..objectCategor > 0540: 79 31 84 00 00 00 3b 04 39 > 43 4e 3d 50 65 72 73 y1....;.9CN=Pers > 0550: 6f 6e 2c 43 4e 3d 53 63 68 65 6d 61 2c 43 4e 3d > on,CN=Schema,CN= > 0560: 43 6f 6e 66 69 67 75 72 61 74 > 69 6f 6e 2c 44 43 > Configuration,DC > 0570: 3d 62 6f 69 6e 67 6f 71 61 2c 44 43 3d 6c 6f 63 > =boingoqa,DC=loc > 0580: 61 6c 30 84 00 00 00 43 04 > 15 64 53 43 6f 72 65 > al0....C..dSCore > 0590: 50 72 6f 70 61 67 61 74 69 > 6f 6e 44 61 74 61 31 > PropagationData1 > 05a0: 84 00 00 00 26 04 11 > 32 30 31 34 30 31 32 > 39 32 ....&..201401292 > 05b0: 32 34 30 32 34 2e 30 5a 04 11 > 31 36 30 31 30 31 > 24024.0Z..160101 > 05c0: 30 31 30 30 30 30 30 > 30 2e 30 5a 30 84 00 00 00 > 01000000.0Z0.... > 05d0: 2e 04 12 6c 61 73 74 4c 6f 67 6f 6e 54 69 6d 65 > ...lastLogonTime > 05e0: 73 74 61 6d 70 31 84 00 00 00 14 > 04 12 31 33 30 > stamp1.......130 > 05f0: 33 35 36 30 36 30 36 > 37 32 31 31 30 35 37 > 38 356060672110578 > > ber_get_next: tag 0x30 len 1537 contents: > read1msg: ld 0x1af3480 msgid 3 message type search-entry > ldap_get_dn_ber > ber_scanf fmt ({ml{) ber: > dn: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local > ber_scanf fmt ({xx) ber: > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: user > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > cn: IDM ADMIN > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > givenName: IDMADMIN > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > distinguishedName: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > instanceType: 4 > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > whenCreated: 20140128182537.0Z > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > whenChanged: 20140131014315.0Z > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > displayName: IDMADMIN > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > uSNCreated: 31968 > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > memberOf: CN=Domain Controllers,CN=Users,DC=boingoqa,DC=local > memberOf: CN=Account Operators,CN=Builtin,DC=boingoqa,DC=local > memberOf: CN=Enterprise Admins,CN=Users,DC=boingoqa,DC=local > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > uSNChanged: 38786 > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > name: IDM ADMIN > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > objectGUID:: jai63JfDvUuOGcURntA7hg== > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > userAccountControl: 66048 > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > badPwdCount: 0 > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > codePage: 0 > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > countryCode: 0 > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > badPasswordTime: 0 > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > lastLogoff: 0 > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > lastLogon: 0 > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > pwdLastSet: 130356008006093750 > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > primaryGroupID: 513 > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > objectSid:: AQUAAAAAAAUVAAAA0+/GU55mz3h0hQ48RwYAAA== > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > adminCount: 1 > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > accountExpires: 9223372036854775807 > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > logonCount: 0 > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > sAMAccountName: idmadmin > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > sAMAccountType: 805306368 > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > userPrincipalName: idmadmin at boingoqa.local > > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > lockoutTime: 0 > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=boingoqa,DC=local > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > dSCorePropagationData: 20140129224024.0Z > dSCorePropagationData: 16010101000000.0Z > ldap_get_attribute_ber > ber_scanf fmt ({mM}) ber: > lastLogonTimestamp: 130356060672110578 > ldap_get_attribute_ber > ldap_msgfree > ldap_result ld 0x1af3480 msgid -1 > wait4msg ld 0x1af3480 msgid -1 (infinite timeout) > wait4msg continue ld 0x1af3480 msgid -1 all 0 > ** ld 0x1af3480 Connections: > * host: qatestdc2.boingoqa.local port: 389 (default) > refcnt: 2 status: Connected > last used: Fri Jan 31 16:30:43 2014 > > > ** ld 0x1af3480 Outstanding Requests: > * msgid 3, origid 3, status InProgress > outstanding referrals 0, parent count 0 > ld 0x1af3480 request count 1 (abandoned 0) > ** ld 0x1af3480 Response Queue: > Empty > ld 0x1af3480 response count 0 > ldap_chkResponseList ld 0x1af3480 msgid -1 all 0 > ldap_chkResponseList returns ld 0x1af3480 NULL > read1msg: ld 0x1af3480 msgid -1 all 0 > ber_get_next > ldap_read: want=8, got=8 > 0000: 30 84 00 00 00 10 02 > 01 > 0....... > ldap_read: want=14, got=14 > 0000: 03 65 84 00 00 00 07 > 0a 01 00 04 00 04 00 > .e............ > ber_get_next: tag 0x30 len 16 contents: > read1msg: ld 0x1af3480 msgid 3 message type search-result > ber_scanf fmt ({eAA) ber: > read1msg: ld 0x1af3480 0 new referrals > read1msg: mark request completed, ld 0x1af3480 msgid 3 > request done: ld 0x1af3480 msgid 3 > res_errno: 0, res_error: <>, res_matched: <> > ldap_free_request (origid 3, msgid 3) > > ldap_parse_result > ber_scanf fmt ({iAA) ber: > ber_scanf fmt (}) ber: > ldap_msgfree > ldap_free_connection 1 1 > ldap_send_unbind > ber_flush2: 7 bytes to sd 3 > tls_write: want=37, written=37 > 0000: 17 03 01 00 20 a3 ef 55 d6 94 > cc f5 97 4f fe c1 .... ..U.....O.. > 0010: 09 95 0b 7a 4c 8f 6d b5 5f 9f 52 ca 5e a6 91 b6 > ...zL.m._.R.^... > 0020: 0f 9d c3 d6 b0 > ..... > ldap_write: want=7, written=7 > 0000: 30 05 02 01 04 42 00 > > 0....B. > tls_write: want=37, written=37 > 0000: 15 03 01 00 20 17 6f cd 57 > b4 79 e3 ef 4f fb 1f .... .o.W.y..O.. > 0010: 57 0b c5 c0 82 ba b4 b0 3e 7a de db 40 87 0d 32 > W.......>z.. at ..2 > 0020: 4b ce 39 be 02 > K.9.. > ldap_free_connection: actually freed > > > > > > -Todd Maugh > > On Jan 31, 2014, at 10:16 AM, "Dmitri Pal" > wrote: > >> On 01/31/2014 12:59 PM, Todd Maugh wrote: >>> please help im stuck trying to finish this winsync agreement >>> >>> [root at se-idm-01.boingo.com slapd-BOINGO-COM]$ ipa-replica-manage >>> connect --winsync --binddn "cn=idm admin, cn=Users, dc=boingoqa, >>> dc=local" --bindpw "*******" --passsync "********" >>> --cacert=/etc/openldap/cacerts/boingoqaCA.cer >>> qatestdc2.boingoqa.local -v >>> Directory Manager password: >>> >>> Added CA certificate /etc/openldap/cacerts/boingoqaCA.cer to >>> certificate database for se-idm-01.boingo.com >>> >>> ipa: INFO: AD Suffix is: DC=boingoqa,DC=local >>> The user for the Windows PassSync service is >>> uid=passsync,cn=sysaccounts,cn=etc,dc=boingo,dc=com >>> 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: -11 - >>> LDAP error: Connect error: start: 0: end: 0 >>> ipa: INFO: Agreement is ready, starting replication . . . >>> Starting replication, please wait until this has completed. >>> [se-idm-01.boingo.com ] reports: Update >>> failed! Status: [-11 - LDAP error: Connect error] >>> Failed to start replication >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> Some DS level logs might help. I am not sure I was clear. It seems that you provided the LDAP trace for the ldapsearch commands you executed above. I was talking about the DS level logs for the replica management agreement establishment and the follow up replication. >> Also may it be a firewall issue? FW resetting connection or something >> like? >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Fri Jan 31 19:16:54 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Fri, 31 Jan 2014 19:16:54 +0000 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <52EBEB74.5000100@redhat.com> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local>, <52EBE850.9070108@redhat.com> <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com>, <52EBEB74.5000100@redhat.com> Message-ID: <6FB698E172A95F49BE009B36D56F53E226A3C6@EXCHMB1-ELS.BWINC.local> RE: I am not sure I was clear. It seems that you provided the LDAP trace for the ldapsearch commands you executed above. I was talking about the DS level logs for the replica management agreement establishment and the follow up replication. here is the log tailed while I deleted teh replication agreement, restarted the dirsrv and tried to setup the replication agreement [31/Jan/2014:19:07:37 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:08:12 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:08:13 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:08:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:10:01 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:11:51 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:11:54 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:12:00 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:12:12 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:12:36 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:12 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:13 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:24 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:57 +0000] NSMMReplicationPlugin - agmt_delete: begin [31/Jan/2014:19:14:09 +0000] - slapd shutting down - signaling operation threads [31/Jan/2014:19:14:09 +0000] - slapd shutting down - waiting for 30 threads to terminate [31/Jan/2014:19:14:09 +0000] - slapd shutting down - closing down internal subsystems and plugins [31/Jan/2014:19:14:09 +0000] - Waiting for 4 database threads to stop [31/Jan/2014:19:14:09 +0000] - All database threads now stopped [31/Jan/2014:19:14:09 +0000] - slapd stopped. [31/Jan/2014:19:14:12 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=boingo,dc=com [31/Jan/2014:19:14:12 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:14:12 +0000] set_krb5_creds - Could not get initial credentials for principal [ldap/se-idm-01.boingo.com at BOINGO.COM] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) [31/Jan/2014:19:14:12 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:14:12 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success) [31/Jan/2014:19:14:12 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) [31/Jan/2014:19:14:12 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) [31/Jan/2014:19:14:12 +0000] - slapd started. Listening on All Interfaces port 389 for LDAP requests [31/Jan/2014:19:14:12 +0000] - Listening on All Interfaces port 636 for LDAPS requests [31/Jan/2014:19:14:12 +0000] - Listening on /var/run/slapd-BOINGO-COM.socket for LDAPI requests [31/Jan/2014:19:14:16 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth resumed [31/Jan/2014:19:15:18 +0000] - slapd shutting down - signaling operation threads [31/Jan/2014:19:15:18 +0000] - slapd shutting down - waiting for 30 threads to terminate [31/Jan/2014:19:15:18 +0000] - slapd shutting down - closing down internal subsystems and plugins [31/Jan/2014:19:15:18 +0000] - Waiting for 4 database threads to stop [31/Jan/2014:19:15:18 +0000] - All database threads now stopped [31/Jan/2014:19:15:18 +0000] - slapd stopped. [31/Jan/2014:19:15:23 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=boingo,dc=com [31/Jan/2014:19:15:23 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:15:23 +0000] set_krb5_creds - Could not get initial credentials for principal [ldap/se-idm-01.boingo.com at BOINGO.COM] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) [31/Jan/2014:19:15:23 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:15:23 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success) [31/Jan/2014:19:15:23 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) [31/Jan/2014:19:15:23 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) [31/Jan/2014:19:15:23 +0000] - slapd started. Listening on All Interfaces port 389 for LDAP requests [31/Jan/2014:19:15:23 +0000] - Listening on All Interfaces port 636 for LDAPS requests [31/Jan/2014:19:15:23 +0000] - Listening on /var/run/slapd-BOINGO-COM.socket for LDAPI requests [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:25 +0000] NSMMReplicationPlugin - agmt="cn=meToqatestdc2.boingoqa.local" (qatestdc2:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error -8179:Peer's Certificate issuer is not recognized.) [31/Jan/2014:19:15:25 +0000] - Entry "cn=meToqatestdc2.boingoqa.local,cn=replica,cn=dc\3Dboingo\2Cdc\3Dcom,cn=mapping tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not allowed [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:26 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth resumed [31/Jan/2014:19:15:27 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:27 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:28 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:30 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigbjorn at nixtra.com Fri Jan 31 19:29:07 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 31 Jan 2014 20:29:07 +0100 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <52EBE166.9010509@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBE166.9010509@redhat.com> Message-ID: Sure thing! I'll send them to you in private. Regards Siggi Dmitri Pal wrote: >On 01/31/2014 10:00 AM, Sigbjorn Lie wrote: >> >> >> On Fri, January 17, 2014 16:37, Rob Crittenden wrote: >>> Sigbjorn Lie wrote: >>> >>>> This worked better than expected. Thank you! :) >>>> >>>> >>>> ipa01 and ipa02 seem to be happy again, "getcert list" no longer >displays any certificates out >>>> of date, and all certificates in need of renewal within 28 days has >been renewed. The webui also >>>> started working again and things seem to be back to normal. >>>> >>>> ipa03 however is still having issues. I could not renew any >certificates on this server to begin >>>> with, but I managed to renew the certificates for the directory >servers by changing the xmlrpc >>>> url to another ipa server in /etc/ipa/default.conf and resubmitting >these requests. >>>> >>>> "getcert resubmit -i with >>>> NEED_GUIDANCE after a short while for the certificates for the PKI >service. >>>> >>>> >>>> /var/log/messages says: "certmonger: #033[?1034h28800" and "python: >>>> Updated certificate for ipaCert not available". >>>> >>>> >>>> There is a lot of information in the /var/log/pki-ca/debug, but >nothing >>>> that I can easily distinguish as an error from all the other >output. Anything in particular I >>>> should look for? >>> Ok, so this is a bug in IPA related to python readline. Garbage is >>> getting inserted and causing bad things to happen, >https://fedorahosted.org/freeipa/ticket/4064 >>> >>> >>> So the question is, are the certs available or not. >>> >>> >>> A number of the same certificates are shared amongst all the CAs. >One >>> does the renewal and stuffs the result into >cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX. The other CAs >>> refer to that location for an updated cert and will load them if >they are updated. >>> >>> Look to see if the certs are updated there. Given that you have 2 >>> working masters I'm assuming that is the case, so it may just be a >matter of fixing the python. >>> >> I could not get anywhere even after manually patching the python >script as mentioned in the ticket >> you provided. >> >> >> I ended up removing and re-adding the replica during a maintenance >window. For future reference, >> what I did was to remove the replica as per the Identity Management >Guide on docs.redhat.com. I >> then re-created the replica installation file and installed the >replica. >> >> At this point Certmonger managed to retrieve new certificates for the >expired certificates, but it >> kept segfaulting when it attempted to save the certificate to disk. I >restarted certmonger a few >> times, but certmonger just ended up segfaulting over and over. I >decided to block the ipa server >> off the network and change the date back to before the certs expired. >After the date was changed I >> restarted certmonger. Certmonger managed to save the certs >successfully this time and a "getcert >> list" now displays only certificates with an expire date of 2015 or >2016 and a status of >> MONTORING. >> >> I changed the date back to correct date and time and removed the >iptables rules. The replica now >> works just fine. >> >> Thank you for your assistance. >> > >Can you give us some core dumps from certmonger to see why it is >crashing. >We would like to fix crash bugs if we them. > > >> Regards, >> Siggi >> >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > >-- >Thank you, >Dmitri Pal > >Sr. Engineering Manager for IdM portfolio >Red Hat Inc. > > >------------------------------- >Looking to carve out IT costs? >www.redhat.com/carveoutcosts/ > > > >_______________________________________________ >Freeipa-users mailing list >Freeipa-users at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-users -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Jan 31 19:32:44 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 31 Jan 2014 14:32:44 -0500 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> Message-ID: <52EBFA5C.4070601@redhat.com> Sigbjorn Lie wrote: > > > > On Fri, January 17, 2014 16:37, Rob Crittenden wrote: >> Sigbjorn Lie wrote: >> >>> >>> This worked better than expected. Thank you! :) >>> >>> >>> ipa01 and ipa02 seem to be happy again, "getcert list" no longer displays any certificates out >>> of date, and all certificates in need of renewal within 28 days has been renewed. The webui also >>> started working again and things seem to be back to normal. >>> >>> ipa03 however is still having issues. I could not renew any certificates on this server to begin >>> with, but I managed to renew the certificates for the directory servers by changing the xmlrpc >>> url to another ipa server in /etc/ipa/default.conf and resubmitting these requests. >>> >>> "getcert resubmit -i >> NEED_GUIDANCE after a short while for the certificates for the PKI service. >>> >>> >>> /var/log/messages says: "certmonger: #033[?1034h28800" and "python: >>> Updated certificate for ipaCert not available". >>> >>> >>> There is a lot of information in the /var/log/pki-ca/debug, but nothing >>> that I can easily distinguish as an error from all the other output. Anything in particular I >>> should look for? >> >> Ok, so this is a bug in IPA related to python readline. Garbage is >> getting inserted and causing bad things to happen, https://fedorahosted.org/freeipa/ticket/4064 >> >> >> So the question is, are the certs available or not. >> >> >> A number of the same certificates are shared amongst all the CAs. One >> does the renewal and stuffs the result into cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX. The other CAs >> refer to that location for an updated cert and will load them if they are updated. >> >> Look to see if the certs are updated there. Given that you have 2 >> working masters I'm assuming that is the case, so it may just be a matter of fixing the python. >> > > I could not get anywhere even after manually patching the python script as mentioned in the ticket > you provided. > > > I ended up removing and re-adding the replica during a maintenance window. For future reference, > what I did was to remove the replica as per the Identity Management Guide on docs.redhat.com. I > then re-created the replica installation file and installed the replica. > > At this point Certmonger managed to retrieve new certificates for the expired certificates, but it > kept segfaulting when it attempted to save the certificate to disk. I restarted certmonger a few > times, but certmonger just ended up segfaulting over and over. I decided to block the ipa server > off the network and change the date back to before the certs expired. After the date was changed I > restarted certmonger. Certmonger managed to save the certs successfully this time and a "getcert > list" now displays only certificates with an expire date of 2015 or 2016 and a status of > MONTORING. > > I changed the date back to correct date and time and removed the iptables rules. The replica now > works just fine. > > Thank you for your assistance. Sounds like https://bugzilla.redhat.com/show_bug.cgi?id=1032760 rob From rmeggins at redhat.com Fri Jan 31 20:39:01 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 31 Jan 2014 13:39:01 -0700 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226A3C6@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local>, <52EBE850.9070108@redhat.com> <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com>, <52EBEB74.5000100@redhat.com> <6FB698E172A95F49BE009B36D56F53E226A3C6@EXCHMB1-ELS.BWINC.local> Message-ID: <52EC09E5.1030604@redhat.com> On 01/31/2014 12:16 PM, Todd Maugh wrote: > RE: > > I am not sure I was clear. It seems that you provided the LDAP trace > for the ldapsearch commands you executed above. I was talking about > the DS level logs for the replica management agreement establishment > and the follow up replication. > > here is the log tailed while I deleted teh replication agreement, > restarted the dirsrv and tried to setup the replication agreement Note that 389 does not use /etc/openldap/cacerts - it uses /etc/dirsrv/slapd-YOUR-DOMAIN, so try this: LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-YOUR-DOMAIN ldapsearch -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm admin,cn=users,dc=boingoqa,dc=local" -W > > > > [31/Jan/2014:19:07:37 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [31/Jan/2014:19:08:12 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [31/Jan/2014:19:08:13 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [31/Jan/2014:19:08:25 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [31/Jan/2014:19:10:01 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [31/Jan/2014:19:11:51 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [31/Jan/2014:19:11:54 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [31/Jan/2014:19:12:00 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [31/Jan/2014:19:12:12 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [31/Jan/2014:19:12:36 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [31/Jan/2014:19:13:12 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [31/Jan/2014:19:13:13 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [31/Jan/2014:19:13:24 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [31/Jan/2014:19:13:57 +0000] NSMMReplicationPlugin - agmt_delete: begin > [31/Jan/2014:19:14:09 +0000] - slapd shutting down - signaling > operation threads > [31/Jan/2014:19:14:09 +0000] - slapd shutting down - waiting for 30 > threads to terminate > [31/Jan/2014:19:14:09 +0000] - slapd shutting down - closing down > internal subsystems and plugins > [31/Jan/2014:19:14:09 +0000] - Waiting for 4 database threads to stop > [31/Jan/2014:19:14:09 +0000] - All database threads now stopped > [31/Jan/2014:19:14:09 +0000] - slapd stopped. > [31/Jan/2014:19:14:12 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 > starting up > [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no > entries set up under cn=computers, cn=compat,dc=boingo,dc=com > [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no > entries set up under cn=ng, cn=compat,dc=boingo,dc=com > [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no > entries set up under ou=sudoers,dc=boingo,dc=com > [31/Jan/2014:19:14:12 +0000] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which > should be added before the CoS Definition. > [31/Jan/2014:19:14:12 +0000] set_krb5_creds - Could not get initial > credentials for principal [ldap/se-idm-01.boingo.com at BOINGO.COM] in > keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see > e-text)) > [31/Jan/2014:19:14:12 +0000] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which > should be added before the CoS Definition. > [31/Jan/2014:19:14:12 +0000] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified > GSS failure. Minor code may provide more information (Credentials > cache file '/tmp/krb5cc_495' not found)) errno 0 (Success) > [31/Jan/2014:19:14:12 +0000] slapi_ldap_bind - Error: could not > perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) > [31/Jan/2014:19:14:12 +0000] NSMMReplicationPlugin - > agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind > with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): > generic failure: GSSAPI Error: Unspecified GSS failure. Minor code > may provide more information (Credentials cache file '/tmp/krb5cc_495' > not found)) > [31/Jan/2014:19:14:12 +0000] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [31/Jan/2014:19:14:12 +0000] - Listening on All Interfaces port 636 > for LDAPS requests > [31/Jan/2014:19:14:12 +0000] - Listening on > /var/run/slapd-BOINGO-COM.socket for LDAPI requests > [31/Jan/2014:19:14:16 +0000] NSMMReplicationPlugin - > agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind > with GSSAPI auth resumed > [31/Jan/2014:19:15:18 +0000] - slapd shutting down - signaling > operation threads > [31/Jan/2014:19:15:18 +0000] - slapd shutting down - waiting for 30 > threads to terminate > [31/Jan/2014:19:15:18 +0000] - slapd shutting down - closing down > internal subsystems and plugins > [31/Jan/2014:19:15:18 +0000] - Waiting for 4 database threads to stop > [31/Jan/2014:19:15:18 +0000] - All database threads now stopped > [31/Jan/2014:19:15:18 +0000] - slapd stopped. > [31/Jan/2014:19:15:23 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 > starting up > [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no > entries set up under cn=computers, cn=compat,dc=boingo,dc=com > [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no > entries set up under cn=ng, cn=compat,dc=boingo,dc=com > [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no > entries set up under ou=sudoers,dc=boingo,dc=com > [31/Jan/2014:19:15:23 +0000] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which > should be added before the CoS Definition. > [31/Jan/2014:19:15:23 +0000] set_krb5_creds - Could not get initial > credentials for principal [ldap/se-idm-01.boingo.com at BOINGO.COM] in > keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see > e-text)) > [31/Jan/2014:19:15:23 +0000] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which > should be added before the CoS Definition. > [31/Jan/2014:19:15:23 +0000] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified > GSS failure. Minor code may provide more information (Credentials > cache file '/tmp/krb5cc_495' not found)) errno 0 (Success) > [31/Jan/2014:19:15:23 +0000] slapi_ldap_bind - Error: could not > perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) > [31/Jan/2014:19:15:23 +0000] NSMMReplicationPlugin - > agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind > with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): > generic failure: GSSAPI Error: Unspecified GSS failure. Minor code > may provide more information (Credentials cache file '/tmp/krb5cc_495' > not found)) > [31/Jan/2014:19:15:23 +0000] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [31/Jan/2014:19:15:23 +0000] - Listening on All Interfaces port 636 > for LDAPS requests > [31/Jan/2014:19:15:23 +0000] - Listening on > /var/run/slapd-BOINGO-COM.socket for LDAPI requests > [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [31/Jan/2014:19:15:25 +0000] NSMMReplicationPlugin - > agmt="cn=meToqatestdc2.boingoqa.local" (qatestdc2:389): Replication > bind with SIMPLE auth failed: LDAP error -11 (Connect error) (TLS > error -8179:Peer's Certificate issuer is not recognized.) > [31/Jan/2014:19:15:25 +0000] - Entry > "cn=meToqatestdc2.boingoqa.local,cn=replica,cn=dc\3Dboingo\2Cdc\3Dcom,cn=mapping > tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not > allowed > [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [31/Jan/2014:19:15:26 +0000] NSMMReplicationPlugin - > agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind > with GSSAPI auth resumed > [31/Jan/2014:19:15:27 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [31/Jan/2014:19:15:27 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [31/Jan/2014:19:15:28 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > [31/Jan/2014:19:15:30 +0000] slapi_ldap_bind - Error: could not send > startTLS request: error -11 (Connect error) errno 0 (Success) > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Fri Jan 31 20:55:22 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Fri, 31 Jan 2014 20:55:22 +0000 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <52EC09E5.1030604@redhat.com> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local>, <52EBE850.9070108@redhat.com> <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com>, <52EBEB74.5000100@redhat.com> <6FB698E172A95F49BE009B36D56F53E226A3C6@EXCHMB1-ELS.BWINC.local>, <52EC09E5.1030604@redhat.com> Message-ID: <6FB698E172A95F49BE009B36D56F53E226A668@EXCHMB1-ELS.BWINC.local> [root at se-idm-01.boingo.com cacerts]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-BOINGO-COM/ ldapsearch -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm admin,cn=users,dc=boingoqa,dc=local" -W Enter LDAP Password: dn: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: IDM ADMIN givenName: IDMADMIN distinguishedName: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local instanceType: 4 whenCreated: 20140128182537.0Z whenChanged: 20140131014315.0Z displayName: IDMADMIN uSNCreated: 31968 memberOf: CN=Domain Controllers,CN=Users,DC=boingoqa,DC=local memberOf: CN=Account Operators,CN=Builtin,DC=boingoqa,DC=local memberOf: CN=Enterprise Admins,CN=Users,DC=boingoqa,DC=local uSNChanged: 38786 name: IDM ADMIN objectGUID:: jai63JfDvUuOGcURntA7hg== userAccountControl: 66048 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 lastLogon: 0 pwdLastSet: 130356008006093750 primaryGroupID: 513 objectSid:: AQUAAAAAAAUVAAAA0+/GU55mz3h0hQ48RwYAAA== adminCount: 1 accountExpires: 9223372036854775807 logonCount: 0 sAMAccountName: idmadmin sAMAccountType: 805306368 userPrincipalName: idmadmin at boingoqa.local lockoutTime: 0 objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=boingoqa,DC=local dSCorePropagationData: 20140129224024.0Z dSCorePropagationData: 16010101000000.0Z lastLogonTimestamp: 130356060672110578 ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Friday, January 31, 2014 12:39 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] cant create winsync reolication On 01/31/2014 12:16 PM, Todd Maugh wrote: RE: I am not sure I was clear. It seems that you provided the LDAP trace for the ldapsearch commands you executed above. I was talking about the DS level logs for the replica management agreement establishment and the follow up replication. here is the log tailed while I deleted teh replication agreement, restarted the dirsrv and tried to setup the replication agreement Note that 389 does not use /etc/openldap/cacerts - it uses /etc/dirsrv/slapd-YOUR-DOMAIN, so try this: LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-YOUR-DOMAIN ldapsearch -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm admin,cn=users,dc=boingoqa,dc=local" -W [31/Jan/2014:19:07:37 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:08:12 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:08:13 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:08:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:10:01 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:11:51 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:11:54 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:12:00 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:12:12 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:12:36 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:12 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:13 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:24 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:57 +0000] NSMMReplicationPlugin - agmt_delete: begin [31/Jan/2014:19:14:09 +0000] - slapd shutting down - signaling operation threads [31/Jan/2014:19:14:09 +0000] - slapd shutting down - waiting for 30 threads to terminate [31/Jan/2014:19:14:09 +0000] - slapd shutting down - closing down internal subsystems and plugins [31/Jan/2014:19:14:09 +0000] - Waiting for 4 database threads to stop [31/Jan/2014:19:14:09 +0000] - All database threads now stopped [31/Jan/2014:19:14:09 +0000] - slapd stopped. [31/Jan/2014:19:14:12 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=boingo,dc=com [31/Jan/2014:19:14:12 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:14:12 +0000] set_krb5_creds - Could not get initial credentials for principal [ldap/se-idm-01.boingo.com at BOINGO.COM] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) [31/Jan/2014:19:14:12 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:14:12 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success) [31/Jan/2014:19:14:12 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) [31/Jan/2014:19:14:12 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) [31/Jan/2014:19:14:12 +0000] - slapd started. Listening on All Interfaces port 389 for LDAP requests [31/Jan/2014:19:14:12 +0000] - Listening on All Interfaces port 636 for LDAPS requests [31/Jan/2014:19:14:12 +0000] - Listening on /var/run/slapd-BOINGO-COM.socket for LDAPI requests [31/Jan/2014:19:14:16 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth resumed [31/Jan/2014:19:15:18 +0000] - slapd shutting down - signaling operation threads [31/Jan/2014:19:15:18 +0000] - slapd shutting down - waiting for 30 threads to terminate [31/Jan/2014:19:15:18 +0000] - slapd shutting down - closing down internal subsystems and plugins [31/Jan/2014:19:15:18 +0000] - Waiting for 4 database threads to stop [31/Jan/2014:19:15:18 +0000] - All database threads now stopped [31/Jan/2014:19:15:18 +0000] - slapd stopped. [31/Jan/2014:19:15:23 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=boingo,dc=com [31/Jan/2014:19:15:23 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:15:23 +0000] set_krb5_creds - Could not get initial credentials for principal [ldap/se-idm-01.boingo.com at BOINGO.COM] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) [31/Jan/2014:19:15:23 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:15:23 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success) [31/Jan/2014:19:15:23 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) [31/Jan/2014:19:15:23 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) [31/Jan/2014:19:15:23 +0000] - slapd started. Listening on All Interfaces port 389 for LDAP requests [31/Jan/2014:19:15:23 +0000] - Listening on All Interfaces port 636 for LDAPS requests [31/Jan/2014:19:15:23 +0000] - Listening on /var/run/slapd-BOINGO-COM.socket for LDAPI requests [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:25 +0000] NSMMReplicationPlugin - agmt="cn=meToqatestdc2.boingoqa.local" (qatestdc2:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error -8179:Peer's Certificate issuer is not recognized.) [31/Jan/2014:19:15:25 +0000] - Entry "cn=meToqatestdc2.boingoqa.local,cn=replica,cn=dc\3Dboingo\2Cdc\3Dcom,cn=mapping tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not allowed [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:26 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth resumed [31/Jan/2014:19:15:27 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:27 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:28 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:30 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Jan 31 21:07:17 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 31 Jan 2014 14:07:17 -0700 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226A668@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local>, <52EBE850.9070108@redhat.com> <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com>, <52EBEB74.5000100@redhat.com> <6FB698E172A95F49BE009B36D56F53E226A3C6@EXCHMB1-ELS.BWINC.local>, <52EC09E5.1030604@redhat.com> <6FB698E172A95F49BE009B36D56F53E226A668@EXCHMB1-ELS.BWINC.local> Message-ID: <52EC1085.4020104@redhat.com> On 01/31/2014 01:55 PM, Todd Maugh wrote: > > > [root at se-idm-01.boingo.com cacerts]$ > LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-BOINGO-COM/ ldapsearch -LLLx -ZZ > -H ldap://qatestdc2.boingoqa.local -b "cn=idm > admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm > admin,cn=users,dc=boingoqa,dc=local" -W > Enter LDAP Password: > dn: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: user > cn: IDM ADMIN > givenName: IDMADMIN > distinguishedName: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local > instanceType: 4 > whenCreated: 20140128182537.0Z > whenChanged: 20140131014315.0Z > displayName: IDMADMIN > uSNCreated: 31968 > memberOf: CN=Domain Controllers,CN=Users,DC=boingoqa,DC=local > memberOf: CN=Account Operators,CN=Builtin,DC=boingoqa,DC=local > memberOf: CN=Enterprise Admins,CN=Users,DC=boingoqa,DC=local > uSNChanged: 38786 > name: IDM ADMIN > objectGUID:: jai63JfDvUuOGcURntA7hg== > userAccountControl: 66048 > badPwdCount: 0 > codePage: 0 > countryCode: 0 > badPasswordTime: 0 > lastLogoff: 0 > lastLogon: 0 > pwdLastSet: 130356008006093750 > primaryGroupID: 513 > objectSid:: AQUAAAAAAAUVAAAA0+/GU55mz3h0hQ48RwYAAA== > adminCount: 1 > accountExpires: 9223372036854775807 > logonCount: 0 > sAMAccountName: idmadmin > sAMAccountType: 805306368 > userPrincipalName: idmadmin at boingoqa.local > lockoutTime: 0 > objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=boingoqa,DC=local > dSCorePropagationData: 20140129224024.0Z > dSCorePropagationData: 16010101000000.0Z > lastLogonTimestamp: 130356060672110578 I'd like to look at the debug output, so try this: LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-BOINGO-COM/ ldapsearch -d 1 -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm admin,cn=users,dc=boingoqa,dc=local" -W 'objectclass=*' dn The 389 errors log indicates "cannot connect" which usually means some sort of SSL error. Unfortunately the logging leaves something to be desired in the way of information necessary to diagnose and fix the problem. If that doesn't help, let's take a look at your winsync agreement configuration: ldapsearch -LLLx -b "cn=config" -D "cn=directory manager" -W 'objectclass=nsdswindowsreplicationagreement' dn > > > ------------------------------------------------------------------------ > *From:* Rich Megginson [rmeggins at redhat.com] > *Sent:* Friday, January 31, 2014 12:39 PM > *To:* Todd Maugh; dpal at redhat.com > *Cc:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] cant create winsync reolication > > On 01/31/2014 12:16 PM, Todd Maugh wrote: >> RE: >> >> I am not sure I was clear. It seems that you provided the LDAP trace >> for the ldapsearch commands you executed above. I was talking about >> the DS level logs for the replica management agreement establishment >> and the follow up replication. >> >> here is the log tailed while I deleted teh replication agreement, >> restarted the dirsrv and tried to setup the replication agreement > > Note that 389 does not use /etc/openldap/cacerts - it uses > /etc/dirsrv/slapd-YOUR-DOMAIN, so try this: > > LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-YOUR-DOMAIN ldapsearch -LLLx -ZZ > -H ldap://qatestdc2.boingoqa.local -b "cn=idm > admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm > admin,cn=users,dc=boingoqa,dc=local" -W > >> >> >> >> [31/Jan/2014:19:07:37 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:08:12 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:08:13 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:08:25 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:10:01 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:11:51 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:11:54 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:12:00 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:12:12 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:12:36 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:13:12 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:13:13 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:13:24 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:13:57 +0000] NSMMReplicationPlugin - agmt_delete: begin >> [31/Jan/2014:19:14:09 +0000] - slapd shutting down - signaling >> operation threads >> [31/Jan/2014:19:14:09 +0000] - slapd shutting down - waiting for 30 >> threads to terminate >> [31/Jan/2014:19:14:09 +0000] - slapd shutting down - closing down >> internal subsystems and plugins >> [31/Jan/2014:19:14:09 +0000] - Waiting for 4 database threads to stop >> [31/Jan/2014:19:14:09 +0000] - All database threads now stopped >> [31/Jan/2014:19:14:09 +0000] - slapd stopped. >> [31/Jan/2014:19:14:12 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 >> starting up >> [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no >> entries set up under cn=computers, cn=compat,dc=boingo,dc=com >> [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no >> entries set up under cn=ng, cn=compat,dc=boingo,dc=com >> [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no >> entries set up under ou=sudoers,dc=boingo,dc=com >> [31/Jan/2014:19:14:12 +0000] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which >> should be added before the CoS Definition. >> [31/Jan/2014:19:14:12 +0000] set_krb5_creds - Could not get initial >> credentials for principal [ldap/se-idm-01.boingo.com at BOINGO.COM] in >> keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see >> e-text)) >> [31/Jan/2014:19:14:12 +0000] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which >> should be added before the CoS Definition. >> [31/Jan/2014:19:14:12 +0000] slapd_ldap_sasl_interactive_bind - >> Error: could not perform interactive bind for id [] mech [GSSAPI]: >> LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: >> Unspecified GSS failure. Minor code may provide more information >> (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success) >> [31/Jan/2014:19:14:12 +0000] slapi_ldap_bind - Error: could not >> perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) >> [31/Jan/2014:19:14:12 +0000] NSMMReplicationPlugin - >> agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind >> with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): >> generic failure: GSSAPI Error: Unspecified GSS failure. Minor code >> may provide more information (Credentials cache file >> '/tmp/krb5cc_495' not found)) >> [31/Jan/2014:19:14:12 +0000] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests >> [31/Jan/2014:19:14:12 +0000] - Listening on All Interfaces port 636 >> for LDAPS requests >> [31/Jan/2014:19:14:12 +0000] - Listening on >> /var/run/slapd-BOINGO-COM.socket for LDAPI requests >> [31/Jan/2014:19:14:16 +0000] NSMMReplicationPlugin - >> agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind >> with GSSAPI auth resumed >> [31/Jan/2014:19:15:18 +0000] - slapd shutting down - signaling >> operation threads >> [31/Jan/2014:19:15:18 +0000] - slapd shutting down - waiting for 30 >> threads to terminate >> [31/Jan/2014:19:15:18 +0000] - slapd shutting down - closing down >> internal subsystems and plugins >> [31/Jan/2014:19:15:18 +0000] - Waiting for 4 database threads to stop >> [31/Jan/2014:19:15:18 +0000] - All database threads now stopped >> [31/Jan/2014:19:15:18 +0000] - slapd stopped. >> [31/Jan/2014:19:15:23 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 >> starting up >> [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no >> entries set up under cn=computers, cn=compat,dc=boingo,dc=com >> [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no >> entries set up under cn=ng, cn=compat,dc=boingo,dc=com >> [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no >> entries set up under ou=sudoers,dc=boingo,dc=com >> [31/Jan/2014:19:15:23 +0000] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which >> should be added before the CoS Definition. >> [31/Jan/2014:19:15:23 +0000] set_krb5_creds - Could not get initial >> credentials for principal [ldap/se-idm-01.boingo.com at BOINGO.COM] in >> keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see >> e-text)) >> [31/Jan/2014:19:15:23 +0000] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which >> should be added before the CoS Definition. >> [31/Jan/2014:19:15:23 +0000] slapd_ldap_sasl_interactive_bind - >> Error: could not perform interactive bind for id [] mech [GSSAPI]: >> LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: >> Unspecified GSS failure. Minor code may provide more information >> (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success) >> [31/Jan/2014:19:15:23 +0000] slapi_ldap_bind - Error: could not >> perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) >> [31/Jan/2014:19:15:23 +0000] NSMMReplicationPlugin - >> agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind >> with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): >> generic failure: GSSAPI Error: Unspecified GSS failure. Minor code >> may provide more information (Credentials cache file >> '/tmp/krb5cc_495' not found)) >> [31/Jan/2014:19:15:23 +0000] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests >> [31/Jan/2014:19:15:23 +0000] - Listening on All Interfaces port 636 >> for LDAPS requests >> [31/Jan/2014:19:15:23 +0000] - Listening on >> /var/run/slapd-BOINGO-COM.socket for LDAPI requests >> [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:15:25 +0000] NSMMReplicationPlugin - >> agmt="cn=meToqatestdc2.boingoqa.local" (qatestdc2:389): Replication >> bind with SIMPLE auth failed: LDAP error -11 (Connect error) (TLS >> error -8179:Peer's Certificate issuer is not recognized.) >> [31/Jan/2014:19:15:25 +0000] - Entry >> "cn=meToqatestdc2.boingoqa.local,cn=replica,cn=dc\3Dboingo\2Cdc\3Dcom,cn=mapping >> tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not >> allowed >> [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:15:26 +0000] NSMMReplicationPlugin - >> agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind >> with GSSAPI auth resumed >> [31/Jan/2014:19:15:27 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:15:27 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:15:28 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:15:30 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Fri Jan 31 21:09:06 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Fri, 31 Jan 2014 21:09:06 +0000 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226A668@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local>, <52EBE850.9070108@redhat.com> <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com>, <52EBEB74.5000100@redhat.com> <6FB698E172A95F49BE009B36D56F53E226A3C6@EXCHMB1-ELS.BWINC.local>, <52EC09E5.1030604@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226A668@EXCHMB1-ELS.BWINC.local> Message-ID: <6FB698E172A95F49BE009B36D56F53E226A6D1@EXCHMB1-ELS.BWINC.local> thank you for the reply. here is the out put of the first command. I'm going to run the second now and will reply with that as well LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-BOINGO-COM/ ldapsearch -d 1 -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm admin,cn=users,dc=boingoqa,dc=local" -W 'objectclass=*' dn ldap_url_parse_ext(ldap://qatestdc2.boingoqa.local) ldap_create ldap_url_parse_ext(ldap://qatestdc2.boingoqa.local:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP qatestdc2.boingoqa.local:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.194.55.48:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x260a160 msgid 1 wait4msg ld 0x260a160 msgid 1 (infinite timeout) wait4msg continue ld 0x260a160 msgid 1 all 1 ** ld 0x260a160 Connections: * host: qatestdc2.boingoqa.local port: 389 (default) refcnt: 2 status: Connected last used: Fri Jan 31 21:07:43 2014 ** ld 0x260a160 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x260a160 request count 1 (abandoned 0) ** ld 0x260a160 Response Queue: Empty ld 0x260a160 response count 0 ldap_chkResponseList ld 0x260a160 msgid 1 all 1 ldap_chkResponseList returns ld 0x260a160 NULL ldap_int_select read1msg: ld 0x260a160 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 40 contents: read1msg: ld 0x260a160 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x260a160 0 new referrals read1msg: mark request completed, ld 0x260a160 msgid 1 request done: ld 0x260a160 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ber_scanf fmt (a) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (x) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS: certdb config: configDir='/etc/dirsrv/slapd-BOINGO-COM/' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: using moznss security dir /etc/dirsrv/slapd-BOINGO-COM/ prefix . TLS: loaded CA certificate file /etc/ipa/ca.crt. TLS: certificate [CN=QATESTDC2.boingoqa.local] is not valid - error -8179:Peer's Certificate issuer is not recognized.. TLS certificate verification: subject: CN=QATESTDC2.boingoqa.local, issuer: CN=SKYWARPCA,DC=boingoqa,DC=local, cipher: AES-128, security level: high, secret key bits: 128, total key bits: 128, cache hits: 0, cache misses: 0, cache not reusable: 0 Enter LDAP Password: ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 65 bytes to sd 3 ldap_result ld 0x260a160 msgid 2 wait4msg ld 0x260a160 msgid 2 (infinite timeout) wait4msg continue ld 0x260a160 msgid 2 all 1 ** ld 0x260a160 Connections: * host: qatestdc2.boingoqa.local port: 389 (default) refcnt: 2 status: Connected last used: Fri Jan 31 21:07:50 2014 ** ld 0x260a160 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x260a160 request count 1 (abandoned 0) ** ld 0x260a160 Response Queue: Empty ld 0x260a160 response count 0 ldap_chkResponseList ld 0x260a160 msgid 2 all 1 ldap_chkResponseList returns ld 0x260a160 NULL ldap_int_select read1msg: ld 0x260a160 msgid 2 all 1 ber_get_next ber_get_next: tag 0x30 len 16 contents: read1msg: ld 0x260a160 msgid 2 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 0x260a160 0 new referrals read1msg: mark request completed, ld 0x260a160 msgid 2 request done: ld 0x260a160 msgid 2 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_search_ext put_filter: "objectclass=*" put_filter: default put_simple_filter: "objectclass=*" ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 85 bytes to sd 3 ldap_result ld 0x260a160 msgid -1 wait4msg ld 0x260a160 msgid -1 (infinite timeout) wait4msg continue ld 0x260a160 msgid -1 all 0 ** ld 0x260a160 Connections: * host: qatestdc2.boingoqa.local port: 389 (default) refcnt: 2 status: Connected last used: Fri Jan 31 21:07:50 2014 ** ld 0x260a160 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x260a160 request count 1 (abandoned 0) ** ld 0x260a160 Response Queue: Empty ld 0x260a160 response count 0 ldap_chkResponseList ld 0x260a160 msgid -1 all 0 ldap_chkResponseList returns ld 0x260a160 NULL ldap_int_select read1msg: ld 0x260a160 msgid -1 all 0 ber_get_next ber_get_next: tag 0x30 len 59 contents: read1msg: ld 0x260a160 msgid 3 message type search-entry ldap_get_dn_ber ber_scanf fmt ({ml{) ber: dn: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local ber_scanf fmt ({xx) ber: ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x260a160 msgid -1 wait4msg ld 0x260a160 msgid -1 (infinite timeout) wait4msg continue ld 0x260a160 msgid -1 all 0 ** ld 0x260a160 Connections: * host: qatestdc2.boingoqa.local port: 389 (default) refcnt: 2 status: Connected last used: Fri Jan 31 21:07:50 2014 ** ld 0x260a160 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x260a160 request count 1 (abandoned 0) ** ld 0x260a160 Response Queue: Empty ld 0x260a160 response count 0 ldap_chkResponseList ld 0x260a160 msgid -1 all 0 ldap_chkResponseList returns ld 0x260a160 NULL read1msg: ld 0x260a160 msgid -1 all 0 ber_get_next ber_get_next: tag 0x30 len 16 contents: read1msg: ld 0x260a160 msgid 3 message type search-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x260a160 0 new referrals read1msg: mark request completed, ld 0x260a160 msgid 3 request done: ld 0x260a160 msgid 3 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 3, msgid 3) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 ldap_free_connection: actually freed -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Fri Jan 31 21:11:32 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Fri, 31 Jan 2014 21:11:32 +0000 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226A668@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local>, <52EBE850.9070108@redhat.com> <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com>, <52EBEB74.5000100@redhat.com> <6FB698E172A95F49BE009B36D56F53E226A3C6@EXCHMB1-ELS.BWINC.local>, <52EC09E5.1030604@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226A668@EXCHMB1-ELS.BWINC.local> Message-ID: <6FB698E172A95F49BE009B36D56F53E226A705@EXCHMB1-ELS.BWINC.local> For the second Command I do not have an account called directory manager, so I do not have a password ldapsearch -LLLx -b "cn=config" -D "cn=directory manager" -W 'objectclass=nsdswindowsreplicationagreement' dn Enter LDAP Password: ldap_bind: Invalid credentials (49) ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Friday, January 31, 2014 12:55 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] cant create winsync reolication [root at se-idm-01.boingo.com cacerts]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-BOINGO-COM/ ldapsearch -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm admin,cn=users,dc=boingoqa,dc=local" -W Enter LDAP Password: dn: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: IDM ADMIN givenName: IDMADMIN distinguishedName: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local instanceType: 4 whenCreated: 20140128182537.0Z whenChanged: 20140131014315.0Z displayName: IDMADMIN uSNCreated: 31968 memberOf: CN=Domain Controllers,CN=Users,DC=boingoqa,DC=local memberOf: CN=Account Operators,CN=Builtin,DC=boingoqa,DC=local memberOf: CN=Enterprise Admins,CN=Users,DC=boingoqa,DC=local uSNChanged: 38786 name: IDM ADMIN objectGUID:: jai63JfDvUuOGcURntA7hg== userAccountControl: 66048 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 lastLogon: 0 pwdLastSet: 130356008006093750 primaryGroupID: 513 objectSid:: AQUAAAAAAAUVAAAA0+/GU55mz3h0hQ48RwYAAA== adminCount: 1 accountExpires: 9223372036854775807 logonCount: 0 sAMAccountName: idmadmin sAMAccountType: 805306368 userPrincipalName: idmadmin at boingoqa.local lockoutTime: 0 objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=boingoqa,DC=local dSCorePropagationData: 20140129224024.0Z dSCorePropagationData: 16010101000000.0Z lastLogonTimestamp: 130356060672110578 ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Friday, January 31, 2014 12:39 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] cant create winsync reolication On 01/31/2014 12:16 PM, Todd Maugh wrote: RE: I am not sure I was clear. It seems that you provided the LDAP trace for the ldapsearch commands you executed above. I was talking about the DS level logs for the replica management agreement establishment and the follow up replication. here is the log tailed while I deleted teh replication agreement, restarted the dirsrv and tried to setup the replication agreement Note that 389 does not use /etc/openldap/cacerts - it uses /etc/dirsrv/slapd-YOUR-DOMAIN, so try this: LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-YOUR-DOMAIN ldapsearch -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm admin,cn=users,dc=boingoqa,dc=local" -W [31/Jan/2014:19:07:37 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:08:12 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:08:13 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:08:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:10:01 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:11:51 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:11:54 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:12:00 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:12:12 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:12:36 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:12 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:13 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:24 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:57 +0000] NSMMReplicationPlugin - agmt_delete: begin [31/Jan/2014:19:14:09 +0000] - slapd shutting down - signaling operation threads [31/Jan/2014:19:14:09 +0000] - slapd shutting down - waiting for 30 threads to terminate [31/Jan/2014:19:14:09 +0000] - slapd shutting down - closing down internal subsystems and plugins [31/Jan/2014:19:14:09 +0000] - Waiting for 4 database threads to stop [31/Jan/2014:19:14:09 +0000] - All database threads now stopped [31/Jan/2014:19:14:09 +0000] - slapd stopped. [31/Jan/2014:19:14:12 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=boingo,dc=com [31/Jan/2014:19:14:12 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:14:12 +0000] set_krb5_creds - Could not get initial credentials for principal [ldap/se-idm-01.boingo.com at BOINGO.COM] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) [31/Jan/2014:19:14:12 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:14:12 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success) [31/Jan/2014:19:14:12 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) [31/Jan/2014:19:14:12 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) [31/Jan/2014:19:14:12 +0000] - slapd started. Listening on All Interfaces port 389 for LDAP requests [31/Jan/2014:19:14:12 +0000] - Listening on All Interfaces port 636 for LDAPS requests [31/Jan/2014:19:14:12 +0000] - Listening on /var/run/slapd-BOINGO-COM.socket for LDAPI requests [31/Jan/2014:19:14:16 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth resumed [31/Jan/2014:19:15:18 +0000] - slapd shutting down - signaling operation threads [31/Jan/2014:19:15:18 +0000] - slapd shutting down - waiting for 30 threads to terminate [31/Jan/2014:19:15:18 +0000] - slapd shutting down - closing down internal subsystems and plugins [31/Jan/2014:19:15:18 +0000] - Waiting for 4 database threads to stop [31/Jan/2014:19:15:18 +0000] - All database threads now stopped [31/Jan/2014:19:15:18 +0000] - slapd stopped. [31/Jan/2014:19:15:23 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=boingo,dc=com [31/Jan/2014:19:15:23 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:15:23 +0000] set_krb5_creds - Could not get initial credentials for principal [ldap/se-idm-01.boingo.com at BOINGO.COM] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) [31/Jan/2014:19:15:23 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:15:23 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success) [31/Jan/2014:19:15:23 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) [31/Jan/2014:19:15:23 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) [31/Jan/2014:19:15:23 +0000] - slapd started. Listening on All Interfaces port 389 for LDAP requests [31/Jan/2014:19:15:23 +0000] - Listening on All Interfaces port 636 for LDAPS requests [31/Jan/2014:19:15:23 +0000] - Listening on /var/run/slapd-BOINGO-COM.socket for LDAPI requests [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:25 +0000] NSMMReplicationPlugin - agmt="cn=meToqatestdc2.boingoqa.local" (qatestdc2:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error -8179:Peer's Certificate issuer is not recognized.) [31/Jan/2014:19:15:25 +0000] - Entry "cn=meToqatestdc2.boingoqa.local,cn=replica,cn=dc\3Dboingo\2Cdc\3Dcom,cn=mapping tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not allowed [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:26 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth resumed [31/Jan/2014:19:15:27 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:27 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:28 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:30 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Fri Jan 31 21:14:05 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Fri, 31 Jan 2014 21:14:05 +0000 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226A705@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local>, <52EBE850.9070108@redhat.com> <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com>, <52EBEB74.5000100@redhat.com> <6FB698E172A95F49BE009B36D56F53E226A3C6@EXCHMB1-ELS.BWINC.local>, <52EC09E5.1030604@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226A668@EXCHMB1-ELS.BWINC.local>, <6FB698E172A95F49BE009B36D56F53E226A705@EXCHMB1-ELS.BWINC.local> Message-ID: <6FB698E172A95F49BE009B36D56F53E226A71A@EXCHMB1-ELS.BWINC.local> I used the IPA directory manager password and got no output [root at se-idm-01.boingo.com cacerts]$ ldapsearch -LLLx -b "cn=config" -D "cn=directory manager" -W 'objectclass=nsdswindowsreplicationagreement' dn Enter LDAP Password: ________________________________ From: Todd Maugh Sent: Friday, January 31, 2014 1:11 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: RE: [Freeipa-users] cant create winsync reolication For the second Command I do not have an account called directory manager, so I do not have a password ldapsearch -LLLx -b "cn=config" -D "cn=directory manager" -W 'objectclass=nsdswindowsreplicationagreement' dn Enter LDAP Password: ldap_bind: Invalid credentials (49) ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Friday, January 31, 2014 12:55 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] cant create winsync reolication [root at se-idm-01.boingo.com cacerts]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-BOINGO-COM/ ldapsearch -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm admin,cn=users,dc=boingoqa,dc=local" -W Enter LDAP Password: dn: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: IDM ADMIN givenName: IDMADMIN distinguishedName: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local instanceType: 4 whenCreated: 20140128182537.0Z whenChanged: 20140131014315.0Z displayName: IDMADMIN uSNCreated: 31968 memberOf: CN=Domain Controllers,CN=Users,DC=boingoqa,DC=local memberOf: CN=Account Operators,CN=Builtin,DC=boingoqa,DC=local memberOf: CN=Enterprise Admins,CN=Users,DC=boingoqa,DC=local uSNChanged: 38786 name: IDM ADMIN objectGUID:: jai63JfDvUuOGcURntA7hg== userAccountControl: 66048 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 lastLogon: 0 pwdLastSet: 130356008006093750 primaryGroupID: 513 objectSid:: AQUAAAAAAAUVAAAA0+/GU55mz3h0hQ48RwYAAA== adminCount: 1 accountExpires: 9223372036854775807 logonCount: 0 sAMAccountName: idmadmin sAMAccountType: 805306368 userPrincipalName: idmadmin at boingoqa.local lockoutTime: 0 objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=boingoqa,DC=local dSCorePropagationData: 20140129224024.0Z dSCorePropagationData: 16010101000000.0Z lastLogonTimestamp: 130356060672110578 ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Friday, January 31, 2014 12:39 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] cant create winsync reolication On 01/31/2014 12:16 PM, Todd Maugh wrote: RE: I am not sure I was clear. It seems that you provided the LDAP trace for the ldapsearch commands you executed above. I was talking about the DS level logs for the replica management agreement establishment and the follow up replication. here is the log tailed while I deleted teh replication agreement, restarted the dirsrv and tried to setup the replication agreement Note that 389 does not use /etc/openldap/cacerts - it uses /etc/dirsrv/slapd-YOUR-DOMAIN, so try this: LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-YOUR-DOMAIN ldapsearch -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm admin,cn=users,dc=boingoqa,dc=local" -W [31/Jan/2014:19:07:37 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:08:12 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:08:13 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:08:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:10:01 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:11:51 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:11:54 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:12:00 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:12:12 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:12:36 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:12 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:13 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:24 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:57 +0000] NSMMReplicationPlugin - agmt_delete: begin [31/Jan/2014:19:14:09 +0000] - slapd shutting down - signaling operation threads [31/Jan/2014:19:14:09 +0000] - slapd shutting down - waiting for 30 threads to terminate [31/Jan/2014:19:14:09 +0000] - slapd shutting down - closing down internal subsystems and plugins [31/Jan/2014:19:14:09 +0000] - Waiting for 4 database threads to stop [31/Jan/2014:19:14:09 +0000] - All database threads now stopped [31/Jan/2014:19:14:09 +0000] - slapd stopped. [31/Jan/2014:19:14:12 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=boingo,dc=com [31/Jan/2014:19:14:12 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:14:12 +0000] set_krb5_creds - Could not get initial credentials for principal [ldap/se-idm-01.boingo.com at BOINGO.COM] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) [31/Jan/2014:19:14:12 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:14:12 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success) [31/Jan/2014:19:14:12 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) [31/Jan/2014:19:14:12 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) [31/Jan/2014:19:14:12 +0000] - slapd started. Listening on All Interfaces port 389 for LDAP requests [31/Jan/2014:19:14:12 +0000] - Listening on All Interfaces port 636 for LDAPS requests [31/Jan/2014:19:14:12 +0000] - Listening on /var/run/slapd-BOINGO-COM.socket for LDAPI requests [31/Jan/2014:19:14:16 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth resumed [31/Jan/2014:19:15:18 +0000] - slapd shutting down - signaling operation threads [31/Jan/2014:19:15:18 +0000] - slapd shutting down - waiting for 30 threads to terminate [31/Jan/2014:19:15:18 +0000] - slapd shutting down - closing down internal subsystems and plugins [31/Jan/2014:19:15:18 +0000] - Waiting for 4 database threads to stop [31/Jan/2014:19:15:18 +0000] - All database threads now stopped [31/Jan/2014:19:15:18 +0000] - slapd stopped. [31/Jan/2014:19:15:23 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=boingo,dc=com [31/Jan/2014:19:15:23 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:15:23 +0000] set_krb5_creds - Could not get initial credentials for principal [ldap/se-idm-01.boingo.com at BOINGO.COM] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) [31/Jan/2014:19:15:23 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:15:23 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success) [31/Jan/2014:19:15:23 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) [31/Jan/2014:19:15:23 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) [31/Jan/2014:19:15:23 +0000] - slapd started. Listening on All Interfaces port 389 for LDAP requests [31/Jan/2014:19:15:23 +0000] - Listening on All Interfaces port 636 for LDAPS requests [31/Jan/2014:19:15:23 +0000] - Listening on /var/run/slapd-BOINGO-COM.socket for LDAPI requests [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:25 +0000] NSMMReplicationPlugin - agmt="cn=meToqatestdc2.boingoqa.local" (qatestdc2:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error -8179:Peer's Certificate issuer is not recognized.) [31/Jan/2014:19:15:25 +0000] - Entry "cn=meToqatestdc2.boingoqa.local,cn=replica,cn=dc\3Dboingo\2Cdc\3Dcom,cn=mapping tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not allowed [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:26 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth resumed [31/Jan/2014:19:15:27 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:27 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:28 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:30 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Jan 31 21:29:55 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 31 Jan 2014 14:29:55 -0700 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226A6D1@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local>, <52EBE850.9070108@redhat.com> <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com>, <52EBEB74.5000100@redhat.com> <6FB698E172A95F49BE009B36D56F53E226A3C6@EXCHMB1-ELS.BWINC.local>, <52EC09E5.1030604@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226A668@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226A6D1@EXCHMB1-ELS.BWINC.local> Message-ID: <52EC15D3.6060705@redhat.com> On 01/31/2014 02:09 PM, Todd Maugh wrote: > thank you for the reply. here is the out put of the first command. I'm > going to run the second now and will reply with that as well > LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-BOINGO-COM/ ldapsearch -d 1 -LLLx > -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm > admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm > admin,cn=users,dc=boingoqa,dc=local" -W 'objectclass=*' dn > ldap_url_parse_ext(ldap://qatestdc2.boingoqa.local) > ldap_create > ldap_url_parse_ext(ldap://qatestdc2.boingoqa.local:389/??base) > ldap_extended_operation_s > ldap_extended_operation > ldap_send_initial_request > ldap_new_connection 1 1 0 > ldap_int_open_connection > ldap_connect_to_host: TCP qatestdc2.boingoqa.local:389 > ldap_new_socket: 3 > ldap_prepare_socket: 3 > ldap_connect_to_host: Trying 10.194.55.48:389 > ldap_pvt_connect: fd: 3 tm: -1 async: 0 > ldap_open_defconn: successful > ldap_send_server_request > ber_scanf fmt ({it) ber: > ber_scanf fmt ({) ber: > ber_flush2: 31 bytes to sd 3 > ldap_result ld 0x260a160 msgid 1 > wait4msg ld 0x260a160 msgid 1 (infinite timeout) > wait4msg continue ld 0x260a160 msgid 1 all 1 > ** ld 0x260a160 Connections: > * host: qatestdc2.boingoqa.local port: 389 (default) > refcnt: 2 status: Connected > last used: Fri Jan 31 21:07:43 2014 > > > ** ld 0x260a160 Outstanding Requests: > * msgid 1, origid 1, status InProgress > outstanding referrals 0, parent count 0 > ld 0x260a160 request count 1 (abandoned 0) > ** ld 0x260a160 Response Queue: > Empty > ld 0x260a160 response count 0 > ldap_chkResponseList ld 0x260a160 msgid 1 all 1 > ldap_chkResponseList returns ld 0x260a160 NULL > ldap_int_select > read1msg: ld 0x260a160 msgid 1 all 1 > ber_get_next > ber_get_next: tag 0x30 len 40 contents: > read1msg: ld 0x260a160 msgid 1 message type extended-result > ber_scanf fmt ({eAA) ber: > read1msg: ld 0x260a160 0 new referrals > read1msg: mark request completed, ld 0x260a160 msgid 1 > request done: ld 0x260a160 msgid 1 > res_errno: 0, res_error: <>, res_matched: <> > ldap_free_request (origid 1, msgid 1) > ldap_parse_extended_result > ber_scanf fmt ({eAA) ber: > ber_scanf fmt (a) ber: > ldap_parse_result > ber_scanf fmt ({iAA) ber: > ber_scanf fmt (x) ber: > ber_scanf fmt (}) ber: > ldap_msgfree > TLS: certdb config: configDir='/etc/dirsrv/slapd-BOINGO-COM/' > tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly > TLS: using moznss security dir /etc/dirsrv/slapd-BOINGO-COM/ prefix . > TLS: loaded CA certificate file /etc/ipa/ca.crt. Can you provide your /etc/openldap/ldap.conf? > TLS: certificate [CN=QATESTDC2.boingoqa.local] is not valid - error > -8179:Peer's Certificate issuer is not recognized.. This is saying QATESTDC2.boingoqa.local cannot be resolved - or the IP address does not match. This is usually a problem, but perhaps you have set your ldap.conf to continue despite this problem? > TLS certificate verification: subject: CN=QATESTDC2.boingoqa.local, > issuer: CN=SKYWARPCA,DC=boingoqa,DC=local, cipher: AES-128, security > level: high, secret key bits: 128, total key bits: 128, cache hits: 0, > cache misses: 0, cache not reusable: 0 > Enter LDAP Password: > ldap_sasl_bind > ldap_send_initial_request > ldap_send_server_request > ber_scanf fmt ({it) ber: > ber_scanf fmt ({i) ber: > ber_flush2: 65 bytes to sd 3 > ldap_result ld 0x260a160 msgid 2 > wait4msg ld 0x260a160 msgid 2 (infinite timeout) > wait4msg continue ld 0x260a160 msgid 2 all 1 > ** ld 0x260a160 Connections: > * host: qatestdc2.boingoqa.local port: 389 (default) > refcnt: 2 status: Connected > last used: Fri Jan 31 21:07:50 2014 > > > ** ld 0x260a160 Outstanding Requests: > * msgid 2, origid 2, status InProgress > outstanding referrals 0, parent count 0 > ld 0x260a160 request count 1 (abandoned 0) > ** ld 0x260a160 Response Queue: > Empty > ld 0x260a160 response count 0 > ldap_chkResponseList ld 0x260a160 msgid 2 all 1 > ldap_chkResponseList returns ld 0x260a160 NULL > ldap_int_select > read1msg: ld 0x260a160 msgid 2 all 1 > ber_get_next > ber_get_next: tag 0x30 len 16 contents: > read1msg: ld 0x260a160 msgid 2 message type bind > ber_scanf fmt ({eAA) ber: > read1msg: ld 0x260a160 0 new referrals > read1msg: mark request completed, ld 0x260a160 msgid 2 > request done: ld 0x260a160 msgid 2 > res_errno: 0, res_error: <>, res_matched: <> > ldap_free_request (origid 2, msgid 2) > ldap_parse_result > ber_scanf fmt ({iAA) ber: > ber_scanf fmt (}) ber: > ldap_msgfree > ldap_search_ext > put_filter: "objectclass=*" > put_filter: default > put_simple_filter: "objectclass=*" > ldap_send_initial_request > ldap_send_server_request > ber_scanf fmt ({it) ber: > ber_scanf fmt ({) ber: > ber_flush2: 85 bytes to sd 3 > ldap_result ld 0x260a160 msgid -1 > wait4msg ld 0x260a160 msgid -1 (infinite timeout) > wait4msg continue ld 0x260a160 msgid -1 all 0 > ** ld 0x260a160 Connections: > * host: qatestdc2.boingoqa.local port: 389 (default) > refcnt: 2 status: Connected > last used: Fri Jan 31 21:07:50 2014 > > > ** ld 0x260a160 Outstanding Requests: > * msgid 3, origid 3, status InProgress > outstanding referrals 0, parent count 0 > ld 0x260a160 request count 1 (abandoned 0) > ** ld 0x260a160 Response Queue: > Empty > ld 0x260a160 response count 0 > ldap_chkResponseList ld 0x260a160 msgid -1 all 0 > ldap_chkResponseList returns ld 0x260a160 NULL > ldap_int_select > read1msg: ld 0x260a160 msgid -1 all 0 > ber_get_next > ber_get_next: tag 0x30 len 59 contents: > read1msg: ld 0x260a160 msgid 3 message type search-entry > ldap_get_dn_ber > ber_scanf fmt ({ml{) ber: > dn: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local > ber_scanf fmt ({xx) ber: > ldap_get_attribute_ber > ldap_msgfree > ldap_result ld 0x260a160 msgid -1 > wait4msg ld 0x260a160 msgid -1 (infinite timeout) > wait4msg continue ld 0x260a160 msgid -1 all 0 > ** ld 0x260a160 Connections: > * host: qatestdc2.boingoqa.local port: 389 (default) > refcnt: 2 status: Connected > last used: Fri Jan 31 21:07:50 2014 > > > ** ld 0x260a160 Outstanding Requests: > * msgid 3, origid 3, status InProgress > outstanding referrals 0, parent count 0 > ld 0x260a160 request count 1 (abandoned 0) > ** ld 0x260a160 Response Queue: > Empty > ld 0x260a160 response count 0 > ldap_chkResponseList ld 0x260a160 msgid -1 all 0 > ldap_chkResponseList returns ld 0x260a160 NULL > read1msg: ld 0x260a160 msgid -1 all 0 > ber_get_next > ber_get_next: tag 0x30 len 16 contents: > read1msg: ld 0x260a160 msgid 3 message type search-result > ber_scanf fmt ({eAA) ber: > read1msg: ld 0x260a160 0 new referrals > read1msg: mark request completed, ld 0x260a160 msgid 3 > request done: ld 0x260a160 msgid 3 > res_errno: 0, res_error: <>, res_matched: <> > ldap_free_request (origid 3, msgid 3) > > ldap_parse_result > ber_scanf fmt ({iAA) ber: > ber_scanf fmt (}) ber: > ldap_msgfree > ldap_free_connection 1 1 > ldap_send_unbind > ber_flush2: 7 bytes to sd 3 > ldap_free_connection: actually freed > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Jan 31 21:30:43 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 31 Jan 2014 14:30:43 -0700 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226A71A@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local>, <52EBE850.9070108@redhat.com> <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com>, <52EBEB74.5000100@redhat.com> <6FB698E172A95F49BE009B36D56F53E226A3C6@EXCHMB1-ELS.BWINC.local>, <52EC09E5.1030604@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226A668@EXCHMB1-ELS.BWINC.local>, <6FB698E172A95F49BE009B36D56F53E226A705@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226A71A@EXCHMB1-ELS.BWINC.local> Message-ID: <52EC1603.4060900@redhat.com> On 01/31/2014 02:14 PM, Todd Maugh wrote: > I used the IPA directory manager password and got no output > > [root at se-idm-01.boingo.com cacerts]$ ldapsearch -LLLx -b "cn=config" > -D "cn=directory manager" -W > 'objectclass=nsdswindowsreplicationagreement' dn > Enter LDAP Password: Very strange. Try this: ldapsearch -LLLx -b "cn=config" -D "cn=directory manager" -W 'objectclass=nsds5replicationagreement' > > > > ------------------------------------------------------------------------ > *From:* Todd Maugh > *Sent:* Friday, January 31, 2014 1:11 PM > *To:* Rich Megginson; dpal at redhat.com > *Cc:* freeipa-users at redhat.com > *Subject:* RE: [Freeipa-users] cant create winsync reolication > > For the second Command I do not have an account called directory > manager, so I do not have a password > > ldapsearch -LLLx -b "cn=config" -D "cn=directory manager" -W > 'objectclass=nsdswindowsreplicationagreement' dn > Enter LDAP Password: > ldap_bind: Invalid credentials (49) > > > ------------------------------------------------------------------------ > *From:* freeipa-users-bounces at redhat.com > [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh > [tmaugh at boingo.com] > *Sent:* Friday, January 31, 2014 12:55 PM > *To:* Rich Megginson; dpal at redhat.com > *Cc:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] cant create winsync reolication > > > > [root at se-idm-01.boingo.com cacerts]$ > LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-BOINGO-COM/ ldapsearch -LLLx -ZZ > -H ldap://qatestdc2.boingoqa.local -b "cn=idm > admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm > admin,cn=users,dc=boingoqa,dc=local" -W > Enter LDAP Password: > dn: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: user > cn: IDM ADMIN > givenName: IDMADMIN > distinguishedName: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local > instanceType: 4 > whenCreated: 20140128182537.0Z > whenChanged: 20140131014315.0Z > displayName: IDMADMIN > uSNCreated: 31968 > memberOf: CN=Domain Controllers,CN=Users,DC=boingoqa,DC=local > memberOf: CN=Account Operators,CN=Builtin,DC=boingoqa,DC=local > memberOf: CN=Enterprise Admins,CN=Users,DC=boingoqa,DC=local > uSNChanged: 38786 > name: IDM ADMIN > objectGUID:: jai63JfDvUuOGcURntA7hg== > userAccountControl: 66048 > badPwdCount: 0 > codePage: 0 > countryCode: 0 > badPasswordTime: 0 > lastLogoff: 0 > lastLogon: 0 > pwdLastSet: 130356008006093750 > primaryGroupID: 513 > objectSid:: AQUAAAAAAAUVAAAA0+/GU55mz3h0hQ48RwYAAA== > adminCount: 1 > accountExpires: 9223372036854775807 > logonCount: 0 > sAMAccountName: idmadmin > sAMAccountType: 805306368 > userPrincipalName: idmadmin at boingoqa.local > lockoutTime: 0 > objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=boingoqa,DC=local > dSCorePropagationData: 20140129224024.0Z > dSCorePropagationData: 16010101000000.0Z > lastLogonTimestamp: 130356060672110578 > > > ------------------------------------------------------------------------ > *From:* Rich Megginson [rmeggins at redhat.com] > *Sent:* Friday, January 31, 2014 12:39 PM > *To:* Todd Maugh; dpal at redhat.com > *Cc:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] cant create winsync reolication > > On 01/31/2014 12:16 PM, Todd Maugh wrote: >> RE: >> >> I am not sure I was clear. It seems that you provided the LDAP trace >> for the ldapsearch commands you executed above. I was talking about >> the DS level logs for the replica management agreement establishment >> and the follow up replication. >> >> here is the log tailed while I deleted teh replication agreement, >> restarted the dirsrv and tried to setup the replication agreement > > Note that 389 does not use /etc/openldap/cacerts - it uses > /etc/dirsrv/slapd-YOUR-DOMAIN, so try this: > > LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-YOUR-DOMAIN ldapsearch -LLLx -ZZ > -H ldap://qatestdc2.boingoqa.local -b "cn=idm > admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm > admin,cn=users,dc=boingoqa,dc=local" -W > >> >> >> >> [31/Jan/2014:19:07:37 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:08:12 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:08:13 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:08:25 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:10:01 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:11:51 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:11:54 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:12:00 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:12:12 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:12:36 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:13:12 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:13:13 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:13:24 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:13:57 +0000] NSMMReplicationPlugin - agmt_delete: begin >> [31/Jan/2014:19:14:09 +0000] - slapd shutting down - signaling >> operation threads >> [31/Jan/2014:19:14:09 +0000] - slapd shutting down - waiting for 30 >> threads to terminate >> [31/Jan/2014:19:14:09 +0000] - slapd shutting down - closing down >> internal subsystems and plugins >> [31/Jan/2014:19:14:09 +0000] - Waiting for 4 database threads to stop >> [31/Jan/2014:19:14:09 +0000] - All database threads now stopped >> [31/Jan/2014:19:14:09 +0000] - slapd stopped. >> [31/Jan/2014:19:14:12 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 >> starting up >> [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no >> entries set up under cn=computers, cn=compat,dc=boingo,dc=com >> [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no >> entries set up under cn=ng, cn=compat,dc=boingo,dc=com >> [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no >> entries set up under ou=sudoers,dc=boingo,dc=com >> [31/Jan/2014:19:14:12 +0000] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which >> should be added before the CoS Definition. >> [31/Jan/2014:19:14:12 +0000] set_krb5_creds - Could not get initial >> credentials for principal [ldap/se-idm-01.boingo.com at BOINGO.COM] in >> keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see >> e-text)) >> [31/Jan/2014:19:14:12 +0000] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which >> should be added before the CoS Definition. >> [31/Jan/2014:19:14:12 +0000] slapd_ldap_sasl_interactive_bind - >> Error: could not perform interactive bind for id [] mech [GSSAPI]: >> LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: >> Unspecified GSS failure. Minor code may provide more information >> (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success) >> [31/Jan/2014:19:14:12 +0000] slapi_ldap_bind - Error: could not >> perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) >> [31/Jan/2014:19:14:12 +0000] NSMMReplicationPlugin - >> agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind >> with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): >> generic failure: GSSAPI Error: Unspecified GSS failure. Minor code >> may provide more information (Credentials cache file >> '/tmp/krb5cc_495' not found)) >> [31/Jan/2014:19:14:12 +0000] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests >> [31/Jan/2014:19:14:12 +0000] - Listening on All Interfaces port 636 >> for LDAPS requests >> [31/Jan/2014:19:14:12 +0000] - Listening on >> /var/run/slapd-BOINGO-COM.socket for LDAPI requests >> [31/Jan/2014:19:14:16 +0000] NSMMReplicationPlugin - >> agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind >> with GSSAPI auth resumed >> [31/Jan/2014:19:15:18 +0000] - slapd shutting down - signaling >> operation threads >> [31/Jan/2014:19:15:18 +0000] - slapd shutting down - waiting for 30 >> threads to terminate >> [31/Jan/2014:19:15:18 +0000] - slapd shutting down - closing down >> internal subsystems and plugins >> [31/Jan/2014:19:15:18 +0000] - Waiting for 4 database threads to stop >> [31/Jan/2014:19:15:18 +0000] - All database threads now stopped >> [31/Jan/2014:19:15:18 +0000] - slapd stopped. >> [31/Jan/2014:19:15:23 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 >> starting up >> [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no >> entries set up under cn=computers, cn=compat,dc=boingo,dc=com >> [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no >> entries set up under cn=ng, cn=compat,dc=boingo,dc=com >> [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no >> entries set up under ou=sudoers,dc=boingo,dc=com >> [31/Jan/2014:19:15:23 +0000] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which >> should be added before the CoS Definition. >> [31/Jan/2014:19:15:23 +0000] set_krb5_creds - Could not get initial >> credentials for principal [ldap/se-idm-01.boingo.com at BOINGO.COM] in >> keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see >> e-text)) >> [31/Jan/2014:19:15:23 +0000] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which >> should be added before the CoS Definition. >> [31/Jan/2014:19:15:23 +0000] slapd_ldap_sasl_interactive_bind - >> Error: could not perform interactive bind for id [] mech [GSSAPI]: >> LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: >> Unspecified GSS failure. Minor code may provide more information >> (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success) >> [31/Jan/2014:19:15:23 +0000] slapi_ldap_bind - Error: could not >> perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) >> [31/Jan/2014:19:15:23 +0000] NSMMReplicationPlugin - >> agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind >> with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): >> generic failure: GSSAPI Error: Unspecified GSS failure. Minor code >> may provide more information (Credentials cache file >> '/tmp/krb5cc_495' not found)) >> [31/Jan/2014:19:15:23 +0000] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests >> [31/Jan/2014:19:15:23 +0000] - Listening on All Interfaces port 636 >> for LDAPS requests >> [31/Jan/2014:19:15:23 +0000] - Listening on >> /var/run/slapd-BOINGO-COM.socket for LDAPI requests >> [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:15:25 +0000] NSMMReplicationPlugin - >> agmt="cn=meToqatestdc2.boingoqa.local" (qatestdc2:389): Replication >> bind with SIMPLE auth failed: LDAP error -11 (Connect error) (TLS >> error -8179:Peer's Certificate issuer is not recognized.) >> [31/Jan/2014:19:15:25 +0000] - Entry >> "cn=meToqatestdc2.boingoqa.local,cn=replica,cn=dc\3Dboingo\2Cdc\3Dcom,cn=mapping >> tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not >> allowed >> [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:15:26 +0000] NSMMReplicationPlugin - >> agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind >> with GSSAPI auth resumed >> [31/Jan/2014:19:15:27 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:15:27 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:15:28 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> [31/Jan/2014:19:15:30 +0000] slapi_ldap_bind - Error: could not send >> startTLS request: error -11 (Connect error) errno 0 (Success) >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Fri Jan 31 21:32:15 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Fri, 31 Jan 2014 21:32:15 +0000 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <52EC1603.4060900@redhat.com> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local>, <52EBE850.9070108@redhat.com> <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com>, <52EBEB74.5000100@redhat.com> <6FB698E172A95F49BE009B36D56F53E226A3C6@EXCHMB1-ELS.BWINC.local>, <52EC09E5.1030604@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226A668@EXCHMB1-ELS.BWINC.local>, <6FB698E172A95F49BE009B36D56F53E226A705@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226A71A@EXCHMB1-ELS.BWINC.local>, <52EC1603.4060900@redhat.com> Message-ID: <6FB698E172A95F49BE009B36D56F53E226A800@EXCHMB1-ELS.BWINC.local> ldapsearch -LLLx -b "cn=config" -D "cn=directory manager" -W 'objectclass=nsds5replicationagreement' ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Friday, January 31, 2014 1:30 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] cant create winsync reolication On 01/31/2014 02:14 PM, Todd Maugh wrote: I used the IPA directory manager password and got no output [root at se-idm-01.boingo.com cacerts]$ ldapsearch -LLLx -b "cn=config" -D "cn=directory manager" -W 'objectclass=nsdswindowsreplicationagreement' dn Enter LDAP Password: Very strange. Try this: ldapsearch -LLLx -b "cn=config" -D "cn=directory manager" -W 'objectclass=nsds5replicationagreement' ________________________________ From: Todd Maugh Sent: Friday, January 31, 2014 1:11 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: RE: [Freeipa-users] cant create winsync reolication For the second Command I do not have an account called directory manager, so I do not have a password ldapsearch -LLLx -b "cn=config" -D "cn=directory manager" -W 'objectclass=nsdswindowsreplicationagreement' dn Enter LDAP Password: ldap_bind: Invalid credentials (49) ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Friday, January 31, 2014 12:55 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] cant create winsync reolication [root at se-idm-01.boingo.com cacerts]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-BOINGO-COM/ ldapsearch -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm admin,cn=users,dc=boingoqa,dc=local" -W Enter LDAP Password: dn: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: IDM ADMIN givenName: IDMADMIN distinguishedName: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local instanceType: 4 whenCreated: 20140128182537.0Z whenChanged: 20140131014315.0Z displayName: IDMADMIN uSNCreated: 31968 memberOf: CN=Domain Controllers,CN=Users,DC=boingoqa,DC=local memberOf: CN=Account Operators,CN=Builtin,DC=boingoqa,DC=local memberOf: CN=Enterprise Admins,CN=Users,DC=boingoqa,DC=local uSNChanged: 38786 name: IDM ADMIN objectGUID:: jai63JfDvUuOGcURntA7hg== userAccountControl: 66048 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 lastLogon: 0 pwdLastSet: 130356008006093750 primaryGroupID: 513 objectSid:: AQUAAAAAAAUVAAAA0+/GU55mz3h0hQ48RwYAAA== adminCount: 1 accountExpires: 9223372036854775807 logonCount: 0 sAMAccountName: idmadmin sAMAccountType: 805306368 userPrincipalName: idmadmin at boingoqa.local lockoutTime: 0 objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=boingoqa,DC=local dSCorePropagationData: 20140129224024.0Z dSCorePropagationData: 16010101000000.0Z lastLogonTimestamp: 130356060672110578 ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Friday, January 31, 2014 12:39 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] cant create winsync reolication On 01/31/2014 12:16 PM, Todd Maugh wrote: RE: I am not sure I was clear. It seems that you provided the LDAP trace for the ldapsearch commands you executed above. I was talking about the DS level logs for the replica management agreement establishment and the follow up replication. here is the log tailed while I deleted teh replication agreement, restarted the dirsrv and tried to setup the replication agreement Note that 389 does not use /etc/openldap/cacerts - it uses /etc/dirsrv/slapd-YOUR-DOMAIN, so try this: LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-YOUR-DOMAIN ldapsearch -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm admin,cn=users,dc=boingoqa,dc=local" -W [31/Jan/2014:19:07:37 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:08:12 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:08:13 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:08:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:10:01 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:11:51 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:11:54 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:12:00 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:12:12 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:12:36 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:12 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:13 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:24 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:13:57 +0000] NSMMReplicationPlugin - agmt_delete: begin [31/Jan/2014:19:14:09 +0000] - slapd shutting down - signaling operation threads [31/Jan/2014:19:14:09 +0000] - slapd shutting down - waiting for 30 threads to terminate [31/Jan/2014:19:14:09 +0000] - slapd shutting down - closing down internal subsystems and plugins [31/Jan/2014:19:14:09 +0000] - Waiting for 4 database threads to stop [31/Jan/2014:19:14:09 +0000] - All database threads now stopped [31/Jan/2014:19:14:09 +0000] - slapd stopped. [31/Jan/2014:19:14:12 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:14:12 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=boingo,dc=com [31/Jan/2014:19:14:12 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:14:12 +0000] set_krb5_creds - Could not get initial credentials for principal [ldap/se-idm-01.boingo.com at BOINGO.COM] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) [31/Jan/2014:19:14:12 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:14:12 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success) [31/Jan/2014:19:14:12 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) [31/Jan/2014:19:14:12 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) [31/Jan/2014:19:14:12 +0000] - slapd started. Listening on All Interfaces port 389 for LDAP requests [31/Jan/2014:19:14:12 +0000] - Listening on All Interfaces port 636 for LDAPS requests [31/Jan/2014:19:14:12 +0000] - Listening on /var/run/slapd-BOINGO-COM.socket for LDAPI requests [31/Jan/2014:19:14:16 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth resumed [31/Jan/2014:19:15:18 +0000] - slapd shutting down - signaling operation threads [31/Jan/2014:19:15:18 +0000] - slapd shutting down - waiting for 30 threads to terminate [31/Jan/2014:19:15:18 +0000] - slapd shutting down - closing down internal subsystems and plugins [31/Jan/2014:19:15:18 +0000] - Waiting for 4 database threads to stop [31/Jan/2014:19:15:18 +0000] - All database threads now stopped [31/Jan/2014:19:15:18 +0000] - slapd stopped. [31/Jan/2014:19:15:23 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=boingo,dc=com [31/Jan/2014:19:15:23 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=boingo,dc=com [31/Jan/2014:19:15:23 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:15:23 +0000] set_krb5_creds - Could not get initial credentials for principal [ldap/se-idm-01.boingo.com at BOINGO.COM] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) [31/Jan/2014:19:15:23 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition. [31/Jan/2014:19:15:23 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success) [31/Jan/2014:19:15:23 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) [31/Jan/2014:19:15:23 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) [31/Jan/2014:19:15:23 +0000] - slapd started. Listening on All Interfaces port 389 for LDAP requests [31/Jan/2014:19:15:23 +0000] - Listening on All Interfaces port 636 for LDAPS requests [31/Jan/2014:19:15:23 +0000] - Listening on /var/run/slapd-BOINGO-COM.socket for LDAPI requests [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:25 +0000] NSMMReplicationPlugin - agmt="cn=meToqatestdc2.boingoqa.local" (qatestdc2:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error -8179:Peer's Certificate issuer is not recognized.) [31/Jan/2014:19:15:25 +0000] - Entry "cn=meToqatestdc2.boingoqa.local,cn=replica,cn=dc\3Dboingo\2Cdc\3Dcom,cn=mapping tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not allowed [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:26 +0000] NSMMReplicationPlugin - agmt="cn=meTose-idm-02.boingo.com" (se-idm-02:389): Replication bind with GSSAPI auth resumed [31/Jan/2014:19:15:27 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:27 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:28 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [31/Jan/2014:19:15:30 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Fri Jan 31 21:34:14 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Fri, 31 Jan 2014 21:34:14 +0000 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226A800@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local>, <52EBE850.9070108@redhat.com> <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com>, <52EBEB74.5000100@redhat.com> <6FB698E172A95F49BE009B36D56F53E226A3C6@EXCHMB1-ELS.BWINC.local>, <52EC09E5.1030604@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226A668@EXCHMB1-ELS.BWINC.local>, <6FB698E172A95F49BE009B36D56F53E226A705@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226A71A@EXCHMB1-ELS.BWINC.local>, <52EC1603.4060900@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226A800@EXCHMB1-ELS.BWINC.local> Message-ID: <6FB698E172A95F49BE009B36D56F53E226A831@EXCHMB1-ELS.BWINC.local> Ok that time i got output [root at se-idm-01.boingo.com slapd-BOINGO-COM]$ ldapsearch -LLLx -b "cn=config" -D "cn=directory manager" -W 'objectclass=nsds5replicationagreement' Enter LDAP Password: dn: cn=meTose-idm-02.boingo.com,cn=replica,cn=dc\3Dboingo\2Cdc\3Dcom,cn=mappin g tree,cn=config cn: meTose-idm-02.boingo.com objectClass: nsds5replicationagreement objectClass: top nsDS5ReplicaTransportInfo: LDAP description: me to se-idm-02.boingo.com nsDS5ReplicaRoot: dc=boingo,dc=com nsDS5ReplicaHost: se-idm-02.boingo.com nsds5replicaTimeout: 120 nsDS5ReplicaPort: 389 nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount nsDS5ReplicaBindMethod: SASL/GSSAPI nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts uccessfulauth krblastfailedauth krbloginfailedcount nsds50ruv: {replicageneration} 52e15369000000040000 nsds50ruv: {replica 3 ldap://se-idm-02.boingo.com:389} 52e15372000100030000 52 ebf423000000030000 nsds50ruv: {replica 4 ldap://se-idm-01.boingo.com:389} 52e153d5000200040000 52 ebf628000000040000 nsruvReplicaLastModified: {replica 3 ldap://se-idm-02.boingo.com:389} 00000000 nsruvReplicaLastModified: {replica 4 ldap://se-idm-01.boingo.com:389} 00000000 nsds5replicareapactive: 0 nsds5replicaLastUpdateStart: 20140131210414Z nsds5replicaLastUpdateEnd: 20140131210414Z nsds5replicaChangesSentSinceStartup:: NDozLzAg nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental upd ate succeeded nsds5replicaUpdateInProgress: FALSE nsds5replicaLastInitStart: 0 nsds5replicaLastInitEnd: 0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Jan 31 22:09:30 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 31 Jan 2014 15:09:30 -0700 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226A831@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local>, <52EBE850.9070108@redhat.com> <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com>, <52EBEB74.5000100@redhat.com> <6FB698E172A95F49BE009B36D56F53E226A3C6@EXCHMB1-ELS.BWINC.local>, <52EC09E5.1030604@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226A668@EXCHMB1-ELS.BWINC.local>, <6FB698E172A95F49BE009B36D56F53E226A705@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226A71A@EXCHMB1-ELS.BWINC.local>, <52EC1603.4060900@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226A800@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226A831@EXCHMB1-ELS.BWINC.local> Message-ID: <52EC1F1A.3060603@redhat.com> On 01/31/2014 02:34 PM, Todd Maugh wrote: > Ok that time i got output Something is not right. There is no windows sync agreement. Did you see my earlier reply, about the previous ldapsearch -d 1 output, asking if the hostname in the certificate in AD was the same as the actual AD hostname? And forward and reverse DNS is working? > > [root at se-idm-01.boingo.com slapd-BOINGO-COM]$ ldapsearch -LLLx -b > "cn=config" -D "cn=directory manager" -W > 'objectclass=nsds5replicationagreement' > Enter LDAP Password: > dn: > cn=meTose-idm-02.boingo.com,cn=replica,cn=dc\3Dboingo\2Cdc\3Dcom,cn=mappin > g tree,cn=config > cn: meTose-idm-02.boingo.com > objectClass: nsds5replicationagreement > objectClass: top > nsDS5ReplicaTransportInfo: LDAP > description: me to se-idm-02.boingo.com > nsDS5ReplicaRoot: dc=boingo,dc=com > nsDS5ReplicaHost: se-idm-02.boingo.com > nsds5replicaTimeout: 120 > nsDS5ReplicaPort: 389 > nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof > idnssoaserial > entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount > nsDS5ReplicaBindMethod: SASL/GSSAPI > nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn > krblasts > uccessfulauth krblastfailedauth krbloginfailedcount > nsds50ruv: {replicageneration} 52e15369000000040000 > nsds50ruv: {replica 3 ldap://se-idm-02.boingo.com:389} > 52e15372000100030000 52 > ebf423000000030000 > nsds50ruv: {replica 4 ldap://se-idm-01.boingo.com:389} > 52e153d5000200040000 52 > ebf628000000040000 > nsruvReplicaLastModified: {replica 3 ldap://se-idm-02.boingo.com:389} > 00000000 > nsruvReplicaLastModified: {replica 4 ldap://se-idm-01.boingo.com:389} > 00000000 > nsds5replicareapactive: 0 > nsds5replicaLastUpdateStart: 20140131210414Z > nsds5replicaLastUpdateEnd: 20140131210414Z > nsds5replicaChangesSentSinceStartup:: NDozLzAg > nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: > Incremental upd > ate succeeded > nsds5replicaUpdateInProgress: FALSE > nsds5replicaLastInitStart: 0 > nsds5replicaLastInitEnd: 0 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at altosresearch.com Fri Jan 31 22:10:25 2014 From: steve at altosresearch.com (Steve Severance) Date: Fri, 31 Jan 2014 14:10:25 -0800 Subject: [Freeipa-users] Deploying freeipa behind nginx In-Reply-To: <52E8F1A0.1070702@redhat.com> References: <52E8F1A0.1070702@redhat.com> Message-ID: Hi Dmitri, I am using Free Ipa 3.1.5 on Fedora 18. The design basically looks like the following. All of this is hosted at AWS in our VPC. The nginx box is on a web addressable subnet while the FreeIPA box is on a private subnet that is not internet accessible. My goal is to be able to use the web UI from our office without having to invest in a hardware VPN connection. So nginx basically just acts as a reverse proxy and created the connection on the users behalf to the ipa server. I can login into other machines I have both in our private data center and in AWS using ipa and that works great as far as I can tell. Any more information I can supply? Thanks. Steve On Wed, Jan 29, 2014 at 4:18 AM, Dmitri Pal wrote: > On 01/28/2014 05:29 PM, Steve Severance wrote: > > Hi Everyone, > > I have deployed freeipa inside our production network. I want to be able > to access the web ui so I am attempting to add it to our nginx edge > machine. I can pass the requests upstream just fine but I am unable to > login using a username/password. I have enabled password authentication in > the kerberos section of the freeipa httpd config file. In the logs it looks > like the authentication succeeds and a ticket is issued. I assume that the > cookie that is returned (ipa_session) has the authentication information in > it. The subsequent call to get json data fails and I am prompted to login > again. > > I found this thread ( > https://www.redhat.com/archives/freeipa-users/2013-August/msg00080.html) > which has instructions on adding ipa.mydomain.com to the keytab. When I > call ipa-getkeytab it hangs for a bit before returning: ldap_sasl_bind(SIMPLE): > Can't contact LDAP server (-1) > > Digging into this if I run: ldapsearch -d 1 -v -H ldaps:// > ldap.mydomain.com > > I get: > ldap_sasl_interactive_bind_s: Unknown authentication method (-6) > additional info: SASL(-4): no mechanism available: > > So we seem to have a SASL problem. If I run ldapsearch with -x simple > authentication works just fine. > > Do I need to do something special to enable SASL so I can get the > keytab? The ipa-getkeytab command does not seem to have an option to use > simple authentication. > > Thanks. > > Steve > > > > To be able to help a small diagram would be really helpful. > The error above indicates that there is an entity that tries to connect to > the LDAP using Kerberos GSSAPI and can't because it either does not have > kerberos identity or keys or it is misconfigured and can't get to them. The > diagram of request flow would help to troubleshoot the issue. > > What version of FreeIPA you are using? What platform? > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Fri Jan 31 23:13:37 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Fri, 31 Jan 2014 23:13:37 +0000 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <52EC15D3.6060705@redhat.com> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local>, <52EBE850.9070108@redhat.com> <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com>, <52EBEB74.5000100@redhat.com> <6FB698E172A95F49BE009B36D56F53E226A3C6@EXCHMB1-ELS.BWINC.local>, <52EC09E5.1030604@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226A668@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226A6D1@EXCHMB1-ELS.BWINC.local>, <52EC15D3.6060705@redhat.com> Message-ID: <6FB698E172A95F49BE009B36D56F53E226AACD@EXCHMB1-ELS.BWINC.local> asked: Can you provide your /etc/openldap/ldap.conf? answer: /etc/openldap/ldap.con #File modified by ipa-client-install URI ldaps://se-idm-01.boingo.com BASE dc=boingo,dc=com TLS_CACERT /etc/ipa/ca.crt TLS_CACERTDIR /etc/openldap/cacerts/ TLS_REQCERT allow ping TLS: certificate [CN=QATESTDC2.boingoqa.local] is not valid - error -8179:Peer's Certificate issuer is not recognized.. This is saying QATESTDC2.boingoqa.local cannot be resolved - or the IP address does not match. This is usually a problem, but perhaps you have set your ldap.conf to continue despite this problem? PING qatestdc2.boingoqa.local (10.194.55.48) 56(84) bytes of data. 64 bytes from qatestdc2.boingoqa.local (10.194.55.48): icmp_seq=1 ttl=124 time=0.559 ms 64 bytes from qatestdc2.boingoqa.local (10.194.55.48): icmp_seq=2 ttl=124 time=0.660 ms ^C --- qatestdc2.boingoqa.local ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1070ms rtt min/avg/max/mdev = 0.559/0.609/0.660/0.056 ms TLS certificate verification: subject: CN=QATESTDC2.boingoqa.local, issuer: CN=SKYWARPCA,DC=boingoqa,DC=local, cipher: AES-128, security level: high, secret key bits: 128, total key bits: 128, cache hits: 0, cache misses: 0, cache not reusable: 0 Enter LDAP Password: ldap_sasl_bind ldap_send_initial_request -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Jan 31 23:58:16 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 31 Jan 2014 16:58:16 -0700 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226AACD@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local>, <52EBE850.9070108@redhat.com> <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com>, <52EBEB74.5000100@redhat.com> <6FB698E172A95F49BE009B36D56F53E226A3C6@EXCHMB1-ELS.BWINC.local>, <52EC09E5.1030604@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226A668@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226A6D1@EXCHMB1-ELS.BWINC.local>, <52EC15D3.6060705@redhat.com> <6FB698E172A95F49BE009B36D56F53E226AACD@EXCHMB1-ELS.BWINC.local> Message-ID: <52EC3898.8020503@redhat.com> On 01/31/2014 04:13 PM, Todd Maugh wrote: > > asked: Can you provide your /etc/openldap/ldap.conf? > > > answer: > > /etc/openldap/ldap.con > #File modified by ipa-client-install > > URI ldaps://se-idm-01.boingo.com > BASE dc=boingo,dc=com > TLS_CACERT /etc/ipa/ca.crt > TLS_CACERTDIR /etc/openldap/cacerts/ > TLS_REQCERT allow This will allow errors where the hostname in the cert subject DN does not match the IP address or vice versa. What happens if you set it to TLS_REQCERT demand? Or, if you don't want to touch this file (because it will probably break other things), try this: LDAPTLS_REQCERT=demand LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-BOINGO-COM/ ldapsearch -d 1 -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm admin,cn=users,dc=boingoqa,dc=local" -W 'objectclass=*' dn If that works, then please provide the output of rpm -q 389-ds-base openldap nss > ping > >> TLS: certificate [CN=QATESTDC2.boingoqa.local] is not valid - error >> -8179:Peer's Certificate issuer is not recognized.. > > This is saying QATESTDC2.boingoqa.local cannot be resolved - or the IP > address does not match. > > This is usually a problem, but perhaps you have set your ldap.conf to > continue despite this problem? > PING qatestdc2.boingoqa.local (10.194.55.48) 56(84) bytes of data. > 64 bytes from qatestdc2.boingoqa.local (10.194.55.48): icmp_seq=1 > ttl=124 time=0.559 ms > 64 bytes from qatestdc2.boingoqa.local (10.194.55.48): icmp_seq=2 > ttl=124 time=0.660 ms > ^C > --- qatestdc2.boingoqa.local ping statistics --- > 2 packets transmitted, 2 received, 0% packet loss, time 1070ms > rtt min/avg/max/mdev = 0.559/0.609/0.660/0.056 ms Ok. Does 10.194.55.48 resolve to qatestdc2.boingoqa.local? > > > > >> TLS certificate verification: subject: CN=QATESTDC2.boingoqa.local, >> issuer: CN=SKYWARPCA,DC=boingoqa,DC=local, cipher: AES-128, security >> level: high, secret key bits: 128, total key bits: 128, cache hits: >> 0, cache misses: 0, cache not reusable: 0 >> Enter LDAP Password: >> ldap_sasl_bind >> ldap_send_initial_request > -------------- next part -------------- An HTML attachment was scrubbed... URL: