Join Log in
Score:0
Dave avatar Server

SSSD is not creating a krb5.conf file after realm join, not able to `id` domain users, why?

id flag
Dave

The main problem is after I join the domain, I cannot id a domain user. Be aware I am not rebooting the host, do I need to? I would think I wouldn't need to.

After doing some basic troubleshooting I realized that after I join the domain, I would think that a krb5.conf file would be created in /etc/krb5.conf but it never does.

I am joining an Ubuntu20.04 host to a Windows 2019 AD server. I have confirmed the following with a script I created before joining:

[PASS] Checking hostname FQDN has domain 'our.domain' configured
[PASS] Checking hosts file for correct entry of 127.0.1.1
[PASS] Checking DNS resolution.
[PASS] Checking DNS search domain.
[PASS] Checking Time Zone is set properly
[PASS] Checking NTP servers are set properly
[PASS] Checking NTP root distance
[PASS] Checking NTP is syncing properly

dcdiag on the DCs comes out clean. /var/log/auth.log looks clean. /var/log/sssd/sssd.log has very little to offer. /var/log/sssd/sssd_our.domain.log has very little to offer. /var/log/sssd/krb5_child is empty.

I also cannot figure out how to get debug logs to work for sssd or Kerberos.

Here is the sssd.conf file


[sssd]
domains = our.domain
config_file_version = 2
services = nss, pam

[domain/our.domain]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = OUR.DOMAIN
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%u@%d
ad_domain = our.domain
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = simple
simple_allow_groups = Domain Users, Domain Admins, Administrators

Here is /usr/share/pam-configs/mkhomedir

Name: activate-mkhomedir
Default: yes
Priority: 900
Session-Type: Additional
Session:
        required                        pam_mkhomedir.so umask=0022 skel=/etc/skel

I am also performing the following, confirmed user is in the 'Domain Users' group

$ sudo realm permit -g 'Domain Users'
$ sudo realm permit -g 'Domain Admins'
$ sudo realm permit -g 'Administrators'

Can anyone help me change the debug logs without using environmental variables, is there a setting I can set? Or just some direction to go with this...

EDIT: I finally figured out what the problem was with our set up. The problem was we had a multi-homed Active Directory server configured with multiple interfaces serving DNS. This is a big no-no. When SSSD LDAP services tried to get an IP for a DC it was given multiple addresses, and not all the addresses were routable from the clients perspective because they were on different subnets. After removing the other interfaces on the DC and only serving DNS on one interface, we no longer had the issue of sporadic realm joins. So it was never a Kerberos problem, but the types of trouble shooting suggest below was very helpful.

1048
1 + 0
Score:3
user1686 avatar Server
fr flag
user1686

Kerberos is purely an authentication service and cannot provide user account information for id – SSSD's "nss" service must query AD via LDAP to get that information. So you're looking in the wrong logs; it's the ldap_child or ad_child that would handle account lookup.

Check your /etc/nsswitch.conf and make sure the sss module (not the "ldap" module!) is configured in the passwd: and group: sections.

After doing some basic troubleshooting I realized that after I join the domain, I would think that a krb5.conf file would be created in /etc/krb5.conf but it never does.

Practically the only time you're dealing with Kerberos is a) when you run kinit, or b) when you log in and SSSD does kinit on your behalf, or c) when SSSD needs to access AD LDAP and uses the machine keytab to "kinit".

You don't strictly need a krb5.conf to acquire tickets, as Kerberos can use SRV records (which AD always has) to discover KDCs – and SSSD also installs a custom libkrb5 "locator" plugin to provide the KDC addresses directly. So although realmd should (if I remember correctly, that is) create a krb5.conf, it would only contain generic information such as:

[libdefaults]
    default_realm = OUR.DOMAIN
    rdns = false

I also cannot figure out how to get debug logs to work for sssd or Kerberos.

For SSSD itself, add something like debug_level = 0x0770 to the [domain/...] section (for krb5/ldap) as well as the [sssd] section (for nss/pam responders).

id does not talk Kerberos nor LDAP – it only talks to the local SSSD service – but you can try the following if you want to get manual kinit working first:

$ export KRB5_TRACE=/dev/stderr
$ export SSSD_KRB5_LOCATOR_DEBUG=1
$ kinit user@REALM
+ 5
Dave avatar
id flag
Dave
Thank so much for all the good information. Things I found: `/etc/nsswitch.conf` has sss in the right places you asked about. Changing the debug level worked great for sssd and Kerberos. I cannot login in with the users creds using `kinit`, keeps saying `KDC reply did not match expectations while getting initial credentials` when correct creds are entered. The following errors repeated on Kerberos stderr `[sssd_krb5_locator] open failed [/var/lib/sss/pubconf/kdcinfo.my.domain][2][No such file or directory]. [sssd_krb5_locator] get_krb5info failed.`
0
Reply
user1686 avatar
fr flag
user1686
"KDC reply did not match expectations" probably means you tried to kinit with the lower-case domain name (UPN), while the reply ticket always has the upper-case Kerberos realm name. Try again with `kinit [email protected]` (realm names are always upper-case) or add the `-C -E` options relaxing the check (allowing UPNs).
0
Reply
Dave avatar
id flag
Dave
Ok capitalizing the domain name worked. I tried with other users too, and that works. However ID still refuses to work. Keep getting "no such user". I checked sssd log output to see which file fills while trying to use `id` the the only filling up is the sssd_my.domain.log. But no errors or failures in it. Nothing in auth.log either. Is there any other log file I can check?
0
Reply
Dave avatar
id flag
Dave
That worked with kinit, but id does not. I add `[nss]` to the `sssd.conf` file and give it a `debug_level=6`, creates a new sssd_nss.log file. Trying to check for a user with id I see these errors: `[nss] [sss_dp_get_account_send] (0x0400): Creating request for [my.domain][0x1][BE_REQ_USER][[email protected]:-] [nss] [cache_req_common_process_dp_reply] (0x0040): CR #155: Could not get account info [1432158212]: SSSD is offline [nss] [cache_req_common_process_dp_reply] (0x0400): CR #155: Due to an error we will return cached data`
0
Reply
Dave avatar
id flag
Dave
Just a note, we figured out the problem. In the end it had nothing to do with Kerberos. So all the errors I was getting was because of a multi-home set up DNS.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.