[Samba] SambaPosix tool

[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
>>> 'user'.
>>
>> 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?
>>
>> Regards,
>>  - 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.
>
> Rowland

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':

  /etc/nslcd.conf
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:)
HTH,
Steve