Kyle McDonald wrote:
> Nicolas Williams wrote:
>
>>>> 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 SFU required to use only NFSv3 between Solaris Machines?
>
> Is NFSv4 required for any of this?
>
>>> 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.
>>
>>
>>
> But Linux SMB mounts are done as a single UserID right?
>
>
> If IT will allo me to run my own AD sub domain, can I run SFU only
> there, and pass the parent domain User/Passord info through to Solaris
> and Linux?
> That's not exactly ideal, but might ork better than getting them to run
> SFU the way I'd need them to.
>
> I'm guessing SFU basically adds a AD<->NIS proxy to the AD server? Does
> it appear as a NIS server to the Linux and Solaris clients? or something
> else? NIS+?
> Any idea if a Solaris NIS server can be a slave to the SFU one (assuming
> my guess above is correct?)
>
>>>> 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.
>>
>>
>>
> That sounds the most striaght forward, but that's the one Linux doesn't
> support yet right?
>
>> 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.
>>
>>
> Even that sounds good to me.
>
>> 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.
>>
>>
>>
> That sounds like it might be great in some situations, but I don't think
> it'll ork for me... Than again after I read everything I might change my
> mind.
>
>> 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.
>>
>>
>>
> By local, you mean local to the local machine? or can these mappings be
> stored in NIS or NIS+? and shared beteen machines?
> For that matter can the Rule Mapping mentioned above be distributed in
> NIS, NIS+, or someother (non-AD) LDAP?
>
> Either way I bet Linux doesn't have anything that matches up.
>
Just in case you haven't seen this
http://directory.fedoraproject.org/
http://directory.fedoraproject.org/wiki/Features
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
