s4: new classicupgrade and uids

Sergey Urushkin urushkin at telros.ru
Fri Jun 22 03:42:34 MDT 2012


22.06.2012 12:11, Andrew Bartlett написал:
> On Thu, 2012-06-21 at 16:43 +0400, Sergey Urushkin wrote:
>> Hi!
>> I've just made a test upgrade from s3 with the new uid/gid migration
>> feature and I have some questions:
>> 1. Computer accounts have objectclass:posixAccount and uidNumber
>> attributes. What is it for? As far as I know unix computer accounts are
>> needed only for s3 dc, am I right? If so, than computer accounts should
>> be excluded somehow.
> Computers can log in and own files, and so we need to preserve the
> uidNumber that has been assigned, to preserve this file ownership.
I know they can with these settings, I'm just wondering where such
ownership could be used with nix systems?
>> 2. 'Administrator' hasn't got an uidNumber (while it had it in
>> openldap), so it makes me map it manually. Is it a bug or feature?
> Simply a bug. 
As I wrote in another branch - 'guest' is also affected. Should I write
report, or it'll be fixed in place soon?
>> 3. To have an ability to manage user's uid, gid, etc. through dsa.msc we
>> need to add NIS domain to AD. And then add some attributes to
>> accounts/groups. Why not to add NIS domain (it's a simple ldif) to
>> config while provisioning (named as workgroup by default and also have
>> an provision/classicupgrade option to change the name) and then
>> additionally modify users like this:
>> changetype: modify
>> replace: msSFU30NisDomain
>> msSFU30NisDomain: $NISDOMAIN
>> -
>> replace: msSFU30Name
>> msSFU30Name: $USER
>> and groups like this:
>> changetype: modify
>> replace: msSFU30NisDomain
>> msSFU30NisDomain: $NISDOMAIN
>> -
>> replace: msSFU30Name
>> msSFU30Name: $GROUP
> I thought that the whole point of the new rfc2307 support was to avoid
> needing to set these SFU attributes?
Maybe I missed discussion about it, I'm just trying to say that support
for these attributes (as a nis domain schema modification) are needed to
manage unix account via dsa.msc.
'msSFU30NisDomain' (and that mean nis schema too) is needed to be able
to change unix atrributes.
'msSFU30Name' seems to be optional, it is filled with account name by
dsa.msc automatically after pressing apply button on unix tab, and since
it can't be changed via dsa.msc (e.g. after renaming account), it can be
leaved unmanaged by samba too, so resulting minimal ldif for
users/groups is:

changetype: modify
replace: msSFU30NisDomain
msSFU30NisDomain: $NISDOMAIN

I don't understand what disadvantages we'll get after adding NIS support to s4? 

Also, another question appeared from another branch of this threat:
4. gidNumber for users is not set too after upgrade. Until it's set we
can not use s3 winbind rfc2307 mode with s4 dc. Maybe it's also about
loginshell, unixHomeDirectory...

# samba --version
Version 4.0.0beta3-GIT-9089d48


Best regards,
Sergey Urushkin

More information about the samba-technical mailing list