Solved

LDAP: Cannot change user password

Posted on 2004-09-20
32
11,076 Views
Last Modified: 2013-12-27
Hey Gang,

I recently activated LDAP on Solaris 9 and I am running into a user password problem.

Basically, I used "idsconfig" to create the domain.  I used "ldapaddent -f /etc/passwd" to create all the users within the LDAP database...but LDAP is not able to identify or change a user password.  

To make troubleshooting easier, I did the following to create a user which is UNIQUE to LDAP (and NOT in the /etc/passwd) ...

1. I created the user "ldapuser" within LDAP with the "ldapaddent" command and used a modified entry from the /etc/passwd (NOTE: LDAPUSER DOES NOT APPEAR IN THE /ETC/PASSWD!)

2. LDAP successfully SEES the new user, since when I enter "su - ldapuser" I successfully su to “ldapuser” and go to correct dir.

3. However, if I "rlogin server1 -l ldapuser" and enter what SHOULD be the password, it simply fails to login (as if I got the password wrong.)

4. I used the “/usr/sbin/directoryserver startconsole” to start the LDAP management console, found the user, and entered a password here.  HOWEVER, when I go back and do step three I get the same results.

5. If I try the command (as root) “passwd –r ldap ldapuser”…I get the following response…
  Enter root's password: <entered correctly>
  New Password: <entered correctly>
  Re-enter new Password: <entered correctly>
  passwd: System error: no ldap password for ldapuser.
  Permission denied

6. I AM able to login into the LDAP Management Console using username:ldapuser and the password I assigned it, but when I try the command (as ldapuser) “passwd –r ldap ldapuser”…I get the following response…
  Enter existing login password: <blank>
  passwd: Sorry, wrong passwd
  Permission denied
  $ passwd -r ldap ldapuser
  Enter existing login password: <password entered in at the management console>
  passwd: Sorry, wrong passwd
  Permission denied

I’M STUCK!  HELP!
Thanks!
M
0
Comment
Question by:Mike R.
  • 13
  • 10
  • 9
32 Comments
 
LVL 38

Expert Comment

by:yuzh
Comment Utility
Check your /etc/nsswitch.conf file

grep ldap /etc/nsswitch.conf

you should see soemting like:
passwd:     files ldap
group:      files ldap
# consult /etc "files" only if ldap is down.
hosts:      ldap [NOTFOUND=return] files
#ipnodes:    ldap [NOTFOUND=return] files
networks:   ldap [NOTFOUND=return] files
protocols:  ldap [NOTFOUND=return] files
rpc:        ldap [NOTFOUND=return] files
ethers:     ldap [NOTFOUND=return] files
netmasks:   ldap [NOTFOUND=return] files
bootparams: ldap [NOTFOUND=return] files
publickey:  ldap [NOTFOUND=return] files
netgroup:   ldap
automount:  files ldap
aliases:    files ldap
# for efficient getservbyname() avoid ldap
services:   files ldap
auth_attr: files ldap
exec_attr: files ldap
prof_attr: files ldap
user_attr: files ldap
audit_user: files ldap
project:    files ldap

If not, you do:
cp -p /etc/nsswitch.conf /etc/nsswitch.conf.old
cp /etc/nsswitch/ldap /etc/nsswitch.conf

then the user can use ldap login.
0
 
LVL 3

Author Comment

by:Mike R.
Comment Utility
Hey Yuzh!

