3

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

3 Answers 3

4

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

9
  • Thanks for the information, helpful links as well. The join does default to use adcli (I edited my answer to reflect this), either setting it as you suggested or not has the same result. I am suspecting the remote AD servers are just not compatible, but I don't control that.
    – aseq
    Jan 14, 2016 at 0:56
  • 2
    Realm/adcli/samba is trying to change the machine to use the most secure encryption types it can support, but using adcli should allow you to continue past that error. Can you try running journalctl -e SYSLOG_IDENTIFIER=realmd and adding the (sanitized) output? I suspect that there's more going on here. It would also be nice to know which minor version of RHEL7 and which versions of realm, adcli, krb5-workstation and samba-common you're using.
    – doombird
    Jan 18, 2016 at 5:36
  • Thanks, I edited my question with the information you requested. The jounralctl command actually shows most lines twice, I doubt it is significant but I thought I'd mention.
    – aseq
    Jan 21, 2016 at 23:18
  • How are you verifying membership? Looks to me like you've got it.
    – doombird
    Jan 22, 2016 at 0:15
  • 1
    Updated answer with more information. It sounds to me like you are having trouble with the sssd_ad module instead of the AD join part. Can you check to see if you can find your machine in AD and that it shows up as enabled?
    – doombird
    Jan 24, 2016 at 22:09
3

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.

3
  • net is used for historical reason, it's part of a set of scripts. In addition samba-tool is not present in rhel7's samba packages. Which actually brings me to README.dc in the rhel7 samba source package which states: "We'll provide Samba AD DC functionality as soon as its support of MIT Kerberos KDC will be ready". It looks like that may be the issue.
    – aseq
    Nov 25, 2015 at 22:48
  • 1
    Oh sorry didn't know that rhel7's samba version. Nov 26, 2015 at 18:23
  • I edited my question, it appears realm/sssd is having the same problem.
    – aseq
    Jan 14, 2016 at 0:20
1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .