On Tue, Jun 07, 2005 at 12:00:34PM +0000, Thomas Mathiesen wrote:
> So, here's what I continued doing:
> Added a user (using the webinterface).
> Added objectclass posixAccount to this user (using GQ)
>
> Turning to my desktop, running Ubuntu Hoary and Openldap, I set it up using
> this ldap config:
> host ldap.mydomain.com
> base dc=mydomain,dc=com
> ldap_version 3
> timelimit 30
> pam_filter objectclass=posixAccount
> pam_login_attribute uid
> ssl no
> #ssl start_tls
> #tls_checkpeer no
> pam_password ssha
>
> I've tried to use ssl (and tls_checkpeer no), and no ssl.... nothing works.
>
> In my log on the fedora directory server, I see the connection, and it first
> tries to find the posixAccount, and returns no error. Then it looks for
> shadowAccount, and returns no error (after I added that objectclass as well).
>
> The client worked fine, authenticating with my previous openldap server... and
> I can't see why I doesn't authenticate with my new fedora server.
Can you give us some more details to go on? Are you using pam_ldap to
check passwords, or are you just using nss_ldap in combination with
pam_unix? What do your system logs indicate when the user's attempt to
authenticate fails?
If it's nss_ldap+pam_unix, can you read the userPassword attribute of
the user's posixAccount object when you bind to the directory
anonymously? For example, does this command give you any userPassword
values?
ldapsearch -x -h ldap.mydomain.com -b dc=mydomain,dc=com \
uid=username userPassword
My guess here is that you have an ACI on dc=mydomain,dc=com which allows
read access to any attribute except "userPassword" for anonymous users,
and because nss_ldap is binding to the directory anonymously on
pam_unix's behalf to read the attribute, pam_unix can't check passwords.
HTH,
Nalin