Thanks for the reply.  Actually, the nsswitch.conf is OK...similar to above (although we have it set to [NOTFOUND=continue] since there will be entries on some box's local files which will not be available in LDAP.

We are sure the nsswitch is working since we CAN su - to the user "ldapuser" (which only appears in LDAP, so LDAP is responding)...but we CAN'T change or set the ldapuser's password through LDAP (or, apparently any other method.)

Thanks!
M
0
 
LVL 38

Expert Comment

by:yuzh
Comment Utility
You can't login as local root to change a LDAP user password (just like you are root for
NIS+ client cann't change a NIS+ user password)!

If your /etc/nsswitch.conf has:
passwd:     files ldap

Do not create local user with the same login as LDAP, it will confuse you.

Please have a look at this Sun doc:
#------------------------------------------------------------------------------------------
Keyword(s):native, ldap, native-ldap

Problem Statement Top

In a secure Lightweight Directory Access Protocol (LDAP) environment
there is usually no administrative "root" user; therefore, you cannot reset
a user's password by running /usr/bin/passwd as root when the user
information is stored in ldap(1). The procedure described in this article
allows you to generate new passwords in a secure LDAP environment.


Resolution Top

The SunONE[TM] Directory Server allows you to store user passwords
in four different formats. These formats are:

    CLEAR    Cleartext
    CRYPT    Crypted with the Unix[TM] crypt(3C) Algorithm
    SHA      Crypted with the Secure Hashing Algorithm
    SSHAA    Crypted with the Salted Secure Hashing Algorithm


Although the Solaris[TM] ldap(1) client supports all the preceding formats
for storing passwords in LDAP,  there may be some restrictions depending on
how the Solaris ldap(1) is used or configured. For example:

     CLEAR     You must use this format if the Solaris ldap(1) client is
               configured to use the SASL for authentication.
            
     CRYPT     You must use this format if the Solaris ldap(1) client is
               configured to use pam_unix(5) for authentication
               OR if one of the NIS+ or NIS transition toolkits is used.
                     
     other     You may use any format if the Solaris ldap(1) client is
               configured to use pam_ldap(5) for authentication.


Determining the Password Storage Format
=======================================

To determine which of these formats your directory server uses, search for
the attribute passwordStorageScheme in the base cn=config of your directory
server's configuration.  For example:

    # ldapsearch -h ldapsrv -p 389 \
                 -D "cn=directory manager" -w <dirmgrpwd> \
                 -b cn=config objectclass=* | grep passwordStorageScheme
    passwordStorageScheme=SSHA


Choosing the Appropriate Procedure
==================================

There are two procedures you can use to reset a user's password. If the
user's new password will be configured in the same way that it is
configured in the attribute passwordStorageScheme, use Procedure A.
If the user's new password will be stored in a different format, use
Procedure B.


Procedure A - User's Password Stored in LDAP in the Same Format
===============================================================

To reset a user's password, and store it in LDAP in the same format as is
already defined in the attribute passwordStorageScheme, follow
these steps:

1. Create a file in LDIF format. For example:

    # vi /tmp/newpassword.ldif
    dn: uid=enduser,ou=people,dc=my,dc=company,dc=com
    changetype: modify
    replace: userPassword
    userPassword: newpassword

2. Load this file into LDAP. For example:

    # ldapmodify -h ldapsrv -p 389
                 -D "cn=Directory Manager" -w <dirmgrpwd>
                 -f newpassword.ldif
     modifying entry uid=enduser,ou=people,dc=my,dc=company,dc=com

(In the preceding example, change dc=my, dc=company, and dc=com to what is
appropriate for your DIT.)

3. Move on to Procedure C.

NOTE: As an alternate to this procedure you can edit the LDAP object for
this user in the Directory Server's Administration Console by typing over
the attribute userPassword with the new value.



Procedure B - User's Password Stored in LDAP in a Different Format
==================================================================  

To reset a user's password and store it in LDAP in a different format than
is already defined in the attribute passwordStorageScheme, follow
these steps:

1. Encrypt the user's new cleartext password (on the system where
    the directory server is running). Use this syntax:

    # /usr/sbin/directoryserver pwdhash
                                -D /var/ds5/slapd-<Instance-Name>
                                -s <format> <new-password>
                               
    Example:
    --------

    # /usr/sbin/directoryserver pwdhash
                                -D /var/ds5/slapd-ldapsrv
                                -s CRYPT newpwd
    /usr/iplanet/ds5/bin/slapd/server/pwdhash -D slapd-ldapsrv -s CRYPT
    newpwd
    {crypt}3S7vhp1/YvzXA


2. Create a file in LDIF format with the following contents and syntax:

    # vi /tmp/newpassword.ldif
    dn: uid=<username>,ou=people,<Base-DN>
    changetype: modify
    replace: userPassword
    userPassword: {crypt}<encrypted password that was created in step 1>

    Example:
    --------

    # vi /tmp/newpassword.ldif
    dn: uid=enduser,ou=people,dc=my,dc=company,dc=com
    changetype: modify
    replace: userPassword
    userPassword: {crypt}3S7vhp1/YvzXA


