On 09/29/2011 10:29 AM, Simo Sorce wrote:
On Thu, 2011-09-29 at 10:15 -0600, Rich Megginson wrote:
On 09/29/2011 10:11 AM, Simo Sorce wrote:
On Thu, 2011-09-29 at 17:56 +0200, Martin Kosek wrote:
On Thu, 2011-09-29 at 11:44 -0400, Simo Sorce wrote:
On Thu, 2011-09-29 at 17:41 +0200, Martin Kosek wrote:
On Wed, 2011-09-28 at 18:43 -0400, Simo Sorce wrote:
This patch allows ipa-client-install to successfully complete if
anonymous access is not allowed on the LDAP server.

I have tested this by changing the value of
nsslapd-allow-anonymous-access from 'on' to 'rootdse' in cn=config
See NOTE about this option.

This patch warns the user that full verification of the LDAP server was
not possible and may even assume realm is domain.upper() if DNS
discovery is not possible.

With these caveats the installation on a DNS compliant domain works fine
against a IPA server with anonynous access to LDAP disabled with this

Fixes #1881


NOTE: Setting rootdse nsslapd-allow-anonymous-access is standards
compliant as it still allows access anonymously to the rootdse entry.
Setting this option to 'off' prevents access even to rootdse and is not
a good idea (the client doesn't know what auth methods are avilable to
authenticate w/o access to rootdse)
NACK. The approach looks good, but I found several errors:

1) IPA discovery for servers with anonymous access _allowed_ is broken
because of the following lines:

+        if ldapret[0] == 0:
+            self.server = ldapret[0]<<<   This should be ldapret[1]
+            self.realm = ldapret[1]<<<<   This should be ldapret[2]
Ouch I swear I was sure I changed those lines ...

@@ -259,24 +268,29 @@ class IPADiscovery:
                       if trealm == r:
                           return [thost, trealm]<<<<<   This should be [0, 
thost, trealm]
                   # must match or something is very wrong
-                return []
+                return [REALM_NOT_FOUND]

2) If anonymous access is forbidden, IPA base DN cannot be searched
since we can't read it's contents and check that it belongs to IPA. If
you apply my patch 130, you will see this error:

# ipa-client-install --server vm-103.idm.lab.bos.redhat.com --domain 
idm.lab.bos.redhat.com -p admin -w kokos123
Warning: Anonymous access to the LDAP server is disabled.
Proceeding without strict verification.
Note: This is not an error if anonymous access has been explicitly restricted.
DNS domain '' is not configured for automatic KDC address lookup.
KDC address will be set to fixed value.

Discovery was successful!
Hostname: vm-050.idm.lab.bos.redhat.com
DNS Domain: idm.lab.bos.redhat.com
IPA Server: vm-103.idm.lab.bos.redhat.com
Traceback (most recent call last):
    File "/usr/sbin/ipa-client-install", line 1148, in<module>
    File "/usr/sbin/ipa-client-install", line 1137, in main
      rval = install(options, env, fstore, statestore)
    File "/usr/sbin/ipa-client-install", line 866, in install
      print "BaseDN: "+cli_basedn
TypeError: cannot concatenate 'str' and 'NoneType' objects

We will have to add user a possibility to pass base DN for IPA since we
cannot check it ourselves. Something like --basedn=BASEDN. I can do it
in a scope of my patch after you fix 1) if you don't feel comfortable
hacking ipa-client-install.
The basedn comes from rootdse, that one can be searched. (if you set the
option in DS to off and din't read my note, you got what you deserve :-)


I read every word of it :-) My point was that you can have more
databases (basedns, suffixes) configured on the server and when the
anonymous access is disabled we cannot check which one is for IPA.
That's what my patch 130 fixes. Before it, we just took the first
Ok, in that case we can compare the suffix with the realm.
It is 100% guaranteed that suffix and realm must match as we create the
suffix out of the realm.
Can you add code to check against REALM if anonymous is turned on ?

In case REALM is missing (DNS discovery failed) we have 2 options, use
domain.upper() or require a --relam= option to be passed by the user,
what do you think ?

We should really add a defaultNamingContext field in rootdse, maybe we
should open a ticket about that so we do not have to dance around this
issue ?
We probably should do this anyway - note that openldap (and AD too?)
support publishing the default naming context in the root DSE.
But you'll still need a way to discover this in older servers.
Yes we can have fallbacks for older servers (the current code).
But having it will makes life easier.
Do you need a bugzilla ?
Yes, please.

Freeipa-devel mailing list

Reply via email to