opensolaris and openldap
Georg Klein
hi all
I a running a openldap environment where all our *nix boxes (Linux,
AIX) are authenticating against. Now I a trying to integrate some
Solaris and opensolaris boxes into that environment.
I did start with a opensolaris box using 'ldapclient -v manual ...' to
configure the box. It generates the /var/ldap/ldap_client_file and the
/var/ldap/ldap_client_cred files, including all the needed settings
(using the proxy mode and having defined ProxyDB and proxyPassword).
When restarting the ldap_cachemgr und nscd everything looks quite
well. I can conntect to ldap, I can query accounts and groups (with getent,
ldaplist, id) and all that stuff. I even can su to a user only in ldap
(getting the error, that the home directory does not exist). If I
craete the hoe directory manually, I can do a successfull su to that
local not available user and have correct uid, gid and group
memberships that are stored in ldap.
However, I am not able to login to that box via ssh. When debugging
that session on one of the openldap servers, I can see thet the box is
not binding to openldap with the configured proxyDN, but as anonymous.
So - for testing - I configured my openldap acls that way, that it
allows anonymous read of the userPassword-attribute: everthing was OK.
I could login to the machine via ssh and my password was accepted.
Changing back the acl settings - it did not work again. So in general
everything looks OK.
Further on I tested to bind as the configured ProxyDN: works too.
So the problem seems to be, that opensolaris is not going to bind as
the defined proxyuser but as anonymous. Am I missing something there?
Is there anything else that has to be configured?
A first try with Solaris 8 showed the same result.
I will check that stuff in the next days against a Solaris 10 and a
Solaris 8 box to make sure, that I am not running into a specific
problem of the opensolaris build. Any hint is welcome.
Thx in advance, Georg
Chris Ridd
> So the problem seems to be, that opensolaris is not going to bind as
> the defined proxyuser but as anonymous. Am I missing something there?
> Is there anything else that has to be configured?
The ldap client should not need to read your entry's userPassword
attribute. My userPassword is unreadable, and works OK on OpenSolaris
build 100, and also Solaris 10, and even Linux.
If memory serves the objectclasses found in your entry in the directory
affects the ldap client's behaviour.
Specifically I think the presence of "shadowAccount" in your entry
changes what the client tries to do. Try adding it and see. According
to RFC 2307 the only mandatory attribute it requires is uid, and that's
pretty likely to be in your entry already :-)
--
Chris
kangcool
Which opensolaris are you using?
ldap could be broke again
Georg Klein
Chris Ridd <chri...@mac.com> wrote:
> On 2008-11-03 20:59:58 +0000, Georg Klein <g...@ux.ennuie.org> said:
>
>> So the problem seems to be, that opensolaris is not going to bind as
>> the defined proxyuser but as anonymous. Am I missing something there?
>> Is there anything else that has to be configured?
>
> The ldap client should not need to read your entry's userPassword
> attribute. My userPassword is unreadable, and works OK on OpenSolaris
> build 100, and also Solaris 10, and even Linux.
My fault: I should have lost some more words on the setup: I am trying
to use the Solaris native ldap-client, no implementation of Padl's
nss_ldap. That works on Linux agaist openldap by giving
auth-permissions to anonymous. That way, a anonymous binding can
access the userPassword attribute for authentication, but is not able
to 'read' and 'display' it. However, that implies, that the
userPassword can be read for that action (it must be compared to the
users typed password). On Linux, that works; on Solaris 10 it worked
for me in the last year against openldap 2.3.38. (Solaris 10 now has
to get verified to act this way against 2.4.11 in the next days). That
does not work for me on opensolaris (b92, but i will update that also
in the next days). On Solaris 8 it did not work that way. Configuring
a ProxyAgentDN and a proxyAgentPassword it works (with all the
disadvantages that every user is able to read the crypted password
with a 'ldaplist -l passwd [user]' (which, however, can get
workarounded). Looking at openldap, the box binds with the
proxyAgentDN and can read the stored password to compare it. Every
other setup ends with the error, that access to the userPassword
attribute is denied. In consequence, it can not get compared with the
user's input and access is denied.
Probably, you can give me some more hints on your setup?
>
> If memory serves the objectclasses found in your entry in the directory
> affects the ldap client's behaviour.
To be honest, it it not obvious to me, what you want to express to me
with that.
>
> Specifically I think the presence of "shadowAccount" in your entry
> changes what the client tries to do. Try adding it and see. According
> to RFC 2307 the only mandatory attribute it requires is uid, and that's
> pretty likely to be in your entry already :-)
The accounts in ldap are maintained as objectclasses 'posixAccount'
and 'shadowAccount', the uid attribute is present.
Thx, Georg
Georg Klein
for the testbox, I am using opensolaris 2008.05 b92 (I will update
that in the next days). I am using the native Solaris ldapclient.
If possible, please let me know about the build that broke ldap.
Thx, Georg
Chris Ridd
> Hi,
>
> Chris Ridd <chri...@mac.com> wrote:
>> On 2008-11-03 20:59:58 +0000, Georg Klein <g...@ux.ennuie.org> said:
>>
>>> So the problem seems to be, that opensolaris is not going to bind as
>>> the defined proxyuser but as anonymous. Am I missing something there?
>>> Is there anything else that has to be configured?
>>
>> The ldap client should not need to read your entry's userPassword
>> attribute. My userPassword is unreadable, and works OK on OpenSolaris
>> build 100, and also Solaris 10, and even Linux.
>
> My fault: I should have lost some more words on the setup: I am trying
> to use the Solaris native ldap-client, no implementation of Padl's
> nss_ldap. That works on Linux agaist openldap by giving
Yes, I use the native nss_ldap and pam_ldap modules on
Solaris/OpenSolaris too. I only use the PADL stuff on Linux.
> Probably, you can give me some more hints on your setup?
I got it all working quite a while ago, but I'll go and look to see
what I did. I do remember having to run a packet sniffer to figure out
what the heck was going on!
>> Specifically I think the presence of "shadowAccount" in your entry
>> changes what the client tries to do. Try adding it and see. According
>> to RFC 2307 the only mandatory attribute it requires is uid, and that's
>> pretty likely to be in your entry already :-)
>
> The accounts in ldap are maintained as objectclasses 'posixAccount'
> and 'shadowAccount', the uid attribute is present.
OK, so it sounds like you've got a different problem. Maybe your
pam.conf is wrong? On Solaris 10/OpenSolaris we change login and other
to be:
login auth requisite pam_authtok_get.so.1
login auth required pam_dhkeys.so.1
login auth required pam_unix_cred.so.1
login auth binding pam_unix_auth.so.1 server_policy
login auth required pam_ldap.so.1
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth required pam_unix_cred.so.1
other auth binding pam_unix_auth.so.1 server_policy
other auth required pam_ldap.so.1
I think that is all that is relevant from pam.conf. As you mentioned
ssh was the particular problem, how is sshd configured? The relevant
bits in our sshd_config files seem to be:
PasswordAuthentication yes
PAMAuthenticationViaKBDInt yes
--
Chris
Wayne
I'm no expert, but...
I believe this is related to NSS. If you set nsswitch.conf to use
ldap, this alters the behavior of the standard PAM module (pam_unix,
but wasn't that changed in S10?) to read the password and compare
locally. That requires anonymous read access!
The correct setup is to NOT alter nsswitch (for passwd/shadow anyway).
Instead, use the pam_ldap module in place of pam_unix. That module
checks authentication by attempting to bind to the openldap server
as the user. If the bind succeeds, the user is authenticated.
This only requires anonymous auth access.
-Wayne
Wayne
I'm no expert, but...
I believe this is related to NSS. If you set nsswitch.conf to use
ldap, this alters the behavior of the standard PAM module (pam_unix,
but wasn't that changed in S10?) to read the password and compare
locally. That requires proxyDN (as configured in /etc/ldap.conf)
read access.