Unable to join domain using samba tool net or realm/sssd

Question

On a rhel7 server I am trying to join the server to a domain, but I am getting the following failure:

net ads join -S domain.example.org -U name Enter name's password: Failed to join domain: failed to set machine kerberos encryption types: Insufficient access 

The settings related to pam, krb5, samba, dns as well as the object in the remote active directory server, are configured correctly, meaning the system will bind successfully using rhel6 and ubuntu 14.04.

I haven't been able to find much information with regards to the specific error I am getting. I tried to set allow_weak_crypto=true in krb5.conf just to see whether it had something to do with that, but it had no effect.

I followed some troubleshooting tips in https://technet.microsoft.com/en-us/library/bb463167.aspx but had no luck, the things I tried appear to work fine.

Specifically I am able to do the following, which means I can acquire an initial credential for user name:

kinit name Password for [email protected]: 

I also am able to generate a keytab file using ktutil and when I moved it to /etc/krb5.keytab klist -e it shows the correct content. But net ads join keeps failing.

Edit: After examining the rhel7 samba source package I found the following in README.dc:

We'll provide Samba AD DC functionality as soon as its support of MIT Kerberos KDC will be ready.

I suspect that may be the issue and I'd have to wait until it's ready.

Edit2: Using realm and sssd instead appears to have the same problem. After doing:

realm -v join --user=example ad.example.org 

I find the following error:

* LANG=C /usr/sbin/adcli join --verbose --domain ad.example.org --domain-realm AD.EXAMPLE.ORG --domain-controller 192.0.2.11 --login-type user --login-user example --stdin-password ! Insufficient permissions to set encryption types on computer account: CN=example,OU=w,OU=x,DC=ad,DC=example,DC=org: 00002098: SecErr: DSID-03150BB9, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0 

Note, this works with rhel6. I also have no permission to make changes to the AD server or my account there.

The rhel version is 7.2 and the relevant packages are at the following versions:

Name : realmd Version : 0.16.1 -- Name : adcli Version : 0.7.5 -- Name : krb5-workstation Version : 1.13.2 -- Name : samba-common Version : 4.2.3 

Sanitised output of journalctl -e SYSLOG_IDENTIFIER=realmd:

Jan 21 14:56:20 host.example.org realmd[25796]: * Using domain name: example.org Jan 21 14:56:20 host.example.org realmd[25796]: * Using computer account name: HOST Jan 21 14:56:20 host.example.org realmd[25796]: * Using domain realm: example.org Jan 21 14:56:20 host.example.org realmd[25796]: * Calculated computer account name from fqdn: HOST Jan 21 14:56:20 host.example.org realmd[25796]: * Generated 120 character computer password Jan 21 14:56:20 host.example.org realmd[25796]: * Using keytab: FILE:/etc/krb5.keytab Jan 21 14:56:20 host.example.org realmd[25796]: * Using fully qualified name: host.example.org Jan 21 14:56:20 host.example.org realmd[25796]: * Using domain name: example.org Jan 21 14:56:20 host.example.org realmd[25796]: * Using computer account name: HOST Jan 21 14:56:20 host.example.org realmd[25796]: * Using domain realm: example.org Jan 21 14:56:20 host.example.org realmd[25796]: * Looked up short domain name: AD Jan 21 14:56:20 host.example.org realmd[25796]: * Found computer account for HOST$ at: CN=host,OU=w,OU=x,DC=ad,DC=example,DC=org Jan 21 14:56:20 host.example.org realmd[25796]: * Set computer password Jan 21 14:56:20 host.example.org realmd[25796]: * Retrieved kvno '87' for computer account in directory: CN=host,OU=w,OU=x,DC=ad,DC=example,DC=org Jan 21 14:56:20 host.example.org realmd[25796]: ! Insufficient permissions to set encryption types on computer account: CN=host,OU=w,OU=x,DC=ad,DC=example,DC=org: 00002098: SecErr: DSID-03150BB9, problem 4003 (INSUFF_ACCESS_RIGHTS), Jan 21 14:56:20 host.example.org realmd[25796]: * Modifying computer account: userAccountControl Jan 21 14:56:20 host.example.org realmd[25796]: * Modifying computer account: operatingSystem, operatingSystemVersion, operatingSystemServicePack Jan 21 14:56:20 host.example.org realmd[25796]: ! Couldn't set operatingSystem, operatingSystemVersion, operatingSystemServicePack on computer account: CN=host,OU=w,OU=x,DC=ad,DC=example,DC=org: Insufficient access Jan 21 14:56:20 host.example.org realmd[25796]: * Updated existing computer account: CN=host,OU=w,OU=x,DC=ad,DC=example,DC=org Jan 21 14:56:20 host.example.org realmd[25796]: * Discovered which keytab salt to use Jan 21 14:56:20 host.example.org realmd[25796]: * Added the entries to the keytab: [email protected]: FILE:/etc/krb5.keytab Jan 21 14:56:20 host.example.org realmd[25796]: * Added the entries to the keytab: HOST/[email protected]: FILE:/etc/krb5.keytab Jan 21 14:56:20 host.example.org realmd[25796]: * Added the entries to the keytab: HOST/[email protected]: FILE:/etc/krb5.keytab Jan 21 14:56:21 host.example.org realmd[25796]: * Added the entries to the keytab: RestrictedKrbHost/[email protected]: FILE:/etc/krb5.keytab Jan 21 14:56:21 host.example.org realmd[25796]: * Added the entries to the keytab: RestrictedKrbHost/[email protected]: FILE:/etc/krb5.keytab Jan 21 14:56:21 host.example.org realmd[25796]: process exited: 25879 Jan 21 14:56:21 host.example.org realmd[25796]: * /usr/bin/systemctl enable sssd.service Jan 21 14:56:21 host.example.org realmd[25796]: process started: 25880 Jan 21 14:56:21 host.example.org realmd[25796]: Created symlink from /etc/systemd/system/multi-user.target.wants/sssd.service to /usr/lib/systemd/system/sssd.service. Jan 21 14:56:21 host.example.org realmd[25796]: process exited: 25880 Jan 21 14:56:21 host.example.org realmd[25796]: * /usr/bin/systemctl restart sssd.service Jan 21 14:56:21 host.example.org realmd[25796]: process started: 25894 Jan 21 14:56:22 host.example.org realmd[25796]: process exited: 25894 Jan 21 14:56:22 host.example.org realmd[25796]: * /usr/bin/sh -c /usr/sbin/authconfig --update --enablesssd --enablesssdauth --enablemkhomedir --nostart && /usr/bin/systemctl enable oddjobd.service && /usr/bin/systemctl start oddjobd.se Jan 21 14:56:22 host.example.org realmd[25796]: process started: 25901 Jan 21 14:56:23 host.example.org realmd[25796]: process exited: 25901 Jan 21 14:56:23 host.example.org realmd[25796]: * Successfully enrolled machine in realm Jan 21 14:56:23 host.example.org realmd[25796]: released daemon: current-invocation Jan 21 14:56:23 host.example.org realmd[25796]: client gone away: :1.3100 Jan 21 14:56:23 host.example.org realmd[25796]: released daemon: :1.3100 Jan 21 14:57:23 host.example.org realmd[25796]: quitting realmd service after timeout Jan 21 14:57:23 host.example.org realmd[25796]: stopping service 