3.  Load this file into LDAP using the ldapmodify command. Use this syntax:

    # ldapmodify -h <hostname> -p <port>
                 -D "cn=Directory Manager" -w <password>
                 -f newpassword.ldif

    Example:
    --------  

    # ldapmodify -h ldapsrv -p 389
                 -D "cn=Directory Manager" -w <dirmgrpwd>
                 -f newpassword.ldif
     modifying entry uid=enduser,ou=people,dc=my,dc=company,dc=com


(In the preceding example, change dc=my, dc=company, and dc=com to what is
appropriate for your DIT.)

4. Move on to Procedure C.


Procedure C - The User Changes the Password
===========================================

The user can now login to any Solaris ldap(1) client system  using the
new password that you created in procedure A or B. The user can then
change his or her password to any value using this sytax:

    % /usr/bin/passwd -r ldap
    passwd: Changing password for <username>
    Enter existing login password: <<< enter the cleartext password
                                       that the administrator
                                       encrypted in step 1
    New Password: <<< enter user's own new (secret) password
    Re-enter new Password: <<< re-enter user's own new (secret) password
   
    passwd: password successfully changed for <username>


    Example:
    --------

    % /usr/bin/passwd -r ldap
    passwd: Changing password for enduser
    Enter existing login password: <<< enter newpwd
    New Password: <<< enter your own new (secret) password
    Re-enter new Password: <<< re-enter your own new (secret) password

    passwd: password successfully changed for enduser
Temporary Workaround Top


Additional Information Top

#--------------------------------------------------------------------------------------------------

From:
http://sunsolve.sun.com/search/printfriendly.do?assetkey=1-25-70151-1

and read:
http://sunsolve.sun.com/search/printfriendly.do?assetkey=1-9-75522-1
0
 
LVL 3

Author Comment

by:Mike R.
Comment Utility
Thanks again, Yuzh!

We were making great progress until the "/usr/bin/passwd -r ldap" command.  The flaw appears to be that when I run the command as root I get ...

ksh # passwd -r ldap ldapuser
Enter existing login password:
passwd: Sorry, wrong passwd
Permission denied

...even though I entered the password created in Procedure B.  And when I do an "su - ldapuser", the system still identifies me as root, as in the following ...

ksh # su - ldapuser
Sun Microsystems Inc.   SunOS 5.9       Generic May 2002
$ passwd -r ldap
passwd: Changing password for root
passwd: User unknown: root
Permission denied

...and, of course, I can't "rlogin ldapserver -l ldapuser", in order to run the "passwd -r ldap" command as "ldapuser", since I don't have the login passwd.

Rats!
M
0
 
LVL 38

Expert Comment

by:yuzh
Comment Utility
Can you create a LDAP user and login as the newuser to the system?

Please re-read http:Q_21138520.html#12118857

And check your LDAP server and client against the following docs:
    LDAP Setup and Configuration Guide:
    http://docs.sun.com/db/doc/806-5580
    http://www.mittelstadt.org/ldap/sun_ldap_setup.pdf
0
 
LVL 3

Author Comment

by:Mike R.
Comment Utility
I can create a new ldap user through either the command line, OR the GUI which comes as a part of the iPlant install...I can then "su" to the user...but I cannot login because the password is unknown.  I cannot login as the user (other than "su"ing) even when I create the user through the GUI and enter a as part of the user creation.  And, of course, I cannot figure out how to change the password.

Thanks!
M
0
 
LVL 38

Accepted Solution

by:
yuzh earned 250 total points
Comment Utility
You should be able to set the user password when you use the GUI tool (user/group).

Don't know how the system was installed an configured, can't help much on this one.

Have a look at the following third party tools for LDAP user manager:
http://diradmin.open-it.org/index.php
http://ldapusrmgr.sourceforge.net/

also the following Sun doc:
#-----------------------------------------------------------------------------------------------------
Document ID: 75522
Title: How to create a user in Directory Server 5.x that can only change user passwords
Synopsis: How to create a user in Directory Server 5.x that can only change user passwords
Update Date: Fri Jul 02 00:00:00 MDT 2004
Products:  Sun Java System Directory Server 5.1 Software Service Pack 3  iPlanet Directory Server 5.1 Service Pack 2
Technical Areas:  LDAP (Lightweight Directory Access Protocol)

