Sorry for the new thread but I just joined the list. The following excerpt from Nathan Stratton's 389DS log shows the same thing that I've been seeing when trying to use IPA. It appears that the directory server type is being misidentified as active directory hence the search on samaccounttype and userprincipalname. [23/Feb/2012:18:33:34 +0000] conn=50 op=3 SRCH base="dc=blinkmind,dc=net" scope=2 filter="(&(samaccounttype=805306368)(userprincipalname=nathan at BLINKMIND.NET <http://lists.ovirt.org/mailman/listinfo/users>))" attrs="nsUniqueId ipaUniqueID objectguid objectClass javaSerializedData javaClassName javaFactory javaCodebase javaReferenceAddress javaClassNames javaremotelocation"
On 02/24/2012 10:35 AM, Jeff Bailey wrote:
Sorry for the new thread but I just joined the list. The following Welcome aboard Jeff
excerpt from Nathan Stratton's 389DS log shows the same thing that I've been seeing when trying to use IPA. It appears that the directory server type is being misidentified as active directory hence the search on samaccounttype and userprincipalname.
[23/Feb/2012:18:33:34 +0000] conn=50 op=3 SRCH base="dc=blinkmind,dc=net" scope=2 filter="(&(samaccounttype=805306368)(userprincipalname=nathan at BLINKMIND.NET <http://lists.ovirt.org/mailman/listinfo/users>))" attrs="nsUniqueId ipaUniqueID objectguid objectClass javaSerializedData javaClassName javaFactory javaCodebase javaReferenceAddress javaClassNames javaremotelocation" One the issues I see here is the fact the the query is using samaccounttype and objectguid which might be relevant only for ActiveDirectory. Nathan, can you provide us the exact query? (you can place userprincipalname=XXXXX in order to prevent spamming, we'll understand what you mean). I just want to fully understand if you truely see both ipaUniqueID and objectguid I would (for example) check what attributes are supports by the 389ds schema.
Yair
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Fri, 24 Feb 2012, Yair Zaslavsky wrote:
One the issues I see here is the fact the the query is using samaccounttype and objectguid which might be relevant only for ActiveDirectory. Nathan, can you provide us the exact query? (you can place userprincipalname=XXXXX in order to prevent spamming, we'll understand what you mean). I just want to fully understand if you truely see both ipaUniqueID and objectguid
[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" They both are there, but with FreeIPA there is no "userprincipalname"
<> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com
----- Original Message -----
From: "Jeff Bailey" <bailey@cs.kent.edu> To: users@ovirt.org Sent: Friday, February 24, 2012 10:35:02 AM Subject: [Users] LDAP
Sorry for the new thread but I just joined the list. The following excerpt from Nathan Stratton's 389DS log shows the same thing that I've been seeing when trying to use IPA. It appears that the directory server type is being misidentified as active directory hence the search on samaccounttype and userprincipalname.
[23/Feb/2012:18:33:34 +0000] conn=50 op=3 SRCH base="dc=blinkmind,dc=net" scope=2 filter="(&(samaccounttype=805306368)(userprincipalname=nathan at BLINKMIND.NET <http://lists.ovirt.org/mailman/listinfo/users>))" attrs="nsUniqueId ipaUniqueID objectguid objectClass javaSerializedData javaClassName javaFactory javaCodebase javaReferenceAddress javaClassNames javaremotelocation"
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 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".
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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.
<> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com
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
On Fri, 24 Feb 2012, Yair Zaslavsky wrote:
Hi Nathan,
I think you're using the wrong query with IPA.
Yep, but so far I have not found how to fix ovirt to use the correct one.
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))
Yes, I understand the query is wrong, what I don't understand is how to make ovirt use the correct query. I started working trying to get LDAP to work with my OpenLDAP system and was told that ovirt does not yet support it. I asked what was supported and was told to try 389, but ran into issues with that so then I was asked to try IPA and now have this issue.
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).
I don't have that .java file, I do have the .class. I am new to Java, how do I go about modifying ovirt to use the correct query?
<> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com
On 02/24/2012 08:59 PM, Nathan Stratton wrote:
On Fri, 24 Feb 2012, Yair Zaslavsky wrote:
Hi Nathan,
I think you're using the wrong query with IPA.
Yep, but so far I have not found how to fix ovirt to use the correct one.
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))
Yes, I understand the query is wrong, what I don't understand is how to make ovirt use the correct query. I started working trying to get LDAP to work with my OpenLDAP system and was told that ovirt does not yet support it. I asked what was supported and was told to try 389, but ran into issues with that so then I was asked to try IPA and now have this issue.
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).
I don't have that .java file, I do have the .class. I am new to Java, how do I go about modifying ovirt to use the correct query?
Nathan, first of all, please try to run the query I suggested for you - change the filter to (&(objectClass=krbPrincipalAux)(krbPrincipalName=nathan@BBLINKMIND.NET)) (I understand you try to query IPA with an external tool - please first try to use this filter and see if it works. In my humble opinion, I don't think that you need to change the code, we need to understand why IPA provider is not "detected". Yair
<> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com
On Fri, 24 Feb 2012, Yair Zaslavsky wrote:
Nathan, first of all, please try to run the query I suggested for you - change the filter to (&(objectClass=krbPrincipalAux)(krbPrincipalName=nathan@BBLINKMIND.NET)) (I understand you try to query IPA with an external tool - please first try to use this filter and see if it works. In my humble opinion, I don't think that you need to change the code, we need to understand why IPA provider is not "detected".
Sorry, new to LDAP, took me a while to figure out how to do the query with ldapsearch. [root@ipa-master ~]# ldapsearch -x -b "dc=blinkmind,dc=net" "(&(objectClass=krbPrincipalAux)(krbPrincipalName=nathan@BLINKMIND.NET))" -h localhost # extended LDIF # # LDAPv3 # base <dc=blinkmind,dc=net> with scope subtree # filter: (&(objectClass=krbPrincipalAux)(krbPrincipalName=nathan@BLINKMIND.NET)) # requesting: ALL # # nathan, users, accounts, blinkmind.net dn: uid=nathan,cn=users,cn=accounts,dc=blinkmind,dc=net displayName: Nathan Stratton cn: Nathan Stratton objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: mepOriginEntry loginShell: /bin/sh sn: Stratton gecos: Nathan Stratton homeDirectory: /home/nathan krbPwdPolicyReference: cn=global_policy,cn=BLINKMIND.NET,cn=kerberos,dc=blinkm ind,dc=net krbPrincipalName: nathan@BLINKMIND.NET givenName: Nathan uid: nathan initials: NS uidNumber: 333400004 gidNumber: 333400004 ipaUniqueID: cfcf627e-5e5c-11e1-8e68-001a4a0d0004 mepManagedEntry: cn=nathan,cn=groups,cn=accounts,dc=blinkmind,dc=net krbLastPwdChange: 20120223202917Z krbPasswordExpiration: 20220220202917Z krbLoginFailedCount: 0 krbExtraData:: AAgBAA== krbExtraData:: AAKdoUZPbmF0aGFuQEJMSU5LTUlORC5ORVQA krbLastFailedAuth: 20120223202750Z krbLastSuccessfulAuth: 20120224191502Z # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
<> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com
On 02/24/2012 09:17 PM, Nathan Stratton wrote:
On Fri, 24 Feb 2012, Yair Zaslavsky wrote:
Nathan, first of all, please try to run the query I suggested for you - change the filter to (&(objectClass=krbPrincipalAux)(krbPrincipalName=nathan@BBLINKMIND.NET)) (I understand you try to query IPA with an external tool - please first try to use this filter and see if it works. In my humble opinion, I don't think that you need to change the code, we need to understand why IPA provider is not "detected".
Sorry, new to LDAP, took me a while to figure out how to do the query with ldapsearch.
[root@ipa-master ~]# ldapsearch -x -b "dc=blinkmind,dc=net" "(&(objectClass=krbPrincipalAux)(krbPrincipalName=nathan@BLINKMIND.NET))" -h localhost # extended LDIF # # LDAPv3 # base <dc=blinkmind,dc=net> with scope subtree # filter: (&(objectClass=krbPrincipalAux)(krbPrincipalName=nathan@BLINKMIND.NET)) # requesting: ALL #
# nathan, users, accounts, blinkmind.net dn: uid=nathan,cn=users,cn=accounts,dc=blinkmind,dc=net displayName: Nathan Stratton cn: Nathan Stratton objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: mepOriginEntry loginShell: /bin/sh sn: Stratton gecos: Nathan Stratton homeDirectory: /home/nathan krbPwdPolicyReference: cn=global_policy,cn=BLINKMIND.NET,cn=kerberos,dc=blinkm ind,dc=net krbPrincipalName: nathan@BLINKMIND.NET givenName: Nathan uid: nathan initials: NS uidNumber: 333400004 gidNumber: 333400004 ipaUniqueID: cfcf627e-5e5c-11e1-8e68-001a4a0d0004 mepManagedEntry: cn=nathan,cn=groups,cn=accounts,dc=blinkmind,dc=net krbLastPwdChange: 20120223202917Z krbPasswordExpiration: 20220220202917Z krbLoginFailedCount: 0 krbExtraData:: AAgBAA== krbExtraData:: AAKdoUZPbmF0aGFuQEJMSU5LTUlORC5ORVQA krbLastFailedAuth: 20120223202750Z krbLastSuccessfulAuth: 20120224191502Z
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
Hi Nathan, that's awesome - looks like you got a result, so first of all - we know the query syntax is working:) Now, I would like to to run some queries on your psql db, so I will check your configuration select * from vdc_options where option_name ilike '%AdUser%'; select * from vdc_options where option_name = 'DomainName';
<> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com
On Fri, 24 Feb 2012, Yair Zaslavsky wrote:
Hi Nathan, that's awesome - looks like you got a result, so first of all - we know the query syntax is working:) Now, I would like to to run some queries on your psql db, so I will check your configuration
select * from vdc_options where option_name ilike '%AdUser%';
All blank for option_vlaue: 5 AdUserPassword general 4 AdUserName general 142 AdUserId general
select * from vdc_options where option_name = 'DomainName';
3 DomainName general Also a blink option_value because engine-manage-domains never finishes. -Nathan
Found the problem. We are identifying if the LDAP server is AD or not by checking if the root DSE contains the "defaultNamingContext" attribute. This attribute is not in the LDAP standard, thus it appears in AD, and not in IPA and RHDS... Looking at the rootDSE you provided it looks like it was added to IPA, therefore we identify it as AD. Can you open us a bug on that upstream? Given that issue, I think we should also provide a way to set the ldap provider type (using the engine-manage-domains utility), in order to workaround such issues in the future. Thank you, Oved ----- Original Message -----
From: "Nathan Stratton" <nathan@robotics.net> To: "Oved Ourfalli" <ovedo@redhat.com> Cc: users@ovirt.org Sent: Friday, February 24, 2012 8:31:02 PM Subject: Re: [Users] LDAP
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.
<> 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
On 02/26/2012 09:18 AM, Oved Ourfalli wrote:
Found the problem. We are identifying if the LDAP server is AD or not by checking if the root DSE contains the "defaultNamingContext" attribute. This attribute is not in the LDAP standard, thus it appears in AD, and not in IPA and RHDS...
Looking at the rootDSE you provided it looks like it was added to IPA, therefore we identify it as AD.
Can you open us a bug on that upstream? Given that issue, I think we should also provide a way to set the ldap provider type (using the engine-manage-domains utility), in order to workaround such issues in the future. Don't you think that now this key (i.e providerType=IPA) kinda becomes mandatory?
Thank you, Oved
----- Original Message -----
From: "Nathan Stratton" <nathan@robotics.net> To: "Oved Ourfalli" <ovedo@redhat.com> Cc: users@ovirt.org Sent: Friday, February 24, 2012 8:31:02 PM Subject: Re: [Users] LDAP
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.
<> 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
On 02/26/2012 09:45 AM, Yair Zaslavsky wrote:
On 02/26/2012 09:18 AM, Oved Ourfalli wrote:
Found the problem. We are identifying if the LDAP server is AD or not by checking if the root DSE contains the "defaultNamingContext" attribute. This attribute is not in the LDAP standard, thus it appears in AD, and not in IPA and RHDS...
Looking at the rootDSE you provided it looks like it was added to IPA, therefore we identify it as AD.
Can you open us a bug on that upstream? Given that issue, I think we should also provide a way to set the ldap provider type (using the engine-manage-domains utility), in order to workaround such issues in the future. Don't you think that now this key (i.e providerType=IPA) kinda becomes mandatory? Or actually, maybe we should have it optional - if set - then this value will be used for providerType, if not - our "auto-deduction" mechanism takes place.
Thoughts?
Thank you, Oved
----- Original Message -----
From: "Nathan Stratton" <nathan@robotics.net> To: "Oved Ourfalli" <ovedo@redhat.com> Cc: users@ovirt.org Sent: Friday, February 24, 2012 8:31:02 PM Subject: Re: [Users] LDAP
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.
<> 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
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 02/26/2012 09:46 AM, Yair Zaslavsky wrote:
On 02/26/2012 09:45 AM, Yair Zaslavsky wrote:
On 02/26/2012 09:18 AM, Oved Ourfalli wrote:
Found the problem. We are identifying if the LDAP server is AD or not by checking if the root DSE contains the "defaultNamingContext" attribute. This attribute is not in the LDAP standard, thus it appears in AD, and not in IPA and RHDS...
Looking at the rootDSE you provided it looks like it was added to IPA, therefore we identify it as AD.
Can you open us a bug on that upstream? Given that issue, I think we should also provide a way to set the ldap provider type (using the engine-manage-domains utility), in order to workaround such issues in the future. Don't you think that now this key (i.e providerType=IPA) kinda becomes mandatory? Or actually, maybe we should have it optional - if set - then this value will be used for providerType, if not - our "auto-deduction" mechanism takes place.
Thoughts?
Drop the auto-detection. Y.
Thank you, Oved
----- Original Message -----
From: "Nathan Stratton"<nathan@robotics.net> To: "Oved Ourfalli"<ovedo@redhat.com> Cc: users@ovirt.org Sent: Friday, February 24, 2012 8:31:02 PM Subject: Re: [Users] LDAP
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.
<> 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
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
----- Original Message -----
From: "Yaniv Kaul" <ykaul@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "Oved Ourfalli" <ovedo@redhat.com>, users@ovirt.org Sent: Sunday, February 26, 2012 9:47:00 AM Subject: Re: [Users] LDAP
On 02/26/2012 09:46 AM, Yair Zaslavsky wrote:
On 02/26/2012 09:45 AM, Yair Zaslavsky wrote:
On 02/26/2012 09:18 AM, Oved Ourfalli wrote:
Found the problem. We are identifying if the LDAP server is AD or not by checking if the root DSE contains the "defaultNamingContext" attribute. This attribute is not in the LDAP standard, thus it appears in AD, and not in IPA and RHDS...
Looking at the rootDSE you provided it looks like it was added to IPA, therefore we identify it as AD.
Can you open us a bug on that upstream? Given that issue, I think we should also provide a way to set the ldap provider type (using the engine-manage-domains utility), in order to workaround such issues in the future. Don't you think that now this key (i.e providerType=IPA) kinda becomes mandatory? Or actually, maybe we should have it optional - if set - then this value will be used for providerType, if not - our "auto-deduction" mechanism takes place.
Thoughts?
Drop the auto-detection. Y.
The pros for adding the auto-detection is the ease of use. The cons are that if it is not good enough it may fail due to changes in the LDAP provider (like what happened in this issue). I think we should improve that, but also make a way to work-around it, using special option of setting the provider type.
Thank you, Oved
----- Original Message -----
From: "Nathan Stratton"<nathan@robotics.net> To: "Oved Ourfalli"<ovedo@redhat.com> Cc: users@ovirt.org Sent: Friday, February 24, 2012 8:31:02 PM Subject: Re: [Users] LDAP
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.
<> 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
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 02/26/2012 12:57 PM, Oved Ourfalli wrote:
----- Original Message -----
From: "Yaniv Kaul" <ykaul@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "Oved Ourfalli" <ovedo@redhat.com>, users@ovirt.org Sent: Sunday, February 26, 2012 9:47:00 AM Subject: Re: [Users] LDAP
On 02/26/2012 09:46 AM, Yair Zaslavsky wrote:
On 02/26/2012 09:45 AM, Yair Zaslavsky wrote:
On 02/26/2012 09:18 AM, Oved Ourfalli wrote:
Found the problem. We are identifying if the LDAP server is AD or not by checking if the root DSE contains the "defaultNamingContext" attribute. This attribute is not in the LDAP standard, thus it appears in AD, and not in IPA and RHDS...
Looking at the rootDSE you provided it looks like it was added to IPA, therefore we identify it as AD.
Can you open us a bug on that upstream? Given that issue, I think we should also provide a way to set the ldap provider type (using the engine-manage-domains utility), in order to workaround such issues in the future. Don't you think that now this key (i.e providerType=IPA) kinda becomes mandatory? Or actually, maybe we should have it optional - if set - then this value will be used for providerType, if not - our "auto-deduction" mechanism takes place.
Thoughts?
Drop the auto-detection. Y.
The pros for adding the auto-detection is the ease of use. The cons are that if it is not good enough it may fail due to changes in the LDAP provider (like what happened in this issue). I think we should improve that, but also make a way to work-around it, using special option of setting the provider type.
So what do u think about my suggestion? manage-domains can add "explicit provider type" - if does not exist, auto-detection is carried out.
Thank you, Oved
----- Original Message -----
From: "Nathan Stratton"<nathan@robotics.net> To: "Oved Ourfalli"<ovedo@redhat.com> Cc: users@ovirt.org Sent: Friday, February 24, 2012 8:31:02 PM Subject: Re: [Users] LDAP
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.
> <> 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
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: "Oved Ourfalli" <ovedo@redhat.com> Cc: users@ovirt.org Sent: Sunday, February 26, 2012 1:09:16 PM Subject: Re: [Users] LDAP
On 02/26/2012 12:57 PM, Oved Ourfalli wrote:
----- Original Message -----
From: "Yaniv Kaul" <ykaul@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "Oved Ourfalli" <ovedo@redhat.com>, users@ovirt.org Sent: Sunday, February 26, 2012 9:47:00 AM Subject: Re: [Users] LDAP
On 02/26/2012 09:46 AM, Yair Zaslavsky wrote:
On 02/26/2012 09:18 AM, Oved Ourfalli wrote:
Found the problem. We are identifying if the LDAP server is AD or not by checking if the root DSE contains the "defaultNamingContext" attribute. This attribute is not in the LDAP standard, thus it appears in AD, and not in IPA and RHDS...
Looking at the rootDSE you provided it looks like it was added to IPA, therefore we identify it as AD.
Can you open us a bug on that upstream? Given that issue, I think we should also provide a way to set the ldap provider type (using the engine-manage-domains utility), in order to workaround such issues in the future. Don't you think that now this key (i.e providerType=IPA) kinda becomes mandatory? Or actually, maybe we should have it optional - if set - then
On 02/26/2012 09:45 AM, Yair Zaslavsky wrote: this value will be used for providerType, if not - our "auto-deduction" mechanism takes place.
Thoughts?
Drop the auto-detection. Y.
The pros for adding the auto-detection is the ease of use. The cons are that if it is not good enough it may fail due to changes in the LDAP provider (like what happened in this issue). I think we should improve that, but also make a way to work-around it, using special option of setting the provider type.
So what do u think about my suggestion? manage-domains can add "explicit provider type" - if does not exist, auto-detection is carried out.
I agree with it. It looks to me like the right way to go.
Thank you, Oved
----- Original Message ----- > From: "Nathan Stratton"<nathan@robotics.net> > To: "Oved Ourfalli"<ovedo@redhat.com> > Cc: users@ovirt.org > Sent: Friday, February 24, 2012 8:31:02 PM > Subject: Re: [Users] LDAP > > 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. > > >> <> > 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 >
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Sun, 26 Feb 2012, Yaniv Kaul wrote:
On 02/26/2012 09:46 AM, Yair Zaslavsky wrote:
On 02/26/2012 09:45 AM, Yair Zaslavsky wrote:
On 02/26/2012 09:18 AM, Oved Ourfalli wrote:
Found the problem. We are identifying if the LDAP server is AD or not by checking if the root DSE contains the "defaultNamingContext" attribute. This attribute is not in the LDAP standard, thus it appears in AD, and not in IPA and RHDS...
Looking at the rootDSE you provided it looks like it was added to IPA, therefore we identify it as AD.
Can you open us a bug on that upstream? Given that issue, I think we should also provide a way to set the ldap provider type (using the engine-manage-domains utility), in order to workaround such issues in the future. Don't you think that now this key (i.e providerType=IPA) kinda becomes mandatory? Or actually, maybe we should have it optional - if set - then this value will be used for providerType, if not - our "auto-deduction" mechanism takes place.
Thoughts?
Drop the auto-detection.
Thats a good point, I think the auto-detection is a bit overkill, most users know what they are running. Is there someting I can add to the oVirt DB manually so I can skip the engine-manage-domains utility for now and move forward with using FreeIPA?
<> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com
On 02/26/2012 05:21 PM, Nathan Stratton wrote:
On Sun, 26 Feb 2012, Yaniv Kaul wrote:
On 02/26/2012 09:46 AM, Yair Zaslavsky wrote:
On 02/26/2012 09:45 AM, Yair Zaslavsky wrote:
On 02/26/2012 09:18 AM, Oved Ourfalli wrote:
Found the problem. We are identifying if the LDAP server is AD or not by checking if the root DSE contains the "defaultNamingContext" attribute. This attribute is not in the LDAP standard, thus it appears in AD, and not in IPA and RHDS...
Looking at the rootDSE you provided it looks like it was added to IPA, therefore we identify it as AD.
Can you open us a bug on that upstream? Given that issue, I think we should also provide a way to set the ldap provider type (using the engine-manage-domains utility), in order to workaround such issues in the future. Don't you think that now this key (i.e providerType=IPA) kinda becomes mandatory? Or actually, maybe we should have it optional - if set - then this value will be used for providerType, if not - our "auto-deduction" mechanism takes place.
Thoughts?
Drop the auto-detection.
Thats a good point, I think the auto-detection is a bit overkill, most users know what they are running. Is there someting I can add to the oVirt DB manually so I can skip the engine-manage-domains utility for now and move forward with using FreeIPA? Nathan, IMHO, you will still encounter auto detection issues, during invocation of rootDSE queries when working with ldap related flows with engine-core. This means you will still get wrong provider type. This is something we should fix. Oved - am I correct here?
<> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com
----- Original Message ----- > From: "Yair Zaslavsky" <yzaslavs@redhat.com> > To: "Nathan Stratton" <nathan@robotics.net> > Cc: "Oved Ourfalli" <ovedo@redhat.com>, users@ovirt.org > Sent: Sunday, February 26, 2012 5:42:08 PM > Subject: Re: [Users] LDAP > > On 02/26/2012 05:21 PM, Nathan Stratton wrote: > > On Sun, 26 Feb 2012, Yaniv Kaul wrote: > > > >> On 02/26/2012 09:46 AM, Yair Zaslavsky wrote: > >>> On 02/26/2012 09:45 AM, Yair Zaslavsky wrote: > >>>> On 02/26/2012 09:18 AM, Oved Ourfalli wrote: > >>>>> Found the problem. > >>>>> We are identifying if the LDAP server is AD or not by checking > >>>>> if > >>>>> the root DSE contains the "defaultNamingContext" attribute. > >>>>> This attribute is not in the LDAP standard, thus it appears in > >>>>> AD, > >>>>> and not in IPA and RHDS... > >>>>> > >>>>> Looking at the rootDSE you provided it looks like it was added > >>>>> to > >>>>> IPA, therefore we identify it as AD. > >>>>> > >>>>> Can you open us a bug on that upstream? > >>>>> Given that issue, I think we should also provide a way to set > >>>>> the > >>>>> ldap provider type (using the engine-manage-domains utility), > >>>>> in > >>>>> order to workaround such issues in the future. > >>>> Don't you think that now this key (i.e providerType=IPA) kinda > >>>> becomes > >>>> mandatory? > >>> Or actually, maybe we should have it optional - if set - then > >>> this value > >>> will be used for providerType, if not - our "auto-deduction" > >>> mechanism > >>> takes place. > >>> > >>> Thoughts? > >> > >> Drop the auto-detection. > > > > Thats a good point, I think the auto-detection is a bit overkill, > > most > > users know what they are running. Is there someting I can add to > > the > > oVirt DB manually so I can skip the engine-manage-domains utility > > for > > now and move forward with using FreeIPA? > Nathan, IMHO, you will still encounter auto detection issues, during > invocation of rootDSE queries when working with ldap related flows > with > engine-core. This means you will still get wrong provider type. > This is something we should fix. > Oved - am I correct here? Yair - You are correct. Nathan - You are more than welcome to push a fix for that upstream. Some details on what you'll have to do: To fix the auto-identification issue you'll have to find out other attribute that can do the differentiation. Do the fix both in the utilities, and in the engine core. To create ability to set it up you'll have to do the following: 1. Create a new configuration entry (all configuration entries are in the vdc_options table). It will be similar to other domain related properties, such as AdUserName, LdapServers and etc. a. Create an upgrader to add it to the database (see <sources_dir>/backend/manager/dbscripts/upgrade for examples). b. Upon upgrade it should be empty. 2. Check in UsersDomainsCacheManagerService if it exists, and if so update a map of ldap provider per domain. 3. When trying to check the ldap provider type, you'll have to test first if the type already appears in the UsersDomainsCacheManagerService, and if so use that. If not, auto-identify it. 4. Make the engine-manage-domains do something similar, and update this field in the database according to the user input. We'll be happy to provide more details on that, and assist in any way. You can start with one of the fixes at start. They don't have to be in the same patchset. Yair - feel free to elaborate on other steps if you believe they are necessary. Thank you! Oved > > > >> <> > > 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 >
On Sun, 26 Feb 2012, Oved Ourfalli wrote:
Found the problem. We are identifying if the LDAP server is AD or not by checking if the root DSE contains the "defaultNamingContext" attribute. This attribute is not in the LDAP standard, thus it appears in AD, and not in IPA and RHDS...
Looking at the rootDSE you provided it looks like it was added to IPA, therefore we identify it as AD.
Is there a way I can fix this short term by modifying my rootDSE in FreeIPA?
Can you open us a bug on that upstream?
How do I do that?
Given that issue, I think we should also provide a way to set the ldap provider type (using the engine-manage-domains utility), in order to workaround such issues in the future.
Any timeframe? It's a bit frustrating that RedHat oVirt project and RedHat 389 and RedHat FreeIPA can't talk to each other.
<> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com
participants (5)
-
Jeff Bailey -
Nathan Stratton -
Oved Ourfalli -
Yair Zaslavsky -
Yaniv Kaul