> Hi,
> (Warning: It's been a looong day, and upon rereading, the below may
> not be entirely coherent. I'll gladly clarify in the morning where needed)
We've been struggling for several months with getting our Linux (a mix of CentOS 7 and
RHEL 7.1) servers AD integrated. We have a Win2012R2 domain with two sites, and several
cross-forest, one-way trusts, and at the moment we are mostly (see below) able to
authenticate with accounts local to our domain. We currently have two problems (that we
know of):
> * After a few days, it is no longer possible to log in with a domain account.
Restarting sssd mostly works, and if not, performing a domain join again does. What
we've seen is that this seems to change the KVNO field of kinit -k, and we've seen
an error message (which I can't find again at the moment, sorry) indicating that this
is a problem. Oddly enough, on some of the servers which we still can log on to, the KVNO
can be different from the one which we just "fixed". The KVNO seems to always
be either 2 or 5, switching when we "fix" a server.
Do you have a policy on the AD servers which changes the machine account password
regularly? In this case you have to update the keytab to contain the new keys. So far this
is not done automatically by SSSD but already tracked by ticket
https://fedorahosted.org/sssd/ticket/1041 .
But running msktutil in a cronjob should help here as well.
No, we have the defaults for password rotation (30 days I believe?). But I hadn't seen
any reference to msktutil before, I'll check that out.
> * Authenticating with an account from a trusted domain never works. I can ping
domain controllers from the other domain, I can telnet all the AD ports I can think of
(significantly, 389 and 88), and there's no real error message shown anywhere. Right
now /var/log/secure complains about unknown users, and journalctl says "Unspecified
GSS failure. Minor code may provide more information (Server not found in Kerberos
database)". I can resolve both A and PTR records, both on local and remote domains.
Currently SSSD does not support AD-AD cross-forest trusts
(
https://fedorahosted.org/sssd/ticket/2078). If you want to allow users from a different
forests to log-in you have to join the other forest as well and add a second [domain/...]
section to sssd.conf for the other forest. I would recommend to use different keytabs here
by using the krb5_keytab option to configure the other domain.
Joining all forests is not an alternative, unfortunately. Both because of the number of
domains, but mostly since we are not administrators of those domains (and those
domain's administrators should not be given any ability to apply gpo:s etc).
Is that ticket approved and planned for next release, or merely "pushed
forward"?
HTH
bye,
Sumit
Thank you very much!
Best regards,
Carl
>
> I'm at a loss on how to continue with the troubleshooting. People are starting
to mumble about requesting local accounts on all machines. Tonight, I tried throwing PBIS
Open (previously Likewise) on a machine, and it just worked. I'd like to avoid PBIS,
though, since it is a bit more opaque about how it works, and we'd probably end up
having to pay to get the features we could get from sssd in a (mostly) more understandable
and clean packaging. But this would at least seem to indicate that the issue is with our
configuration, rather than some infrastructural problem?
>
> Here's the configuration files:
>
> /etc/krb5.conf:
> [logging]
> default = FILE:/var/log/krb5libs.log
> kdc = FILE:/var/log/krb5kdc.log
> admin_server = FILE:/var/log/kadmind.log
>
> [libdefaults]
> default_realm =
AD.MAIN-DOMAIN.COM
> dns_lookup_realm = true
> dns_lookup_kdc = true
> ticket_lifetime = 24h
> renew_lifetime = 7d
> forwardable = true
>
> [realms]
> [domain_realm]
>
> /etc/sssd/sssd.conf
> [sssd]
> services = nss, pam, ssh, autofs
> config_file_version = 2
> domains =
AD.MAIN-DOMAIN.COM
>
> [nss]
> override_homedir = /home/%d/%u
> override_shell = /bin/bash
>
> [
domain/AD.MAIN-DOMAIN.COM]
> id_provider = ad
> use_fully_qualified_names = TRUE
> krb5_renew_interval = 1h
>
> I tried replacing the krb5.conf file with the one generated by PBIS, but that
didn't help, unfortunately.
>
> Any ideas for things to try would be greatly appreciated!
>
> Best regards,
> Carl