--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

Keyword(s):Directory Server 5.x, admin user

Description Top

How to create a user in Directory Server 5.x that can only change user
passwords.  

This can be used when an account is needed solely for the purpose of
changing user passwords.
Document Body Top

1) create the new user
Ex. create the user pswdadmin in the Administrators container.
It's dn would look like this:
dn: uid=pswdadmin,ou=Administrators, ou=TopologyManagement,o=NetscapeRoot

Wherever the users/groups are, you have to modify the acis for that
particular group, not for the pswdadmin user.  


2) do a ldapsearch to dump the acis for that tree (ex. o=sharpei.com)
bash-2.03# ./ldapsearch -D cn=dirmanager -w dirmanager -p 30001 -b
"o=sharpei.com" -s
sub
aci=\* aci
version: 1
dn: o=sharpei.com
aci: (targetattr != "userPassword || passwordHistory") (version 3.0; acl  
 "Anonymous access"; allow (read, search, compare)userdn =
"ldap:///anyone";)

aci: (targetattr != "nsroledn || aci || nsLookThroughLimit || nsSizeLimit
||nsTimeLimit ||
 nsIdleTimeout || passwordPolicySubentry ||        
 passwordExpirationTime || passwordExpWarned || passwordRetryCount ||
 retryCountResetTime || accountUnlockTime || passwordHistory ||
 passwordAllowChangeTime")(version 3.0; acl "Allow self entry modification
 except for nsroledn, aci, resource limit attributes,
 passwordPolicySubentry and password policy state attributes"; allow
(write)userdn
 ="ldap:///self";)

aci: (targetattr = "*")(version 3.0; acl "Configuration Administrator";
 allow (all) userdn = "ldap:///uid=admin, ou=Administrators,
 ou=TopologyManagement,o=NetscapeRoot";)

There are three acis above.  The first aci allows anyone to
read/search/compare everything in that tree except for the userPassword and
passwordHistory.  The second aci allows "self" to modify/write all of the
above attributes.  The third aci allows
uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot to
everything.


3) Copy the aci output to a text editor file.  You're going to create a new
aci for the pswdadmin user you just created.  It will look like this:

aci: (targetattr = "userPassword")(version 3.0; acl "Configuration
Administrator";
 allow (write) userdn  = "ldap:///uid=pswdadmin,ou=Administrators,
 ou=TopologyManagement,o=NetscapeRoot";)

Now, you should have four acis in your text editor.  The aci above says
for uid=pswdadmin, the user has write access only to the userPassword
attribute.


4) In your text editor, put the lines one after another, without the spaces
between the lines. It should look similar to how it looked during the
ldapsearch of the
aci's.  There needs to be a space for each line in the aci for ldapmodify
to
recognize it as one aci.
ex.  
aci............etcetc....
<put_space_here>....cont aci.
aci.............etcetc.....
<put_space_here>...cont aci...


