connect Uyuni container application to AD

[AxHuGH]

Dear Uyuni community,

We use openSUSE Leap 15.6 as host in our environment and Uyuni runs in a container. We want to connect Uyuni via PAM (SSSD) to Microsoft AD to authenticate the Uyuni users with their Windows user password. What we have now understood is that the SSSD configuration (/etc/sssd/sssd.conf) is done in the container.
Where does the configuration of Kerberos, PAM, ... ecetera has to be done?
The container itself has a ‘local’ IP address and hostname that cannot be reached from outside.

[aaannz]

Hi, seems like uyuni docs update was not yet published. Take a look at SMLM docs, there is an example - https://documentation.suse.com/suma/5.0/en/suse-manager/administration/auth-methods-pam.html

[AxHuGH]

Thanks for the information.

Still get the following errror in journalctl:
sssd[3817]: tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Server not found in Kerberos database.

ad_hostname is set to the FQDN ame of the host, but additional i found the error in the extendet journalctl
uyuni-server:/ # journalctl -l -u sssd --output verbose
_HOSTNAME=uyuni-server.mgr.internalqq

the host is already connected to the AD with the PBIS (BeyondTrust AD Bridge) application and works fine.

[aaannz]

Did you also join AD from the container? That snippet is for PAM to work, but before that adcli join must be called from the container itself (with correct -H $hostname matching what is in the sssd.conf as ad_hostname.

[AxHuGH]

not yet, because the host itself with openSUSE Leap is already successfully connected to the AD with this hostname.
Therefore i'm not sure if this could cause problems, when i also use the same name and register Uyuni in the container.

[aaannz]

That's the problem. Uyuni container and the host system are different entities here and they do not share keytab and other details. So both needs to be enrolled to the AD and of course make sure you use different hostnames for host and container.

[AxHuGH]

What is the best way to change the hostname of the Uyuni container?
The default is uyuni-server.mgr.internal in /etc/hostname.
Simply changing the file is probably not the right way.
In the container with the command /usr/bin/spacewalk-hostname-rename?
Or on the host with other means?

[aaannz]

Please do not change internal hostname of the container. Many things can stop working.

For the AD you can simply add -H for the adcli join command and ad_hostname in the sssd.conf.

AFAIK we are not listening on anything from AD so hostname passed to the AD might not be actually resolvable hostname.
Should be IMO something you will recognize on the AD what it is. So like host fqdn with suffix uyunicontainer or something.

[AxHuGH]

The following steps are necessary in the sequence to connect Uyuni in the container to the AD:

1. Create an AD computer account and connect it to Uyuni with adcli join
2. Configure sssd with the corresponding parameters from 1)

I still have the following error message for point 1:

! Couldn't get kerberos ticket for: [email protected]: KDC reply did not match expectations
adcli: couldn't connect to DOMAIN.com domain: Couldn't get kerberos ticket for: [email protected]: KDC reply did not match expectations

[ppanon2022]

The tricky part is that the default location used by adcli for the Kerberos keytab is not persisted across container restarts and updates. So when you use regular adcli without any fancy parameters then, after the first container restart, the keytab file (normally in /etc/krb5.keytab) will no longer be there and you will get the Server not found in Kerberos database error. There's also the issue that the container "hostname" value is uyuni-server, which could be a problem if you have more than one Uyuni server. Since you had already joined AD, you would need to reset or delete the UYUNI-SERVER computer account and wait for replication across your domain to complete before trying to re-join for the creation of a new keytab file. Because you can't run sssd both in container and on the host (due to container NATting and needing callbacks for automated monthly machine account password updates, you would get a port conflict), I figure it makes more sense to use the host's name for the machine account of the container sssd since that keeps things more consistent with whatever naming scheme you use for computers and computer accounts.

I wound up adding a couple of parameters with adcli and modifying the sssd.conf file. Running
adcli join --computer-name=<container host NetBIOS name> --host=<container host FQDN> -U <username> -D <FQADDomainName>

and then I had to copy or move the default /etc/krb5.keytab created by adcli to /etc/rhn/krb5.conf.d/krb5.keytab so that it will persist through a container restart. Alternatively, you can use the -K option to create it directly as /etc/rhn/krb5.conf.d/krb5.keytab

In the sssd.conf file afterwards, I added the following options to match the settings from adcli and to suppress DDNS registration of the container NATted IP address. You also need to change the cache name template to use FILE: caches because the other default mechanism doesn't work in the container. There's a few other things I tweaked but you'll need those at minimum.

