[sparks-discuss] Active Directory name service module (nss_ad) [PSARC/2008/441 FastTrack timeout 07/18/2008]

[Gary Winiger]

> 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..