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: [email protected] > 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 [email protected]. 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)([email protected]))" > 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 [email protected] > 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 - [email protected] So I guess the filter should look like - (&(objectClass=krbPrincipalAux)([email protected])) 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 > [email protected] > http://lists.ovirt.org/mailman/listinfo/users _______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
