[Samba] Running off pre-created keytabs

Remy Zandwijk (Samba) remy+samba at luckyhands.nl
Fri Jan 11 14:04:10 UTC 2019

> On 11 Jan 2019, at 14:48, L.P.H. van Belle via samba <samba at lists.samba.org> wrote:
>> -----Oorspronkelijk bericht-----
>> Van: samba [mailto:samba-bounces at lists.samba.org] Namens Remy 
>> Zandwijk (Samba) via samba
>> Verzonden: vrijdag 11 januari 2019 14:38
>> Aan: Remy Zandwijk (Samba) via samba
>> Onderwerp: Re: [Samba] Running off pre-created keytabs
>>> On 11 Jan 2019, at 14:25, Rowland Penny via samba 
>> <samba at lists.samba.org> wrote:
>>> On Fri, 11 Jan 2019 13:14:16 +0100
>>> "Remy Zandwijk \(Samba\) via samba" <samba at lists.samba.org> wrote:
>>>>> On 11 Jan 2019, at 12:34, Rowland Penny via samba
>>>>> <samba at lists.samba.org> wrote:
>>>>> On Fri, 11 Jan 2019 12:03:30 +0100
>>>>> "Remy Zandwijk \(Samba\) via samba" <samba at lists.samba.org> wrote:
>>>>>>> On 11 Jan 2019, at 10:33, Rowland Penny via samba
>>>>>>> <samba at lists.samba.org> wrote:
>>>>>>> On Fri, 11 Jan 2019 09:39:35 +0100
>>>>>>> "Osipov, Michael via samba" <samba at lists.samba.org> wrote:
>>>>>>>> Am 2019-01-10 um 17:02 schrieb Rowland Penny via samba:
>>>>>>>>> On Thu, 10 Jan 2019 16:23:06 +0100
>>>>>>>>> "Osipov, Michael via samba" <samba at lists.samba.org> wrote:
>>>>>>>>>> Hi folks,
>>>>>>>>>> we'd like to provision new Samba servers (file sharing only)
>>>>>>>>>> with the system keytab. It will precreated by some other
>>>>>>>>>> process (msktutil) because we don't have direct access to a
>>>>>>>>>> domain admin account. Is there any degragation in
>>>>>>>>>> functionality by not using "secrets and keytab" and not doing
>>>>>>>>>> "net ads join"?
>>>>>>>>>> This is somewhat similiar to my question from 2017-11 [1]
>>>>>>>>>> where I wanted to do "net ads join" with precreated accounts,
>>>>>>>>>> but haven't really found a usable solution.
>>>>>>>>>> Michael
>>>>>>>>>> [1]
>> https://lists.samba.org/archive/samba/2017-November/211945.html
>>>>>>>>> There is an interesting fact, if you add:
>>>>>>>>> dedicated keytab file = /etc/krb5.keytab
>>>>>>>>> kerberos method = secrets and keytab
>>>>>>>>> to smb.conf and then join the domain with:
>>>>>>>>> net ads join -U Administrator (or another user capable of
>>>>>>>>> joining machines)
>>>>>>>>> You will get the computers account created in AD and 
>> the keytab
>>>>>>>>> created, so why do you feel the need to precreate the machines
>>>>>>>>> in AD and use an extra package to join the domain ?
>>>>>>>> As depicted, this still requires an admin to be present at the
>>>>>>>> box. I have to constantly beg people with that kind of 
>> permission
>>>>>>>> to do a session with us to kinit and then join servers 
>> or create
>>>>>>>> SPNs which do not match the FQDN. If the account can be
>>>>>>>> precreated one can do this asynchronously and I'd remove the
>>>>>>>> dependency on relying on specific people.
>>>>>>>> While it sounds for you trivial to have an admin 
>> account, in our
>>>>>>>> huge new forest (Siemens and MS claim it to be the 
>> largest one on
>>>>>>>> the planet) it is very strict about permissions after severe
>>>>>>>> incident in the last forest. It took us weeks to find 
>> someone who
>>>>>>>> is willing to join our servers once in a while. I 
>> guess this can
>>>>>>>> be/is the case in many large companies. Morover, I 
>> will request a
>>>>>>>> server which shall precreate machine accounts. This 
>> will make us
>>>>>>>> independent from humans, but Samba won't play well 
>> with that. At
>>>>>>>> last, if the colleague is on sick leave or else and we have to
>>>>>>>> reset the account for whatsoever reason, we are bust!
>>>>>>>> Regards,
>>>>>>>> Michael
>>>>>>> I am with Louis here, this definitely says more about 
>> your company
>>>>>>> than you or Samba. To put it bluntly, it appears that 
>> they do not
>>>>>>> trust you, otherwise they would have given you 
>> delegated powers to
>>>>>>> join computers.
>>>>>> Another use case is joining a machine to a domain of 
>> which only the
>>>>>> read-only domain controllers are reachable (in a DMZ, 
>> for example).
>>>>>> In the university I work at, Windows servers in the DMZ 
>> are joined
>>>>>> to the domain by pre-creating the machine account and running a
>>>>>> script (as local admin) on the server. If Windows can do 
>> that, why
>>>>>> not Samba?
>>>>> It probably can, 'samba-tool computer create <computername>' will
>>>>> precreate the computer in AD, so all that should be needed is the
>>>>> script, anybody got an example script ?
>>>> The script which is being used on the Windows server 
>> to-be-joined is
>>>> provided for by Microsoft:
>> http://technet.microsoft.com/en-us/library/dd728035(v=ws.10).a
> spx#sample_script_RODC_join
>> <http://technet.microsoft.com/en-us/library/dd728035(v=ws.10).
> aspx#sample_script_RODC_join>
>>>> Before running the script, a registry key needs to be added:
>>>> reg add 
>> HKLM\System\CurrentControlSet\Services\Netlogon\Parameters /v
>>>> SiteName /t REG_SZ /d Default-First-Site-Name-Perimeter
>>>> Then run the script like:
>>>> cscript JoinScript.vbs /domain YOURDOMAIN /machinepassword
>>>> "THE_PASSWORD" /dc RODC_FQDN /readonly
>>>> I spend a lot of time trying to join a Samba domain member 
>> server to
>>>> an Windows read-only AD, but I couldn't get it to work. My 
>> impression
>>>> is that Samba is not playing very well with site perimeters, but I
>>>> cannot recall the details.
>>> Samba AD is very much a work in progress and gets major updates
>>> regularly, but these updates rely on people saying 'this does not
>>> work'. If people don't tell us what doesn't work and provide data
>>> (logs, error messages etc) to back this up, they will never 
>> get fixed.
>> We are not talking about Samba AD. We are talking about 
>> Windows AD and Samba domain member servers.
> So, you still need Admin rights... Samba or or MS AD or Novell DS, does not matter..
> All need Admin right before you can join without admin rights. 
> Simple as that, if not... Then you have a big security hole. 

