[Samba] Inconsistent results while attempting to preset a computer with a one-time-password

[Denis Cardon]

Hi Dan,

>>>>>> I'm not opposed to the idea. Does 'net ads join' support supplying
>>>>>> the machine name as the user, and the one-time-password given to it?
>>>>>> The only reason I'm using adcli at all is the preset-computer option
>>>>>> which I couldn't find an analogue to in 'net ads'.
>>>>>>
>>>>>>
>>>>>
>>>>> I have never tried this, but there is the 'createcomputer=OU' option:
>>>>>
>>>>> Precreate the computer account in a specific OU.
>>>>> The OU string read from top to bottom without RDNs
>>>>> and delimited by a '/'.
>>>>> E.g. "createcomputer=Computers/Servers/Unix"
>>>>> NB: A backslash '\' is used as escape at multiple
>>>>> levels and may need to be doubled or even
>>>>> quadrupled. It is not used as a separator.
>>>>>
>>>>> Rowland
>>>>>
>>>>> --
>>>>> To unsubscribe from this list go to the following URL and read the
>>>>> instructions:  https://lists.samba.org/mailman/options/samba
>>>>
>>>> So I have the computer precreated in the OU. Lets call this host
>>>> 'ruby'. I also pass 'machinepass' so that it can join itself later
>>>> (I think?). On 'ruby' I run 'net ads join', except it asks me for a
>>>> password still. If I try to run 'net ads join -U RUBY$%onetimepass
>>>> -v -d 5' it seems as if it tries to create the machine again, as in
>>>> the logs I get 'machine account creation failed', then 'failed to
>>>> precreate account in ou ....: Insufficient accesssigned SMB2
>>>> message'. Should I be specifying something else? The man page seems
>>>> to suggest that if the machine already exists, it'll use that entry.
>>>> Having 'net ads join' prompt me for a password is a no-go, as it
>>>> brings me right back to manually doing this all by hand.
>>>>
>>>>
>>>> --
>>>> To unsubscribe from this list go to the following URL and read the
>>>> instructions:  https://lists.samba.org/mailman/options/samba
>>>
>>> Also it kind of seems from the logs that running 'net ads join
>>> createcomputer=OU' is attempting to join the computer I'm running the
>>> command on again. The man page really isn't all that specific about it.
>>>
>>>
>>> --
>>> To unsubscribe from this list go to the following URL and read the
>>> instructions:  https://lists.samba.org/mailman/options/samba
>>
>> So testing around still being unsure how to have 'net' prep the
>> computer, I found
>> https://lists.samba.org/archive/samba-technical/2010-August/072627.html from
>> 2010 where another user seems to be trying to accomplish a similar
>> task. Is net capable of setting the allowed joiner as mentioned in
>> that post?
>>
>> In any case, I hit another roadblock: I create the computer in ADUC
>> allowing SELF to join, use 'net' to set the password since it seems
>> 'net' still doesn't allow for no-password, then attempt to join with
>> 'net ads join -U RUBY$%password'. It seems I'm back to the same
>> permissions problem I was running in to with adcli though. It gets to
>> 'machine account creation failed', then 'Host account for RUBY does
>> not have service principal names' and 'Failed to join domain: Failed
>> to set machine spn: Insufficient access'. So it looks like even though
>> the machine account has the permissions to join itself, it still can't
>> set its own SPN.
>>
>>
>> --
>> To unsubscribe from this list go to the following URL and read the
>> instructions:  https://lists.samba.org/mailman/options/samba
>
> And just like that post, if I modify that machine entry and grant 'Read
> Write all properties' on the SELF object, it can then successfully join
> itself. That doesn't really seem like a great idea though, and
> definitely doesn't lend itself to automation. Unfortunately it seems as
> though that thread ends without resolution so I'm still unsure as to
> where to go from here.

Indeed a computer should'nt have all write access to its AD entry 
(otherwise after the computer will be able to add itself some funny SPN 
and all for example).

What you are trying to do is actually some kind of offline join [1]. The 
trick here is to be able to recreate the secrets.tdb file. The easiest 
way would be to create it in a lightweight container by joining a temp 
machine with a privileged account, and copy over the secrets.tdb file to 
your virtual machine.

Another way would be to dive into python-tdb and the cryptic hex entries 
of secrets.tdb and recreate the file by hand.

Actually piping in the password is not the complicated step, you could 
do something like this:
echo "store SECRETS/MACHINE_PASSWORD/TRANQUILIT mysupersecretpassword" 
| tdbtool  /var/lib/samba/private/secrets.tdb

But after that you'd still need to pipe in all the other values.

Cheers,

Denis

[1] 
https://docs.microsoft.com/en-us/windows-server/remote/remote-access/directaccess/directaccess-offline-domain-join


>
>
>

-- 
Denis Cardon
Tranquil IT Systems
Les Espaces Jules Verne, bâtiment A
12 avenue Jules Verne
44230 Saint Sébastien sur Loire
tel : +33 (0) 2.40.97.57.55
http://www.tranquil-it-systems.fr