Web lists-archives.com

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




Quoting Dan Oriani via samba <samba@xxxxxxxxxxxxxxx>:

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@xxxxxxxxxx: FILE:/etc/krb5.keytab Feb 3 16:14:20 in-target: * Added the entries to the keytab: host/beth-jaurigue.domain.com@xxxxxxxxxx: FILE:/etc/krb5.keytab Feb 3 16:14:20 in-target: * Added the entries to the keytab: RestrictedKrbHost/BETH-JAURIGUE@xxxxxxxxxx: FILE:/etc/krb5.keytab Feb 3 16:14:20 in-target: * Added the entries to the keytab: RestrictedKrbHost/beth-jaurigue.domain.com@xxxxxxxxxx: 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?


--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba