On Wed, Jun 18, 2008 at 06:53:08AM -0400, Kyle McDonald wrote:
> >>                                             as a Domain Controller?
> >
> >No.
> >  
> That's OK. But (liking Solaris as much as I do,) it seems a shame to 
> leave Windows as the only system that can be the authoritative source 
> for this stuff. :)

Well, Sun should have made a large investment in directories and network
authentication when it became obviouw that MSFT was doing the same.  Or
even immediately post-win2k.

> >The solution we use works for Solaris.  We made no changes to Linux.
> >
> >You can still interop with Linux and use Windows identities provided
> >that you have a Unix name service with users and groups that are the
> >equivalents of Windows ones.  SFU will do as a such a name services.
> >
> >  
> Is SFU the only option right now?

If you want NFSv3 interop with Linux, yes.

Other options: interop with Linux via CIFS.

>                                   Is MS still developing/supporting SFU? 

Yes, but it's not a separate product anymore -- it's fully bundled now.

> I thought it was either dead or at least on life support only now?

Nope.

> What are my choices if the people who run the AD and Windos 
> infrastructure refuse to install SFU?

No interop with Linux with NFSv3.  Try using CIFS.

> >It's not the same algorithm, except for name-based mapping, where it's
> >close enough.
> >  
> I'm not sure I get this statement, but maybe I'll get after I read all 
> the other blogs and docs you pointed me to. Thanks!

idmapd supports just these ID mapping methods:

 - directory-based name mapping
 - rule-based name mapping
 - ephemeral ID mapping
 - local SID mapping

The first one works by adding attributes to your AD or native LDAP
schema to name an entity's equivalent entity on the other side.

The second works by providing local rules that tell you how to map an
entity on one side to one on the other.  These rules also work with
names.

Ephemeral ID mapping dynamically allocates UIDs and GIDs to Windows
entities on demand.  The pool of UIDs and GIDs used for this is the 2^31
to 2^31-2 range of UID/GID values.  We took pains to make sure that the
system does not store these anywhere permanently, and we restart the
allocations on reboot.  ZFS stores SIDs now.

Local SID mapping is used to map non-ephemeral UIDs/GIDs to RIDs
relative to the local SID when there's no other way to map them.

> >We're considering adding more ID mapping options too.
> >
> >  
> What types of things are you considering? (If you can talk about them?)

Direct support for SFU (right now you have to configure either DS-based
name mapping or local name rules + nss_ldap with schema mapping to get
SFU support).

Also, perhaps we might want to add some algorithmic ID mapping schemes.

> Thanks!

NP.
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Reply via email to