Sanitised output of net ads -P status:

objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user objectClass: computer cn: host distinguishedName: CN=host,OU=w,OU=x,DC=ad,DC=example,DC=org instanceType: 4 whenCreated: 2012 whenChanged: 2016 uSNCreated: 1687590 memberOf: CN=group,OU=groups,OU=w,DC=ad,DC=example,DC=org uSNChanged: 1212121212 name: host objectGUID: x userAccountControl: 6 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 1 lastLogoff: 0 lastLogon: 1 localPolicyFlags: 0 pwdLastSet: 1 primaryGroupID: 600 objectSid: S-1-5-21 accountExpires: 9 logonCount: 1 sAMAccountName: HOST$ sAMAccountType: 8 dNSHostName: host.ad.example.org servicePrincipalName: RestrictedKrbHost/HOST servicePrincipalName: RestrictedKrbHost/host.ad.example.org servicePrincipalName: HOST/host.ad.example.org servicePrincipalName: HOST/HOST objectCategory: CN=Computer,CN=Schema,CN=Configuration,DC=ad,DC=example,DC=org isCriticalSystemObject: FALSE dSCorePropagationData: 2 dSCorePropagationData: 3 dSCorePropagationData: 4 dSCorePropagationData: 5 dSCorePropagationData: 6 lastLogonTimestamp: 1 

Answer 1

I had the same issue, realm plus adcli was the solution. realm uses the samba-common backend by default. Get the realmd and adcli packages, and use

# realm join --membership-software=adcli -U <username> <domain> 

You never even have to use adcli directly. Note that the same permissions error occurs, but you continue to join the domain rather than fail at the encryption type denial.

This had me tied up for weeks. The project ended up getting delayed until I could figure it out. Learn from my pain.

Unfortunately, as far as I can tell adcli doesn't seem to have any way to verify the join without making changes to AD. To verify, you can back up /etc/samba/smb.conf and replace it with (just):

realm = <REALM> workgroup = <WORKGROUP> 

Then run net ads -P status to get a wealth of information pulled from AD about your newly enrolled machine account. You can do the same with ldapsearch against the DC, by searching with Windows tools, or by asking your AD admins, but I don't know which options to use for LDAP and I like to be self-sufficient.

Often times adcli/net enroll a machine but the sssd_ad doesn't quite work right for identity management out-of-the-box. I find especially in enterprise AD environments with RIDS in excess of 200000 or that have been updated from much older versions several times, problems generally pop up. If you get results from the net ads status command but still can't get user information, look for issues with sssd and sssd_ad. systemctl status sssd.service is a good place to start. However, troubleshooting sssd_ad for I'd mapping and authentication isn't in the scope of your original question.

Extra credit reading:

Docs for realm on freedesktop.org.

Docs for adcli on freedesktop.org.

Man page for sssd_ad

Answer 2

Why are you using net? You should join the domain with samba-tool

samba-tool domain join domain.example.org DC -Uadministrator --realm=domain.example.org 

net isn't really used in samba 4 anymore except for shares and some other stuff.
Don't mess with kerberos cryptographic settings.

Answer 3

The problem also appeared to occur on debian and ubuntu after samba was upgraded from 4.1 to the 4.3 minor version. Which means it was not redhat specific. As an aside I did contact redhat support.

I was not able to find a solution, but I found a work around which is good enough. For some reason when the particular failure occurs the keytab is not created or an incorrect one is created. The bind to the active directory servers actually was successful and to make things work a new keytab needs to be created.

Failed to join domain: failed to set machine kerberos encryption types: Insufficient access

Run this to create the keytab:

net -P ads keytab create 

Though I opted to keep using samba I think when using realm you can use this work around as well.