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

Tue Feb 6 17:43:20 UTC 2018

Quoting Dan Oriani via samba <samba at lists.samba.org>:

> Hello all, I'm kind of pulling my hair out over here.
>
>
>
>     I'll preface this by saying that I'm using the latest version of Samba
> packaged in Debian Stretch as my domain controller. Currently, I'm trying to
> build an infrastructure where I can deploy a new virtual machine, then have
> it automatically join the domain so that users can log in to it without very
> much (if any) intervention by myself. To this end, I created a new user for
> this process and delegated this user joining permissions as I found on the
> Wiki. The problem is, more often than not, running adcli preset-computer
> with --one-time--password set (I haven't really tested otherwise, as I don't
> care about running adcli to preset or join a computer manually), I get an
> error of "Cannot set computer password: Access denied: No such user when
> changing password". Thinking that the permissions on the wiki weren't broad
> enough, I added this user to the 'Domain Admin' account. Still the same
> error. In fact, more often than not, even if I run the command as myself or
> Administrator, I still get the same failure.
>
>
>
>     The kicker is, sometimes it works. I deploy the machine, and that's
> where my second issue begins. To join the computer to the domain, I issue a
> kind of long adcli command that specifies the domain, fqdn, realm, etc.
> Pretty much every option set to their correct value to rule out any
> inconsistencies. This command more often than not fails as well, but
> annoyingly at several different stages, depending on seemingly the time of
> day. Sometimes it can't change the dNSHostName, sometimes it gets past that
> then can't set userAccountControl. Each time it fails though, it can
> definitely never set the userPrincipalName. Every so often that too works
> though.
>
>
>
>     These successes and failures happen with nothing changed on my part.
> I'll run the commands and get a failure, but then the next time I try
> sometimes it works and I haven't changed a single thing. Same command,
> different results. I feel like I'm going crazy, so if anybody has any
> suggestions at all, I'd be greatly appreciative!
>
>
>
> Thanks!
>
> Dan
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba

     As an update to this, I figured out the preset-computer problem:  
It was related to the server I was running this command in not having  
the FQDN as the hostname, nor the hostname in /etc/hosts pointed to  
the interface IP address. This feels pretty hacky though I guess.

     Now I'm getting an issue where the computer that gets preset  
cannot join the directory. Note that this is happening during a Debian  
preseed, but I can't imagine that would make a significant difference.  
By the time this command is run, the hostname is set and the proper IP  
address is in place in /etc/hosts. See the following log excerpt:

Feb  3 16:14:20 in-target:  * LANG=C /usr/sbin/adcli join --verbose  
--domain domain.com --domain-realm DOMAIN.COM --domain-controller  
192.168.3.70 --login-type computer --stdin-password
Feb  3 16:14:20 in-target:  * Using domain name: domain.com
Feb  3 16:14:20 in-target:  * Calculated computer account name from  
fqdn: BETH-JAURIGUE
Feb  3 16:14:20 in-target:  * Using domain realm: domain.com
Feb  3 16:14:20 in-target:  * Sending netlogon pings to domain  
controller: ldap://192.168.3.70
Feb  3 16:14:20 in-target:  * Received NetLogon info from: dc02.domain.com
Feb  3 16:14:20 in-target:  * Wrote out krb5.conf snippet to  
/var/cache/realmd/adcli-krb5-2Yh592/krb5.d/adcli-krb5-conf-UqXdCT
Feb  3 16:14:20 adcli: GSSAPI client step 1
Feb  3 16:14:20 adcli: GSSAPI client step 1
Feb  3 16:14:20 in-target:  * Authenticated as default/reset computer  
account: BETH-JAURIGUE
Feb  3 16:14:20 adcli: GSSAPI client step 1
Feb  3 16:14:20 adcli: GSSAPI client step 2
Feb  3 16:14:20 in-target:  * Looked up short domain name: DOMAIN
Feb  3 16:14:20 in-target:  * Using fully qualified name:  
beth-jaurigue.domain.com
Feb  3 16:14:20 in-target:  * Using domain name: domain.com
Feb  3 16:14:20 in-target:  * Using computer account name: BETH-JAURIGUE
Feb  3 16:14:20 in-target:  * Using domain realm: domain.com
Feb  3 16:14:20 in-target:  * Calculated computer account name from  
fqdn: BETH-JAURIGUE
Feb  3 16:14:20 in-target:  * Generated 120 character computer password
Feb  3 16:14:20 in-target:  * Using keytab: FILE:/etc/krb5.keytab
Feb  3 16:14:20 in-target:  * Found computer account for  
BETH-JAURIGUE$ at: CN=BETH-JAURIGUE,CN=Computers,DC=domain,DC=com
Feb  3 16:14:20 in-target:  * Changed computer password
Feb  3 16:14:20 in-target:  * Retrieved kvno '3' for computer account  
in directory: CN=BETH-JAURIGUE,CN=Computers,DC=domain,DC=com
Feb  3 16:14:20 in-target:  * Modifying computer account: userAccountControl
Feb  3 16:14:20 in-target:  ! Couldn't set userAccountControl on  
computer account: CN=BETH-JAURIGUE,CN=Computers,DC=domain,DC=com:  
Insufficient access
Feb  3 16:14:20 in-target:  * Updated existing computer account:  
CN=BETH-JAURIGUE,CN=Computers,DC=domain,DC=com
Feb  3 16:14:20 in-target:  ! Couldn't set service principals on  
computer account CN=BETH-JAURIGUE,CN=Computers,DC=domain,DC=com: acl:  
spn validation failed for spn[host/BETH-JAURIGUE] uac[0x11000]  
account[ BETH-JAURIGUE$] hostname[beth-jaurigue.domain.com]  
nbname[DOMAIN] ntds[(null)] forest[domain.com] domain[domain.com]
Feb  3 16:14:20 in-target:
Feb  3 16:14:20 in-target:  ! Couldn't authenticate with keytab while  
discovering which salt to use: BETH-JAURIGUE$@DOMAIN.COM:  
Preauthentication failed
Feb  3 16:14:20 in-target:  * Added the entries to the keytab:  
BETH-JAURIGUE$@DOMAIN.COM: FILE:/etc/krb5.keytab
Feb  3 16:14:20 in-target:  * Added the entries to the keytab:  
host/BETH-JAURIGUE at DOMAIN.COM: FILE:/etc/krb5.keytab
Feb  3 16:14:20 in-target:  * Added the entries to the keytab:  
host/beth-jaurigue.domain.com at DOMAIN.COM: FILE:/etc/krb5.keytab
Feb  3 16:14:20 in-target:  * Added the entries to the keytab:  
RestrictedKrbHost/BETH-JAURIGUE at DOMAIN.COM: FILE:/etc/krb5.keytab
Feb  3 16:14:20 in-target:  * Added the entries to the keytab:  
RestrictedKrbHost/beth-jaurigue.domain.com at DOMAIN.COM:  
FILE:/etc/krb5.keytab
Feb  3 16:14:20 in-target:  * /usr/sbin/update-rc.d sssd enable
Feb  3 16:14:20 in-target:  * /usr/sbin/service sssd restart

     There seems to be an open bug open about this issue,  
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858981, however the  
FQDN of this machine is already in /etc/hostname, which seemed to be  
the workaround. I'm still unsure as to where to go from here. I ran  
'samba-tool  dbcheck --cross-ncs --reset-well-known-acls --fix' which  
did discover a couple issues and fixed them, but did not fix this  
issue. Should I expand the SELF permission on the CN=Computer object  
or something? When I view 'Effective Permissions' of the computer  
object for SELF, it would seem that it lacks permissions on 'Write  
userAccountControl', but shouldn't this be granted by default?