s4: new classicupgrade and uids

[steve]

On 06/22/2012 09:09 AM, Sergey Urushkin wrote:
> Hi.
>
> 21.06.2012 19:09, steve написал:
>> On 06/21/2012 02:43 PM, 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, that we can join Linux clients to those
>>> attributes so am I right? If so, than computer accounts should
>>> be excluded somehow.
>> Hi
>> We use those attributes so that we can join Linux clients to the
>> domain and users can login with them without having to use winbind.
> But how can computer's uidnumber attribute help us with this... Joining
> works without computer posix accounts. ldapd, sss, nss_ldap doesn't need
> computer accounts.
We need computer accounts for Kerberos to work. It is the user who logs 
in, but only if the computer account is present. To be able to login to 
Linux, the rfc2307 attributes need to be present. We currently store:
uidNumber
gidNumber
loginShell
uid (map   passwd    uid    samAccountName)
unixHomeDirectory (map    passwd    homeDirectory    unixHomeDirectory)
gid
(nss mappings in brackets) in the directory.

A Linux user logs in and is placed in his home directory. Files he 
creates there have the correct attributes. It is just as if he has 
logged in as in the old days under NIS.

>   We can also export computer creds into keytab without
> posixaccount objectclass. Uids are only needed for owning files and nss
> info, and I don't see any reason to support setting computer as an owner
> and logging in as a computer (at least by default).
The computer does not log in. The computer account is stored in the 
keytab (we use net ads join on the Linux client and then net ads keytab 
create) on the client and in the directory. We need the keytab on the 
client for kerberized NFS. The user logs in and the user owns files.
>>> 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?
> Here, seems that "Guest" account is also affected.
You can add rfc2307 attributes to Administrator if you like as you but 
any kerberos stuff Administrator has to do (like kerberized nss ldap 
binds) can be done via kinit or setting up e.g. a keytab for a user who 
can access nss. Also we have root on Linux who can do just about 
everything on the directory without kerberos.
>>> 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
>>>
>>> Thanks.
>>>
>> We made a simple script to do this without changing the schema. We
>> manage most of the domain from the s4DC and rarely touch ADUC.
> But we still don't have something like 'samba-tool user unix ...' and
> 'samba-tool domain nis ...' and all managing of unix attribs is made
> with external tools (you suggested, I have one too).
No, we don't have that in samba-tool. That is what our scripts do. They 
give you the equivalent of e.g.
samba-tool user add steve --unix
or
samba-tool group --make-unix
> Schema modification I made works and replicates well (I've been using it
> for tests for more then half of a year) , so I don't see actual reason
> why not just to implement it. In summary to begin we need one ldif with
> 2 params - basedn and nis domain, one option to provision/classicupgrade
> (--nis-domain), and user/group provisioning modifications showed above.
> I would be glad to make it but my python is not good, anyway I'm ready
> to help with testing.
>> The main reason we don't use winbind is because our unixHomeDrirectory
>> attributes do not all point at the same directory.
>>
> It's a problem for s4 winbind, but s3 winbind works nicely with rfc2307
> schema and respects attribs like uid, unixHomeDirectory.
>> The script is here. It has many similarities to your sfu example for
>> the most part.
>> http://dl.dropbox.com/u/45150875/s4bind.tar.gz
>>
> Thanks for the script.
>
> Also, another question appeared:
>
> 4. gidNumber for users is not set too. Until it's set we can not use s3
> winbind rfc2307 mode with s4 dc. Maybe it's also about loginshell,
> unixHomeDirectory...
>
> Thanks.
>
We set:
  objectClass posixGroup
  gidNumber
for groups created with samba-tool so that they appear correctly via nss 
(getent and stuff).

The gidNumber for the user is also stored along with his other rfc2307 
stuff in the directory.

e.g. We made Domain Users into a posix group.

Cheers,
Steve