Fwd: Re: s4: new classicupgrade and uids

Sergey Urushkin urushkin at telros.ru
Thu Aug 9 01:49:14 MDT 2012


09.08.2012 11:17, Andrew Bartlett пишет:
> On Thu, 2012-08-09 at 10:25 +0400, Sergey Urushkin wrote:
>> 08.08.2012 15:29, Andrew Bartlett пишет:
>>> On Wed, 2012-08-08 at 15:21 +0400, Sergey Urushkin wrote:
>>>> 08.08.2012 12:55, Andrew Bartlett пишет:
>>>>
>>>>> On Wed, 2012-08-08 at 11:01 +0400, Sergey Urushkin wrote:
>>>>>> Hi.
>>>>>> Some time ago I sent the patch to the list, but didn't get answer. For
>>>>>> better readability it's attached again.
>>>>>> The problem with it now is that it may set administrator uid to non-zero
>>>>>> value (what will break GP editing, until appropriate posix acls is set.
>>>>>> As a workaround - chown -R administrator path/to/sysvol). It may need
>>>>>> additional warning message.
>>>>> My thoughts are that I don't like the upgrade handling any of the well
>>>>> known users, except perhaps to assign a UID.  Even then, things like
>>>>> administrator UID should be connected via the provision() stage.
>>>> Then, may be we should add some default uid/gid attributes to
>>>> wellknown users/groups on the provision stage (if --use-rfc2307 is
>>>> used add them to the directory too). That would also be a step to
>>>> provision default posix acls for sysvol. Here is the list which I feel
>>>> needed and suggested values.
>>>>
>>>> name : sid : uid/gid
>>>> ---------------------------------
>>>> Administrators    :    S-1-5-32-544    :    300544                -
>>>> should to be synced on all dcs (it's a part of default ms's sysvol
>>>> permissions)
>>>> Server Operators    :    S-1-5-32-549    :    300549            - the
>>>> same
>>>> Authenticated Users    :    S-1-5-11    :    300011              - the
>>>> same
>>>> Local System    :    S-1-5-18    :    300018/300018             - the
>>>> same
>>>>
>>>> Administrator    :    S-1-5-21domain-500    :    0/0
>>>> Guest    :    S-1-5-21domain-501    :    nobody's uid/nobody's gid
>>>> Anonymous    :    S-1-5-7    :    nobody's gid
>>>>
>>>> What do you think?
>>> I don't mind assigning a UID in the directory based on the imported
>>> values to well known users, but I'm just saying we need to be careful
>>> about actually 'importing' the user.
>> If you are suggesting importing only uid and gid for wellknown accounts,
>> then I'll change the patch such way.
>> But could you explain why we need to import it via provision()? For
>> example, "domain admins" is a wellknown account too, but we don't import
>> it via provision().
> We do create "domain admins" during provision. 
Sorry, I meant we don't import "domain admins" gid.
>> Another question is what I wrote previously: for >1 DC's domains we need
>> to write at least several account's uid/gid to the ldap while
>> provisioning, to have acls synced. So, some uid/gid initialization is
>> needed for provision anyway. And in the case of classicupgrade
>> s3-existed account uids would be overwritten. Doesn't it look reasonable?
> It is reasonable to set these UID values to the s3 accounts, but I don't
> want to import the s3 accounts, just modify the provision-provided
> accounts.  We also need to take care that some things are done during
> the provision, that uses the id map, so we have to set
The patch doesn't create any accounts, it just adds posix attributes to
provisioned wellknown accounts (like if they were imported accounts),
see this part of the patch:

-        s4_passdb.add_sam_account(userdata[username])
+        if username.lower() == 'administrator' or username.lower() ==
'guest' or username.lower() == 'krbtgt':
+            logger.warn("  Skipping wellknown provisioned user '%s'",
username)
+        else:
+            s4_passdb.add_sam_account(userdata[username])


And about provisioning uid/gid for some wellknown accounts in ldap. As I
understood you don't mind implementing this, then I'll try to prepare
another patch.
>
>>>>>> Also, I have to say that "if entry['rid'] < 1000:" check gives an error
>>>>>> at the "adding users to groups" stage (nonexisting user). Ways to solve it:
>>>>>>  1. Stop provision with error if such accounts exist (think it's the best)
>>>>>>  2. Add some workaround to the function that lists members
>>>>>>  3. Remove this check.
>>>>> I'm not entirely sure what you mean here.  I guess we do need to upgrade
>>>>> groups of any well known users we find?
>>>>>
>>>> If group contains user with rid < 1000 (skipped), then
>>>> add_users_to_group ends with error (because this user hasn't been
>>>> actually imported), and upgrading fails.
>>>> So, if there are 1000 users, we have to wait for a really long time
>>>> (while all users are being imported) to just see an error at the end.
>>>> I think we should give an error immediately, or test somehow for user
>>>> existence in s4 db before trying to add it to some group.   
>>> What users are you importing with a sid below 1000 that Samba4 doesn't
>>> already define?
>>>
>> I haven't yet met such users, I've got this issue while testing
>> suggested patch (I changed the sid manually for one of the users). I'm
>> just trying to say if someone's s3db contains such user (I guess some
>> do), we'll need to do something with it, the more so because we already
>> have this check.
> I guess we should error out.
>
I'll change the patch that way.

Thanks.

-- 
Best regards,
Sergey Urushkin



More information about the samba-technical mailing list