[Samba] Running off pre-created keytabs

Fri Jan 11 13:37:46 UTC 2019

> 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).aspx#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.

>> 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. I think it's a best practice to adhere the least
>> privilege principles. If the AD admins pre-create the computer
>> account and give the Samba domain member server admin the keytab and
>> machine password, 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.
> 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.