5) do an ldapmodify on the acis. it will look similar to this:
bash-2.03# ./ldapmodify -D cn=dirmanager -w dirmanager -p 30001
dn: o=sharpei.com
changetype: modify
replace: aci
aci: (targetattr != "userPassword || passwordHistory") (version 3.0; acl
 "Anonymous access"; allow (read, search, compare)userdn =
"ldap:///anyone";)
aci: (targetattr != "nsroledn || aci || nsLookThroughLimit || nsSizeLimit
|| nsTimeLimit ||  
 nsIdleTimeout || passwordPolicySubentry ||  passwordExpirationTime ||
passwordExpWarned  
 || passwordRetryCount ||retryCountResetTime || accountUnlockTime ||
passwordHistory ||
 passwordAllowChangeTime")(version 3.0; acl "Allow self entry modification
except for  
 nsroledn, aci, resource limit attributes, passwordPolicySubentry and
password policy state
 attributes";allow (write)userdn ="ldap:///self";)
aci: (targetattr = "*")(version 3.0; acl "Configuration Administrator";
allow  (all) userdn =
 "ldap:///uid=admin,
ou=Administrators,ou=TopologyManagement,o=NetscapeRoot";)
aci: (targetattr = "userPassword")(version 3.0; acl "Configuration          
 Administrator"; allow (write) userdn = "ldap:///uid=pswdadmin,          
 ou=Administrators, ou=TopologyManagement,o=NetscapeRoot";)

modifying entry o=sharpei.com

-------> you can do a tail -f on the audit log (if enabled) to verify the
changes were made

6) you can now modify users' passwords for that part of the tree
(o=sharpei.com)

bash-2.03# ./ldapmodify -D
uid=pswdadmin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot -w
testadmin -p
30001
dn: uid=userA,ou=People,o=sharpei.com
changetype: modify
replace: userPassword
userPassword: newpassword123

modifying entry uid=userA,ou=People,o=sharpei.com

7) test by doing an ldapsearch binding as that user with the new password.
#----------------------------------------------------------------------------------------------------

From: http://sunsolve.sun.com/search/printfriendly.do?assetkey=1-9-75522-1
0
 
LVL 51

Assisted Solution

by:ahoffmann
ahoffmann earned 250 total points
Comment Utility
dooh, huge thread to a complicated setup ...

Do I understand correctly that you can do without problems:
  + add user with ldapaddent
  + login to that user (either console or X or ssh)
  + switch to that user using su
but you cannot:
  - rlogin to that user
  - change password using standard utilities (like /bin/passwd)

If so, I'd assume that the entry for that user in LDAP does not allow rlogin, and that you have to use ldapmodify or similar to change the password in LDAP.
Can you please use ldapsearch to extract the ldapuser's entry and check it. If in doubt, please post it.
Note: most likely LDAP is configured to return the full entry (means all its attributes) only if you bind as Directory Manager and/or specify the required attributes in the search filter.
0
 
LVL 3

Author Comment

by:Mike R.
Comment Utility
Hey ahoffmann,

Do I understand correctly that you can do without problems:
  + add user with ldapaddent - yes
  + login to that user (either console or X or ssh) - no
  + switch to that user using su - yes
but you cannot:
  - rlogin to that user - correct
  - change password using standard utilities (like /bin/passwd) = correct

When I attempt to login as this user by any method, it responds as if I typed the wrong password.  I can ONLY "su" to the user from root (and no one else, due to the password.)

Also, I cannot get any user information through an ldapsearch (keeps saying object does not exist), although an "ldaplist passwd ldapuser" or "getent passwd ldapuser" works fine and reports all the correct info.

It is nuts!
M
0
 
LVL 51

Expert Comment

by:ahoffmann
Comment Utility
sounds like you need to get used to ldapsearch/ldapmodyfy
Sorry, don't have Solaris 9, but I assume that ldapaddent and ldaplist are just some more user friendly frontends to ldapsearch and ldapmodify. Can you please veryfy, ldapaddent and ldaplist are probably scripts.

Please use ldapsearch to extract your ldapuser entry and post here, something like:
   ldapsearch -h localhost -D "uid=Directory Manager" -w directory-manager-password uid=ldapuser

NOTE: that the filter uid=ldapuser is just an assumtion from me, please adapt to your requirements (probably ldaplist gave some hinst)
0
 
LVL 38

Expert Comment

by:yuzh
Comment Utility
Please read the following doc to learn the LDAP tools:
http://tille.soti.org/training/ldap/ch01.html

Full "LDAP Operations HOWTO":
http://tille.soti.org/training/ldap/

ahoffmann, do you have boxes with LDAP handy? it doesn't need to be Solaris 9, I don't
have one on hand at the moment.

rightmirem, please post all the infor about the errors.

0
 
LVL 3

Author Comment

by:Mike R.
Comment Utility
Hey Yuzh,

I will check out the links...but I am suspicious the issue with the search is not usage of the tools, but something wrong with the ldap config.  I am currently also working with SUN to see if there is a problem with the ldap config...but the tools don't seem to be responding properly regardless of use.

I think one critical question is whether the password, as shown through the LDAP GUI (which comes with the Solaris install) should be the password for the user to login.  Point being, that your steps to change the password worked perfectly (except for the last step, requiring the user login and change it) and when I went into the GUI and looked at the account's password, it was set to the "{crypt}blahblahblah" as it should have been, but the account still won't login directly.

I.E.  When I did the...
# ldapsearch -h ldapsrv -p 389  -D "cn=directory manager" -w <dirmgrpwd> -b cn=config objectclass=* | grep passwordStorageScheme
...it returned passwordStorageScheme=crypt

So I did the passwdhash, and the steps to insert the password into the user...and when I check the password through the GUI, the correct "{crypt}blahblahblah" IS in the password field...but I still cannot login.

Also, although the search for the password encryption type worked, I cannot get any other response from a search - no matter the search syntax, or what I search for - other than "ldap_simple_bind_s: No such object"

Thanks!
M



0
 
LVL 51

Expert Comment

by:ahoffmann
Comment Utility
> .. with  LDAP handy?
yes, multiple ... but none ist setupe/used for system authentification

rightmirem, can you use ldapsearch and bind as the a problematic user and it's password.
   ldapsearch -h ldapsrv -p 389  -D "uid=user" -w <userpwd> uid=user

When talking about LDAP GUI, I assume you mean startconsole.
Did you set the "userpassword" (or however this attribute is called) in the ACLs to be modifyable by the user itself?
0
 
LVL 3

Author Comment

by:Mike R.
Comment Utility
Hey AH!

ldapsearch -h ldapsrv -p 389  -D "uid=user" -w <userpwd> uid=user
ldap_simple_bind_s: No such object

Yes to startconsole

I have not made any changes to the ACLs, so I will check on the userpassword setting and see if that helps!

Thanks!
M
0
 
LVL 38

Expert Comment

by:yuzh
Comment Utility
You forgot "-b"
 -b "o=yourdomain"
man ldapsearch
0
 
LVL 51

Expert Comment

by:ahoffmann
Comment Utility
> ..  -D "uid=user"
needs to be the real one, obviously :)
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 
LVL 3

