Kpasswd and user password change do not work after 4.3

UCS - Univention Corporate Server
,
#1

Hi,

/edit: It may be even easier: Changing the password from console using kpasswd does not work for “normal” users, error shown is:
kpasswd: krb5_set_password_using_ccache: Unable to rearch any changepw server in realm …

Getting a ticket via kinit works as that user.

/Original message:
after the update to UCS 4.3-1 from 4.2-4 and some minor bugs, this one also impacts users. When trying to change the password using the self-service module, the User receives the following german error:

Passwort ändern fehlgeschlagen. Der Grund konnte nicht festgestellt werden. Für den Fall, dass es hilft, hier die originale Fehlernachricht: Unable to reach any changepw server in realm D1.D2.d3.DE. Errorcode 20: Das neue Passwort konnte nicht gesetzt werden.

The password is set anyway [sic!] for login with the web frontend, but not for IMAP.
Changing the password from the UMS seems to work.

The server configuration looks like this:
Master - sidious
Backup - vader (except for replication this should not be a problem?)

root@sidious:/etc/pam.d# ucr search --brief kerberos
kerberos/adminserver: sidious.d1.d2.d3.de
kerberos/adminusers: <empty>
kerberos/afscell: <empty>
kerberos/allow/weak/crypto: <empty>
kerberos/autostart: yes
kerberos/defaults/debug: <empty>
kerberos/defaults/dns_lookup_kdc: <empty>
kerberos/defaults/dns_lookup_realm: <empty>
kerberos/defaults/enctypes/permitted: <empty>
kerberos/defaults/enctypes/tgs: <empty>
kerberos/defaults/enctypes/tkt: <empty>
kerberos/defaults/forwardable: <empty>
kerberos/defaults/ignore_acceptor_hostname: true
kerberos/defaults/kdc_timesync: <empty>
kerberos/defaults/proxiable: <empty>
kerberos/defaults/rdns: <empty>
kerberos/domain_realms: <empty>
kerberos/kadmin/default/keys: <empty>
kerberos/kdc: sidious.d1.d2.d3.de
kerberos/kpasswdserver: sidious.d1.d2.d3.de
kerberos/password/quality/check: yes
kerberos/realm: D1.D2.D3.DE

The logfiles in /var/log/univention/ show:

==> ./management-console-server.log <==
13.08.18 09:26:46.995 MODULE ( PROCESS ) : Setting auth type to None
13.08.18 09:26:47.077 MAIN ( PROCESS ) : Updating user password in 0 running module processes (auth-type: None).

==> ./management-console-web-server.log <==
13.08.18 09:26:47.078 MAIN ( PROCESS ) : SessionClient(0x7feab43d0210): _authenticated: success=True status=200 message=None
13.08.18 09:26:47.078 MAIN ( PROCESS ) : auth_type=None

==> ./listener.log <==
13.08.18 09:26:57.612 LISTENER ( PROCESS ) : updating ‘uid=testbenutzer,cn=users,dc=d1,dc=d2,dc=d3,dc=de’ command m

==> ./management-console-server.log <==
13.08.18 09:26:59.346 AUTH ( WARN ) : Changing password failed ((‘Fehler beim \xc3\x84ndern des Authentifizierungstoken’, 20)). Prompts: [('Current Kerberos password: ', 1), ('Geben Sie ein neues Passwort ein: ', 1), ('Geben Sie das neue Passwort erneut ein: ', 1), (‘Unable to reach any changepw server in realm D1.D2.D3.DE’, 3)]

==> ./management-console-web-server.log <==
13.08.18 09:26:59.460 MAIN ( PROCESS ) : CPSet (IP_ADRESSE:42304) response status code: 400
13.08.18 09:26:59.460 MAIN ( PROCESS ) : CPSet (IP_ADRESSE:42304) response message: Passwort ändern fehlgeschlagen. Der Grund konnte nicht festgestellt werden. Für den Fall, dass es hilft, hier die originale Fehlernachricht: Unable to reach any changepw server in realm D1.D2.D3.DE. Errorcode 20: Das neue Passwort konnte nicht gesetzt werden.
13.08.18 09:26:59.460 MAIN ( PROCESS ) : CPSet (IP_ADRESSE:42304) response result: {‘new_password’: u’Passwort \xe4ndern fehlgeschlagen. Der Grund konnte nicht festgestellt werden. F\xfcr den Fall, dass es hilft, hier die originale Fehlernachricht: Unable to reach any changepw server in realm D1.D2.D3.DE. Errorcode 20: Das neue Passwort konnte nicht gesetzt werden.’}

==> ./management-console-server.log <==
13.08.18 09:27:14.373 MAIN ( PROCESS ) : Connection timed out.

/var/log/heimdal-kdc.log shows:

2018-08-13T08:59:22 AS-REQ testbenutzer@D1.D2.D3.DE from IPv4:SERVERIP for krbtgt/D1.D2.D3.DE@D1.D2.D3.DE
2018-08-13T08:59:22 Client sent patypes: ENC-TS, REQ-ENC-PA-REP
2018-08-13T08:59:22 Looking for PK-INIT(ietf) pa-data -- testbenutzer@D1.D2.D3.DE
2018-08-13T08:59:22 Looking for PK-INIT(win2k) pa-data -- testbenutzer@D1.D2.D3.DE
2018-08-13T08:59:22 Looking for ENC-TS pa-data -- testbenutzer@D1.D2.D3.DE
2018-08-13T08:59:22 Failed to decrypt PA-DATA -- testbenutzer@D1.D2.D3.DE (enctype aes256-cts-hmac-sha1-96) error Decrypt integrity check failed for checksum type hmac-sha1-96-aes256, key type aes256-cts-hmac-sha1-96
2018-08-13T08:59:22 sending 153 bytes to IPv4:SIDIOUSIP

/var/log/auth.log shows:

Aug 13 08:58:35 sidious python2.7: pam_unix(univention-management-console:chauthtok): user "testbenutzer" does not exist in /etc/passwd
Aug 13 08:58:45 sidious python2.7: pam_unix(univention-management-console:chauthtok): user "testbenutzer" does not exist in /etc/passwd
Aug 13 08:58:45 sidious kpasswdd[897]: Changing password for testbenutzer@D1.D2.D3.de
Aug 13 08:58:45 sidious kpasswdd[897]: Changing password for testbenutzer@D1.D2.D3.de
Aug 13 08:58:45 sidious kpasswdd[897]: <class 'univention.admin.uexceptions.pwalreadyused'>
Aug 13 08:58:46 sidious kpasswdd[897]: Changing password for testbenutzer@D1.D2.D3.de
Aug 13 08:58:46 sidious kpasswdd[897]: <class 'univention.admin.uexceptions.pwalreadyused'>
Aug 13 08:58:46 sidious kpasswdd[897]: Changing password for testbenutzer@D1.D2.D3.de
Aug 13 08:58:46 sidious kpasswdd[897]: <class 'univention.admin.uexceptions.pwalreadyused'>
Aug 13 08:58:46 sidious kpasswdd[897]: Changing password for testbenutzer@D1.D2.D3.de
Aug 13 08:58:46 sidious kpasswdd[897]: <class 'univention.admin.uexceptions.pwalreadyused'>
Aug 13 08:58:46 sidious kpasswdd[897]: Changing password for testbenutzer@D1.D2.D3.de
Aug 13 08:58:46 sidious kpasswdd[897]: <class 'univention.admin.uexceptions.pwalreadyused'>
Aug 13 08:58:46 sidious kpasswdd[897]: Changing password for testbenutzer@D1.D2.D3.de
Aug 13 08:58:46 sidious kpasswdd[897]: <class 'univention.admin.uexceptions.pwalreadyused'>
Aug 13 08:58:47 sidious kpasswdd[897]: Changing password for testbenutzer@D1.D2.D3.de
Aug 13 08:58:47 sidious kpasswdd[897]: <class 'univention.admin.uexceptions.pwalreadyused'>
Aug 13 08:58:47 sidious kpasswdd[897]: Changing password for testbenutzer@D1.D2.D3.de
Aug 13 08:58:47 sidious kpasswdd[897]: <class 'univention.admin.uexceptions.pwalreadyused'>
Aug 13 08:58:47 sidious kpasswdd[897]: Changing password for testbenutzer@D1.D2.D3.de
Aug 13 08:58:47 sidious kpasswdd[897]: <class 'univention.admin.uexceptions.pwalreadyused'>
Aug 13 08:59:12 sidious python2.7: pam_unix(univention-management-console:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  user=testbenutzer

The same also happens in a virtual machine configuration, that has been upgraded in the same intervals as the original systems. Any ideas where I can continue looking?

#2

After some more digging, I saw that _kerberos._tcp and _kerberos._udp point to the Backup DC, where Samba is running. Is it possible, that this is some incompatibility between kerberos on the master and Samba kerberos on the backup?

#3

Hey,

Samba is the component that’s providing Kerberos. Those DNS records point to Samba is therefore expected.

Are you running Samba on your DC master as well?

Please post the output of the following:

# This from both your DC Master and your DC Backup:
univention-app info
# The following from your DC Master only:
host -t srv _kerberos._tcp.$(ucr get domainname)
host -t srv _kerberos._udp.$(ucr get domainname)

Additionally: are there any errors when you run the “system diagnosis” module in the UMC?

Kind regards,
mosu

#4

Hello Moritz,

thank you for your reply.
The Master is running heimdal-kdc, the Backup is running Samba.
kdc is running on all interfaces ipv4 and ipv6 on Port 88 on the Master, samba is running on all interfaces ipv4 and ipv6 on Port 88 on the Backup.

Univention Master:

root@sidious:~# univention-app info
UCS: 4.3-1 errata163
Installed: dhcp-server=12.0 horde=5.2.17-2 mailserver=12.0 nagios=4.3 self-service=3.0
Upgradable: horde

Univention Backup:

root@vader:~# univention-app info
UCS: 4.3-1 errata163
Installed: samba4=4.7
Upgradable:

_kerberos._tcp. points to the Univention Backup (Vader) from both machines.

Interestingly, krb5.conf has all entries set to sidious on sidious, and to 127.0.01 on vader except for admin_server (which is set to sidious) on vader.

System diagnostics has some messages regarding shared IMAP folders, a few hostnames with underscore and I changed the amavis and dovecot templates.

Maybe I will try a reboot at night, that solved a kerberos problem for me once. Nevertheless I rebooted both systems for good measure after all upgrades were finished.

#5

Why aren’t you running Samba on your DC Master? At the moment your network won’t work without your DC Backup, which is kind of not the purpose of having both a DC Master and a DC Backup.

This might be a bug, or this kind of setup might simply not be supported fully. I bet this isn’t tested all that well.

Reading the admin documentation (Kerberos, S4 Connector) doesn’t really make it clear whether or not it’s supported.

m.

#6

Long story short, it worked for UCS 4.0, 4.1 and 4.2. Changing the current situation involves a takeover and new installation of the E-Mail server, which takes some time.

Thanks for your information, I will see whether I can get it working.

Are there any known downsides from setting kerberos/defaults/dns_lookup_kdc to false? We do not have any Linux clients except for both Univention boxes.

#7

Hey,

Uhm… I don’t follow? Installing Samba as an AD DC on your UCS DC Master is as simple as installing the corresponding app. You may have to make sure the S4 connector is only run on the DC Master and not on the DC Backup afterwards. But that should be it. Samba AD DCs will automatically sync bi-directionally between themselves.

m.

1 Like
#8

I wanted to avoid that additional synchronisation between the two Samba AD DCs, because I felt the sync UCS DC Master -> UCS DC Backup -> S4 Connector is quite enough (and I had to deal with connector rejects and s4 connector bugs in the past), but your suggestion does sound interesting.

#9

As this topic contains quite a lot of kerberos errors, I will update it with some more information. Please note the posts before, as Samba is only running on the UCS Backup.

Current status was:

kinit on UCS Master works slow, kpasswd does not work.
kinit on UCS Backup works fast, kpasswd works fast

krb5.conf on DC Master:

[libdefaults]
default_realm = D1.D2.D3.DE
...
dns_lookup_kdc = true
dns_lookup_realm = false
...

[realms]
D1.D2.D3.de = {
acl_file = ...
kdc = ucsmaster.d1.d2.d3.de
admin_server = ucsmaster.d1.d2.d3.de
kpasswd_server = ucsmaster.d1.d2.d3.de
}
...

I recognized, that kinit is really slow on the DC Master and takes around 12 seconds to complete (but it is successful!). On the DC Backup kinit is almost instantanously.

Changing dns_lookup_kdc to false does not help.

Adding dots/perdios/. to the end of the FQDN of the kdc, admin_server and kpasswd_server makes kinit instantanously (thank you internet!). kpasswd works again on DC Master. Self-Service Password change works again.

This looks like a DNS/Resolver problem. Why does Kerberos still try to resolve something via DNS when dns_lookup_kdc is set to false and what do the dots at the end of the domain name exactly do.

Thank you again @Moritz_Bunkus for the comments regarding the setup and the general help on this board.

#10

Hey,

In DNS configuration situations (mostly in Bind zone files) a dot at the end signals that the name is fully formed and that the current domain name shouldn’t be appended. Let’s take the following zone file excerpt as an example:

$ORIGIN test.intranet.

www                      A 192.168.0.1 ; effectively the same as "www.test.intranet"
other.sub                A 192.168.0.2 ; this is "other.sub.test.intranet"
external.whatever.local. A 192.168.0.3 ; this remains "external.whatever.local" due to the dot at the end

Now this isn’t a general mechanism in all DNS situations, but I’d guess that the Kerberos software won’t append the DNS search domains (from /etc/resolv.conf) or the Kerberos realm or something like that when doing DNS lookups.

This setting only controls whether an SRV lookup is done in order to determine the KDC’s host name. The host name itself must of course still be resolved to an IP address, no matter how the host name is obtained (SRV lookup or read from krb5.conf).

m.

1 Like
#11

Whyever the above setting solves my problem, here is another weird thing:

/etc/hosts contains the line:

127.0.1.1 dcmaster.d1.d2.d3.de

There is no kdc or kpasswd running at 127.0.1.1, just at 127.0.0.1.

The local running named resolves dcmaster.d1.d2.d3.de to the external IP, where kerberos is running.

Depending on how kinit etc. try to resolve the name, they see a running kerberos or they do not.

I am not sure why or how that setting got into the configuration:

root@dcmaster:/etc# ucr search --brief 127.0.1.1
hosts/static/127.0.1.1: dcmaster.d1.d2.d3.de dcmaster

On the next reboot/maintenance I will remove that static address.

#12

Hey,

All addresses in the 127.0.0.0/8 network are mapped to the local-loopback interface, not just 127.0.0.1. That one is just the most well-known one.

Using another address from the 127.0.0.0/8 network often allows one to set up interesting things such as having multiple DNS servers listening on the local loopback interface on port 53 but with different addresses (pretty important as you can easily change the IP address used for DNS lookups but not the port number).

m.

#13

Meanwhile we created an article for this issue

Mastodon