ad_hostname = <container host NetBIOS name>
krb5_ccname_template = FILE:/tmp/krb5.ccache.%{uid}
krb5_keytab = /etc/rhn/krb5.conf.d/krb5.keytab
dyndns_update = false

@aaannz 's doc link above has a FILE: prefix for the krb5_keytab entry but that may not be correct since the above works for me with no errors.

[AxHuGH]

when connection the container with adcli join i get still the error:
! Couldn't get kerberos ticket for: [email protected]: KDC reply did not match expectation

even the SSSD service claims:
uyuni-server.mgr.internal ldap_child[16657]: Failed to initialize credentials using keytab [MEMORY:/etc/rhn/krb5.conf.d/krb5.keytab]: Client '[email protected]' not found in Kerberos database.

[ppanon2022]

For a start, are you running the 2024.12 version of the Uyuni container? That functionality was just broken in prior releases. If you're not running 2024.12, upgrade before you waste any more time trying to get this to work.

uyuni-server.mgr.internal ldap_child[16657]: Failed to initialize credentials using keytab [MEMORY:/etc/rhn/krb5.conf.d/krb5.keytab]: Client '[email protected]' not found in Kerberos database indicates a) sssd is looking for the keytab file at /etc/rhn/krb5.conf.d/krb5.keytab - which is what you want so that krb5_keytab = option is working properly, but
b) it can't find any keytab entries for UYUNI-SERVER. Does that mean you didn't use the computer-name and host options for adcli, or that you forgot to include ad_hostname = in sssd.conf? It also could mean the adcli command failed to do the join.

"! Couldn't get kerberos ticket for: [[email protected]](mailto:[email protected]): KDC reply did not match expectation" seems to indicate that your credentials aren't allowing you to login to the DC to be able to create the machine account. It doesn't seem to be the normal error for a bad password though. Are you due to change your password soon? Sometimes the authentication API has a different response if a password change is recommended and that can result in an apparent authentication failure even if the right password is provided. An authentication failure would prevent the keytab entries from being created. I would suggest you use adcli's -v option to see if you can get any more detail on the authentication failure and also try changing your password using a Windows server (and waiting enough time for the new password to get replicated across the domain). Another possibility might be a connectivity issue with a randomly chosen DC due to an inter-site firewall - you could try using the adcli -S option to specify a DC that's topologically close to avoid any intermediate systems.

If you can resolve the authentication issue for adcli, then I would
a) delete or reset the UYUNI-SERVER or whatever machine account you're trying to use in AD
b) wait 15-45 minutes, depending on the size of your network, topology and how long it takes for changes to replicate to all DCs. If you're deleting the account, then you can connect to the DC furthest from the one where you make the change (i.e. with the highest latency hops) to verify the account is deleted
c) delete the keytab file.
d) rerun the adcli command with -v (or possibly -vvv if it takes it - I normally use realm so I'm not sure about adcli) to get the maximum reporting on the conversation with the DC and make sure the keytab entries are being created.
e) use ktutil to verify what is in the keytab file matches what you expect. The container doesn't have ktutil. Since you're running Leap 15.6 you could exfiltrate a copy of the keytab file to the host with mgrctl cp, install ktutil on the host and use that to look at what is actually in the keytab file. Delete the host copy of the keytab file after you've checked its contents.
f) If you're using a machine account other than the container hostname, make sure the ad_hostname in sssd.conf is set to match.

[AxHuGH]

we are running 2024.12 version of the Uyuni container.
The AD connection "should" work with this version?

computername and host options are added to the adcli command and are also present in sssd.conf.
Is a functioning sssd configuration a prerequisite for the adcli command, or is this independent of it or only necessary in normal operation for
the authentication of Uyuni users with AD?
the call of the adcli command looks something like this (DOMAIN and SERVER are placeholders for the correct name):
adcli join --computer-name=SERVER --domain=SERVER.domain.com --domain-controller=DOMAINCONTROLLER.domain.com --host-fqdn SERVER.DOMAIN.com --login-user [email protected] --domain-ou="OU=X,OU=Y,DC=DOAIN,DC=DOMAIN,DC=com" -v

The password for the user is also fine, what I have tested with another application.
The DC is also fixed in the adcli command, see above.

