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@xxxxxxxx> wrote:
* D G Teed <donald.teed@xxxxxxxxx> [080108 07:43]:> On RHEL 4, I have configured authentication for ssh accessI use MsA.D. for user auth and account info on Debian systems via pam.
> 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
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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/pam-list
_______________________________________________ Pam-list mailing list Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
