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

Nor is RBAC (after all, if AD users will not be able to login on Solaris
using nss_ad, then they won't need rights profiles, nor will they need
to run the passwd(1) command.  As for administrators, if they have AD
they know how to administer it, and if they really want to use Unix
commands to change AD users passwords they can always use kpasswd(1).

>       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)!

Of course, when we get around to adding logon support here we'll have to
ensure that passwd(1) can change AD users' passwords.

>       It further seems to add a 3rd name service repository where
>       in the past only two were implicitly supported.

I'm not sure that "in the past only two were implicitly supported," nor
why that would limit us now if it was an unstated limit.

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

Yes (and if not, we'll make sure it does).  getusernam(3SECDB) goes
through the name service switch, after all, so the full engine's support
for nsswitch.conf entry "criteria" is supported.

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

getpwY() and getusernam() both follow the one 'passwd' database
configuration from nsswitch.conf.

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

Sure, but note that we're not changing how anything works in the name
service switch (except to allow the name service switch to pass
ephemeral IDs) or elsewhere, thus all these questions' answers are
implied.

Nico
-- 

Reply via email to