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

[Baban Kenkre]

Gary Winiger wrote:
>> Nicolas Williams wrote:
>>     
>>> On Tue, Jul 22, 2008 at 04:07:16PM -0700, Gary Winiger wrote:
>>>       
>>>> 	Hummm, looking at the architecture of passwd(1), it only
>>>> 	supports 2 repositories.  I suspect this is left over from some
>>>>         
>>> The question is:  Is this architecture?  Where is it written that
>>> passwd(1) has/must have this limitation?  If it isn't a stated
>>> limitation then we'll simply fix this bug, otherwise we'll simply change
>>> that limitation.
>>>
>>> passwd(1) says:
>>>
>>>      When a user has a password stored in one of  the  name  ser-
>>>      vices  as  well  as  a local files entry, the passwd command
>>>      updates both. It is possible to have different passwords  in
>>>      the  name  service  and  local files entry. Use passwd -r to
>>>      change a specific password repository.
>>>
>>> I don't think that implies a limit of two name service backends for the
>>> passwd database.
>>>       
>> passwd(1) also says:
>>     
>
> 	IMO, there is still an incomplete specification here.  The
> 	getxby stuff is clear enough from the discussion, but IMO,
> 	not from the man page changes.  IMO, that's a NIT that can be
> 	worked off line.
> 	It's the putxby stuff as privately implemented since SunOS 2.x/3.x
> 	when NIS (nee yp) was added to passwd that has been brought
> 	forward to/through the name service switch that is more the
> 	architecture that I'm finding a need for more detail.  Indeed
> 	not all architecture is captured in man pages.  And without
> 	doing a good bit of archaeology on passwd/passwdutil, name
> 	services (probably also nisplus) ARC cases, I can't say if the
> 	two backends architecture was ever formally presented.
>   


The nsswitch is capable of supporting multiple backends 
architecture-wise. However in the past we have told customers (and is 
also mentioned in nsswitch.conf manpage) that we do not support mixing 
nis, nisplus and ldap name services on a single box. This is because we 
have not tested these configurations and we do not provide any tools to 
the customer to install/configure their systems in such manner. (For 
e.g. ldapclient does not allow the user to keep their existing 
nis/nisplus configuration alongwith ldap. They have to manually move 
files which is not supported). Therefore all that  remains and which 
were tested are the single and two-backends (where one must be files) 
configurations. Removing this restriction will require testing 
configurations involving multilple non-ad backends and is beyond the 
scope of this case.

Therefore for this case, I suggest we notify users through 
nsswitch.conf(4) and passwd(1) manpages that adding "ad" to the existing 
valid configurations is supported and that "ad" will be skipped during 
password updates via passwd(1).

--Baban


> 	I can say it is present in the code and has been explicitly
> 	called out for some time.  IMO, that may not make it formal
> 	architecture, but it also does not make it a bug.
> 	Back to my original concern:  Is this case modifying the passwd:
> 	(and any other database:) architecture to allow for more than
> 	two name services?  If so, will ad be explicitly worked around
> 	in the passwd(1) implementation (including the putxbyy private
> 	implementations and interactions with nsswitch)?  How will
> 	such be documented for the admin/user?
> 	Please don't interpret this as opposing adding nss_ad, or
> 	changing the nsswitch or passwd/passwdutil/putxbyy architectures.
> 	It's that these are security relevant and don't seem to me
> 	well enough specified in the case materials.
>
> Gary..
>   
>> ....
>>       If all requirements are met, by default, the passwd  command
>>       consults  /etc/nsswitch.conf  to  determine in which reposi-
>>       tories to perform password update. It  searches  the  passwd
>>       and  passwd_compat entries. The sources (repositories) asso-
>>       ciated with these entries are updated. However, the password
>>       update configurations supported are limited to the following
>>       cases. Failure to comply with  the  configurations  prevents
>>       users from logging onto the system. The password update con-
>>       figurations are:
>>
>>           o    passwd: files
>>
>>           o    passwd: files ldap
>>     
> _______________________________________________
> sparks-discuss mailing list
> sparks-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/sparks-discuss
>