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: te...@myrealm.net for krbtgt/myrealm....@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: te...@myrealm.net for krbtgt/myrealm....@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)},
te...@myrealm.net for krbtgt/myrealm....@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)},
te...@myrealm.net for host/testy.myrealm....@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: te...@myrealm.net for krbtgt/myrealm....@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: te...@myrealm.net for krbtgt/myrealm....@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)},
te...@myrealm.net for krbtgt/myrealm....@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)},
te...@myrealm.net for host/testy.myrealm....@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.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
