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

[Gary Winiger]

> > 	My concern is here in nsswitch.conf(4) functionality.
> > 	From the provided it's not clear what the project is
> > 	proposing.
> >   
> 
> This case basically allows any application using 
> get{pw,gr}{nam,uid,gid}() interfaces to resolve Windows users and group 
> names using native Active Directory schema. (nssad_details.txt, Section 
> 6, Bullet 6 has the example).
> 
> > 	+     When using Active Directory with native schema for name service,
> > 	+     the default configuration should be modified to use ad for
> > 	+     for passwd and group, dns for hosts resolution and files
> > 	+     for the remaining databases on client machines.
> >
> > 	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.
	It further seems to add a 3rd name service repository where
	in the past only two were implicitly supported.
	
	For those name services databases that follow the passwd:
	entry, audit_user(4) and user_attr(4) in particular will
	there be any issues in lookup?  If not found in the first or
	second entry, will the (now third) be processed?

	Will getpwnam type stuff function like:
	passwd: files ldap ad
	And getauusernam() and getuserattr() function like:
	passwd: files ldap [NOTFOUND=return] ad

	IMO, it is important to understand this and ensure that users
	of nss_ad are correctly informed.

Gary..