> On Wed, Jul 16, 2008 at 02:58:54PM -0700, Gary Winiger wrote:
> > > > What passwd:, group: entries are supported?
> > >
> > > You can add "ad" to any of the existing valid passwd: and group: entries.
> > > Examples:
> > > passwd: files ad OR
> > > passwd: files ldap ad
> > > > In particular how are passwd(1), getauusernam(3), getuserattr(3)
> > > > and possibly other interfaces affected.
>
>
> > > passwd(1) is not supported for "ad". Probably that needs to be addressed
> > So this project intends to modify the architecure of passwd(1)
> > where is keeps in sync a user's password across password repositories.
>
> That's a big stretch! These users will not be able to login, ergo they
> won't be able to run the passwd(1) command. Furthermore, these users
> cannot all exist in multiple repositories since AD has a notion of
> forest of domains that we don't have for Unix domains (and the password
> repositories that go with them)!
Hummm, looking at the architecture of passwd(1), it only
supports 2 repositories. I suspect this is left over from some
other day and age. It has nothing to do with whether an AD user
can login. It has to do with passwd(1) getting an error
if the nsswitch passwd: line were to look like the example
given.
Diving below the architecture, I suspect:
struct __nsw_switchconfig *conf
conf = __nsw_getconfig("passwd", &pserr);
conf->num_lookups
will be 3 in the above example.
In that case, passwd(1) looks like it will return
"Unexpected failure. Password file/table unchanged."
(localized of course).
I guess I've just ended up in this code too often.
So is this example correct? If so, doesn't it require
some change to the passwd(1) architecture dealing with the
various limitations imposed?
Gary..