The problem of accessing the windows file server by a freeipa domain user

[dorokhinra]

Hello! Faced with the problem of accessing the ws2019 file server by a trusted FreeIPA user. Stand Description:

• Active directory Domain Controller - (ad-01.winad.lan)
• Domain Controller Free Ipa - (srv-freeipa-01.test2.lan)
• Active directory Domain Controller (ad-dc-01.test.lan)
• File server on Windows server 2019 in the Active Directory domain - (ad-fs-01.winad.lan)
• FreeIPA client connected via ipa-sssd-client – (client2.test2.lan) A two-way trust relationship is set up between ad-01.winad.lan and srv-freeipa-01.test2.lan, as well as ad-dc-01.test.lan and ad-01.winad.lan: ad-01.winad.lan < - - > srv-freeipa-01.test2.lan srv-freeipa-01.test2.lan < - - > ad-dc-01.test.lan ad-dc-01.test.lan < - - > ad-01.winad.lan Scenario 1 AD user (administrator@WINAD.LAN) The user receives a kerberos ticket, connects to the windows folder via smbclient (smbclient //ad-fs-01.winad.lan/share -k) The connection is established, the user gets access. Scenario 2 User AD (super@TEST.LAN) The user receives a kerberos ticket, connects to the windows folder via smbclient (smbclient //ad-fs-01.winad.lan/share -k) The connection is established, the user gets access. Scenario 3 User FreeIPA (admin@TEST2.LAN) The user receives a kerberos ticket, connects to the windows folder via smbclient (smbclient //ad-fs-01.winad.lan/share -k) When connecting, a message appears – "Access is denied" An error occurs on the file server in the logs:

SMB Session Authentication Failure

Client Name: \192.168.1.40 Client Address: 192.168.1.40:59416 User Name: TEST2.LAN\admin Session ID: 0xFFFFFFFFFFFFFFFF Status: {Access Denied} A process has requested access to an object, but has not been granted those access rights. (0xC0000022) SPN: session setup failed before the SPN could be queried SPN Validation Policy: SPN optional / no validation Guidance: You should expect this error when attempting to connect to shares using incorrect credentials. This error does not always indicate a problem with authorization, but mainly authentication. It is more common with non-Windows clients. This error can occur when using incorrect usernames and passwords with NTLM, mismatched LmCompatibility settings between client and server, an incorrect service principal name, duplicate Kerberos service principal names, incorrect Kerberos ticket-granting service tickets, or Guest accounts without Guest access enabled When checking the traffic from the client machine, a strange behavior of the request for the provision of a service ticket was noticed. First there is an appeal to FreeIPA for the service cifs/ad-fs-01.winad.lan@TEST2.LAN naturally, there is no such service in FreeIPA, and the request fails, then the request goes to the ad domain controller and a service ticket is provided, but access to the smb session comes with an error in the response. Users of AD domains do not have this behavior – they immediately turn to ad-01.winad.lan with a reference principal (cifs/ad-fs-01.winad.lan@WINAD .LAN) Also tested with the help of login and password (smbclient //ad-fs-01.winad.lan/share –U admin –W TEST2.LAN), there are no problems access is provided. Have you ever encountered a similar problem? perhaps there are some solutions.

[abbra]

FreeIPA does not support this usecase without global catalog implementation. It seems you aren't using one, so it is expected to fail.

[dorokhinra]

How then is it possible to get access by password: smbclient //ad-fs-01.winad.lan/share –U admin –W TEST2.LAN?

[dorokhinra]

[dorokhinra]

In theory, you don't need a global directory to access it. It is needed to delimit access. When removing the wireshark trace from the file server during smbclient startup, it was not noticed that the file server accesses the domain controller at all

[dorokhinra]

log_smb_wireshark.tar.gz

[dorokhinra]

Here is the traffic from the client machine: freeipa kerberos auth user, freeipa login and password user, windows kerberos auth user

[dorokhinra]

fs_server_windows_wireshark.tar.gz

[abbra]

Is there anything in the Windows server logs about Kerberos? It may well not like our PAC content for some reason. In general, this use case is not supported, as I said, so far at least.

[dorokhinra]

Only two types of errors are shown on the windows server

[dorokhinra]

[dorokhinra]

[dorokhinra]

I hope our research will help you in your future work. Perhaps you will find something interesting

[abbra]

Well, you need to find out whether default access rights to IPC$ share allow any access to out-of-domain users. Perhaps it is not allowed due to security concerns so we get a denial and stop connecting. The explicit password connection is interesting but it looks like it goes straight for the share and not to IPC$ so it avoids this issue. Anonymous access is expected to be denied by default in Windows.

I don't have time to look at these issues for next few months at least, so I'll keep this issue open to not forget about it.

Thank you!

[dorokhinra]

Thank you very much! I will also be monitoring this issue. If you need help in researching this problem, I am ready to help

[dorokhinra]

Good evening! The problem has been solved! From wireshark traffic, it was noticed that as_req was sent without include-pac. We created our request with the help of python code with include-pac true. The user was then granted access. Do you know if it's possible to include the default mc-pac prompt? We searched the kerberos5 documentation but found nothing other than kinit --request-pac. However, I would like the request for MS-PAC to be enabled automatically.

[abbra]

Could you please share your python code and the trace? I'd also like to see at least krbtgt/AD@IPA and krbtgt/IPA@AD keys to be able to decode the kerberos bits in the trace. Your previous trace does not have any krb5 protocol exchanges.

We are currently investigating somewhat similar issue with Microsoft's dochelp team: https://lists.samba.org/archive/cifs-protocol/2022-September/003743.html. It is a bit weird because we do assign PAC to IPA users if they have SIDs.

[dorokhinra]

Here is the traffic with the received ticket via python code. There is an include-pac parameter in this AS_REQ. When using a tgt obtained in this way. Access to the windows folder is allowed. I want to note that the permission of the folder itself is authenticated users. 1.tar.gz

[abbra]

Ok, so this is about the client side when requesting a TGT. kinit --request-pac would basically set default options to include a PAC request towards KDC in AS-REQ.

I think what might be broken on FreeIPA side is that we were supposed to enforce issuing PAC in TGT to all users who have SID, regardless what clients are asking for. This is practical requirement since Microsoft enforced PAC buffer presence in November 2021 security updates. Dochelp response was that LOGON_INFO buffer was missing in the PAC, so may be these two connected: we don't default to ask for a PAC in AS-REQ and thus LOGON_INFO is missing? I'll look at this in more detail today.

[dorokhinra]

Here is the python code. It was taken from the impacket library: https://github.com/SecureAuthCorp/impacket ?ysclid=l88em3m1vz27641427. We redid it a bit, since t ipa_get_tgt.tar.gz he ASN 1 encoding did not work. I apologize for the purity of the code. This was done for testing, and very quickly.

[dorokhinra]

But I don't think it will be needed, since it can be done using kinit --request-pac

[abbra]

Got you, thanks.

[dorokhinra]

In touch! We solve the problem further! Thank you very much for the quick answers too!

[dorokhinra]

I checked the tgt request again via kinit --request-pac, access is also denied, although there is include-pac true in the traffic. Everything works well through python code. There is access. So the problem is not only in the MS-PAC request, but also in the ticket structure or AS-REQ request.

[dorokhinra]

Perhaps the problem is not in the ms-pac request, but on the KDC Active Directory side. Perhaps Active directory does not support SPAKE pre-authentication. This can be seen by the traffic (PA-ENC-TIMESTAMP parameter). According to the documentation: https://web.mit.edu/kerberos/krb5-devel/doc/admin/spake.html , it turns on when SPAKE is unsupported. Have you ever encountered such a problem?

[abbra]

This is irrelevant. A Kerberos client indicates to a KDC a list of supported pre-authentication mechanisms. KDC may respond with pre-authentication data using any of those it supports. It is normal for clients to indicate more than a KDC might support -- AD DCs do not support many of modern pre-authentication methods. They basically support only encrypted timestamp and PKINIT.

I am not sure why it would matter at all. TGT for IPA users is handled by IPA KDCs, not AD DCs.

[dorokhinra]

Yes, but nevertheless, access with my code, where I specify only include-pac and timestamp, is provided to the client.

[dorokhinra]

Good afternoon! We solved the problem with accessing the windows file server (disabled preauth except timestamp). To do this, on the freeipa server, you need to comment out a line in the /etc/krb5.conf.d/freeipa file. After that, we get a Kerberos ticket using kinit and connect via smbclient. However, when the user logs in (for example, su admin). It is impossible to get access again. In wireshark AS_REQ traffic, again with preauth. We suspect that the problem is with sssd. Is it possible to disable preauth on sssd somehow? We understand all the risks, but nevertheless we need to access and disable preauth.

[dorokhinra]

[abbra]

I am not sure what you are showing here. FAST is unrelated to SPAKE and is unrelated to anything else in this discussion.

I think you are experiencing the same problem we see with https://lists.samba.org/archive/cifs-protocol/2022-September/003743.html which turned out to be an issue with a lack of RFC8009 support in Windows environment. Since PAC has to include a PrivSvr signature, the signature should be done with one of algorithms supported by AD and MIT Kerberos currently uses one of RFC8009 algorithms instead. Then AD rejects tickets with these signatures.

[dorokhinra]

Maybe I did something wrong, but on the client in sssd.conf I added the parameter: krb5_use_fast = never and everything worked with sssd

[abbra]

There is an issue with cross-realm FAST use in MIT, we saw that in past too, but I think it is really boils down to this bug with enctypes I pointed out.

[dorokhinra]

Accepted, we will keep in mind. Thank you very much!