adcli join fails

I can also verify that I'm literally having the same issue. I'm trying to create a use case to show that we can have Linux on the domain if needed instead of having to pay fees to MSoft for useless upgrades...

Status changed to 'Confirmed' because the bug affects multiple users.

I have also a fresh installed Ubuntu 19.10 system and would like to add it toe the company's AD. I have the same issue as the others i think:

* Resolving: _ldap._tcp.*****
 * Performing LDAP DSE lookup on: 192.168.10.23
 * Successfully discovered: *****
Passwort für *****:
 * Unconditionally checking packages
 * Resolving required packages
 * LANG=C /usr/sbin/adcli join --verbose --domain ***** --domain-realm ***** --domain-controller 192.168.10.23 --login-type user --login-user ***** --stdin-password
 * Using domain name: *****
 * Calculated computer account name from fqdn: *****
 * Using domain realm: *****
 * Sending netlogon pings to domain controller: cldap://192.168.10.23
 * Received NetLogon info from: srvdc2.*****
 * Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-dYvKUg/krb5.d/adcli-krb5-conf-UxBkNg
 * Authenticated as user: *****@*****
 * Looked up short domain name: *****
 * Using fully qualified name: *****
 * Using domain name: *****
 * Using computer account name: *****
 * Using domain realm: *****
 * Calculated computer account name from fqdn: *****
 * Generated 120 character computer password
 * Using keytab: FILE:/etc/krb5.keytab
 * Found computer account for *****$ at: CN=*****,CN=Computers,DC=*****,DC=de
 * Set computer password
 * Retrieved kvno '8' for computer account in directory: CN=*****,CN=Computers,DC=*****,DC=de
 * Modifying computer account: userAccountControl
 * Modifying computer account: operatingSystemVersion, operatingSystemServicePack
 * Modifying computer account: userPrincipalName
 ! Couldn't set service principals on computer account CN=*****,CN=Computers,DC=*****,DC=de: 00002083: AtrErr: DSID-03151337, #1:
 0: 00002083: DSID-03151337, problem 1006 (ATT_OR_VALUE_EXISTS), data 0, Att 90303 (servicePrincipalName)

adcli: 'code == 0' not true at _adcli_krb5_keytab_test_salt
 ! Couldn't authenticate with keytab while discovering which salt to use: *****$@*****: Bad encryption type
 ! Couldn't add keytab entries: FILE:/etc/krb5.keytab: Bad encryption type
adcli: joining domain ***** failed: Couldn't add keytab entries: FILE:/etc/krb5.keytab: Bad encryption type
 ! Failed to join the domain
realm: Dem Bereich konnte nicht beigetreten werden: Failed to join the domain

I've added the latest version 0.9.0 of adcli to my PPA, which fixed the issue for me.

https://launchpad.net/~aroth/+archive/ubuntu/ppa

I had the same problem. I downloaded `adcli_0.9.0-1` from https://packages.debian.org/bullseye/amd64/adcli/download; it installs cleanly on my eoan system and resolved the problem.

Andreas work looked good (https://launchpad.net/~aroth/+archive/ubuntu/ppa/+packages?field.name_filter=adcli&field.status_filter=published&field.series_filter=eoan) but I was leary on pulling authentication package from a PPA of someone I didn't actually know.

Still want to send a thanks to Andreas for pointing out that this is already fixed upstream and giving us a workaround until it gets packaged in Ubuntu.

Followup, it looks like this is already in the process of being packaged for Focal: https://launchpad.net/ubuntu/focal/+source/adcli ( I had tried checking for it here before Debian, but apparently I used launchpad poorly).

Just wanted to let others know this impacts me in 19.10 as well, and http://ftp.us.debian.org/debian/pool/main/a/adcli/adcli_0.9.0-1_amd64.deb worked for me as well.

Having the same issue on 19.10

19.10, having the same issue. Installed the latest adcli (0.9.0) and this resolved my issue.

I had a functioning 19.04 system joined to the domain, and after upgrading it was unable to talk to the domain. This breaks existing systems and is still an issue.

I guess Canonical doesn't want people to use Ubuntu in a corporate environment anymore. I mean, why else would they ignore such a devastating bug for so long, even when it's already been solved?

I just wanted to add that 4 months after the initial bug report, and a month after the last comment in this thread, Ubuntu repo version was 0.8.2-1 which still contained aforementioned bug. I downloaded the debian adcli 0.9.0-1 package and adcli/realmd appear to be working properly. If this is so easy to fix, why isn't a newer version of adcli incorporated into Ubuntu repo yet?

@Avery, there is a process for this, called the Ubuntu SRU process (https://wiki.ubuntu.com/StableReleaseUpdates) that needs to be followed to get a package updated in Ubuntu. Just filing the bug with the problem will not make it happen.

Solved,
upgrading to adcli 0.9.0-1 .... solve mine problem

I also added in /etc/apparmor.d/usr.sbin.sssd this line:
/usr/libexec/sssd/* rm,
as I got several suspicious logs in /var/log/kern.log with denied mask r or rm to files in that directory

The Eoan Ermine has reached end of life, so this bug will not be fixed for that release