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

Nicolas Williams Nicolas.Williams at sun.com
Fri Jul 18 14:51:07 PDT 2008


On Fri, Jul 18, 2008 at 03:59:09PM -0500, Mark Martin wrote:
> On Fri, Jul 18, 2008 at 3:30 PM, Nicolas Williams <Nicolas.Williams at sun.com>
> wrote:
> > There's plenty of documentation, starting with the CIFS server admin
> > guide, which contains the ID mapping admin guide, as well as various ARC
> > cases, man pages, ...
> 
> True enough.  Unfortunately, at least some of the referred ARC cases are
> closed, and the only materials in this caselog available publicly are the
> onepager and the email sink.  I wasn't able to find the answer on SBS in the
> referred materials (or on Winchester's project page nor SunDocs). I know
> from personal experience nss_ldap requires extra twiddling for that schema,
> and I was curious about this case.

We should look into opening related closed cases.

In any case, the answer to your question is that nss_ad will require no
additional features from AD -- it will work with Windows 2000 through
Windows 2008 without requiring the deployment of SFU (bundled in Windows
2003R2).

nss_ldap does require schema mapping, but this case is not about
nss_ldap.

(For the benefit of ARC members, "SBS" stands for Small Business Server,
which is a flavor of Windows that includes Active Directory.)

> > The case materials for this case indicate that SFU will not be used by
> > nss_ad for any purpose, although a future case may add support for using
> > SFU in idmapd for mapping Windows users in _one_ domain to non-ephemeral
> > UIDs and GIDs.  Such a future case would cause nss_ad to indirectly
> > support SFU for the same purpose because nss_ad will use ID mapping APIs
> > for mapping Windows SIDs to UIDs/GIDs, and consequently nss_ad will use
> > idmapd.
> 
> It doesn't explicitly prohibit the use of SFU either, though, from the man
> page excerpts I can see in this thread.

The original e-mail said:

  o  nss_ad will not support SFU initially and will be limited to
     native AD schema.  If SFU is deployed then nss_ldap must be used.


>                                          "I have SFU installed on SBS, will
> nss_ad still work?" was the question I was after.

The answer is "yes," and it's so because whether or not you use SFU
there will be Windows-specific user/group information in AD, and that is
what nss_ad uses.

>                                                    Call it migration from
> the legacy solution.  I suspect that's a question better posed in general to
> the CIFS client/idmapper team as it would appear that's where the dependency
> is.

Considering that you will not be able to login on a Solaris system using
Windows user accounts resolved via nss_ad, I think it's too soon to
speak of "migration from the legacy solution."  Future cases may redress
this, but until then if you wish to login on Solaris with a Windows user
account then you'll have to keep using nss_ldap with schema mapping.

> This was mostly for curiosity.  I'm not interested in dwelling -- moving
> along.  Thanks for the response.

No problem.  These are good questions.  Thanks for participating!

Nico
-- 



More information about the opensolaris-arc mailing list