# Passwd Not Working With LDAP

## Duck Man

Short version:

I just switched to LDAP and when I try to change my password I get:

```
passwd: User not known to the underlying authentication module
```

This is my /etc/pam.d/system-auth:

```
auth            required        pam_env.so

auth            required        pam_unix.so try_first_pass likeauth nullok

auth            sufficient      pam_ldap.so use_first_pass

auth            optional        pam_permit.so

account         sufficient      pam_ldap.so

account         required        pam_unix.so

account         optional        pam_permit.so

password        required        pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3

password        required        pam_unix.so try_first_pass use_authtok nullok sha512 shadow

password        sufficient      pam_ldap.so use_authtok use_first_pass

password        optional        pam_permit.so

session         required        pam_limits.so

session         required        pam_env.so

session         required        pam_unix.so

session         optional        pam_ldap.so

session         optional        pam_permit.so
```

Long version:

This is the 4th time trying to get LDAP running. I finally broke down and bought a book and spent 3 days reading and everything started to make sense.  :Smile:  Today was the first day I tried tying it into my system and it was a success! Now I am just trying to iron out the kinks and make sure I didn't actually break anything  :Razz: .

----------

## Duck Man

Messing around with things and thinking some more and I think it has to do with the ACL. I didn't have one set and I believe the default is to allow everyone to read everything but not write to anything. I tried to tes this theory and now I can't login  :Razz: . I'm at work right now and I have root set to only be accessible from the local console so I will have to wait till I get home before I can hopefully fix it  :Razz: .

If you have any other ideas while I wait, let me know  :Smile: 

----------

## Duck Man

I was able to get access again through a security hole I have neglected to patch up  :Razz: . Anyways... Removing the access stuff makes everything work again. I am pretty ure what is getting in the way is that users can't write to their own password attribute, hence why I was messing with the ACL stuff in the first place. So I tried the just a stupid simple:

```
access to *

  by * search
```

And it still breaks the login. I am so confused right now  :Razz: .

----------

## Duck Man

I am almost positive its my ACL messing things up, I just can't get any ACL to work without messing things up even more. Figured out today that you have to stop slapd and run slapindex to get indexes running. Is there a similar thing that needs to be done to get ACLs to work?

----------

## depontius

I think you also want your pam_unix to be "sufficient" instead of "required".  The latter will work, assuming all of your users are in /etc/passwd and /etc/shadow, but at this point ldap isn't doing anything for you.  Come to think of it, with "required" I'm not sure what happens in terms of keeping your password in sync between local files and the ldap server.  With "sufficient" you can get in with *either* local files or ldap - handy if the server goes down.

I've wanted to have central authentication for some time, even tried starting the process a few times.  I"ve never been able to dedicate the time to get it all running.

----------

## Duck Man

Your causing my head to explode  :Razz: . So if I change both to be sufficient that means that when you succeeds it breaks and therefore fail stays false and therefore we have a successful login. Since nothing else there will ever set fail to true, the pam_permit should be changed to pam_deny then right (why is the pam_permit there?)?

BUT this is assuming what is going on right now isn't working. but I am able to login to a ldap account. This tells me that pam_unix isn't failing, but returning a PAM_IGNORE. So pam_unix must return PAM_IGNORE if the user isn't found, and there for if the password doesn't work in the ldap one it will let you login anyways? But that doesn't seem to be the case either... I am so confused now...

P.S. still trying to figure out how to set ACLs in ldap

----------

## depontius

I'm guessing that at the moment you're trying to migrate your own userid from unix to ldap, which is the right place to start.  But it also means that your own userid will pass both pam_unix and pam_ldap, if both tests are done.  I would suggest adding a pair of extra userids just for testing, and add one to unix only and one to ldap only.  The unix-only userid will become generally usable for emergency maintenance, assuming you're one of us who doesn't like to login directlyas root.  It also validates the ability of a box-local userid to login without ldap.  The ldap-only userid validates the ability to login through ldap without a unix userid, though obviously you'll have to have created and initially populated a home directory somehow.  All of this leaves your own userid safe and working, the way it is now.  If everything works the way you want, then you can think about migrating your own userid to exclusively ldap.  (after you solve the ACL problems)

----------

## Duck Man

I'm actually migrating from a mysql setup. It was cool because it was easy to integrate it into my website, but it wasn't perfect and as well implemented as LDAP. But so I am actually living on the edge right now and my main account is already LDAP only. There are a few accounts that are local only as well, with the idea that some accounts don't need to be shared all over the place.

I plan on adding other boxes to the network at some point so a centralized place for user accounts will come in handy. But I am mainly doing this because it seems really cool and something I really should know. Seems like the primary way things are done in the linux world and I have actually had to mess with LDAP when programming for the company I work for to tie into AD.

Anyways, I am going to mess with the ACL some more today. Hopefully it will magically work.  :Razz: 

----------

