Krb5-kdc
Joseph
Note:
The native replication mechanism explained here relies on a cron job; it essentially dumps the DB on the primary and loads it back up on the secondary. You may want to take a look at using the kldap backend, which can use the OpenLDAP replication mechanism. This is explained further below.
The secondary KDC should now be able to issue tickets for the realm. You can test this by stopping the krb5-kdc daemon on the primary KDC, then using kinit to request a ticket. If all goes well you should receive a ticket from the secondary KDC. Otherwise, check /var/log/syslog and /var/log/auth.log on the secondary KDC.
This is in preparation for setting up an OpenLDAP server, a Kerberos server with an LDAP backend, and saslauthd for pass-through authentication. krb5-kdc was auto-selected when running the steps in the guide here in my development environment: -kerberos-with-openldap-backend When installing that, I get the following in the output:
I cannot find any further debug in the syslog or anything to indicate what the root cause is; the list of packages here are all installed together on a separate development server where I experimented with the configuration I will be deploying here in production so I don't think it's incompatible packages in the install list, but I am open to feedback on that.
None of those should cause a conflict. I did a "dpkg-reconfigure" on all of them, and the only one with an issue is krb5-kdc, and on 22.10 the error is a slightly different line, "Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 145." That's line 145 instead of 142, seems like it's that systemd-invoke line, is there a way for me to get additional debug from that command?
So, there was a bug that made its way to the Debian TC asking what the
behavior ought to be when a maintainer script tried to restart a unit
and the unit failed.
The conclusion of that bug was that there is no general
policy--sometimes you want the maintainer script to fail, sometimes you
do not.
At least that was my recollection.
There is a bunch of interesting order-of-events issues I'm discovering with what I'm doing, and because of that it is creating errors that are obscured in the packaging process. I don't know if there's a fix, or just some alerts, etc. The package failure appears to be because I did NOT set up a realm; intending to use ldap as the backend, I figured I would NOT have krb5-kdc config create an initial realm. This means when it tries to start the service, I get this in the logs:
The realm is defined by the install of krb5-config, so it knows the realm it wants to use. So, fine, maybe that's expected; then I go in and run krb5_ldap_util to create the realm, and THAT led to another error...the tool doesn't support TLS. I get "Confidentiality required while initializing database" which indicates a TLS error. Disabled forcing of tls on the ldap server and I could initialize the realm, stash everything needed in keyfiles, and I was off to the races.
I feel like this is indeed a problem with how init-system-helpers (more specifically, deb-systemd-invoke) warns users about errors. Since it uses "--quiet" when invoking systemctl, I believe it needs to be a bit more verbose to explain what happened.
What's interesting that I can't reproduce the apt failure. For example, "apt install proftpd" will warn me about deb-systemd-invoke, but the command will finish successfully. ISTR having seen this behaviour before, but I don't remember my conclusion at the time.
Job for xrdp.service failed because the control process exited with error code.
See "systemctl status xrdp.service" and "journalctl -xeu xrdp.service" for details.
Could not execute systemctl: - start at /usr/bin/deb-systemd-invoke line 143.
I fixed it editing /var/lib/dpkg/info/proftpd-core.postinst and commenting the deb-systemd-invoke commands, running the apt install another time and letting the postint script as it was after the package was installed correctly.
Before installing the Kerberos server, a properly configured DNS server is needed for your domain. Since the Kerberos realm (by convention) matches the domain name, this section uses the EXAMPLE.COM domain configured in the primary server section of the DNS documentation.
Also, Kerberos is a time sensitive protocol. If the local system time between a client machine and the server differs by more than five minutes (by default), the workstation will not be able to authenticate. To correct the problem all hosts should have their time synchronized using the same Network Time Protocol (NTP) server. Check out the NTP chapter for more details.
You will be asked at the end of the install to supply the hostname for the Kerberos and Admin servers for the realm, which may or may not be the same server. Since we are going to create the realm, and thus these servers, type in the full hostname of this server.
The questions asked during installation are used to configure the /etc/krb5.conf and /etc/krb5kdc/kdc.conf files. The former is used by the Kerberos 5 libraries, and the latter configures the KDC. If you need to adjust the KDC settings, edit the file and restart the krb5-kdc daemon. If you need to reconfigure Kerberos from scratch, perhaps to change the realm name, you can do so by typing:
kinit will inspect /etc/krb5.conf to find out which KDC to contact, and the corresponding address. The KDC can also be found via DNS lookups for special TXT and SRV records. You can add these records to your example.com DNS zone:
64591212e2