[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: AW: LDAP proxy for AD -- still no solution
Hi,
I am using nss_base_passwd to tell ldap client about the location of user account.
I cannot see any user (getent password returns only the local users) and hence su also fails.
Here is my ldap.conf
uri ldap://hera2.research.phg.com.au/
base dc=internal,dc=phg,dc=com,dc=au
scope sub
bind_timelimit 15
timelimit 15
ssl no
referrals no
nss_base_passwd dc=internal,dc=phg,dc=com,dc=au?sub
nss_base_shadow dc=internal,dc=phg,dc=com,dc=au?sub
nss_base_group dc=internal,dc=phg,dc=com,dc=au?sub?&(objectCategory=group)(gidnumber=*)
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup group
nss_map_attribute gecos cn
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute uniqueMember member
nss_initgroups_ignoreusers root,ldap
pam_filter objectClass=posixAccount
pam_login_attribute uid
pam_lookup_policy no
Regards
Nazeer
-----Original Message-----
From: openldap-technical-bounces+nazeerm=phg.com.au@OpenLDAP.org [mailto:openldap-technical-bounces+nazeerm=phg.com.au@OpenLDAP.org] On Behalf Of Kick, Claus
Sent: Wednesday, 17 September 2008 5:54 PM
To: openldap-technical@openldap.org
Subject: AW: AW: LDAP proxy for AD -- still no solution
Hello,
(I do not have the thread beginning anymore, so I don't know your config anymore).
Do you have something like this:
NS_LDAP_SERVICE_SEARCH_DESC= group:ou=Group,o=xxxx
NS_LDAP_SERVICE_SEARCH_DESC= passwd:ou=People,o=xxxx
NS_LDAP_OBJECTCLASSMAP= group:posixGroup=posixGroup
In your ldap_client_file?
Sorry if this is a redundant question.
Other than that, does su to an ldap user work?
Cheers,
CLaus
-----Ursprüngliche Nachricht-----
Von: Nazeeruddin Mohammad [mailto:nazeerm@phg.com.au]
Gesendet: Mittwoch, 17. September 2008 07:40
An: openldap-technical@openldap.org
Cc: Kick, Claus; Buchan Milne
Betreff: RE: AW: LDAP proxy for AD -- still no solution
Thank you Claus and Buchan for your comments.
I tried your suggestions today. Even with the full access, I still cannot see any ldap users.
The basic search like the following command works; only id and getent fails.
ldapsearch -x -h ldapserver -LLL -b dc=internal,dc=phg,dc=com,dc=au '(uid=nazeerm)'
Thanks again.
Regards
Nazeer
-----Original Message-----
From: openldap-technical-bounces+nazeerm=phg.com.au@OpenLDAP.org [mailto:openldap-technical-bounces+nazeerm=phg.com.au@OpenLDAP.org] On Behalf Of Buchan Milne
Sent: Monday, 15 September 2008 9:44 PM
To: openldap-technical@openldap.org
Cc: Kick, Claus
Subject: Re: AW: LDAP proxy for AD -- still no solution
On Monday 15 September 2008 11:19:01 Kick, Claus wrote:
> Hello Nazeer,
>
> >Hi All,
> >I progressed further, but still haven't reached stage where I can use
>
> AD account.
>
> >Through, the proxy setup I could able to query ldap, but unable to use
>
> it for authentication. For example,
>
> >ldapsearch -x -h ldapserver -LLL -b dc=internal,dc=phg,dc=com,dc=au
>
> '(uid=nazeerm)'
>
> >is Successful, but id nazeerm fails (returns id: nazeerm: No such
>
> user).
>
> >Here is ldap.conf file on client machine.
>
> We had a similar problem (on Solaris though), the problem was that the
> ACLs for slapd were too tight.
>
> Bear in mind that we use OpenLDAP as internal user management tool (in a
> DMZ), so security isnt too much an issue.
>
> We now use:
>
> access to * by * read
>
> access to attrs=userpassword by self write by * read by anonymous auth
> access to dn.subtree="<subtree for the group mapping>" by * read by *
> write
This ACL set provides absolutely no security in the order they are above ...
>
> (I know this is partly redundant, never got to change it on the
> production system since we do not have downtimes very often).
>
> Access to userpassword was necessary for "su" commands to succeed.
Only if you didn't have PAM configured correctly on the LDAP clients.
> Access to the group subtree was necessary for getting the proper
> user-to-group mapping via the "id" or "getent" commands.
If you don't use a proxy user ...
> I would suggest to start with widely opened gates and then gradually
> closing them as far as you can.
I would suggest the other approach (open access as necessary, and definitely
don't use 'access to * by * read' as the first rule.
Regards,
Buchan
***************************************************************************
CAUTION: This email message and accompanying data may contain information
that is confidential and/or subject to legal privilege. If you are not the
intended recipient, you are notified that any use, dissemination,
distribution or copying of this message or data is prohibited.
If you have received this email message in error, please notify us
immediately and erase all copies of this message and attachments. Thank you.
***************************************************************************