Re: [Users] ldap
- Original Message - From: Ryan Wilkinson ryanw...@gmail.com To: users@ovirt.org Sent: Thursday, March 28, 2013 2:42:56 PM Subject: [Users] ldap I'm able to set up Active Directory authentication if my ovirt engine is set to use dns that is hosted on the same system as Active Directory. However, if I use static host entries in my engine hosts file instead of using dns I'm getting the error ldap server for domain not found when I issue the command: engine-manage-domains -action=add -domain=’ovirt.local' -user='admin' -provider=ActiveDirectory -interactive from the engine. I've googled to death how to configure static entries on my engine system for the ldap server and it seems that I need to configure my nsswitch and ldap.conf files but still no luck... Any ideas?? Hi Ryan, To work with LDAP you currently need to have both LDAP and Kerberos SRV records in the DNS, as well as PTR record. If you would like to work locally I can suggest working with dnsmasq (lightweight DHCP and caching DNS server) locally, defining these entries there, and setting /etc/resolv.conf properly, so that it would access it. The configuration is in /etc/dnsmasq.conf (or in /etc/dnsmasq.d/...). Example for LDAP and Kerberos records: srv-host=_ldap._tcp.my_domain.com,ad.my_domain.com,389 srv-host=_kerberos._tcp.my_domain.com,ad.my_domain.com,88 and, afaik it also takes /etc/hosts and creates PTR records for the entries there, so that should be enough, if you add your AD host in /etc/hosts (I guess you can also add those manually in dnsmasq). Let me know if you need further assistance. Oved ___ 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
Re: [Users] ldap simple
Hi.
Further testing...
- Setup: one ldap server with added user to match ovirt searches
(while adding user in webadmin),
- Fedora 18, engine 3.2.1, openldap-server, simple authentication,
no firewalls,
- with packet inspection we can see ldap responding with requested
attributes
- still, there are errors in logs, see below, and no users are
listed in webadmin, engine fails to parse given attributes
- engine-manage-domains -action="" returns "Invalid
credentials" even though binding is ok and ldap is replying with
data.
Can anyone point us to some documentation on this topic?
Is really AD the only good solution for user management?
engine.log
2013-03-19 15:16:53,042 ERROR
[org.ovirt.engine.core.bll.adbroker.LDAPTemplateWrapper]
(ajp--127.0.0.1-8702-3) Error in running LDAP query. BaseDN is ,
filter is (((objectClass=person))
(|(givenname=test)(sn=test)(uid=test)(uid=test))). Exception message
is: null
2013-03-19 15:16:53,043 ERROR
[org.ovirt.engine.core.bll.adbroker.DirectorySearcher]
(ajp--127.0.0.1-8702-3) Failed ldap search server
ldap://ldaphost.domain.si:389 due to null. We should try the next
server
server.log
2013-03-19 15:17:24,113 ERROR
[org.springframework.ldap.control.AbstractRequestControlDirContextProcessor]
(ajp--127.0.0.1-8702-6) No matching response control found for paged
results - looking for 'class
javax.naming.ldap.PagedResultsResponseControl
On 03/18/2013 09:09 AM, Yair Zaslavsky
wrote:
Hi,
We're issuing a RootDSE query (once per LDAP domain
configured).
We try to obtain from it the "defaultNamingContext"
attribute.
If does not exist - we try to obtain ""NamingContexts"
We store the result at a "domainDn" (we have a data
structure which maps domains to information objects, one of
the fields at the information object is the DN of the domain)
field, and we use it to compose the full ldap URL we send the
queries to.
From:
"Andrej Bagon" andrej.ba...@arnes.si
To: "Itamar Heim" ih...@redhat.com
Cc: users@ovirt.org, "Yair Zaslavsky"
yzasl...@redhat.com, "Oved Ourfalli"
oourf...@redhat.com
Sent: Monday, March 18, 2013 9:07:06 AM
Subject: Re: [Users] ldap simple
Hi,
the system is trying to bind to ldap as:
bind request:
uid=cn=ovirt,cn=Users,cn=Accounts,dc=ourdomain,dc=si
I dont know how it knows dc=ourdomain,dc=si
It should be
bind request: cn=ovirt,ou=system,dc=ourdomain,dc=si" -b
"dc=arnes,dc=si
The same with the search: we have users in form as:
edupersonprincipalname=usern...@users.ourdomain.si,dc=users,dc=ourdomain,dc=si
values in database:
select * from vdc_options where option_name in
('DomainName','LdapServers','LDAPSecurityAuthentication','LDAPProviderTypes','AdUserName','AdUserPassword')
order by option_id;
option_id | option_name |
option_value | version
---+++-
10 | AdUserName |
users.ourdomain.si:ovirt | general
11 | AdUserPassword
|users.ourdomain.si:adminpassword | general
69 | DomainName | users.ourdomain.si
| general
130 | LDAPSecurityAuthentication|
users.ourdomain.si:SIMPLE | general
132 | LdapServers |
users.ourdomain.si:server.ourdomain.si | general
133 | LDAPProviderTypes |
users.ourdomain.si:rhds | general
(6 rows)
Best Regards,
Andrej Bagon
On 03/15/2013 12:09 PM, Itamar Heim wrote:
On
03/14/2013 01:58 PM, Andrej Bagon wrote:
Hi,
is it possible to change the bind request that is sent
to the ldap
server? The default
uid=user,cn=Users,cn=Accounts,cn=our,cn=domain is
not suitable.
can you please explain why / what you would like to change
it to?
Re: [Users] ldap simple
Why openldap server?
We do not support openldap at the moment.
- Original Message -
From: Jure Kranjc jure.kra...@arnes.si
To: users@ovirt.org
Sent: Tuesday, March 19, 2013 3:50:49 PM
Subject: Re: [Users] ldap simple
Hi.
Further testing...
- Setup: one ldap server with added user to match ovirt searches
(while adding user in webadmin),
- Fedora 18, engine 3.2.1, openldap-server, simple authentication, no
firewalls,
- with packet inspection we can see ldap responding with requested
attributes
- still, there are errors in logs, see below, and no users are listed
in webadmin, engine fails to parse given attributes
- engine-manage-domains -action=validate returns Invalid
credentials even though binding is ok and ldap is replying with
data.
Can anyone point us to some documentation on this topic?
Is really AD the only good solution for user management?
engine.log
2013-03-19 15:16:53,042 ERROR
[org.ovirt.engine.core.bll.adbroker.LDAPTemplateWrapper]
(ajp--127.0.0.1-8702-3) Error in running LDAP query. BaseDN is ,
filter is (((objectClass=person))
(|(givenname=test)(sn=test)(uid=test)(uid=test))). Exception message
is: null
2013-03-19 15:16:53,043 ERROR
[org.ovirt.engine.core.bll.adbroker.DirectorySearcher]
(ajp--127.0.0.1-8702-3) Failed ldap search server
ldap://ldaphost.domain.si:389 due to null. We should try the next
server
server.log
2013-03-19 15:17:24,113 ERROR
[org.springframework.ldap.control.AbstractRequestControlDirContextProcessor]
(ajp--127.0.0.1-8702-6) No matching response control found for paged
results - looking for 'class
javax.naming.ldap.PagedResultsResponseControl
On 03/18/2013 09:09 AM, Yair Zaslavsky wrote:
Hi,
We're issuing a RootDSE query (once per LDAP domain configured).
We try to obtain from it the defaultNamingContext attribute.
If does not exist - we try to obtain NamingContexts
We store the result at a domainDn (we have a data structure which
maps domains to information objects, one of the fields at the
information object is the DN of the domain) field, and we use it to
compose the full ldap URL we send the queries to.
- Original Message -
From: Andrej Bagon andrej.ba...@arnes.si
To: Itamar Heim ih...@redhat.com
Cc: users@ovirt.org , Yair Zaslavsky yzasl...@redhat.com ,
Oved
Ourfalli oourf...@redhat.com
Sent: Monday, March 18, 2013 9:07:06 AM
Subject: Re: [Users] ldap simple
Hi,
the system is trying to bind to ldap as:
bind request:
uid=cn=ovirt,cn=Users,cn=Accounts,dc=ourdomain,dc=si
I dont know how it knows dc=ourdomain,dc=si
It should be
bind request: cn=ovirt,ou=system,dc=ourdomain,dc=si -b
dc=arnes,dc=si
The same with the search: we have users in form as:
edupersonprincipalname=usern...@users.ourdomain.si
,dc=users,dc=ourdomain,dc=si
values in database:
select * from vdc_options where option_name in
('DomainName','LdapServers','LDAPSecurityAuthentication','LDAPProviderTypes','AdUserName','AdUserPassword')
order by option_id;
option_id | option_name | option_value | version
---+++-
10 | AdUserName | users.ourdomain.si:ovirt | general
11 | AdUserPassword |users.ourdomain.si:adminpassword | general
69 | DomainName | users.ourdomain.si | general
130 | LDAPSecurityAuthentication| users.ourdomain.si:SIMPLE |
general
132 | LdapServers | users.ourdomain.si:server.ourdomain.si |
general
133 | LDAPProviderTypes | users.ourdomain.si:rhds | general
(6 rows)
Best Regards,
Andrej Bagon
On 03/15/2013 12:09 PM, Itamar Heim wrote:
On 03/14/2013 01:58 PM, Andrej Bagon wrote:
Hi,
is it possible to change the bind request that is sent to the
ldap
server? The default
uid=user,cn=Users,cn=Accounts,cn=our,cn=domain
is
not suitable.
can you please explain why / what you would like to change it
to?
(not sure possible now, but there is work to make it more
configurable/pluggable)
___
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
Re: [Users] ldap simple
On 03/19/2013 05:26 PM, Yair Zaslavsky wrote:
Why openldap server?
We do not support openldap at the moment.
hopefully, the changes to auth part will make it for 3.3 to cover that,
but depends on progress there.
*From: *Jure Kranjc jure.kra...@arnes.si
*To: *users@ovirt.org
*Sent: *Tuesday, March 19, 2013 3:50:49 PM
*Subject: *Re: [Users] ldap simple
Hi.
Further testing...
- Setup: one ldap server with added user to match ovirt searches
(while adding user in webadmin),
- Fedora 18, engine 3.2.1, openldap-server, simple authentication,
no firewalls,
- with packet inspection we can see ldap responding with requested
attributes
- still, there are errors in logs, see below, and no users are
listed in webadmin, engine fails to parse given attributes
- engine-manage-domains -action=validate returns Invalid
credentials even though binding is ok and ldap is replying with data.
Can anyone point us to some documentation on this topic?
Is really AD the only good solution for user management?
engine.log
2013-03-19 15:16:53,042 ERROR
[org.ovirt.engine.core.bll.adbroker.LDAPTemplateWrapper]
(ajp--127.0.0.1-8702-3) Error in running LDAP query. BaseDN is ,
filter is (((objectClass=person))
(|(givenname=test)(sn=test)(uid=test)(uid=test))). Exception message
is: null
2013-03-19 15:16:53,043 ERROR
[org.ovirt.engine.core.bll.adbroker.DirectorySearcher]
(ajp--127.0.0.1-8702-3) Failed ldap search server
ldap://ldaphost.domain.si:389 due to null. We should try the next server
server.log
2013-03-19 15:17:24,113 ERROR
[org.springframework.ldap.control.AbstractRequestControlDirContextProcessor]
(ajp--127.0.0.1-8702-6) No matching response control found for paged
results - looking for 'class
javax.naming.ldap.PagedResultsResponseControl
On 03/18/2013 09:09 AM, Yair Zaslavsky wrote:
Hi,
We're issuing a RootDSE query (once per LDAP domain configured).
We try to obtain from it the defaultNamingContext attribute.
If does not exist - we try to obtain NamingContexts
We store the result at a domainDn (we have a data structure
which maps domains to information objects, one of the fields at
the information object is the DN of the domain) field, and we
use it to compose the full ldap URL we send the queries to.
*From: *Andrej Bagon andrej.ba...@arnes.si
*To: *Itamar Heim ih...@redhat.com
*Cc: *users@ovirt.org, Yair Zaslavsky
yzasl...@redhat.com, Oved Ourfalli oourf...@redhat.com
*Sent: *Monday, March 18, 2013 9:07:06 AM
*Subject: *Re: [Users] ldap simple
Hi,
the system is trying to bind to ldap as:
bind request:
uid=cn=ovirt,cn=Users,cn=Accounts,dc=ourdomain,dc=si
I dont know how it knows dc=ourdomain,dc=si
It should be
bind request: cn=ovirt,ou=system,dc=ourdomain,dc=si -b
dc=arnes,dc=si
The same with the search: we have users in form as:
edupersonprincipalname=usern...@users.ourdomain.si
mailto:edupersonprincipalname=aba...@guest.arnes.si,dc=users,dc=ourdomain,dc=si
values in database:
select * from vdc_options where option_name in
('DomainName','LdapServers','LDAPSecurityAuthentication','LDAPProviderTypes','AdUserName','AdUserPassword')
order by option_id;
option_id |option_name |
option_value | version
---+++-
10 | AdUserName |
users.ourdomain.si:ovirt | general
11 | AdUserPassword
|users.ourdomain.si:adminpassword | general
69 | DomainName |
users.ourdomain.si | general
130 | LDAPSecurityAuthentication|
users.ourdomain.si:SIMPLE | general
132 | LdapServers|
users.ourdomain.si:server.ourdomain.si | general
133 | LDAPProviderTypes |
users.ourdomain.si:rhds| general
(6 rows)
Best Regards,
Andrej Bagon
On 03/15/2013 12:09 PM, Itamar Heim wrote:
On 03/14/2013 01:58 PM, Andrej Bagon wrote:
Hi,
is it possible to change the bind request that is
sent to the ldap
server? The default
uid=user,cn=Users,cn
Re: [Users] ldap simple
389 DS is so far working as expected. Thank you for your clarification,
somehow missed that out.
On 19.3.2013 21:56, Itamar Heim wrote:
On 03/19/2013 05:26 PM, Yair Zaslavsky wrote:
Why openldap server?
We do not support openldap at the moment.
hopefully, the changes to auth part will make it for 3.3 to cover
that, but depends on progress there.
*From: *Jure Kranjc jure.kra...@arnes.si
*To: *users@ovirt.org
*Sent: *Tuesday, March 19, 2013 3:50:49 PM
*Subject: *Re: [Users] ldap simple
Hi.
Further testing...
- Setup: one ldap server with added user to match ovirt searches
(while adding user in webadmin),
- Fedora 18, engine 3.2.1, openldap-server, simple authentication,
no firewalls,
- with packet inspection we can see ldap responding with requested
attributes
- still, there are errors in logs, see below, and no users are
listed in webadmin, engine fails to parse given attributes
- engine-manage-domains -action=validate returns Invalid
credentials even though binding is ok and ldap is replying with
data.
Can anyone point us to some documentation on this topic?
Is really AD the only good solution for user management?
engine.log
2013-03-19 15:16:53,042 ERROR
[org.ovirt.engine.core.bll.adbroker.LDAPTemplateWrapper]
(ajp--127.0.0.1-8702-3) Error in running LDAP query. BaseDN is ,
filter is (((objectClass=person))
(|(givenname=test)(sn=test)(uid=test)(uid=test))). Exception message
is: null
2013-03-19 15:16:53,043 ERROR
[org.ovirt.engine.core.bll.adbroker.DirectorySearcher]
(ajp--127.0.0.1-8702-3) Failed ldap search server
ldap://ldaphost.domain.si:389 due to null. We should try the next
server
server.log
2013-03-19 15:17:24,113 ERROR
[org.springframework.ldap.control.AbstractRequestControlDirContextProcessor]
(ajp--127.0.0.1-8702-6) No matching response control found for paged
results - looking for 'class
javax.naming.ldap.PagedResultsResponseControl
On 03/18/2013 09:09 AM, Yair Zaslavsky wrote:
Hi,
We're issuing a RootDSE query (once per LDAP domain configured).
We try to obtain from it the defaultNamingContext attribute.
If does not exist - we try to obtain NamingContexts
We store the result at a domainDn (we have a data structure
which maps domains to information objects, one of the fields at
the information object is the DN of the domain) field, and we
use it to compose the full ldap URL we send the queries to.
*From: *Andrej Bagon andrej.ba...@arnes.si
*To: *Itamar Heim ih...@redhat.com
*Cc: *users@ovirt.org, Yair Zaslavsky
yzasl...@redhat.com, Oved Ourfalli oourf...@redhat.com
*Sent: *Monday, March 18, 2013 9:07:06 AM
*Subject: *Re: [Users] ldap simple
Hi,
the system is trying to bind to ldap as:
bind request:
uid=cn=ovirt,cn=Users,cn=Accounts,dc=ourdomain,dc=si
I dont know how it knows dc=ourdomain,dc=si
It should be
bind request: cn=ovirt,ou=system,dc=ourdomain,dc=si -b
dc=arnes,dc=si
The same with the search: we have users in form as:
edupersonprincipalname=usern...@users.ourdomain.si
mailto:edupersonprincipalname=aba...@guest.arnes.si,dc=users,dc=ourdomain,dc=si
values in database:
select * from vdc_options where option_name in
('DomainName','LdapServers','LDAPSecurityAuthentication','LDAPProviderTypes','AdUserName','AdUserPassword')
order by option_id;
option_id |option_name |
option_value | version
---+++-
10 | AdUserName |
users.ourdomain.si:ovirt | general
11 | AdUserPassword
|users.ourdomain.si:adminpassword | general
69 | DomainName |
users.ourdomain.si | general
130 | LDAPSecurityAuthentication|
users.ourdomain.si:SIMPLE | general
132 | LdapServers|
users.ourdomain.si:server.ourdomain.si | general
133 | LDAPProviderTypes |
users.ourdomain.si:rhds| general
(6 rows)
Best Regards,
Andrej Bagon
On 03/15/2013 12:09 PM, Itamar Heim wrote:
On 03/14/2013 01:58 PM, Andrej Bagon wrote:
Hi,
is it possible to change the bind request that is
sent
Re: [Users] ldap simple
Hi,
the system is trying to bind to ldap as:
bind request: uid=cn=ovirt,cn=Users,cn=Accounts,dc=ourdomain,dc=si
I dont know how it knows dc=ourdomain,dc=si
It should be
bind request: cn=ovirt,ou=system,dc=ourdomain,dc=si -b dc=arnes,dc=si
The same with the search: we have users in form as:
edupersonprincipalname=usern...@users.ourdomain.si
mailto:edupersonprincipalname=aba...@guest.arnes.si,dc=users,dc=ourdomain,dc=si
values in database:
select * from vdc_options where option_name in
('DomainName','LdapServers','LDAPSecurityAuthentication','LDAPProviderTypes','AdUserName','AdUserPassword')
order by option_id;
option_id |option_name | option_value
| version
---+++-
10 | AdUserName |
users.ourdomain.si:ovirt | general
11 | AdUserPassword
|users.ourdomain.si:adminpassword | general
69 | DomainName | users.ourdomain.si
| general
130 | LDAPSecurityAuthentication|
users.ourdomain.si:SIMPLE | general
132 | LdapServers|
users.ourdomain.si:server.ourdomain.si | general
133 | LDAPProviderTypes |
users.ourdomain.si:rhds| general
(6 rows)
Best Regards,
Andrej Bagon
On 03/15/2013 12:09 PM, Itamar Heim wrote:
On 03/14/2013 01:58 PM, Andrej Bagon wrote:
Hi,
is it possible to change the bind request that is sent to the ldap
server? The default uid=user,cn=Users,cn=Accounts,cn=our,cn=domain is
not suitable.
can you please explain why / what you would like to change it to?
(not sure possible now, but there is work to make it more
configurable/pluggable)
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] ldap simple
Hi,
We're issuing a RootDSE query (once per LDAP domain configured).
We try to obtain from it the defaultNamingContext attribute.
If does not exist - we try to obtain NamingContexts
We store the result at a domainDn (we have a data structure which maps
domains to information objects, one of the fields at the information object is
the DN of the domain) field, and we use it to compose the full ldap URL we send
the queries to.
- Original Message -
From: Andrej Bagon andrej.ba...@arnes.si
To: Itamar Heim ih...@redhat.com
Cc: users@ovirt.org, Yair Zaslavsky yzasl...@redhat.com, Oved
Ourfalli oourf...@redhat.com
Sent: Monday, March 18, 2013 9:07:06 AM
Subject: Re: [Users] ldap simple
Hi,
the system is trying to bind to ldap as:
bind request: uid=cn=ovirt,cn=Users,cn=Accounts,dc=ourdomain,dc=si
I dont know how it knows dc=ourdomain,dc=si
It should be
bind request: cn=ovirt,ou=system,dc=ourdomain,dc=si -b
dc=arnes,dc=si
The same with the search: we have users in form as:
edupersonprincipalname=usern...@users.ourdomain.si
,dc=users,dc=ourdomain,dc=si
values in database:
select * from vdc_options where option_name in
('DomainName','LdapServers','LDAPSecurityAuthentication','LDAPProviderTypes','AdUserName','AdUserPassword')
order by option_id;
option_id | option_name | option_value | version
---+++-
10 | AdUserName | users.ourdomain.si:ovirt | general
11 | AdUserPassword |users.ourdomain.si:adminpassword | general
69 | DomainName | users.ourdomain.si | general
130 | LDAPSecurityAuthentication| users.ourdomain.si:SIMPLE | general
132 | LdapServers | users.ourdomain.si:server.ourdomain.si | general
133 | LDAPProviderTypes | users.ourdomain.si:rhds | general
(6 rows)
Best Regards,
Andrej Bagon
On 03/15/2013 12:09 PM, Itamar Heim wrote:
On 03/14/2013 01:58 PM, Andrej Bagon wrote:
Hi,
is it possible to change the bind request that is sent to the
ldap
server? The default
uid=user,cn=Users,cn=Accounts,cn=our,cn=domain
is
not suitable.
can you please explain why / what you would like to change it to?
(not sure possible now, but there is work to make it more
configurable/pluggable)
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] ldap simple
On 03/14/2013 01:58 PM, Andrej Bagon wrote: Hi, is it possible to change the bind request that is sent to the ldap server? The default uid=user,cn=Users,cn=Accounts,cn=our,cn=domain is not suitable. can you please explain why / what you would like to change it to? (not sure possible now, but there is work to make it more configurable/pluggable) ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] LDAP SimpleAuthentication issue.
On 02/27/2012 09:11 PM, Sharad Mishra wrote:
On Fri, 2012-02-24 at 22:19 +0200, Yair Zaslavsky wrote:
On 02/24/2012 09:19 PM, Sharad Mishra wrote:
Hi,
I am new to ovirt and LDAP. Looking at adding support for Tivoli
Directory Server. Here is a small java/jndi program (not using Spring
LDAP) that takes IBM intranet Id and searches the directory to return
IBM serial number.
Hi Sharard, welcome aboard.
First of all, although this can be found in our mailing list, I would
like to point you that currently Roy Golan (rgolan at redhat dot com),
Oved ourfali (ovedo at redhat dot com) and myself are the people that
work mostly on ldap/authentication issues at engine-core - so feel free
to ask us questions.
In addition, I would like to give you a WIKI to help that will give you
some getting started info (This WIKI was written by Oved) -
http://ovirt.org/wiki/DomainInfrastructure
Yair, Thanks for your prompt reply. I did find a link to above wiki page
in one of Oved's earlier post on this mailing list. I found the
documentation very helpful.
*
Hashtable env = new Hashtable();
env.put(java.naming.factory.initial,
com.sun.jndi.ldap.LdapCtxFactory);
env.put(java.naming.factory.url.pkgs, com.ibm.jndi);
env.put(java.naming.provider.url,
ldap://ldap-server:389);
String dn = null;
try{
InitialDirContext dirContext = new
InitialDirContext(env);
SearchControls constraints = new
SearchControls();
String[] attr = new String[] {uid};
constraints.setSearchScope(SearchControls.SUBTREE_SCOPE);
constraints.setReturningAttributes(attr);
NamingEnumeration ne =
dirContext.search(ou=ldpap-server-name,o=ibm.com,
(mail= + intranetID + ),
constraints);
**
But when I try to use
org.ovirt.engine.core.utils.ipa.SimpleAuthenticationCheck.java, I get a
javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid
Credentials]
I am issuing - ldapTemplate.search(, , contextMapper);
Where contextMapper is RHDSUserContextMapper and
screenshots of ldapTemplate are attached.
As you willl probably see in Oved's WIKI, you don't need to provide
RHDSUserContextMapper - the name may be misleading, but this class is
for RedHat DS directory service - I think you need to have context
mappers for IBM Tivoli DS.
In addition you will have to add your own provider type, as can be seen
for example in GetRootDSE java (we send a ROOT DSE query in order to
understand what is our provider type, as currently engine-core
supports more than one type of DS.
Yes, I understand that there will be much more code changes to add
support for a new LDAP server. But my this post was to find the reason
for AuthenticationException.
There may be issues with the way I have setup filter and baseDN; but
that should not give AuthEx. At this time I am looking for ways to get
rid of authentication exception. Also, when using simple authentication,
why do I need to give password? I can run ldapsearch -LLL
(mail=intranetID) -h ldap-server:389 -x without password to give
me expected results.
This is a good question - I admit I did not work thoroughly enough with
SIMPLE authentication - maybe we can bypass this.
I looked at the code of this class - it uses Spring-LDAP
LdapContextSource class which extends AbstractContextSource which uses
SimpleDirContextAuthenticationStrategy as the default authentication
strategy - so I guess that playing with the code of this example, and
ignoring the password may work for you.
Thanks for the hint. While playing with AbstractContextSource class, I
was able to find the property AnonymousReadOnly. Setting it to 'true'
eliminated the AuthEx.
Sharad,
I actually wasn't aware to this option in AbstractContextSource.
If spring-ldap does not have an LdapContextSource subclass that sets
this property , maybe you can create your own subclass
(AnoymousReadOnlyContextSource extends LdapContextSource) and set this
property in its code - and then you can use it in
SimpleAuthenticationCheck, and also in our engine-core code at
PrepareLdapConntectionTask -
In this class we create the context source. Perhaps we can add some
configuration indicating whether to perform AnonymousReadOnly or not,
using our Config infra (See org.ovirt.engine.core.common.config.Config
and its usages).
Yair
Regards,
Sharad Mishra
IBM
I would like to also point out that when I look at Spring-LDAP's
SimpleDirContextAuthenticationStrategy I it does set
env.put(Context.SECURITY_CREDENTIALS, password) (look at public void
setupEnvironment method ) - so what I have in mind is that you might
need to create your own AuthenticationStrategy - see for example
Re: [Users] LDAP SimpleAuthentication issue.
On Fri, 2012-02-24 at 22:19 +0200, Yair Zaslavsky wrote:
On 02/24/2012 09:19 PM, Sharad Mishra wrote:
Hi,
I am new to ovirt and LDAP. Looking at adding support for Tivoli
Directory Server. Here is a small java/jndi program (not using Spring
LDAP) that takes IBM intranet Id and searches the directory to return
IBM serial number.
Hi Sharard, welcome aboard.
First of all, although this can be found in our mailing list, I would
like to point you that currently Roy Golan (rgolan at redhat dot com),
Oved ourfali (ovedo at redhat dot com) and myself are the people that
work mostly on ldap/authentication issues at engine-core - so feel free
to ask us questions.
In addition, I would like to give you a WIKI to help that will give you
some getting started info (This WIKI was written by Oved) -
http://ovirt.org/wiki/DomainInfrastructure
Yair, Thanks for your prompt reply. I did find a link to above wiki page
in one of Oved's earlier post on this mailing list. I found the
documentation very helpful.
*
Hashtable env = new Hashtable();
env.put(java.naming.factory.initial,
com.sun.jndi.ldap.LdapCtxFactory);
env.put(java.naming.factory.url.pkgs, com.ibm.jndi);
env.put(java.naming.provider.url,
ldap://ldap-server:389);
String dn = null;
try{
InitialDirContext dirContext = new
InitialDirContext(env);
SearchControls constraints = new
SearchControls();
String[] attr = new String[] {uid};
constraints.setSearchScope(SearchControls.SUBTREE_SCOPE);
constraints.setReturningAttributes(attr);
NamingEnumeration ne =
dirContext.search(ou=ldpap-server-name,o=ibm.com,
(mail= + intranetID + ),
constraints);
**
But when I try to use
org.ovirt.engine.core.utils.ipa.SimpleAuthenticationCheck.java, I get a
javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid
Credentials]
I am issuing - ldapTemplate.search(, , contextMapper);
Where contextMapper is RHDSUserContextMapper and
screenshots of ldapTemplate are attached.
As you willl probably see in Oved's WIKI, you don't need to provide
RHDSUserContextMapper - the name may be misleading, but this class is
for RedHat DS directory service - I think you need to have context
mappers for IBM Tivoli DS.
In addition you will have to add your own provider type, as can be seen
for example in GetRootDSE java (we send a ROOT DSE query in order to
understand what is our provider type, as currently engine-core
supports more than one type of DS.
Yes, I understand that there will be much more code changes to add
support for a new LDAP server. But my this post was to find the reason
for AuthenticationException.
There may be issues with the way I have setup filter and baseDN; but
that should not give AuthEx. At this time I am looking for ways to get
rid of authentication exception. Also, when using simple authentication,
why do I need to give password? I can run ldapsearch -LLL
(mail=intranetID) -h ldap-server:389 -x without password to give
me expected results.
This is a good question - I admit I did not work thoroughly enough with
SIMPLE authentication - maybe we can bypass this.
I looked at the code of this class - it uses Spring-LDAP
LdapContextSource class which extends AbstractContextSource which uses
SimpleDirContextAuthenticationStrategy as the default authentication
strategy - so I guess that playing with the code of this example, and
ignoring the password may work for you.
Thanks for the hint. While playing with AbstractContextSource class, I
was able to find the property AnonymousReadOnly. Setting it to 'true'
eliminated the AuthEx.
Regards,
Sharad Mishra
IBM
I would like to also point out that when I look at Spring-LDAP's
SimpleDirContextAuthenticationStrategy I it does set
env.put(Context.SECURITY_CREDENTIALS, password) (look at public void
setupEnvironment method ) - so what I have in mind is that you might
need to create your own AuthenticationStrategy - see for example
org.ovirt.engine.core.bll.adbroker.GSSAPIDirContextAuthenticationStrategy -
an authentication strategy that Oved, Roy and myself worked on to
support kerberos/GSS-API authentication with Spring-LDAP.
You will have to call after you implement such strategy a call to
context.setAuthenticationStategy with your implemented
AuthenticationStategy (for example, I think it can be placed after the
line of - LdapContextSource context = new LdapContextSource(); at
SimpleAuthenticationCheck.java
I think I gave you some pointers here,
Feel free to ask more questions
Yair
Thanks
Sharad Mishra
IBM
Re: [Users] LDAP
On 02/26/2012 12:57 PM, Oved Ourfalli wrote: - Original Message - From: Yaniv Kaul yk...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com Cc: Oved Ourfalli ov...@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 Strattonnat...@robotics.net To: Oved Ourfalliov...@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 -Ddistinguished name of the username -hldap 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: ad...@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
Re: [Users] LDAP
- Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Oved Ourfalli ov...@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 yk...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com Cc: Oved Ourfalli ov...@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. I agree with it. It looks to me like the right way to go. Thank you, Oved - Original Message - From: Nathan Strattonnat...@robotics.net To: Oved Ourfalliov...@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 -Ddistinguished name of the username -hldap 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: ad...@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
Re: [Users] LDAP
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 nat...@robotics.net To: Oved Ourfalli ov...@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: ad...@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 nat...@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 +] conn=144 op=3 SRCH base=dc=blinkmind,dc=net scope=2 filter=((samaccounttype=805306368)(userprincipalname=nat...@blinkmind.net)) attrs=nsUniqueId ipaUniqueID objectguid objectClass javaSerializedData javaClassName javaFactory javaCodebase javaReferenceAddress
Re: [Users] LDAP
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 nat...@robotics.net To: Oved Ourfalli ov...@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: ad...@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 nat...@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 +] conn=144 op=3 SRCH base=dc=blinkmind,dc=net scope=2 filter=((samaccounttype=805306368)(userprincipalname=nat...@blinkmind.net)) attrs=nsUniqueId ipaUniqueID
Re: [Users] LDAP
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 nat...@robotics.net To: Oved Ourfalli ov...@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: ad...@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 nat...@blinkmind.net. Trying next LDAP server in list Failure while testing domain blinkmind.net. Details: No user information was found for user On my
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. Thank you, Oved - Original Message - From: Nathan Strattonnat...@robotics.net To: Oved Ourfalliov...@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 -Ddistinguished name of the username -hldap 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: ad...@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 nat...@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
Re: [Users] LDAP
On 02/23/2012 08:26 PM, Oved Ourfalli wrote: - Original Message - From: Nathan Stratton nat...@robotics.net To: Oved Ourfalli ov...@redhat.com Cc: users@ovirt.org, Yaniv Kaul yk...@redhat.com Sent: Thursday, February 23, 2012 8:13:33 PM Subject: Re: [Users] LDAP On Thu, 23 Feb 2012, Oved Ourfalli wrote: IIRC, we only support using -interactive or using -passwordFile, and not both. The fact that you don't get a warning on that is a bug. :) Opps. Found this blog with a similar error that is caused due to password expiration (in the engine log, and not while running the manage domains utility, but that might also help): http://blog.rtfm.co.hu/2012/02/rhev-error-from-kerberos-integrity-check-on-decrypted-field-failed/ But the information there doesn't go very well with the fact that kinit is successful. Ya, I saw that also, (been doing a lot of googling), but: -bash-4.2# kinit nathan Password for nat...@blinkmind.net: -bash-4.2# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: nat...@blinkmind.net Valid starting ExpiresService principal 02/23/12 12:07:21 02/24/12 12:07:16 krbtgt/blinkmind@blinkmind.net renew until 03/01/12 12:07:16 Is the file containing the correct password? Try using only -interactive, and enter the password interactively. Yep, the password is correct, I get the same error no matter what password I use. However when I try with -interactive I get more debug info (see below). Also, attaching the log of the utility might be helpful. How would I get that? I don't see anyting anywhere in /var/log/* It should be in /var/log/ovirt-engine/engine-manage-domains/engine-manage-domains.log (or in /var/log/engine/engine-manage-domains/engine-manage-domains.log... not sure). Also, try logging in with that user to the IPA machine, that way you'll know if you need to change your password (I saw that sometimes kinit doesn't ask you to change the password, but logging in does). Yep, that works fine. If I do it with -interactive I get the errors below. It seams to have an issue with DNS, but yet it is pulling the two SRV records AND hitting the right servers. Also both ovirt-engine and ipa-master have forward and reverse dns and proper /etc/hosts files. -bash-4.2# engine-manage-domains -action=add -domain=blinkmind.net -user=nathan -interactive Enter password: javax.naming.AuthenticationException: GSSAPI [Root exception is javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7) - UNKNOWN_SERVER)]] at com.sun.jndi.ldap.sasl.LdapSasl.saslBind(LdapSasl.java:168) at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:232) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2685) at com.sun.jndi.ldap.LdapCtx.init(LdapCtx.java:306) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305) at javax.naming.InitialContext.init(InitialContext.java:240) at javax.naming.InitialContext.init(InitialContext.java:214) at javax.naming.directory.InitialDirContext.init(InitialDirContext.java:99) at org.ovirt.engine.core.utils.kerberos.JndiAction.run(JndiAction.java:78) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:357) at org.ovirt.engine.core.utils.kerberos.KerberosConfigCheck.promptSuccessfulAuthentication(KerberosConfigCheck.java:174) at org.ovirt.engine.core.utils.kerberos.KerberosConfigCheck.validateKerberosInstallation(KerberosConfigCheck.java:154) at org.ovirt.engine.core.utils.kerberos.KerberosConfigCheck.checkInstallation(KerberosConfigCheck.java:140) at org.ovirt.engine.core.utils.kerberos.ManageDomains.checkKerberosConfiguration(ManageDomains.java:563) at org.ovirt.engine.core.utils.kerberos.ManageDomains.testConfiguration(ManageDomains.java:709) at org.ovirt.engine.core.utils.kerberos.ManageDomains.addDomain(ManageDomains.java:404) at org.ovirt.engine.core.utils.kerberos.ManageDomains.runCommand(ManageDomains.java:235) at org.ovirt.engine.core.utils.kerberos.ManageDomains.main(ManageDomains.java:163) Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7) - UNKNOWN_SERVER)] Not sure if help is still needed in this issue (krb error code
Re: [Users] LDAP
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 +] 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=X 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 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] LDAP
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=nat...@bblinkmind.net So I guess the filter should look like - ((objectClass=krbPrincipalAux)(krbPrincipalName=nat...@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=nat...@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 StrattonCTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.nethttp://www.blinkmind.com ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] LDAP
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=nat...@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=nat...@blinkmind.net)) -h localhost # extended LDIF # # LDAPv3 # base dc=blinkmind,dc=net with scope subtree # filter: ((objectClass=krbPrincipalAux)(krbPrincipalName=nat...@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: nat...@blinkmind.net givenName: Nathan uid: nathan initials: NS uidNumber: 33344 gidNumber: 33344 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 StrattonCTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.nethttp://www.blinkmind.com ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] LDAP
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=nat...@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=nat...@blinkmind.net)) -h localhost # extended LDIF # # LDAPv3 # base dc=blinkmind,dc=net with scope subtree # filter: ((objectClass=krbPrincipalAux)(krbPrincipalName=nat...@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: nat...@blinkmind.net givenName: Nathan uid: nathan initials: NS uidNumber: 33344 gidNumber: 33344 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 StrattonCTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.nethttp://www.blinkmind.com ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] LDAP SimpleAuthentication issue.
On 02/24/2012 09:19 PM, Sharad Mishra wrote:
Hi,
I am new to ovirt and LDAP. Looking at adding support for Tivoli
Directory Server. Here is a small java/jndi program (not using Spring
LDAP) that takes IBM intranet Id and searches the directory to return
IBM serial number.
Hi Sharard, welcome aboard.
First of all, although this can be found in our mailing list, I would
like to point you that currently Roy Golan (rgolan at redhat dot com),
Oved ourfali (ovedo at redhat dot com) and myself are the people that
work mostly on ldap/authentication issues at engine-core - so feel free
to ask us questions.
In addition, I would like to give you a WIKI to help that will give you
some getting started info (This WIKI was written by Oved) -
http://ovirt.org/wiki/DomainInfrastructure
*
Hashtable env = new Hashtable();
env.put(java.naming.factory.initial,
com.sun.jndi.ldap.LdapCtxFactory);
env.put(java.naming.factory.url.pkgs, com.ibm.jndi);
env.put(java.naming.provider.url,
ldap://ldap-server:389);
String dn = null;
try{
InitialDirContext dirContext = new
InitialDirContext(env);
SearchControls constraints = new
SearchControls();
String[] attr = new String[] {uid};
constraints.setSearchScope(SearchControls.SUBTREE_SCOPE);
constraints.setReturningAttributes(attr);
NamingEnumeration ne =
dirContext.search(ou=ldpap-server-name,o=ibm.com,
(mail= + intranetID + ),
constraints);
**
But when I try to use
org.ovirt.engine.core.utils.ipa.SimpleAuthenticationCheck.java, I get a
javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid
Credentials]
I am issuing - ldapTemplate.search(, , contextMapper);
Where contextMapper is RHDSUserContextMapper and
screenshots of ldapTemplate are attached.
As you willl probably see in Oved's WIKI, you don't need to provide
RHDSUserContextMapper - the name may be misleading, but this class is
for RedHat DS directory service - I think you need to have context
mappers for IBM Tivoli DS.
In addition you will have to add your own provider type, as can be seen
for example in GetRootDSE java (we send a ROOT DSE query in order to
understand what is our provider type, as currently engine-core
supports more than one type of DS.
There may be issues with the way I have setup filter and baseDN; but
that should not give AuthEx. At this time I am looking for ways to get
rid of authentication exception. Also, when using simple authentication,
why do I need to give password? I can run ldapsearch -LLL
(mail=intranetID) -h ldap-server:389 -x without password to give
me expected results.
This is a good question - I admit I did not work thoroughly enough with
SIMPLE authentication - maybe we can bypass this.
I looked at the code of this class - it uses Spring-LDAP
LdapContextSource class which extends AbstractContextSource which uses
SimpleDirContextAuthenticationStrategy as the default authentication
strategy - so I guess that playing with the code of this example, and
ignoring the password may work for you.
I would like to also point out that when I look at Spring-LDAP's
SimpleDirContextAuthenticationStrategy I it does set
env.put(Context.SECURITY_CREDENTIALS, password) (look at public void
setupEnvironment method ) - so what I have in mind is that you might
need to create your own AuthenticationStrategy - see for example
org.ovirt.engine.core.bll.adbroker.GSSAPIDirContextAuthenticationStrategy -
an authentication strategy that Oved, Roy and myself worked on to
support kerberos/GSS-API authentication with Spring-LDAP.
You will have to call after you implement such strategy a call to
context.setAuthenticationStategy with your implemented
AuthenticationStategy (for example, I think it can be placed after the
line of - LdapContextSource context = new LdapContextSource(); at
SimpleAuthenticationCheck.java
I think I gave you some pointers here,
Feel free to ask more questions
Yair
Thanks
Sharad Mishra
IBM
___
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
Re: [Users] LDAP
On 02/22/2012 11:02 PM, Nathan Stratton wrote: On Wed, 22 Feb 2012, Oved Ourfalli wrote: Hey, This error usually happens where there is no krb5.conf file, or there is one, but your domain isn't in that. The krb5.conf file should be located in $JBOSS_HOME/standalone/configuration directory. Ya, I gave up on the 389/Kerberos, looking at FreeIPA now. BTW, why can't we just use LDAP??? well, this goes to history, as ovirt was ported from a C# solution focused that evolved to server virtualization from VDI (virtual desktops). virtual desktops were mostly windows. so integration with AD was a must, and was based on kerberos (in C#) java port first supported backward compatibility. nothing prevents adding LDAP support, but it probably requires supporting multiple LDAP redundant servers and SSL. btw, the code for basic LDAP (WITHOUT SECURITY) may still work, if you change the authentication type to SIMPLE. but it is never discussed as a deployment option, as it is not secure. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] LDAP
On Sun, 19 Feb 2012, Itamar Heim wrote: On 02/19/2012 11:11 PM, Nathan Stratton wrote: On Sun, 19 Feb 2012, Itamar Heim wrote: the current code supports AD, freeIPA/IPA and 389ds/RHDS. if apache directory server is similar to any of them, you could try hacking the code to add support for it. Ok, will go with 389 for now, its in the family, tho Gluster is in the family and you don't support it as a storage file system... : ) please remember you need 389ds with kerberos support. Got it installed and setup, I am able to authenticate from linux boxes with the new 389 LDAP so I know that works. However still running into issues getting ovirt-engine to work with it. http://share.robotics.net/ldap.pcap As you can see from the pcap, I see a DNS SRV query for _ldap._tcp.blinkmind.net and the box does talk to the LDAP box. I don't see anyting on port 88, or a ldap query for the kerberos or does it try to just use the same IP as ldap? 2012-02-21 16:59:48,411 ERROR [org.ovirt.engine.core.bll.adbroker.DirectorySearcher] (http--0.0.0.0-8080-1) Failed ldap search server LDAP://ldap-master.hou.blinkmind.net:389 due to org.ovirt.engine.core.bll.adbroker.EngineDirectoryServiceException. We should not try the next server: org.ovirt.engine.core.bll.adbroker.EngineDirectoryServiceException at org.ovirt.engine.core.bll.adbroker.GSSAPIDirContextAuthenticationStrategy.authenticateToKDC(GSSAPIDirContextAuthenticationStrategy.java:150) [engine-bll.jar:] at org.ovirt.engine.core.bll.adbroker.GSSAPIDirContextAuthenticationStrategy.explicitAuth(GSSAPIDirContextAuthenticationStrategy.java:119) [engine-bll.jar:] at org.ovirt.engine.core.bll.adbroker.GSSAPIDirContextAuthenticationStrategy.authenticate(GSSAPIDirContextAuthenticationStrategy.java:111) [engine-bll.jar:] at org.ovirt.engine.core.bll.adbroker.GSSAPILdapTemplateWrapper.useAuthenticationStrategy(GSSAPILdapTemplateWrapper.java:90) [engine-bll.jar:] at org.ovirt.engine.core.bll.adbroker.PrepareLdapConnectionTask.call(PrepareLdapConnectionTask.java:56) [engine-bll.jar:] at org.ovirt.engine.core.bll.adbroker.DirectorySearcher$1.call(DirectorySearcher.java:108) [engine-bll.jar:] at org.ovirt.engine.core.bll.adbroker.DirectorySearcher$1.call(DirectorySearcher.java:97) [engine-bll.jar:] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [:1.6.0_22] at java.util.concurrent.FutureTask.run(FutureTask.java:166) [:1.6.0_22] at org.ovirt.engine.core.utils.threadpool.ThreadPoolUtil$InternalWrapperRunnable.run(ThreadPoolUtil.java:57) [utils-3.0.0-0001.jar:] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [:1.6.0_22] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [:1.6.0_22] at java.util.concurrent.FutureTask.run(FutureTask.java:166) [:1.6.0_22] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_22] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_22] at java.lang.Thread.run(Thread.java:679) [:1.6.0_22] 2012-02-21 16:59:48,415 ERROR [org.ovirt.engine.core.bll.adbroker.LdapAuthenticateUserCommand] (http--0.0.0.0-8080-1) Failed authenticating user: nathan to domain blinkmind.net. Ldap Query Type is getUserByName 2012-02-21 16:59:48,416 ERROR [org.ovirt.engine.core.bll.LoginAdminUserCommand] (http--0.0.0.0-8080-1) USER_FAILED_TO_AUTHENTICATE_NO_KDCS_FOUND : nathan 2012-02-21 16:59:48,416 WARN [org.ovirt.engine.core.bll.LoginAdminUserCommand] (http--0.0.0.0-8080-1) CanDoAction of action LoginAdminUser failed. Reasons:USER_FAILED_TO_AUTHENTICATE_NO_KDCS_FOUND ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] LDAP
- Original Message - From: Nathan Stratton nat...@robotics.net To: Itamar Heim ih...@redhat.com Cc: users@ovirt.org Sent: Wednesday, February 22, 2012 1:03:33 AM Subject: Re: [Users] LDAP On Sun, 19 Feb 2012, Itamar Heim wrote: On 02/19/2012 11:11 PM, Nathan Stratton wrote: On Sun, 19 Feb 2012, Itamar Heim wrote: the current code supports AD, freeIPA/IPA and 389ds/RHDS. if apache directory server is similar to any of them, you could try hacking the code to add support for it. Ok, will go with 389 for now, its in the family, tho Gluster is in the family and you don't support it as a storage file system... : ) please remember you need 389ds with kerberos support. Got it installed and setup, I am able to authenticate from linux boxes with the new 389 LDAP so I know that works. However still running into issues getting ovirt-engine to work with it. http://share.robotics.net/ldap.pcap As you can see from the pcap, I see a DNS SRV query for _ldap._tcp.blinkmind.net and the box does talk to the LDAP box. I don't see anyting on port 88, or a ldap query for the kerberos or does it try to just use the same IP as ldap? 2012-02-21 16:59:48,411 ERROR [org.ovirt.engine.core.bll.adbroker.DirectorySearcher] (http--0.0.0.0-8080-1) Failed ldap search server LDAP://ldap-master.hou.blinkmind.net:389 due to org.ovirt.engine.core.bll.adbroker.EngineDirectoryServiceException. We should not try the next server: org.ovirt.engine.core.bll.adbroker.EngineDirectoryServiceException at org.ovirt.engine.core.bll.adbroker.GSSAPIDirContextAuthenticationStrategy.authenticateToKDC(GSSAPIDirContextAuthenticationStrategy.java:150) [engine-bll.jar:] at org.ovirt.engine.core.bll.adbroker.GSSAPIDirContextAuthenticationStrategy.explicitAuth(GSSAPIDirContextAuthenticationStrategy.java:119) [engine-bll.jar:] at org.ovirt.engine.core.bll.adbroker.GSSAPIDirContextAuthenticationStrategy.authenticate(GSSAPIDirContextAuthenticationStrategy.java:111) [engine-bll.jar:] at org.ovirt.engine.core.bll.adbroker.GSSAPILdapTemplateWrapper.useAuthenticationStrategy(GSSAPILdapTemplateWrapper.java:90) [engine-bll.jar:] at org.ovirt.engine.core.bll.adbroker.PrepareLdapConnectionTask.call(PrepareLdapConnectionTask.java:56) [engine-bll.jar:] at org.ovirt.engine.core.bll.adbroker.DirectorySearcher$1.call(DirectorySearcher.java:108) [engine-bll.jar:] at org.ovirt.engine.core.bll.adbroker.DirectorySearcher$1.call(DirectorySearcher.java:97) [engine-bll.jar:] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [:1.6.0_22] at java.util.concurrent.FutureTask.run(FutureTask.java:166) [:1.6.0_22] at org.ovirt.engine.core.utils.threadpool.ThreadPoolUtil$InternalWrapperRunnable.run(ThreadPoolUtil.java:57) [utils-3.0.0-0001.jar:] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [:1.6.0_22] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [:1.6.0_22] at java.util.concurrent.FutureTask.run(FutureTask.java:166) [:1.6.0_22] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_22] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_22] at java.lang.Thread.run(Thread.java:679) [:1.6.0_22] 2012-02-21 16:59:48,415 ERROR [org.ovirt.engine.core.bll.adbroker.LdapAuthenticateUserCommand] (http--0.0.0.0-8080-1) Failed authenticating user: nathan to domain blinkmind.net. Ldap Query Type is getUserByName 2012-02-21 16:59:48,416 ERROR [org.ovirt.engine.core.bll.LoginAdminUserCommand] (http--0.0.0.0-8080-1) USER_FAILED_TO_AUTHENTICATE_NO_KDCS_FOUND : nathan 2012-02-21 16:59:48,416 WARN [org.ovirt.engine.core.bll.LoginAdminUserCommand] (http--0.0.0.0-8080-1) CanDoAction of action LoginAdminUser failed. Reasons:USER_FAILED_TO_AUTHENTICATE_NO_KDCS_FOUND Hey, This error usually happens where there is no krb5.conf file, or there is one, but your domain isn't in that. The krb5.conf file should be located in $JBOSS_HOME/standalone/configuration directory. How did you configure the new domain? Using engine-manage-domains utility? Attaching the full server log and the krb5.conf file may help understand the problem. We query for LDAP SRV records in the engine. In the utility we also query for kerberos SRV records, and update the krb5.conf file accordingly. Then, the kerberos authentication uses the host updated in the krb5.conf file to perform the authentication. Oved ___ 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
Re: [Users] LDAP
On Sun, 19 Feb 2012, Yaniv Kaul wrote: Sorry, my fault - should have seen it earlier - we do not support OpenLDAP yet - we fail to parse its rootDSE, therefore do not have a way to proceed. I think there's a RFE for it somewhere filed, but if not, worth filing. Ouch, do you support Apache Directory Server? Nathan StrattonCTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.nethttp://www.blinkmind.com Y. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] LDAP
On 02/19/2012 10:30 PM, Nathan Stratton wrote: On Sun, 19 Feb 2012, Yaniv Kaul wrote: Sorry, my fault - should have seen it earlier - we do not support OpenLDAP yet - we fail to parse its rootDSE, therefore do not have a way to proceed. I think there's a RFE for it somewhere filed, but if not, worth filing. Ouch, do you support Apache Directory Server? Sorry Nathan, we do not support this one as well. Yair Nathan StrattonCTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.nethttp://www.blinkmind.com Y. ___ 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
Re: [Users] LDAP
Hey, More information on the domain infrastructure we have can be found in: http://www.ovirt.org/wiki/DomainInfrastructure (I might update it more soon, but it can give you a basic view of how the domain management in oVirt is working, and what do you need to update in order to support a new ldap provider). Oved - Original Message - From: Itamar Heim ih...@redhat.com To: Nathan Stratton nat...@robotics.net Cc: users@ovirt.org Sent: Sunday, February 19, 2012 11:14:24 PM Subject: Re: [Users] LDAP On 02/19/2012 11:11 PM, Nathan Stratton wrote: On Sun, 19 Feb 2012, Itamar Heim wrote: the current code supports AD, freeIPA/IPA and 389ds/RHDS. if apache directory server is similar to any of them, you could try hacking the code to add support for it. Ok, will go with 389 for now, its in the family, tho Gluster is in the family and you don't support it as a storage file system... : ) please remember you need 389ds with kerberos support. gluster is in the works... see: http://www.ovirt.org/wiki/AddingGlusterSupportToOvirt Just kidding, you guys are great, keep up the good work. 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
