On 02/24/2012 08:31 PM, Nathan Stratton wrote:
On Fri, 24 Feb 2012, Oved Ourfalli wrote:
The identification of the provider type is done using the following logic, according to the results from the root DSE query: * if it contains a defaultNamingContext attribute --> AD * else * Check the vendorName attribute * if it is "389 Project" then it is IPA * if it is "Red Hat" then it is RHDS.
We added support for AD, IPA and RHDS. I guess that 389ds has a different vendor name.
What does your root DSE query show? You can run it using ldapsearch, with the options" -LLL -Y GSSAPI -D <distinguished name of the username> -h <ldap server> -b "" -s base objectClass=*
the distinguished name will be something like: uid=username,dc=example,dc=com
[root@ipa-master ~]# ldapsearch -LLL -Y GSSAPI -D uid=nathan,cn=users,cn=accounts,dc=blinkmind,dc=net -h localhost -b "" -s base objectClass=* SASL/GSSAPI authentication started SASL username: admin@BLINKMIND.NET SASL SSF: 56 SASL data security layer installed. dn: objectClass: top namingContexts: dc=blinkmind,dc=net defaultnamingcontext: dc=blinkmind,dc=net supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 supportedExtension: 2.16.840.1.113730.3.5.10 supportedExtension: 2.16.840.1.113730.3.8.10.3 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 2.16.840.1.113730.3.8.10.1 supportedExtension: 2.16.840.1.113730.3.5.3 supportedExtension: 2.16.840.1.113730.3.5.12 supportedExtension: 2.16.840.1.113730.3.5.5 supportedExtension: 2.16.840.1.113730.3.5.6 supportedExtension: 2.16.840.1.113730.3.5.9 supportedExtension: 2.16.840.1.113730.3.5.4 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.15 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.14 supportedControl: 2.16.840.1.113730.3.4.20 supportedControl: 1.3.6.1.4.1.1466.29539.12 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.13 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: PLAIN supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: ANONYMOUS supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: LOGIN supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: 389 Project vendorVersion: 389-Directory/1.2.10.rc1 B2012.035.328 dataversion: 020120223201756 netscapemdsuffix: cn=ldap://dc=ipa-master,dc=blinkmind,dc=net:389 lastusn: 468
It will help us understand which vendor name is shown in your ldap server, and we might use it in order to improve the identification.
It surprises me that IPA is not identified correctly, as "389 Project" is the vendor name that was used there (unless it was changed). As for 389ds, as I said before we added RHDS support, so there might be changes in the schema, and also probably the vendor name there is not "Red Hat".
Looks like "389 Project"
However I still see:
-bash-4.2# engine-manage-domains -action=add -domain=blinkmind.net -user=nathan -interactive Enter password:
No user in Directory was found for nathan@BLINKMIND.NET. Trying next LDAP server in list Failure while testing domain blinkmind.net. Details: No user information was found for user
On my FreeIPA server I see:
[24/Feb/2012:18:28:46 +0000] conn=144 op=3 SRCH base="dc=blinkmind,dc=net" scope=2 filter="(&(samaccounttype=805306368)(userprincipalname=nathan@BLINKMIND.NET))" attrs="nsUniqueId ipaUniqueID objectguid objectClass javaSerializedData javaClassName javaFactory javaCodebase javaReferenceAddress javaClassNames javaremotelocation" [24/Feb/2012:18:28:46 +0000] conn=144 op=3 RESULT err=0 tag=101 nentries=0 etime=0 notes=U
Entries returned are 0 because userprincipalname=nathan@BLINKMIND.NET does not exist. Hi Nathan,
I think you're using the wrong query with IPA. the part of samaccounttype=805306368 should be replaced with objectClass=krbPrincipalAux the part of userprincipalname should be replaced with - krbPrincipalName=nathan@BBLINKMIND.NET So I guess the filter should look like - (&(objectClass=krbPrincipalAux)(krbPrincipalName=nathan@BBLINKMIND.NET)) I did not develop the IPA support, however, I checked the file - LdapQueryMetadataFactoryImpl.java and found definitions of the queries for the different providers - what you will see there is that each LDAP provider has its own map of keys to queries - the relevant key is LdapQueryType.getUserByPrincipalName - so you can see how it is defined in adHashMap and how it is defined in ipaHashMap, and other maps (dsMap , for instance). Hope this helps you Yair
<> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users