[Samba] SambaPosix tool

[Rowland Penny]

On 06/11/14 11:15, Lars Hanke wrote:
> Am 05.11.2014 um 23:18 schrieb Rowland Penny:
>> 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.
>
> I pondered on that last night. Someone using ADUC probably uses a 
> different profile on the libnss-ldap* end. E.g. ADUC puts the POSIX 
> user name in 'msSFU30Name'. It may be an idea to add profile options 
> to the tool, including profiles for ADUC compatibility. But I'll have 
> to further explore ADUC to detail what that might be.

If you add unix attributes with ADUC, you get these:

uid: <username>
msSFU30Name: <username>
msSFU30NisDomain: <lowercase workgroup name>
uidNumber: <a unique id number>
gidNumber: <users primary unix group id number>
loginShell: </bin/bash>
unixHomeDirectory: <users unix home directory path>
unixUserPassword: ABCD!efgh12345$67890 # All users get this password 
unless password syncronization is turned on

It does not add the posixAccount objectClass.

>
> On the other hand admins using a Linux console and those using ADUC 
> probably have a small cross-section. The profile option will help 
> infrastructures with admins of both sorts.

You should, if possible, add the same attributes as ADUC, as you are 
writing a new script, it should take this into account.

>
> My environments are Linux centered. Most Windozers are VM. Windows is 
> only used to run specialized software not available under Linux. So I 
> would sacrifice ADUC compatibility for benefits on the POSIX side. The 
> core benefit of AD, i.e. cross-platform SSO, must however be maintained.

With Samba4 you have available all the rfc2307 attributes and a pure 
windows user that never connects to a Linux machine as a Linux user, 
doesn't need the rfc2307 attributes.

If you really want your script to be of use, convert these bash script 
excerpts to python:

# Finds the next useable user uidNumber or group gidNumber
# Input : $1
# $1 : msSFU30MaxUidNumber or msSFU30MaxGidNumber
# Output : the first free uidNumber or gidNumber
_findnext () {
   _NEXTID=$($LDBSEARCHBIN -H $DBPATH -b 
"CN=$LDOMAIN,CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System,$SUFFIX" 
-s sub '(objectClass=msSFU30DomainInfo)' $1 | grep "$1: " | awk '{print 
$NF}')
   if [ -z "$_NEXTID" ] || [ "$_NEXTID" -lt "$IDSTART" ]; then
     _NEXTID="$IDSTART"
   fi
}

# UPDATE msSFU30MaxUidNumber/msSFU30MaxGidNumber
# Input : $1 $2
# $1: what to update (msSFU30MaxUidNumber or msSFU30MaxGidNumber)
# $2: Next Number
#
# Output : Nothing
_updatemax () {
log_output "Updating $1"

echo "dn: 
CN=$LDOMAIN,CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System,$SUFFIX
changetype: modify
replace: $1
$1: $2" > /tmp/newgid

$LDBMODIFYBIN --url=$KERBEROS /tmp/newgid  2>>"$LOGFILE" 1>/dev/null
if [ $? != 0 ]; then
     log_output "Error updating $1 in AD."
     exit 1 # exits here if error
fi
rm -f /tmp/newgid
log_output "Successfully updated $1 in AD"
}

If you could add something like the above, you wouldn't have to store 
the next uidNumber or gidNumber anywhere (i.e. scribbled on a bit of 
paper), they would be stored in AD, where they are supposed to be.

Rowland

>
>
> I never used the M$ POSIX integration stuff (is there anything beyond 
> NFS?), but I accept that we should not break that.
>
> Regards,
>  -lars.
>