s4: new classicupgrade and uids

[Andrew Bartlett]

On Fri, 2012-06-22 at 13:42 +0400, Sergey Urushkin wrote:
> HI.
> 
> 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? 

I can't think of any.  

> 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

The best approach would be for you to prepare a series of patches to
improve the python script that handles this:
source4/scripting/python/samba/upgrade.py

I want this tool to be as useful as possible to administrators, so
rather than me guessing, you know what you need, and can test that it
works just right.  I can then review and hopefully include them!

On primaryGroupID/gidNumber, we should carefully look at how that
interatiction works.  On loginshell etc, the main issue with including
them (which makes sense) is that at the moment, the s4 winbind won't
honour them (the clients can of course) .  I know this is a pain point,
but it's also harder to fix (patches for this more difficult issue also
welcome). 

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org