Author Comment

by:Mike R.
Comment Utility
Alright!

We made some progress!  Basically, you guys are on the right track with ACIs...that is what needs to happen.  I need to change the access from anonymous, to proxy, and add some encryption to the box.  SUN and I are going to work on that tomorrow...

BUT I have another question related to this entire issue that I need your opinions on!  The SUN tech said that you should never/can never have an LDAP client on the same box as the server.  

1. Well, first this SEEMS to be contradictory to the documentation I had, as MY UNDERSTANDING (wouldn't be the first time I was wrong, however) was that you could not actually access the LDAP server install directly, so everything had to go through a client (and the docs had me setting the client up locally.)

2. However, more importantly, this would carry the implication that the LDAP server could not actually USE LDAP as a resource...meaning that if you set up LDAP to handle all your clients (passwd,) your groups, your network structure, ETC...your LDAP server would not actually be able to USE these to allow users to login.

Does your LDAP server have to be completely isolated and run off local files?  Have you ever heard this?  That might be fine in a limited environment, but this just seems unfeasible for an enterprise environment where you might have 100 LDAP servers replicating the same databases.

Thanks!
M
0
 
LVL 51

Expert Comment

by:ahoffmann
Comment Utility
> .. never/can never have an LDAP client on the same box as the server.
hmm, don't know what these people define as "LDAP client", ldapsearch is an LDAP client, and that runs on the LDAP server, obviously. Hence this statement seems to be BS, but see below ...

> 1. .. could not actually access the LDAP server install directly ..
what do you mean by that? I'm unshure about the "install" here.
If I read without "install", then see my answer above

> 2. .. .your LDAP server would not actually be able to USE these to allow users to login.
you mean logins on the LDAP server itself.
That's a bit true, but that's what /etc/nsswitch.conf is for: it should be different on the LDAP server itself, for example:

  passwd:   ldap files
  group:     ldap files

Ask your "SUN tech" again, they need to know that, otherwise ask EE :-))
0
 
LVL 38

Expert Comment

by:yuzh
Comment Utility
For /etc/nsswitch.conf  it is better to use files before ldap, just in case something happen,

passwd: files ldap
group: files ldap

see http:#12109691

and remember to modify the hosts record to:
hosts: files ldap



0
 
LVL 51

Expert Comment

by:ahoffmann
Comment Utility
outch, yuzh is right!
this was a copy&paste error from me, sorry
0
 
LVL 3

Author Comment

