Am Wed, Dec 14, 2022 at 07:52:38PM +0000 schrieb Christian, Mark:
On Wed, 2022-12-14 at 13:00 -0600, Spike White wrote:
> Sssd experts,
> We have been running sssd to AD integrate to a cross-domain AD forest
> for ~2 years now. With RHEL 7, 8 and (now) 9 servers. Has worked
> great.
> Just this week, we have a new message appearing in /var/log/messages
> related to sssd that we’ve never seen before:
> Dec 10 06:11:19
pshnldur01.amer.company.com sssd_be[343144]: PAC
> check is requested but krb5_validate is set to false. PAC checks will
> be skipped.
> This is a RHEL8 server, running sssd 2.7.3-4.0.1.el8_7.1 -- installed
> Fri 02 Dec 2022. We notice a new sssd_pac process running, even
> though in /etc/sssd/sssd.conf, we did not explicitly define any “pac”
> service.
> In RHEL7 servers, we do not see any such sssd_pac process. We do see
> this process in RHEL9 servers.
> In the change log for this new RHEL8 sssd version, I notice this
> recent entry:
> [2.7.3-4.1]
> - Resolves: rhbz#2128902 - Cannot SSH with AD user to ipa-client
> (krb5_validate and pac_check settings conflict) [rhel-9.1.0.z]
>
> Yes, in our /etc/sssd/sssd.conf file we set:
> krb5_validate = False
>
> All seems to be behaving. The server appears to be able to
> communicate fine with this local domain. All expected logins appear
> to work.
> 1. Can we ignore these messages?
Hi,
as mentioned below the PAC is part of the Kerberos ticket you receive
during authentication from an AD DC. Over the last year Microsoft added
some new information into the PAC and started to add more checks for the
consistency of the PAC and the mapping to the operation system account.
Since the Kerberos ticket is by design independent of the operating
system account there must be some additional information to map the
Kerberos ticket to the operating system account during authentication
and Microsoft is using the PAC for this.
Since the mapping is also important for the login to Linux system we
implemented some of the checks as well. To be able to decode the PAC we
have to request a service ticket first. This is the same operation which
is done during the generic ticket validation (krb5_validate) and if this
is disabled we skip the PAC check as well since we assume that ticket
validation is disabled because there are issues requesting the service
ticket.
So, coming back to your question 'Can we ignore these messages?'. The
message should make you aware that something which we consider as a
security feature is skipped due to a not strictly related configuration
option and it might be worth to reconsider if 'krb5_validate = False' is
really necessary.
If you disabled the PAC check explicitly by setting
'pac_check = no_check' in the [pac] section of sssd.conf, the log
message should go away, see man sssd.conf for details.
> 2. Are they due to this new sssd version?
yes
> 3. Why does a pac service start up if we do not explicitly
define
> it in our list of services?
Since we want to do the PAC checks by default if the AD provider is used
the PAC responder is started automatically if the AD provider is used.
If you do not want to have it running you can set
'implicit_pac_responder = False' in the [sssd] section of sssd.conf, see
man sssd.conf for details.
HTH
bye,
Sumit
PAC[1] provides authorization info within a Kerberos ticket. I believe
it can be more efficient and/or secure to query the PAC for
authorization information rather than using LDAP to query a user's
group information. It sounds like your sssd clients don't need to use
the PAC to provide user/group identity and you shouldn't be concerned
with these messages.
Check out [2] for more details.
Mark
[1]:
http://msdn.microsoft.com/en-us/library/cc237917.aspx
[2]:
https://www.freeipa.org/page/Howto/Inspecting_the_PAC
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue