LDAP client behaviour - Solaris 9 vs 10
- From: "Brad Rosser" <Brad_Rosser@xxxxxxxxxxxxxxxxx>
- Date: Fri, 03 Oct 2008 12:03:08 +1000
Hi,
I'm in the midst of converting our organisation's Solaris Naming Services
infrastructure from NIS to LDAP and I've come across some differences
in the way clients access the LDAP server depending on whether they are
running Solaris 9 or Solaris 10. Everything seems to be working for both
operating systems despite the differences under the hood ... I'd
just like to ask if the Solaris 9 behaviour in particular is as expected, or
whether things can be tuned/optimised better.
I'm running Sun Java Directory Server Enterprise Edition 6.3 on a
Solaris 9 system and am starting to test it with Solaris 9 (9/05) and
Solaris 10 (5/08) clients. I've set up my profile to have
proxy credential authentication using 'simple' authentication for standard
LDAP services but 'tls:simple' for pam_ldap and passwd services.
I.e. the pertinent parts of the profile with regard to the above, from
'ldapclient list' output, is as follows:
NS_LDAP_BINDN= uid=hostproxy,ou=People,dc=.....
NS_LDAP_AUTH= simple
NS_LDAP_SERVICE_AUTH_METHOD= pam_ldap:tls:simple
NS_LDAP_SERVICE_AUTH_METHOD= keyserv:tls:simple
NS_LDAP_SERVICE_AUTH_METHOD= passwd-cmd:tls:simple
I did most of my principal testing with a Solaris 10 client, and the
behaviour
I observed from looking at the LDAP server log and the occasional snoop
showed what I thought was the correct behaviour in the following
types of connections being made:
#1 - on the boot of the client a couple of anonymous connections would
search for attributes 'supportedControl' and 'supportedSASLMechanisms'
on the base root of the LDAP server. Similar connections would be made
periodically every five minutes.
#2 - on boot an LDAP connection would be made, bound to the proxy, searching
for the profile;
#3 - a persistent LDAP connection would be made, bound to the proxy, which
conducted multiple searches, all associated with name service activity
requested by the client during its normal operation, for the lifetime of
the
client's uptime;
#4 - Encrypted (SSL) LDAPS connections would be made to the LDAP server
whenever a user logged in or changed his password. The LDAPS connections
would be bound to the user concerned.
This all made perfect sense as far as I was concerned. I'm not sure what
was generating the #1 connections every five minutes - the LDAP cache
daemon on the client? I'd guess that the #3 persistent connection was
held open by that daemon - or maybe nscd? - to forward all the
naming service queries requested by the machine. And pam_ldap/passwd
operations were made by SSL connections and bound to the user concerned.
But recently I've set up a Solaris 9 client using exactly the same procedure
('ldapclient init' using the same profile and so forth) and I've noted quite
markedly different behaviour:
A. There seems to be no 'persistent', long-running connection such as #3
above. Every single name service request that the Solaris 9 client
makes
seems to result in a separate, short-lived LDAP connection which is
created,
bound to the proxy, runs the search and then terminates.
B. When a user changes his password it is stored in the LDAP server in
{crypt} format. Yet when a user changes his password on a Solaris 10
client it is stored in {SSHA} format on the LDAP server.
C. Logging in via ssh on the Solaris 9 client seems to show that it has
multiple personalities. :-) After entering a user name I'm given a
'Password:' prompt. If I enter the correct password I am logged in ...
but a standard, non-encrypted, 'LDAP' connection is made to the
LDAP server and bound to the user.
But if I enter the wrong password I am then given a second
prompt - 'LDAP Password:' - and if I enter the correct password
this second time I am logged in ... and an SSL, 'LDAPS' connection
is made and bound to the LDAP server.
I'd appreciate any advice or discussion about these observed differences
between Solaris 9 and Solaris 10 clients. Begin a newcomer to LDAP I
was happy with the Solaris 10 behaviour - it seemed to behave exactly
as I expected - so the Solaris 9 activity shook me somewhat. Is (A) normal
for Solaris 9 clients? One of the improvements made to Solaris 10 being
the 'caching' activity (of the LDAP cache daemon?) and standard name
service requests consigned to a long-running persistent connection?
Why are user passwords stored in {crypt} format under Solaris 9? I
guess I'm not fully conversant with all the intricacies of how passwords
are managed; I haven't elected to encrypt 'userPassword' - the command
'dsconf list-encrypted-attrs' gives zero output - but with the behaviour
of the Solaris 10 client I (naively) assumed that 'userPassword' was
encrypted on the LDAP server anyway. :-) From my reading of the LDAP
server documentation I'm fuzzy on whether the 'userPassword' is a
special case that is always encrypted regardless.
The behaviour of (C) really puzzles me. Do I have to adjust the Solaris 9
pam.conf to modify the behaviour of login/sshd to remove the LDAP
connections made in the clear up login? I *don't* have any special
entries in the pam.conf files for either Solaris 9 or Solaris 10 clients; do
I (for some reason) need 'sshd' entries for the pam.conf for Solaris 9?
Any references to documentation on these sorts of mysteries, or
documentation out there on the differences between Solaris 9 and
Solaris 10 LDAP behaviour would be most gratefully received.
Thanks,
Brad
*****************************************************************************
***
This email, including any attachments sent with it, is confidential and for
the sole use of the intended recipient(s). This confidentiality is not waived
or lost, if you receive it and you are not the intended recipient(s), or if it
is transmitted/received in error.
Any unauthorised use, alteration, disclosure, distribution or review of this
email is strictly prohibited. The information contained in this email,
including any attachment sent with it, may be subject to a statutory duty of
confidentiality if it relates to health service matters.
If you are not the intended recipient(s), or if you have received this email
in error, you are asked to immediately notify the sender by telephone collect
on Australia +61 1800 198 175 or by return email. You should also delete this
email, and any copies, from your computer system network and destroy any hard
copies produced.
If not an intended recipient of this email, you must not copy, distribute or
take any action(s) that relies on it; any form of disclosure, modification,
distribution and/or publication of this email is also prohibited.
Although Queensland Health takes all reasonable steps to ensure this email
does not contain malicious software, Queensland Health does not accept
responsibility for the consequences if any person's computer inadvertently
suffers any disruption to services, loss of information, harm or is infected
with a virus, other malicious computer programme or code that may occur as a
consequence of receiving this email.
Unless stated otherwise, this email represents only the views of the sender
and not the views of the Queensland Government.
*****************************************************************************
*****
_______________________________________________
sunmanagers mailing list
sunmanagers@xxxxxxxxxxxxxxx
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
- Prev by Date: FW: NFS Mounts from multiple NAS heads
- Next by Date: recovering a V120 with unknown eeprom password & inaccessible ALOM
- Previous by thread: FW: NFS Mounts from multiple NAS heads
- Next by thread: recovering a V120 with unknown eeprom password & inaccessible ALOM
- Index(es):
Relevant Pages
|
Loading
