Hi, I am working on getting the logging for FreeIPA set-up properly. I have a test server (testy) running. This server/host is under control of FreeIPA. I have a user group defined for test users, and a host group for test servers. There is a HBAC rule to ensure that the members of testing group has only access to the test servers.
This works fine, but I have a question regarding the logs.
Scenario 1: User : test2 is member of the testusergroup and should be granted access to the test server. This works as expected, test2 is authorized to login to server and the log (var/log/krb5kdc.log) looks like this.
Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287272](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: NEEDED_PREAUTH: test2@MYREALM.NET for krbtgt/MYREALM.NET@MYREALM.NET, Additional pre-authentication required Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287272](info): closing down fd 11 Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287272](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: NEEDED_PREAUTH: test2@MYREALM.NET for krbtgt/MYREALM.NET@MYREALM.NET, Additional pre-authentication required Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287272](info): closing down fd 11 Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287271](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: ISSUE: authtime 1695041719, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)}, test2@MYREALM.NET for krbtgt/MYREALM.NET@MYREALM.NET Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287271](info): closing down fd 11 Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287271](info): TGS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: ISSUE: authtime 1695041719, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)}, test2@MYREALM.NET for host/testy.myrealm.net@MYREALM.NET Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287271](info): closing down fd 11
In this log, I see the AS_REQs and then the TGS_REQ for obtaining the TGS.
Scenario 2: User : test2 is not a member of testusergroup anymore and should not be granted access to the test server. This also works as expected, when logging in with correct password, test2 is denied service with message "Connection closed by ...." This is great, but I would like to see this happening in the log: The log looks like this:
Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287271](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: NEEDED_PREAUTH: test2@MYREALM.NET for krbtgt/MYREALM.NET@MYREALM.NET, Additional pre-authentication required Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287271](info): closing down fd 11 Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287272](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: NEEDED_PREAUTH: test2@MYREALM.NET for krbtgt/MYREALM.NET@MYREALM.NET, Additional pre-authentication required Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287272](info): closing down fd 11 Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287271](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: ISSUE: authtime 1695041889, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)}, test2@MYREALM.NET for krbtgt/MYREALM.NET@MYREALM.NET Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287271](info): closing down fd 11 Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287272](info): TGS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: ISSUE: authtime 1695041889, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)}, test2@MYREALM.NET for host/testy.myrealm.net@MYREALM.NET Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287272](info): closing down fd 11
In this log, I see the same AS_REQ as expected with no failure, since I am using correct password , and the same kind of TGS_REQ
My question is: When FreeIPA is handling the service authorization through the use of HBAC rules, why does it issue a similar TGS? Or is it different?, How does the actual authorization fail between the client and the server/service itself? Is it the content of the TGS ?
I know I can see failed login in the logs of the server it self, but I would like to see everything that goes on in the FreeIPA logs. regards Ole Frøslie Com4
On 18/09/2023 14:19, Ole Froslie via FreeIPA-users wrote:
Scenario 2: User : test2 is not a member of testusergroup anymore and should not be granted access to the test server. This also works as expected, when logging in with correct password, test2 is denied service with message "Connection closed by ...." This is great, but I would like to see this happening in the log: The log looks like this:
[...]
In this log, I see the same AS_REQ as expected with no failure, since I am using correct password , and the same kind of TGS_REQ
My question is: When FreeIPA is handling the service authorization through the use of HBAC rules, why does it issue a similar TGS? Or is it different?, How does the actual authorization fail between the client and the server/service itself? Is it the content of the TGS ?
Kerberos deals with the question of authentication: determining the identity of a client.
HBAC deals with the question of authorization: is the client allowed to SSH into a server?
I know I can see failed login in the logs of the server it self, but I would like to see everything that goes on in the FreeIPA logs.
It's up to SSSD, running on the server itself, to evaluate HBAC rules. So any messages logged when HBAC denies access by a client to a server have to be logged on the server itself.
On Пан, 18 вер 2023, Ole Froslie via FreeIPA-users wrote:
Hi, I am working on getting the logging for FreeIPA set-up properly. I have a test server (testy) running. This server/host is under control of FreeIPA. I have a user group defined for test users, and a host group for test servers. There is a HBAC rule to ensure that the members of testing group has only access to the test servers.
This works fine, but I have a question regarding the logs.
Scenario 1: User : test2 is member of the testusergroup and should be granted access to the test server. This works as expected, test2 is authorized to login to server and the log (var/log/krb5kdc.log) looks like this.
Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287272](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: NEEDED_PREAUTH: test2@MYREALM.NET for krbtgt/MYREALM.NET@MYREALM.NET, Additional pre-authentication required Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287272](info): closing down fd 11 Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287272](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: NEEDED_PREAUTH: test2@MYREALM.NET for krbtgt/MYREALM.NET@MYREALM.NET, Additional pre-authentication required Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287272](info): closing down fd 11 Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287271](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: ISSUE: authtime 1695041719, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)}, test2@MYREALM.NET for krbtgt/MYREALM.NET@MYREALM.NET Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287271](info): closing down fd 11 Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287271](info): TGS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: ISSUE: authtime 1695041719, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)}, test2@MYREALM.NET for host/testy.myrealm.net@MYREALM.NET Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287271](info): closing down fd 11
In this log, I see the AS_REQs and then the TGS_REQ for obtaining the TGS.
Scenario 2: User : test2 is not a member of testusergroup anymore and should not be granted access to the test server. This also works as expected, when logging in with correct password, test2 is denied service with message "Connection closed by ...." This is great, but I would like to see this happening in the log: The log looks like this:
Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287271](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: NEEDED_PREAUTH: test2@MYREALM.NET for krbtgt/MYREALM.NET@MYREALM.NET, Additional pre-authentication required Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287271](info): closing down fd 11 Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287272](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: NEEDED_PREAUTH: test2@MYREALM.NET for krbtgt/MYREALM.NET@MYREALM.NET, Additional pre-authentication required Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287272](info): closing down fd 11 Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287271](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: ISSUE: authtime 1695041889, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)}, test2@MYREALM.NET for krbtgt/MYREALM.NET@MYREALM.NET Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287271](info): closing down fd 11 Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287272](info): TGS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: ISSUE: authtime 1695041889, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)}, test2@MYREALM.NET for host/testy.myrealm.net@MYREALM.NET Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287272](info): closing down fd 11
In this log, I see the same AS_REQ as expected with no failure, since I am using correct password , and the same kind of TGS_REQ
My question is: When FreeIPA is handling the service authorization through the use of HBAC rules, why does it issue a similar TGS? Or is it different?, How does the actual authorization fail between the client and the server/service itself? Is it the content of the TGS ?
You are misinterpreting what is being done by what. Kerberos is authentication, not authorization, mechanism. Authorization is being done by SSSD on the client side. SSSD loads HBAC rules from LDAP server and performs actual authorization locally.
If you'd increase debug level for SSSD ('sssctl debug-level 9', for example) on the client side, then in the domain logs in /var/log/sssd you will see something like
/var/log/sssd/sssd_example.test.log: * (2023-09-10 7:40:24): [be[example.test]] [ipa_hbac_evaluate_rules] (0x0080): [RID#145] Access granted by HBAC rule [allow_all]
when access is allowed.
I know I can see failed login in the logs of the server it self, but I would like to see everything that goes on in the FreeIPA logs.
FreeIPA is not a single-server system, it is a combination of resources, both server and client sides. Despite 'A' in the project name, we don't have centralized audit feature, so you need to set that manually using other, existing, tools.
Hi and thank you for good clarification of my misunderstanding. I will rely on logging on the clients to see the complete picture. Regards, Ole Frøslie Com4
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Ole Froslie -
Sam Morris