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. > > 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. "I have SFU installed on SBS, will nss_ad still work?" was the question I was after. 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. This was mostly for curiosity. I'm not interested in dwelling -- moving along. Thanks for the response. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080718/acf08dc0/attachment.html>