by:Mike R.
Comment Utility
I think you guys understood my question, and your answers actually indicate that...but I will re-iterate, just to be sure I was clear.

The tech said you could not have a server and a client running on the same box.  MY understanding is, you cannot access an LDAP server except through a client (with the exception of the console...with which you can only do configuration tasks.)

This would mean, as you indicated above, that if the server was not running an LDAP client you could make no requests of LDAP while on the server itself.  I.E.  ...

1. You could not run an "ldapsearch" from the command prompt while on the server, because this is a client request to a server and you cannot have a client on the server (you would have to be on a different machine to do the search.)  

2. You could not use the "ldapaddent", from the command line on the server because this is, again, a client request to a server.

3. Having "passwd:  files ldap" appear in your nsswitch.conf on the server would be useless, because unless the server computer had a client running...it could not make a request of LDAP and, thus, could not authenticate a user through the LDAP database (meaning the only users who could possibly log into your LDAP server would have to appear in its local "/etc/passwd" file.)

To me, this seems like nonsense...but the tech was pretty adamant.  Do you suppose we could have been thinking of different things when she said "client" and I said "client"?  If so, I wonder what else she might have been referring to.  Any guesses?

Thanks again!
M

P.S.  She will be calling back today, so maybe I could get this cleared up :-)
0
 
LVL 51

Expert Comment

by:ahoffmann
Comment Utility
1. is wrong, for shure
2. wrong probably too (sorry I don't know ldapaddent)
3. a bit confusing your description:
   lets rephrase: having "passwd: files ldap" in nsswitch.conf enshures that all authentication request are first check for in /etc/passwd, only if that fails LDAP is consulted
   actually it's not that simple in practice 'cause it may depend on what you relay have written in nsswitch.conf,
  but it's the general way it works

  in other words: having an entry (like root) in /etc/passwd, and "passwd: files ldap" in nsswitch.conf, then root can login on that server, even it is the LDAP server, means running the slapd
0
 
LVL 3

Author Comment

by:Mike R.
Comment Utility
Hey Guys,

Actually, I think I clouded the issue with my last comment.  

Basically, the big concern with not being able to run an LDAP client on the LDAP server is that...if I had 100 users in the LDAP passwd database, NONE of those users could log into the LDAP server computer unless they were ALSO in the server's "/etc/passwd" files.

This is not a big deal with one LDAP server, but if I were in an enterprise environment with 20 LDAP servers, that would mean I would have to update one LDAP passwd database, and 20 "/etc/passwd" files everytime I added a user (since the servers could not use the LDAP passwd database to authenticate the new user un less there was a client running on the server too.)

That just seems frickin' ridiculous...

HOWEVER, the tech re-iterated on the phone this IS the case.  Although having a client on the LDAP server machine will WORK...they won't support it.  

They are trying to fix the issue, however.

M
0
 
LVL 38

Expert Comment

by:yuzh
Comment Utility
Not sure if you have use something like NIS+, you do NOT install NIS+ client in the Master server or replicas, but the NIS+ user can login, why? because /etc/nsswitch.conf  can tell
the system to use passwd:    

files nisplus
group:      files nisplus

If we take the "nisplus" only the user definded in files can login! Is this example make sense
to you.

0
 
LVL 3

Author Comment

by:Mike R.
Comment Utility
Hey Yuzh,

No...it makes sense.  I understand how the /etc/nsswitch.conf works.  What I am questioning is that if you don't have an LDAP client running on the LDAP server, then LDAP users cannot log into the LDAP server machine.

SUN's policy means you cannot use LDAP to log into an LDAP server...and this seems like nonsense to me.

Example:
-You have a user called newuser
-"newuser" ONLY exists within the "People" database, on the LDAP server on "machine1" (not in "/etc/passwd", not NIS)
-if you DON'T have an LDAP client running on "machine1"...then "newuser" can never log into "machine1"
-UNLESS you add "newuser" to the "/etc/passed" on "machine1"
-being required to add "newuser" to the "etc/passwd" (or NIS) on "machine1", because SUN does not support an LDAP client running on the same machine as the LDAP server...seems like nonsense to me.

Do you see what I am saying :-) ?

Thanks for all the help!
M
0
 
LVL 3

Author Comment