The Windows AD admin needs admin rights on the Windows AD server to add a machine account. In our case the Windows domain member admin only needs *local* admin rights to a) add the registry key and b) run the script. The Windows domain member admin does *not* need admin rights on the Windows AD server. 

It would be nice if we could say the same for a Windows AD server and a Samba domain member server.

That's the whole thing: you *can* join a Windows domain server to the domain without the need for the Windows domain member server admin to have admin rights on the AD. You cannot join a Samba domain member server in the same fashion.

>>> Personally, I do not agree at all with the statement that not being
>>> allowed to join machines to the domain is a matter of lack of trust
>>> within the company.
> It is in 90% of all cases, i've seen hunders of these cases. 
>>> I think it's a best practice to adhere the least privilege principles. 
> Yes, and for that you need admin rights to setup.

No. See above.

>>> If the AD admins pre-create the computer account and give the Samba 
>>> domain member server admin the keytab and machine password, 
> Again, the need of admin rights.

No. See above.

>>> it should be just about enough to be able to join the particular 
>>> machine and only the particular machine (if only it would work with Samba). 
>> Best practice is one thing, but from my experience, windows sysadmins
>> look down on Unix sysadmins and don't want them anywhere near 'their' computers.
> :-S hmm, what if your both?  ;-)  unix and win admin..  :-)) may i add novell admin also ;-) 
>> In the instance that started this discussion, I think it is fairly
>> obvious, there has been a lack of investment and I also think it is
>> about to blow up in their face.
> It probley is, but i also know sometimes, its a must to keep something old running. 
> So lets not be to hard on the admin, if it blows up, then its the company CEO's fault. 
> Just dont tell this, put it on paper and mail it to him, like officially warn him for it. 
> Then when i blows up, only then you can say "told you so".. 

More information about the samba mailing list