there is no computer account for the server UYUNI-SERVER in the AD domain.
i have deleted the keytab file and rerun the adcli command, but without success.
the is no -vvv option availabel only -v
ktutil and realm are not availabel in the container, will try to install this later in the container.
there is no keytab file anymore.
hostname is set in the sssd.conf

[ppanon2022]

OK, maybe I misunderstood. The reason why I'm asking is that seeing the error message
Client '[email protected]' not found in Kerberos database.
led me to believe that UYUNI-SERVER (which is the hostname=>NETBIOS UC conversion in the container context) was being reported verbatim, which would indicate that the ad_hostname entry in /etc/sssd/sssd.conf was not being correctly recognized. If you replaced your UC hostname with UYUNI-SERVER$ in that error message the way you presumably did with DOMAIN.COM, then that makes sense, but you can hopefully understand my confusion.

If you didn't do that substitution, then there is an issue with the ad_hostname directive. Maybe it's in the wrong section, or a there's a typo or spacing/separation issue around the = sign.

That said, maybe it's a mistake in the security anonymization you did on the command, but it should be --domain=domain.com, not --domain=SERVER.domain.com. Also, because you're specifying the domain separately, I'm pretty sure you need to use the SAMAccountName, not the principal name, i.e. --login-user USER instead of --login-user [email protected]. The manpage example indicates

-U, --login-user=User
Use the specified user account to authenticate with the domain. If not specified, then the name 'Administrator' will be used.

Note that it says Administrator, not [email protected]

Perhaps that last item is the problem with the failure to authenticate?

[AxHuGH]

I apologise for the misunderstanding:
Hostname, domain name and username are only meant as placeholders here.
I did not want to publish the official names of the company here.

i have to user the principal name because the user is located in a different AD domain as the computer name.

[ppanon2022]

Ah. I'm afraid you're beyond the bounds of what I've worked with then. I haven't tried to do multi-domain authentication through a trust. The way I'm interpreting your latest email, the Uyuni server is hostname.DomainA, joined to DomainA. DomainA has a trust with DomainB, and the user is in DomainB. Given how the pam authentication is set up, where the Uyuni account name needs to match the pam account, I'm not sure it's possible. If you use sssd with two trusted domains, you need to use fully qualified usernames (and two sssd domain sections), which need to match the simple (non-qualified) user name in Uyuni. I don't see how you can make that work but maybe the Uyuni devs can think of something I've missed though.

I'm thinking you might need to use SAML with a SAML id provider that can act as a broker for the two domains instead.

[AxHuGH]

the user account and the computer account are in two different Windows AD domains.

I will implement the tip with two areas in the sssd configuration which brings me back to an original question:
Is a proper configuration of the sssd service the basis for the adcli join command to work or would this command work without a proper sssd configuration?

[ppanon2022]

Sorry I've been sick and then catching up on other stuff.

What adcli does is to set up the Kerberos keytab for the computer account created when joining AD. However, sssd still needs to be configured to match and use those Kerberos keytab entries. Normally the realm package/command is what I use to do the sssd configuration (and it invokes adcli) however it's not available in the container so you need to run adcli and edit sssd.conf manually. In addition, realm is normally used for a single domain so even if you use that to start with, you'll have to manually modify the config file after to include additional domains. What you could do is set up a VM elsewhere with any recent Redhat-derived or Debian-derived Linux distro, and use realm to experiment with creating the sssd.conf to have an example to work with. That would give you a single domain sssd.conf, and you could then experiment with adding the secondary domain and see if you can get it to work with forwarding from the primary domain. You could also experiment with the value of the use_fully_qualified_names = setting in the two domain sections in combination with the default_domain= setting in the leading [sssd] section (but I expect you can only use use_fully_qualified_names for one domain, the one matching the default_domain).

Once you have something working on your test system, you can copy it to the container (either cut+paste or with mgctl cp) and add the option fields necessary for the alternative krb5.keytab location needed for persistence in the container.

Redhat has an article for support subscribers on doing authentication from two domain in two different forests, and they use different keytab files for each domain, using realm for the first configuration and adcli to create the second keytab file for the second domain.
https://access.redhat.com/solutions/4035171
But if your domains are in the same forest with a trust, then I think you shouldn't need to use that approach and should just be able to add the second domain for forwarded authentication through the first domain. For that, https://docs.pagure.org/sssd.sssd/design_pages/subdomain_configuration.html and https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ look like they might have some useful tips.