by:Mike R.
Comment Utility
OR...am I misunderstanding...and you are saying you do NOT need an LDAP client on the LDAP server for the LDAP server to functionally USE ldap (for example, to authenticate a user found ONLY in the LDAP "people" database?)
0
 
LVL 51

Expert Comment

by:ahoffmann
Comment Utility
> ..  the tech re-iterated on the phone ..
someone heard of multi-master architectures for LDAP? Sun techs should, otherwise get your money back ;-)

> .. ...they won't support it.  
if you pay for support, get your money back.

> SUN's policy means  ..
have you a link to that? a paper or whatever?

> -if you DON'T have an LDAP client running on "machine1"...then "newuser" can never log into "machine1"
> -UNLESS you add "newuser" to the "/etc/passed" on "machine1"
if machine1 is a slave LDAP (or part of a multi-master) then it should be configured to forward the request to the other, lets say machine2, problem solved.

> ...seems like nonsense to me.
full ACK

0
 
LVL 3

Author Comment

by:Mike R.
Comment Utility
Unfortunately, in THIS particular installation (for now), the LDAP server is running solo.  The tech finally said the only real issue with running the server and client on the same box was with the startup (as the client is dependent on the server starting first) and there are easy workarounds for that...but she still insited that "...they won't support that configuration..."

What a bunch of hooey :-)

Anyway, we have implemented a proxy agent, but still need to do some configuration to get the "client" to use it correctly...and to implement the ACIs.  I will leave some detail as to what we do as sson as we get it done.

Thanks again! :-D
M
0
 
LVL 51

Expert Comment

by:ahoffmann
Comment Utility
good luck so far ...
0
 
LVL 38

Expert Comment

by:yuzh
Comment Utility
>>> The tech finally said the only real issue with running the server and client on the same box was with the startup (as the client is dependent on the server starting first) and there are easy workarounds for that...but she still insited that "...they won't support that configuration..."


If both LDAP server and client startup script is in /etc/rc2.d (default location) you need to make
sure that the server startup script has a smaller number than the client startup script
(typical name S71ldap.client), or you can move the client start script to /etc/rc3.d

0
 
LVL 3

Author Comment

by:Mike R.
Comment Utility
OK...it was the ACIs.  We re-setup the LDAP configuration to use proxy, and then had to create an ACI for the proxy to read and modify the user passwords.  We got thrown off by an earlier tech who had checked the ACIs and said they were fine...but they were not.

Thanks again for all the help.  I am going to split the points as you were both very helpful and got me on the right track.

As for the client running on a server...so far, it appears they can co-exist fine with the exception of starting up.  As the LDAP server starts in rc2, and the client also tries to start in rc2, I found out the hard way that...left unchanged...the system will get into an irresolvable loop when trying to restart.  However, moving the /etc/rc2.d/S99ldap.client script to rc3 allows the server to start up without issue.  I am not sure why SUN considers this a deal breaker for supporting the system...but they stand by that.

So the solution is...move the ldap.client startup script and don't tell SUN :-)

Thanks again!
M
0
 
LVL 38

Expert Comment

by:yuzh
Comment Utility
You are welcome, cheers!
0

Featured Post

IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Suggested Solutions

Title # Comments Views Activity
prtdiag report hdd failure 10 118
AIX Server 10 74
AIX 6.1: need to grow single SAN disk rootvg, does this require a downtime? 11 40
UNIX SCP 5 46
Introduction Regular patching is part of a system administrator's tasks. However, many patches require that the system be in single-user mode before they can be installed. A cluster patch in particular can take quite a while to apply if the machine…
FreeBSD on EC2 FreeBSD (https://www.freebsd.org) is a robust Unix-like operating system that has been around for many years. FreeBSD is available on Amazon EC2 through Amazon Machine Images (AMIs) provided by FreeBSD developer and security office…
Learn several ways to interact with files and get file information from the bash shell. ls lists the contents of a directory: Using the -a flag displays hidden files: Using the -l flag formats the output in a long list: The file command gives us mor…
This video shows how to set up a shell script to accept a positional parameter when called, pass that to a SQL script, accept the output from the statement back and then manipulate it in the Shell.

744 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

17 Experts available now in Live!

Get 1:1 Help Now