[Samba] Samba AD: gidNumber?
Viktor Trojanovic
viktor at troja.ch
Tue Oct 27 11:17:59 UTC 2015
On 27.10.2015 11:17, Rowland Penny wrote:
> On 27/10/15 09:34, Viktor Trojanovic wrote:
>>
>>
>> On 27.10.2015 09:05, Rowland Penny wrote:
>>> On 26/10/15 22:35, Viktor Trojanovic wrote:
>>>>
>>>>
>>>> On 26.10.2015 23:03, Rowland Penny wrote:
>>>>> On 26/10/15 21:38, Viktor Trojanovic wrote:
>>>>>> I joined a Samba AD member server (file server) to a Samba AD DC.
>>>>>> This seems to have worked. However, if I try to access the file
>>>>>> server from the domain administrator account on a Windows client,
>>>>>> I am asked to provide authorization details. Since I have no
>>>>>> other privileged users, I am using the domain admin credentials
>>>>>> but they're not accepted.
>>>>>>
>>>>>> I'm not sure exactly where to look but I think the problem could
>>>>>> be connected to the following: On my member server, the getent
>>>>>> command does not yield any results. As per the recommendations on
>>>>>> the "Samba Member Server Troubleshooting" page, I checked on the
>>>>>> DC if the group Domain Users has a gidNumber. Well, it doesn't.
>>>>>> Neither do my users have uidNumbers though this, allegedly, is
>>>>>> not such an issue.
>>>>>
>>>>> Yes it is, there is no point in adding a gidNumber to Domain Users
>>>>> if you are not going to give your Users a uidNumber.
>>>>>
>>>>> As far as how to add uidNumbers and gidNumbers, well firstly, do
>>>>> you need to? if your users are never going to actually log into
>>>>> the member server and this is your only Unix machine, you could
>>>>> use the winbind 'rid' backend, this will create the ID numbers on
>>>>> the fly.
>>>>> If you have more than one member server, or Unix clients or want
>>>>> your users to log into the member server, you will probably be
>>>>> better off using the winbind 'ad' backend. To do this you will
>>>>> need to give your users a unique uidNumber and Domain Users (at
>>>>> least) a gidNumber. You can do this by using the ADUC UNIX
>>>>> Attributes tab, by writing your own script using an ldif, or by
>>>>> using something like the LDAP Account Manager (LAM).
>>>>>
>>>>> Rowland
>>>> Thanks again for helping, Rowland.
>>>>
>>>> As I mentioned before, both the DC and the member server are Unix
>>>> running Samba 4.3. The purpose of the member server is to act as
>>>> file server, nothing more.
>>>>
>>>> The clients are all windows machines and users, they will never log
>>>> in to one of the unix systems directly. If they are able to access
>>>> shares on the file server without having to log in, then I guess
>>>> this 'rid' backend seems to be what I need. Correct? Can you give
>>>> me some pointers on how to do that, or direct me to the documentation?
>>>>
>>>> Though one has to wonder: There is a wiki how to implement a Samba
>>>> AD, and how to add a Samba Member Server. I followed the
>>>> instructions step by step, for both, and now it turns out that the
>>>> instructions for the member server are not made to fit the
>>>> configuration of the DC? That's a bit discouraging.
>>>>
>>>> Viktor
>>>
>>> The main problem is that idmap.ldb on the DC will allocate an
>>> xidNumber to a user in the '3000000' range, this xidNumber is used
>>> for the users uidNumber. If you use the DC as a fileserver and a
>>> user stores something on the DC and you were to examine the
>>> permissions, you will find that it doesn't belong to a user but a
>>> number. This gets worse, if you have two DCs, you can and probably
>>> will get different numbers on each DC. Now this is not a problem
>>> until you do something like copy the file from one DC to the other,
>>> the file could then belong to another user, this can also happen
>>> with a member server.
>>>
>>> If you use a member server and do not want your users to log into
>>> it, you can use the winbind 'rid' backend, this will allocate UID
>>> numbers to your users using an algorithm based on the users RID,
>>> this also has the affect of creating the same UID on every member
>>> server.
>>>
>>> If you need to use the DC as a fileserver, then I would advise the
>>> use of the winbind 'ad' backend. Using this, your users will get the
>>> same UID everywhere, as the users UID is stored in AD using the
>>> uidNumber attribute.
>>>
>>> To add uidNumber & gidNumber attributes to AD is fairly simple, you
>>> can do it using ADUC, or by writing your own script around an ldif.
>>>
>>> To use the winbind 'rid' backend, see here:
>>> https://wiki.samba.org/index.php/Idmap_config_rid
>>>
>>> Rowland
>>>
>>>
>>
>> Thanks a lot for this very valuable information, this all became a
>> lot clearer now.
>>
>> I am currently just doing a lab setup with a very small AD (5 users,
>> 1 OU, just the standard groups), so I want to try both variations,
>> starting with the ad (rfc2307) backend, and I already have some
>> questions.
>>
>> I'm using Win10 RSAT, so I don't have the "Unix Attributes" tab but I
>> can still modify the attributes manually in the "Attributes" tab. I
>> understand how to change the attributes but I'm not clear on which
>> values to use.
>>
>> The wiki says that "by default, ADUC starts assigning UIDs and GIDs
>> at 10000". I haven't changed those defaults anywhere so this is what
>> must apply for my AD. But I don't understand how ADUC "assigns"
>> anything. It seems that I have to manually choose which values to
>> enter, and I'm not being restricted. So, I'm worried I will break
>> something if I do a mistake here.
>>
>> For example, I gave the admin account a UID of 10000 and my Domain
>> Users group a GID of 10000. Was that the right thing to do? And where
>> do I go from here? Because I'm further confused by the sentence in
>> the wiki "Every time a UID/GID is assigned using ADUC, the next
>> UID/GID is stored inside the AD". So, this sounds that there has to
>> be a strict rule which number comes next.
>>
>> By the way, is there a way that the server could just handle these
>> assignments automatically for me? Or is this the ldif script I would
>> have to write myself you were mentioning?
>
> I don't have access to RSAT on a win10 machine, so wasn't really aware
> that the UNIX Attributes tab had disappeared, but this isn't really a
> problem, you will just have to resort to another tool such as LAM.
>
> When ADUC adds the uidNumber to a user, it first tries to obtain the
> next number from an attribute in AD, this attribute is '
> msSFU30MaxUidNumber' (groups use 'msSFU30MaxGidNumber') and is not
> created as standard on a Samba4 AD DC. This attribute usually starts
> at 10000 and is the number that will be used for the next uidNumber,
> once it is used, it is replaced with the number just used plus one
> i.e. if the uidNumber just created was '10000' it would be replaced
> with '10001'. The same system is used for groups.
>
> Now that we know where the uidNumber comes from, what other attributes
> does ADUC add?
>
> uid
> msSFU30Name
> msSFU30NisDomain
> uidNumber
> gidNumber
> loginShell
> unixHomeDirectory
>
> It also adds unixUserPassword and this is always set to
> 'ABCD!efgh12345$67890'
>
> So what is the easiest way to add these?
>
> The user is 'Fred Bloggs' with the samaccountname of 'fred', the
> workgroup is 'SAMDOM', the realm is 'SAMDOM.EXAMPLE.COM', you want the
> user to have the uidNumber of '10001' and be a member of Domain Users
> which has the gidNumber '10000', he will have the login shell of
> '/bin/bash' and will have an home directory stored at '/home/fred'.
>
> Create an ldif /tmp/user with this info:
>
> dn: CN=Fred Bloggs,CN=Users,DC=samdom.DC=example,DC=com
> changetype: modify
> add: uid
> uid: fred
> -
> add: msSFU30Name
> msSFU30Name: fred
> -
> add: msSFU30NisDomain
> msSFU30NisDomain: samdom
> -
> add: uidNumber
> uidNumber: 10001
> -
> add: gidNumber
> gidNumber: 10000
> -
> add: loginShell
> loginShell: /bin/bash
> -
> add: unixHomeDirectory
> unixHomeDirectory: /home/fred
> -
> add: unixUserPassword
> unixUserPassword: ABCD!efgh12345$67890
>
> Now use ldbmodify to alter the user object in AD:
>
> ldbmodify --url=/usr/local/samba/private/sam.ldb /tmp/user
>
> If you do this on the DC as 'root', it should update the users object
> in AD.
>
> Note that '--url=' may need to be changed if you are using a distro
> package
> You will also need to keep track of uidNumbers and gidNumbers yourself
>
> Rowland
>
Before doing anything, let me clarify a few points because I don't
understand it all.
1. While the "Unix Attributes" tab is gone on windows, there is a new
"Attributes" tab that gives me access to just about any attribute. I
take it, I can use this then and don't have to resort to third party
software, such as LAM?
I took two screenshots of the new ADUC for you to get a feel. General
view: http://imgur.com/WPjJJPM. Changing the uidNumber:
http://imgur.com/JKMOeO3 (the content of the field is neither proposed
nor checked).
2. I'm not sure I understand your second statement. You say that when I
assign a UID for an account in the ADUC, the ADUC is doing something
actively (looking up the next number), at the same time you're saying
that Samba DCs don't create the attributes where this information would
be stored. I'm confused. Am I supposed to create those attributes
(msSFU30MaxUidNumber' and 'msSFU30MaxGidNumber')? All I can confirm is
that, at the current stage, ADUC is not checking my entries. I was able
to give the same UID to two different accounts without any error or
warning messages.
3. Since my users will only log in to their windows stations, is it
really necessary to define a shell and a home directory? Are there any
benefits of doing that, or drawbacks of omitting?
Thank you so much for bearing with me.
4. I think I understand the ldif template. If I were to import it
manually, I would just increase the UID by one each after having used
it. The GID you selected would be the GID I have assigned to "Domain
Users", so I would leave it. Correct? And since there are only two
attributes that need to be changed to add a GID to a group, an ldif
template would be overkill.
4b) What about the Admin account? Do I treat it as any other account
(with regards to assigning a UID) or is there something special I have
to consider?
More information about the samba
mailing list