Re: [Freeipa-users] Auto discover of the IPA server failing with LDAP anonymous binds off
On 04/06/2013 07:38 PM, Sigbjorn Lie wrote:
Hi,
I am trying to install the IPA client on a CentOS 6.4 host, however the auto
discovery of the IPA server is failing, from what seem to be caused by my IPA
servers having anonymous binds switched off.
Is this expected behaviour?
# rpm -qa|grep ^ipa|sort
ipa-client-3.0.0-26.el6_4.2.x86_64
ipa-python-3.0.0-26.el6_4.2.x86_64
# ipa-client-install -U --domain=unix.nuexample.com --password='somepassword'
--enable-dns-updates -d
/usr/sbin/ipa-client-install was invoked with options: {'domain':
'unix.nuexample.com', 'force': False, 'krb5_offline_passwords': True,
'primary': False, 'mkhomedir': False, 'create_sshfp': True, 'conf_sshd': True,
'on_master': False, 'conf_ntp': True, 'ca_cert_file': None, 'ntp_server':
None,
'principal': None, 'hostname': None, 'no_ac': False, 'unattended': True,
'sssd': True, 'trust_sshfp': False, 'dns_updates': True, 'realm_name': None,
'conf_ssh': True, 'server': None, 'prompt_password': False, 'permit': False,
'debug': True, 'preserve_sssd': False, 'uninstall': False}
missing options might be asked for interactively later
Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index'
Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
[IPA Discovery]
Starting IPA discovery with domain=unix.nuexample.com, servers=None,
hostname=clienthost.unix.nuexample.com
Search for LDAP SRV record in unix.nuexample.com
Search DNS for SRV record of _ldap._tcp.unix.nuexample.com.
DNS record found:
DNSResult::name:_ldap._tcp.unix.nuexample.com.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:ipa01.unix.nuexample.com.}
DNS record found:
DNSResult::name:_ldap._tcp.unix.nuexample.com.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:ipa02.unix.nuexample.com.}
DNS record found:
DNSResult::name:_ldap._tcp.unix.nuexample.com.,type:33,class:1,rdata={priority:5,port:389,weight:100,server:ipa03.unix.nuexample.com.}
[Kerberos realm search]
Search DNS for TXT record of _kerberos.unix.nuexample.com.
DNS record found:
DNSResult::name:_kerberos.unix.nuexample.com.,type:16,class:1,rdata={data:UNIX.NUEXAMPLE.COM}
Search DNS for SRV record of _kerberos._udp.unix.nuexample.com.
DNS record found:
DNSResult::name:_kerberos._udp.unix.nuexample.com.,type:33,class:1,rdata={priority:0,port:88,weight:100,server:ipa02.unix.nuexample.com.}
DNS record found:
DNSResult::name:_kerberos._udp.unix.nuexample.com.,type:33,class:1,rdata={priority:5,port:88,weight:100,server:ipa03.unix.nuexample.com.}
DNS record found:
DNSResult::name:_kerberos._udp.unix.nuexample.com.,type:33,class:1,rdata={priority:0,port:88,weight:100,server:ipa01.unix.nuexample.com.}
[LDAP server check]
Verifying that ipa01.unix.nuexample.com (realm UNIX.NUEXAMPLE.COM) is an IPA
server
Init LDAP connection with: ldap://ipa01.unix.nuexample.com:389
Search LDAP server for IPA base DN
Check if naming context 'dc=unix,dc=nuexample,dc=com' is for IPA
Naming context 'dc=unix,dc=nuexample,dc=com' is a valid IPA context
Search for (objectClass=krbRealmContainer) in dc=unix,dc=nuexample,dc=com
(sub)
LDAP Error: Anonymous access not allowed
Discovery result: NO_ACCESS_TO_LDAP; server=None, domain=unix.nuexample.com,
kdc=ipa02.unix.nuexample.com,ipa03.unix.nuexample.com,ipa01.unix.nuexample.com,
basedn=dc=unix,dc=nuexample,dc=com
Validated servers: ipa01.unix.nuexample.com
will use discovered domain: unix.nuexample.com
IPA Server not found
Unable to find IPA Server to join
Installation failed. Rolling back changes.
IPA client is not configured on this system.
Regards,
Siggi
Hello Sigbjorn,
This is caused by an unfortunate regression in RHEL-6.4 client which emerges
when cn=config's nsslapd-allow-anonymous-access is set to rootdse. This was
already fixed upstream (ticket 3519) and there is a bugzilla filed for RHEL-6.5:
https://bugzilla.redhat.com/show_bug.cgi?id=922843
If this is not satisfactory, you can contact your customer service and we will
look for alternative solutions for you.
Thanks,
Martin
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Slow ipa performance -- why so many ldap lookups ?
On Fri, Apr 05, 2013 at 02:00:58PM +0200, Jan-Frode Myklebust wrote: On Fri, Mar 22, 2013 at 06:43:07PM +0100, Jan-Frode Myklebust wrote: Does the problem go away if you set: selinux_provider = none Sorry, no. Also the No SELinux user maps found! didn't go away. At Apr 5 13:46:22 I was denied access again by pam_access, and then seconds later I could log in: Apr 5 13:46:22 ipa2 sshd[15417]: pam_access(sshd:account): access denied for user `janfrode' from `login2.example.com' Apr 5 13:46:29 ipa2 sshd[15423]: pam_unix(sshd:session): session opened for user janfrode by (uid=0) Apr 5 13:46:33 ipa2 su: pam_unix(su-l:session): session opened for user root by janfrode(uid=15019) debug=6 logs attached. Any other suggestions? I tried a similar case locally and everything worked for me. In the domain log I saw: [sssd[be[idm.lab.bos.redhat.com]]] [be_pam_handler_callback] (0x0400): SELinux provider doesn't exist, not sending the request to it when I set selinux_provider=none. What exact SSSD version is this? Can you paste the domain section of the sssd.conf? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Slow ipa performance -- why so many ldap lookups ?
On Mon, Apr 08, 2013 at 12:26:43PM +0200, Jakub Hrozek wrote: I tried a similar case locally and everything worked for me. In the domain log I saw: [sssd[be[idm.lab.bos.redhat.com]]] [be_pam_handler_callback] (0x0400): SELinux provider doesn't exist, not sending the request to it when I set selinux_provider=none. What exact SSSD version is this? sssd-1.8.0-32.el6.x86_64 Can you paste the domain section of the sssd.conf? [domain/example.net] cache_credentials = True krb5_store_password_if_offline = True krb5_realm = EXAMPLE.NET ipa_domain = example.net id_provider = ipa auth_provider = ipa access_provider = ipa chpass_provider = ipa #ipa_server = ipa1.example.net ipa_server = _srv_, ipa1.example.net #ipa_server = ipa2.example.net, ipa1.example.net ldap_tls_cacert = /etc/ipa/ca.crt enumerate = false selinux_provider = none debug_level = 6 I know fixed the schema problem we had in 60ipaconfig.ldif. We were missing ipaSELinuxUserMapDefault and ipaSELinuxUserMapOrder in the ipaGuiConfig object class. But after fixing this I still see No SELinux user maps found! messages..: (Mon Apr 8 12:23:08 2013) [sssd[be[example.net]]] [dp_copy_options] (0x0400): Option ipa_selinux_search_base has value cn=selinux,dc=example,dc=net (Mon Apr 8 12:23:08 2013) [sssd[be[example.net]]] [dp_copy_options] (0x0400): Option ipa_selinux_search_base has value cn=selinux,dc=example,dc=net (Mon Apr 8 12:23:27 2013) [sssd[be[example.net]]] [ipa_get_selinux_send] (0x0400): Retrieving SELinux user mapping (Mon Apr 8 12:23:27 2013) [sssd[be[example.net]]] [ipa_selinux_get_maps_next] (0x0400): Trying to fetch SELinux maps with following parameters: [2][(null)][cn=selinux,dc=example,dc=net] (Mon Apr 8 12:23:27 2013) [sssd[be[example.net]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [((objectclass=ipaselinuxusermap)(ipaEnabledFlag=TRUE))][cn=selinux,dc=example,dc=net]. (Mon Apr 8 12:23:27 2013) [sssd[be[example.net]]] [ipa_selinux_get_maps_done] (0x0400): No SELinux user maps found! Should this be the full cn=selinux,dc=example,dc=net ? --- dn: cn=selinux,dc=example,dc=net objectClass: top objectClass: nsContainer cn: selinux dn: cn=usermap,cn=selinux,dc=example,dc=net objectClass: top objectClass: nsContainer cn: usermap --- -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Slow ipa performance -- why so many ldap lookups ?
On Mon, Apr 08, 2013 at 12:40:53PM +0200, Jan-Frode Myklebust wrote: On Mon, Apr 08, 2013 at 12:26:43PM +0200, Jakub Hrozek wrote: I tried a similar case locally and everything worked for me. In the domain log I saw: [sssd[be[idm.lab.bos.redhat.com]]] [be_pam_handler_callback] (0x0400): SELinux provider doesn't exist, not sending the request to it when I set selinux_provider=none. What exact SSSD version is this? sssd-1.8.0-32.el6.x86_64 Gotcha. For some reason I suspected that you were running 6.4. The selinux handling was completely broken in 6.3, it simply doesn't work. I haven't tried setting selinux_provider = none with the 6.3 packages, but I wouldn't be surprised if that was broken as well. Please upgrade (at least the SSSD if not the whole system) to 6.4, the issue is fixed there. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] EXTERNAL: Re: ipa-replica-install errors
Hey, So on the IPA server under the access logs I am getting the following error. Error: could not send startTLS request: Error -11 (connect error) errno 0 (success) Any ideas? Matt From: Nathan Kinder [mailto:nkin...@redhat.com] Sent: Thursday, April 04, 2013 6:00 PM To: Joseph, Matthew (EXP) Cc: freeipa-users@redhat.com Subject: EXTERNAL: Re: [Freeipa-users] ipa-replica-install errors On 04/04/2013 07:14 AM, Joseph, Matthew (EXP) wrote: Hello, I'm trying to setup a replica server with ipa-2.2.0-16 on both the Server and the Replica Server. Here are the steps I ran (From the Red Hat 6.3 IdM Administration Guide); IPA_Server: ipa-replica-prepare ipareplica.example.com --ip-address 192.168.1.2 scp /var/lib/ipa/replica-info-ipareplica.example.com.gpg root@ ipareplica:/var/lib/ipa/ IPA_Replica: ipa-replica-install --setup-ca --setup-dns /var/lib/ipa/replica-info-ipareplica.exam ple.com.gpg -- Below is the error I am getting when running ipa-replica-install; Directory Manager (existing master) password: Run connection check to master Check connection from replica to remote master 'IPA_Server.domain.ca': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK PKI-CA: Directory Service port (7389): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master ad...@domain.camailto:ad...@domain.ca password: Execute check on remote master Check connection from master to remote replica 'IPA_Replica.domain.ca': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK PKI-CA: Directory Service port (7389): OK Connection from master to replica is OK. Connection check OK Configuring ntpd [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd done configuring ntpd. Configuring directory server for the CA: Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server done configuring pkids. Configuring certificate server: Estimated time 3 minutes 30 seconds [1/13]: creating certificate server user [2/13]: creating pki-ca instance [3/13]: configuring certificate server instance [4/13]: disabling nonces [5/13]: creating RA agent certificate database [6/13]: importing CA chain to RA certificate database [7/13]: fixing RA database permissions [8/13]: setting up signing cert profile [9/13]: set up CRL publishing [10/13]: set certificate subject base [11/13]: enabling Subject Key Identifier [12/13]: configuring certificate server to start on boot [13/13]: Configure HTTP to proxy connections done configuring pki-cad. Restarting the directory and certificate servers Configuring directory server: Estimated time 1 minute [1/30]: creating directory server user [2/30]: creating directory server instance [3/30]: adding default schema [4/30]: enabling memberof plugin [5/30]: enabling referential integrity plugin [6/30]: enabling winsync plugin [7/30]: configuring replication version plugin [8/30]: enabling IPA enrollment plugin [9/30]: enabling ldapi [10/30]: configuring uniqueness plugin [11/30]: configuring uuid plugin [12/30]: configuring modrdn plugin [13/30]: enabling entryUSN plugin [14/30]: configuring lockout plugin [15/30]: creating indices [16/30]: configuring ssl for ds instance [17/30]: configuring certmap.conf [18/30]: configure autobind for root [19/30]: configure new location for managed entries [20/30]: restarting directory server [21/30]: setting up initial replication Starting replication, please wait until this has completed. [IPA_Server.domain.ca] reports: Update failed! Status: [-11 - System error] creation of replica failed: Failed to start replication Also in the error log(/var/log/dirsrv/slapd-DOMAIN-CA/errors) is the following error; NSMMReplicationPlugin - agmt=cn=metoIPA_Server.domain.ca (ipa_server:389): Replica has a different generation ID than the local data. This is probably just fallout from the replica initialization failure. If a replica is never initialized, it will get a generation ID mismatch error when the master contacts it. Any thoughts or ideas on this issue? Searching google I don't see anyone getting the Status:-11 - System Error. There was
Re: [Freeipa-users] EXTERNAL: Re: ipa-replica-install errors
Hey, Yup, the client side says the following; Op=-1 fd=64 closed - Peer does not recognize and trust the CA that issued your certificate. Matt From: Nathan Kinder [mailto:nkin...@redhat.com] Sent: Monday, April 08, 2013 12:28 PM To: Joseph, Matthew (EXP) Cc: freeipa-users@redhat.com Subject: Re: EXTERNAL: Re: [Freeipa-users] ipa-replica-install errors On 04/08/2013 07:16 AM, Joseph, Matthew (EXP) wrote: Hey, So on the IPA server under the access logs I am getting the following error. Error: could not send startTLS request: Error -11 (connect error) errno 0 (success) Any ideas? Does the access log on the receiving side show a connection attempt from the master at the same time? The access log will be located at /var/log/dirsrv/slapd-DOMAIN/access. -NGK Matt From: Nathan Kinder [mailto:nkin...@redhat.com] Sent: Thursday, April 04, 2013 6:00 PM To: Joseph, Matthew (EXP) Cc: freeipa-users@redhat.commailto:freeipa-users@redhat.com Subject: EXTERNAL: Re: [Freeipa-users] ipa-replica-install errors On 04/04/2013 07:14 AM, Joseph, Matthew (EXP) wrote: Hello, I'm trying to setup a replica server with ipa-2.2.0-16 on both the Server and the Replica Server. Here are the steps I ran (From the Red Hat 6.3 IdM Administration Guide); IPA_Server: ipa-replica-prepare ipareplica.example.com --ip-address 192.168.1.2 scp /var/lib/ipa/replica-info-ipareplica.example.com.gpg root@ ipareplica:/var/lib/ipa/ IPA_Replica: ipa-replica-install --setup-ca --setup-dns /var/lib/ipa/replica-info-ipareplica.exam ple.com.gpg -- Below is the error I am getting when running ipa-replica-install; Directory Manager (existing master) password: Run connection check to master Check connection from replica to remote master 'IPA_Server.domain.ca': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK PKI-CA: Directory Service port (7389): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master ad...@domain.camailto:ad...@domain.ca password: Execute check on remote master Check connection from master to remote replica 'IPA_Replica.domain.ca': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK PKI-CA: Directory Service port (7389): OK Connection from master to replica is OK. Connection check OK Configuring ntpd [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd done configuring ntpd. Configuring directory server for the CA: Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server done configuring pkids. Configuring certificate server: Estimated time 3 minutes 30 seconds [1/13]: creating certificate server user [2/13]: creating pki-ca instance [3/13]: configuring certificate server instance [4/13]: disabling nonces [5/13]: creating RA agent certificate database [6/13]: importing CA chain to RA certificate database [7/13]: fixing RA database permissions [8/13]: setting up signing cert profile [9/13]: set up CRL publishing [10/13]: set certificate subject base [11/13]: enabling Subject Key Identifier [12/13]: configuring certificate server to start on boot [13/13]: Configure HTTP to proxy connections done configuring pki-cad. Restarting the directory and certificate servers Configuring directory server: Estimated time 1 minute [1/30]: creating directory server user [2/30]: creating directory server instance [3/30]: adding default schema [4/30]: enabling memberof plugin [5/30]: enabling referential integrity plugin [6/30]: enabling winsync plugin [7/30]: configuring replication version plugin [8/30]: enabling IPA enrollment plugin [9/30]: enabling ldapi [10/30]: configuring uniqueness plugin [11/30]: configuring uuid plugin [12/30]: configuring modrdn plugin [13/30]: enabling entryUSN plugin [14/30]: configuring lockout plugin [15/30]: creating indices [16/30]: configuring ssl for ds instance [17/30]: configuring certmap.conf [18/30]: configure autobind for root [19/30]: configure new location for managed entries [20/30]: restarting directory server [21/30]: setting up initial replication Starting replication, please wait until this has completed. [IPA_Server.domain.ca] reports:
Re: [Freeipa-users] Replication Issue
On 04/05/2013 08:53 PM, Simo Sorce wrote: On Fri, 2013-04-05 at 09:51 -0600, Rich Megginson wrote: On 04/05/2013 08:41 AM, Simo Sorce wrote: On Fri, 2013-04-05 at 08:30 -0600, Brent Clark wrote: You were correct, my reverse DNS entries for the master and replica were missing. Odd, since they both existed at one point. Rob, I think we should open a ticket against 389ds, we should never depend on PTR records. In this case I believe the ldap libraries are at fault since they now force SASL canonicalization on which is know to be broken for gssapi as it causes reverse resolution. Rich do you set LDAP_OPT_X_SASL_NOCANON in 389ds code at all ? Yes. ldap/servers/slapd/ldaputil.c:ldap_set_option(ld, LDAP_OPT_X_SASL_NOCANON, LDAP_OPT_ON); I looked at the code, and this is called only if the env variable HACK_SASL_NOCANON is set. I think this should be the default instead. Should this be off by default? Should this be configurable? Maybe make it configurable, I do not have a strong love for 1M knobs, but it should be on by default, relying on reverse resolution defeats mutual authentication through very simple DNS attacks. See this blog post for details: http://ssimo.org/blog/id_015.html https://fedorahosted.org/389/ticket/47317 Simo. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Where has my LDAP server gone!
Thank you, that has solved the issue wonderfully! I do remember the update hanging now you mention it, but I didn't put two and two together! Regards Simon On 7 Apr 2013 21:47, Rob Crittenden rcrit...@redhat.com wrote: Simon Williams wrote: Hi I ran a yum update on my CentOS 6 server that runs FreeIPA a couple of days ago and it upgraded FreeIPA to version 3. I use a couple of web applications that cannot use Kerberos, but can use LDAP to authenticate. These stopped working. When I investigated the issue, I discovered that the LDAP server wasn't there any more. Google searches have proved fruitless and I can't find any documentation for v3. Can anyone tell me how to get my LDAP server back? There is a bug in 389-ds that is affecting some IPA upgrades. It causes the upgrade process to hang and breaking out of it leaves the LDAP server not listening to anything (note that if the upgrade outright fails we do restore things). What you want to do is this: 1. service dirsrv stop (you MUST do this before editing dse.ldif) 2. edit dse.ldif and set nsslapd-port: 389 nsslapd-security: on 3. service dirsrv start 4. as root, ipa-ldap-updater --ldapi Updated 389-ds packages are being worked on. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
