Samba PDC as a password server

[Dana Canfield]

Luke Kenneth Casson Leighton wrote:

> > Has anyone tried it with a really large passwd file?  I'm extremely cautious
> > of PAM right now.
>
> i'm cc'ing your message to the pam list, because this issue has just been
> raised there: your experiences, dana, will be useful feedback, and i am
> sure that someone on the pam list will let you (us) know if any
> performance improvements in pam_pwdb (or other) have been made.

As I mentioned before, I've got a large environment and a machine in which I can
do *some* experimentation, so if it helps anyone, I'm willing to test some things.

> > PAM support.  (I'm certainly open to the possibility that this might be a
> > configuration error, but RedHat had no
> > suggestions, either.)  My concern is that if PAM_NTDOM isn't lightning-fast,
>
> do you consider 12-15 packet exchanges totalling about 10k of network
> traffic just to verify one user to be "lightning fast", regardless of the
> system it is implemented on (samba or NT)?
>
> because this is what happens.  the LsaSamLogon response alone can be
> anything between 500 and 800 bytes, and the rest of the traffic is just to
> establish "common ground" etc.

Let me clarify my concern:  It sounds as though (despite the security risks), most
of us are looking for a method to allow our users to have a single logon.
Assuming we want to use NT on the desktops, that means we need to use NT-style
encryption since NT encrypts beforesending.  Now, if we want to try to eliminate
duplicate password files we need to find some way to make Unix authenticate to the
NT passwords.  We can do that with PAM_NTDOM, but this means that ALL
authentication has to go through this module.  Considering
the overhead mentioned above, it sounds as though this might not be such a great
idea if you are serving a lot of users through a lot of services.

Initially, it may not sound as though two password files are such a bad thing.
But my biggest concern is that none of the schemes I've seen so far have a
contingency in case one password change is successful, but the other one fails.
We would need to go back and un-change the first one, making for a rather complex
scheme. The only "tidy" solution I can think of that might keep overhead low is to
create some kind of "pam_smbdb".  This would work just like pam_pwdb, but would
work with NT-style encryption, meaning you could yank out /etc/passwd and replace
it with the contents of smbpasswd.  Does anyone know if there is a way to format
the smbpasswd file that wouldn't break the system calls such as getpwnam(),
getpwuid(), etc.?  What happens if we tack this on to the end of a "standard"
passwd file line (with a standard password replaced by an NT-style password)?

Am I way off base on this?

Dana