[prev in list] [next in list] [prev in thread] [next in thread]
List: opensolaris-sysadmin-discuss
Subject: Re: [sysadmin-discuss] Solaris LDAP client and password checking?
From: Luke Scharf <lscharf () vt ! edu>
Date: 2007-03-28 20:59:23
Message-ID: 460AD778.9040208 () vt ! edu
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
[Attachment #4 (multipart/alternative)]
Iain MacDonnell wrote:
>
>
> Luke Scharf wrote on 03/27/07 03:05 PM:
>> I have an LDAP server running that holds user accounts, groups, and
>> other typical data.
>>
>> It works well with Linux and Mac OS X clients. In fact, the master
>> server is running Mac OS X, and the slave/backup server is running
>> Linux with OpenLDAP (and some schema additions). The password hashes
>> are stored in the shadowAccount's userPassword attribute.
>>
>> This setup works great for the Linux and Mac OS X clients.
>>
>> I set up my Solaris client with the following ldapclient command:
>>
>> [solarisclient]# ldapclient manual \
>> -a credentialLevel=anonymous \
>> -a authenticationMethod=none \
>> -a defaultSearchBase='dc=XXXX,dc=vt,dc=edu' \
>> -a
>> serviceSearchDescriptor='passwd:cn=users,dc=tcf-int,dc=vt,dc=edu' \
>> -a
>> serviceSearchDescriptor='group:cn=groups,dc=tcf-int,dc=vt,dc=edu' \
>> -a defaultServerList='10.X.X.5 10.X.X.6' \
>> -a domainName='XXXX.vt.edu'
>>
>>
>> When I run "getent passwd" on the Solaris client, I get the userlist
>> that I expected. The password hash field is, of course, contains an
>> "x" for each user.
>>
>> However, when I try to ssh into the machine as a regular user, or run
>> "su - user1" then "su - user2", the password is never authenticated.
>>
>> I've run a packet sniffer (Ethereal/Wireshark) on the LDAP server (my
>> server, my client, my test account, all on a private network), I see
>> the LDAP query is issued. The Solaris client asks for the
>> userPassword attribute, and the server answers saying that the
>> userPassword: attribute is a bunch of asterisks. The server does not
>> return the hash.
>>
>> Is there a way to tell Solaris to check the user's password by
>> attempting to bind to the LDAP server? I could then leave the ACLs
>> as-is, and I could also use whatever hash format my server can
>> interpret for the userPassword.
>
> Yes, pam_ldap(5) can do that. You need to wire that into your
> pam.conf(4). One approach is to find every line like:
>
> <service> auth required pam_unix_auth.so.1
>
> and replace it with:
>
> <service> auth sufficient pam_unix_auth.so.1
> <service> auth required pam_ldap.so.1
That did the trick! For others with a similar issue or others who may
be monitoring the listserv, the changes that I made to my /etc/pam.conf
are as follows:
23c23,24
< login auth required pam_unix_auth.so.1
---
> login auth binding pam_unix_auth.so.1 server_policy
> login auth required pam_ldap.so.1
32c33,34
< rlogin auth required pam_unix_auth.so.1
---
> rlogin auth binding pam_unix_auth.so.1 server_policy
> rlogin auth required pam_ldap.so.1
38c40,41
< krlogin auth required pam_unix_auth.so.1
---
> krlogin auth binding pam_unix_auth.so.1 server_policy
> krlogin auth required pam_ldap.so.1
50c53,54
< krsh auth required pam_unix_auth.so.1
---
> krsh auth binding pam_unix_auth.so.1 server_policy
> krsh auth required pam_ldap.so.1
56c60,61
< ktelnet auth required pam_unix_auth.so.1
---
> ktelnet auth binding pam_unix_auth.so.1 server_policy
> ktelnet auth required pam_ldap.so.1
63c68,69
< ppp auth required pam_unix_auth.so.1
---
> ppp auth binding pam_unix_auth.so.1 server_policy
> ppp auth required pam_ldap.so.1
72c78,79
< other auth required pam_unix_auth.so.1
---
> other auth binding pam_unix_auth.so.1 server_policy
> other auth required pam_ldap.so.1
76c83,84
< passwd auth required pam_passwd_auth.so.1
---
> passwd auth binding pam_passwd_auth.so.1 server_policy
> passwd auth required pam_ldap.so.1
86c94,95
< other account required pam_unix_account.so.1
---
> other account binding pam_unix_account.so.1 server_policy
> other account required pam_ldap.so.1
Now all that's left is to see why the proxy user, root, and the
update-user can bind to my slave-server -- but my everyday account can't
bind to my slave-server.... But that's an OpenLDAP problem and not a
Solaris problem!
Thanks,
-Luke
[Attachment #7 (text/html)]
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Iain MacDonnell wrote:
<blockquote cite="mid460A8FC7.8000504@Sun.COM" type="cite"><br>
<br>
Luke Scharf wrote on 03/27/07 03:05 PM:
<br>
<blockquote type="cite">I have an LDAP server running that holds user
accounts, groups, and other typical data.
<br>
<br>
It works well with Linux and Mac OS X clients. In fact, the master
server is running Mac OS X, and the slave/backup server is running
Linux with OpenLDAP (and some schema additions). The password hashes
are stored in the shadowAccount's userPassword attribute.
<br>
<br>
This setup works great for the Linux and Mac OS X clients.
<br>
<br>
I set up my Solaris client with the following ldapclient command:
<br>
<br>
[solarisclient]# ldapclient manual \
<br>
-a credentialLevel=anonymous \
<br>
-a authenticationMethod=none \
<br>
-a \
defaultSearchBase='dc=XXXX,dc=vt,dc=edu' \ <br>
-a
serviceSearchDescriptor='passwd:cn=users,dc=tcf-int,dc=vt,dc=edu' \
<br>
-a
serviceSearchDescriptor='group:cn=groups,dc=tcf-int,dc=vt,dc=edu' \
<br>
-a defaultServerList='10.X.X.5 10.X.X.6' \
<br>
-a domainName='XXXX.vt.edu'
<br>
<br>
<br>
When I run "getent passwd" on the Solaris client, I get the userlist
that I expected. The password hash field is, of course, contains an
"x" for each user.
<br>
<br>
However, when I try to ssh into the machine as a regular user, or run
"su - user1" then "su - user2", the password is never authenticated.
<br>
<br>
I've run a packet sniffer (Ethereal/Wireshark) on the LDAP server (my
server, my client, my test account, all on a private network), I see
the LDAP query is issued. The Solaris client asks for the userPassword
attribute, and the server answers saying that the userPassword:
attribute is a bunch of asterisks. The server does not return the
hash.
<br>
<br>
Is there a way to tell Solaris to check the user's password by
attempting to bind to the LDAP server? I could then leave the ACLs
as-is, and I could also use whatever hash format my server can
interpret for the userPassword.
<br>
</blockquote>
<br>
Yes, pam_ldap(5) can do that. You need to wire that into your
<br>
pam.conf(4). One approach is to find every line like:
<br>
<br>
<service> auth \
required pam_unix_auth.so.1 <br>
<br>
and replace it with:
<br>
<br>
<service> auth sufficient \
pam_unix_auth.so.1 <br>
<service> auth \
required pam_ldap.so.1 <br>
</blockquote>
<br>
<br>
That did the trick! For others with a similar issue or others who may
be monitoring the listserv, the changes that I made to my /etc/pam.conf
are as follows:<br>
<blockquote>
<pre>23c23,24
< login auth required pam_unix_auth.so.1
---
> login auth binding pam_unix_auth.so.1 server_policy
> login auth required pam_ldap.so.1
32c33,34
< rlogin auth required pam_unix_auth.so.1
---
> rlogin auth binding pam_unix_auth.so.1 server_policy
> rlogin auth required pam_ldap.so.1
38c40,41
< krlogin auth required pam_unix_auth.so.1
---
> krlogin auth binding pam_unix_auth.so.1 server_policy
> krlogin auth required pam_ldap.so.1
50c53,54
< krsh auth required pam_unix_auth.so.1
---
> krsh auth binding pam_unix_auth.so.1 server_policy
> krsh auth required pam_ldap.so.1
56c60,61
< ktelnet auth required pam_unix_auth.so.1
---
> ktelnet auth binding pam_unix_auth.so.1 server_policy
> ktelnet auth required pam_ldap.so.1
63c68,69
< ppp auth required pam_unix_auth.so.1
---
> ppp auth binding pam_unix_auth.so.1 server_policy
> ppp auth required pam_ldap.so.1
72c78,79
< other auth required pam_unix_auth.so.1
---
> other auth binding pam_unix_auth.so.1 server_policy
> other auth required pam_ldap.so.1
76c83,84
< passwd auth required pam_passwd_auth.so.1
---
> passwd auth binding pam_passwd_auth.so.1 server_policy
> passwd auth required pam_ldap.so.1
86c94,95
< other account required pam_unix_account.so.1
---
> other account binding pam_unix_account.so.1 server_policy
> other account required pam_ldap.so.1</pre>
</blockquote>
<br>
Now all that's left is to see why the proxy user, root, and the
update-user can bind to my slave-server -- but my everyday account
can't bind to my slave-server.... But that's an OpenLDAP problem and
not a Solaris problem!<br>
<br>
Thanks,<br>
-Luke<br>
<br>
</body>
</html>
["smime.p7s" (application/x-pkcs7-signature)]
_______________________________________________
sysadmin-discuss mailing list
sysadmin-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic