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