[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