[Samba] SambaPosix tool
debian at lhanke.de
Thu Nov 6 04:14:45 MST 2014
Am 06.11.2014 um 07:57 schrieb steve:
> On 05/11/14 23:18, Rowland Penny wrote:
>> On 05/11/14 22:07, Lars Hanke wrote:
>>> Am 05.11.2014 um 22:31 schrieb Rowland Penny:
>>>> On 05/11/14 21:17, Lars Hanke wrote:
>>>>> As announced several weeks ago, I'd share my tool to manage POSIX
>>>>> attributes in Samba4 AD LDAP.
>>>>> You can find it at https://github.com/laotse/SambaPosix.
>>>>> It works on my particular system, but it is largely untested and
>>>>> weakly documented. But it supports a --dry-run mode, which produces
>>>>> LDIF, if you don't trust the tool. ;)
>>>>> I'll welcome contributions: tests, documentation, comments,
>>>>> extensions, fixes, ...
>>>>> Have fun,
>>>>> - lars.
>>>> After a quick scan, it would appear that you are adding 'posixAccount'
>>>> to a user, please don't do this, ADUC doesn't do this because the
>>>> 'posix*' objectClasses are auxiliaries of other objectClasses, like
>>> In a LDAP with schema these would even be required. I accept that M$
>>> doesn't do it, so it might call for another option.
>>> In my particular setup, I did not posixify all users and groups. E.g.
>>> Administrator is no POSIX user. Having the object classes around helps
>>> to filter out these, so nslcd and friends don't have to bother with
>>> incomplete RFC fields. This is to say, I see a benefit in having the
>>> objectClasses. So far I did not encounter problems. Is there any
>>> trouble known?
>>> - lars.
>> OK, I see where you are coming from, but what if you come up with
>> something that requires these objectClasses, but somebody then decides
>> to add a large group of users with ADUC (these will not have the posix
>> objectClasses), these users will not show up in whatever it is that you
>> are using that requires the posix objectClasses. I personally think that
>> it is better to only rely on objectClasses & attributes that ADUC would
>> add, that way you can never have problems caused by the posix
>> objectClasses being there or not.
>> What you have to remember is, you are now dealing with AD not LDAP.
> It's OK because modern versions of nss-ldapd and sssd look 'behind' the
> DN for those classes. Here is the arrangement for the nslcd 'ad-backend':
> uid your-user
> gid your-group
> #If you do not have the posixAccount class then uncomment filters
> #filter passwd (objectClass=user)
> #filter group (objectClass=group)
> uri ldap://your.site
> base dc=your,dc=site
> map passwd uid samAccountName
> map passwd homeDirectory unixHomeDirectory
> sasl_mech GSSAPI
> sasl_realm YOUR.SITE
> krb5_ccname /your/ticket
> sssd does it by itself:)
What do nslcd and sssd do, if an account doesn't have 'uidNumber'?
Winbind invents one, which is something I explicitly do not want.
More information about the samba