Am 30.09.2009 21:44, schrieb Howard Chu:
> 
>> Date: Wed, 30 Sep 2009 15:52:59 +0200
>> From: Florian Manschwetus<florianmanschwetus at gmx.de>
> 
>> Ok, basically we have currently on opensolaris two choices:
>> nss_ldap =>  alows the use of directory based mapping (unix nuid and ngid
>> and so are stored in directory (as in my case))
>> nss_ad =>  allows easy and clean access but relies currently on generated
>> nuid and so
>>
>> Problems:
>> 1. General
>> - Normally solaris is limited to 16 group-memberships for a single user
>>
>> 2. nss_ldap
>> - can't search the complete directory for users/groups (no idea why)
> 
> Probably because AD uses so many referrals to glue its tree together,
> you need to look into configuring referral chasing.
> 
>> - need a modification to support DN as membership attribute and allow so
>> recursive group-memberships (otherwise it would need additional manual
>> membership handling)
> 
> Should already be supported as part of RFC2307bis. Certainly the
> PADL-based nss-ldap does. Also nss-pam-ldapd and OpenLDAP nssov support
> that.
> 
Oh, is there an indiana package for the PADL-based one? I use it
successfully on linux for that.

Florian

>> - incomplete group mapping leads to idmap problems with cifs-server
>> (maybe there is a workaround)
>>
>> 3. nss_ad
>> - seems to not support directory based id-mappings
>> - currently I was always unable to configure it correctly
>> - need a fine documentation (not found a really nice one)
>>
>> maybe some one could correct me if I made a mistake.
>>
>> The plan is to use the directory based nss and kerberos to authenticate
>> network fs (nfsv4 and cifs, maybe webdav) and system access (ssh,
>> pfexec).
>>
>> Kerberos works fine so far, but the nss stuff isn't solved kindly
>> currently so, some hints or advices are welcome.
>> If someone could give me a good documentation how the things are
>> evolving, I'm willing to do my best to make the things go faster.
> 
> Perhaps more low-level than you're asking for, but this is how things
> are evolving...
> 
> http://tools.ietf.org/draft/draft-howard-rfc2307bis/
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3686 bytes
Desc: S/MIME Cryptographic Signature
URL: 
<http://mail.opensolaris.org/pipermail/sparks-discuss/attachments/20090930/182d64cf/attachment.bin>

Reply via email to