useradd vs system-config-users and pam

[D G Teed]

Hi,

Thanks for this suggestion.  I still don't understand why passwd and
useradd work OK on RHEL 5 while winbind is set up up for passwd
in nsswitch.conf .  Odd.  Anyway, keeping it to just "files" works fine
for AD based authentication, so that's great.

I might consider your method down the road when we have a larger
implementation of users to handle.

Regards,

--Donald

On Jan 8, 2008 10:58 AM, <Jonathan.Detert at msoe.edu> wrote:

> * D G Teed <donald.teed at gmail.com> [080108 07:43]:
> >    On RHEL 4, I have configured authentication for ssh access
> >    via Active Directory authentication, using the
> >    system-config-authentication
> >    GUI.  Users can login OK with either local authentication or AD
> >    authentication.
> >
> >    However, two system commands are misbehaving.  useradd refuses to
> >    add someone to the system if they are found in AD.  The error
> >    is simply in the form of  "useradd: user john exists".  I've heard
>
> I use MsA.D. for user auth and account info on Debian systems via pam.
>
> My guess is that you have more than one source listed in
> /etc/nsswitch.conf for the 'passwd:' name type, and that one of them
> indicates MsA.D. (probably 'ldap' or 'winbind').
>
> If you want to use MsAD solely for auth - i.e. not for anything else in
> the traditional passwd(5) entry (e.g. uid, gid, login shell, home dir),
> then remove the source in /etc/nsswitch.conf for the passwd: name type
> that uses MsAD.
>
> That would allow you to useradd and passwd to your heart's content, and
> only operate on the values in your local /etc/passwd file.  The only way
> you'd then use msad would be this:
>
>        if the username in /etc/passwd also existed in msad, you'd do
>        your auth against msad instead of /etc/shadow.  The value in
>        /etc/shadow would be immaterial (but shouldn't be null).
>
> You may have to modify /etc/pam.d/common-account to not use msad as well
> - I'm not sure.
>
> What I do, which you might be interested in, is to use msad for both
> auth and passwd(5) info (uid, gid, login-shell, home dir).  Note that
> this does require you to 'extend' your msad schema to include those
> posix login attributes (but ms provides this kind of extension as a free
> option).  The beauty of this is that combined w. pam_mkhomedir,
> pam_winbind, and pam_winbind's 'require_membership' attribute, you can
> use msad group membership to govern access to your linux server.  All
> you have to do is put the msad user in the appropriate msad group, and
> automatically, they have access to your linux server.  No useradd.  No
> setting the passwd.  Nothing.  Just put them in the msad group.
>
> Likewise, to revoke a user's access to your server, just remove the
> luser's msad account from the msad group.
>
> >    the passwd command may also be trying to update the password
> >    on AD rather local.
> >
> >    We can work around the problem by running the GUI system-config-users
> >    - this works fine to create new users or set the local password.
> >    So I wonder if pam settings for the system-config-users
> >    GUI are somehow giving us local target for the user creation
> commands.
> >    Running strings on the useradd command I don't find any pam
> reference.
> >    There is no pam.d entry for the useradd command as a file named
> useradd.
> >
> >    Our intentions are to use AD to authenticate only, not to allow users
> to
> >    manage
> >    their password or anything about their AD account from the Linux
> host.
> >
> >    Can anyone give a hint about what we should adjust to point useradd
> >    and passwd commands to local mechanisms?
> --
> Jon Detert
> IT Systems Administrator, Milwaukee School of Engineering
> 1025 N. Broadway, Milwaukee, Wisconsin 53202, U.S.A.
> --
> "Most of the trouble in the world is caused by people wanting to be
> important."
> ~ T.S. Eliot
>
> _______________________________________________
> Pam-list mailing list
> Pam-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pam-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pam-list/attachments/20080109/f1d04d2e/attachment.htm>