On ke, 28 huhti 2021, Dominik Vogt via FreeIPA-users wrote:

What is the correct way to disable "kinit admin" on all ipa clients? In our setup, becoming admin should only possible on the ipa server. (Everything is done by scripts runn through ssh; nobody ever logs in to the server directly.)

Kerberos principals for users are not tied to specific hosts. There is also nothing that does explicit 'kinit admin' unless you do it yourself.

Anyone who is in possesion of 'admin' account password can ask to obtain a Kerberos ticket for this principal. There are no specific limitations to hosts where this could happen.

On ke, 28 huhti 2021, Dominik Vogt via FreeIPA-users wrote:

On Wed, Apr 28, 2021 at 01:10:08PM +0300, Alexander Bokovoy via FreeIPA-users wrote:

...

On ke, 28 huhti 2021, Dominik Vogt via FreeIPA-users wrote:

...

What is the correct way to disable "kinit admin" on all ipa clients? In our setup, becoming admin should only possible on the ipa server. (Everything is done by scripts runn through ssh; nobody ever logs in to the server directly.)

Kerberos principals for users are not tied to specific hosts. There is also nothing that does explicit 'kinit admin' unless you do it yourself.

Anyone who is in possesion of 'admin' account password can ask to obtain a Kerberos ticket for this principal. There are no specific limitations to hosts where this could happen.

So there is no way to prevent that someone issues administrative ipa command from any host, except by keeping the password secret?

Correct, you have to keep passwords safe from the parties you don't want to use the powers those passwords entail.

On ke, 28 huhti 2021, Dominik Vogt via FreeIPA-users wrote:

On Wed, Apr 28, 2021 at 02:57:08PM +0300, Alexander Bokovoy via FreeIPA-users wrote:

...

On ke, 28 huhti 2021, Dominik Vogt via FreeIPA-users wrote:

...

So there is no way to prevent that someone issues administrative ipa command from any host, except by keeping the password secret?

Correct, you have to keep passwords safe from the parties you don't want to use the powers those passwords entail.

Will the clients work if we delete the /usr/bin/ipa on them?

If you'd want to remove IPA client componets after enrolling, then you need to remove python3-ipalib (on Fedora or RHEL 8). That would remove freeipa-client and python3-ipaclient but it will not remove any configuration, so things would continue working. At least theoretically, I haven't tried that myself.

I'd recommend you to investigate this on your own before deploying such changes. Note that IPA API use does not require existence of these packages and people can actually communicate with IPA server with just an HTTPS request, using whatever HTTP client they have. So, removing packages will not solve your problem at all.

On Чцв, 14 ліс 2024, Magnus Sandberg via FreeIPA-users wrote:

Hi,

This is a rather late reply but I'm now to RedHat IdM.

Would it be possible to have a kdcpolicy plugin that only allow admin tokens issued on machines that are listed in some allow list? I guess the list could even by dynamic as I also would like to limit it to the IdM servers them selves.

It is possible to write a KDC policy plugin but I don't think it will help. Kerberos tickets have concept of adressfulness but it is not used in real life due to NATs and other factors.

See, for example, very recent discussion upstream where MIT Kerberos upstream maintainer explains it: https://github.com/krb5/krb5/pull/1359#issuecomment-2472625591 -------- Addressful tickets are rarely used. When they are used, the AS client decides what addresses get stored in the ticket. The ticket is then restricted to use from one of the listed addresses. In our client implementation (e.g. if you do "kinit -a"), we construct a list of the local interface IP addresses and asks for those. ---------

So if you want to make decision based on the addresses client has provided in the list, you are already in a pretty bad situation as you have to trust that information. What if an attacker knows that you will only be issuing 'admin' tickets on IPA servers? They'd simply fabricate their AS-REQ packet with corresponding addresses.

A better approach would be to switch admin accounts to use passwordless authentication methods, with factors that cannot be easily get access to by attackers: smartcards or FIDO2 passkeys, for example.

I guess that it would require some C programming but maybe not that hard to do.

Regards, // mem -- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

On Пят, 15 ліс 2024, Magnus Sandberg via FreeIPA-users wrote:

Alexander Bokovoy wrote:

...

On Чцв, 14 ліс 2024, Magnus Sandberg via FreeIPA-users wrote:

...

Hi, This is a rather late reply but I'm now to RedHat IdM. Would it be possible to have a kdcpolicy plugin that only allow admin tokens issued on machines that are listed in some allow list? I guess the list could even by dynamic as I also would like to limit it to the IdM servers them selves.

It is possible to write a KDC policy plugin but I don't think it will help. Kerberos tickets have concept of adressfulness but it is not used in real life due to NATs and other factors. See, for example, very recent discussion upstream where MIT Kerberos upstream maintainer explains it: https://github.com/krb5/krb5/pull/1359#issuecomment-2472625591

---

Addressful tickets are rarely used. When they are used, the AS client decides what addresses get stored in the ticket. The ticket is then restricted to use from one of the listed addresses. In our client implementation (e.g. if you do "kinit -a"), we construct a list of the local interface IP addresses and asks for those.

---

So if you want to make decision based on the addresses client has provided in the list, you are already in a pretty bad situation as you have to trust that information. What if an attacker knows that you will only be issuing 'admin' tickets on IPA servers? They'd simply fabricate their AS-REQ packet with corresponding addresses. A better approach would be to switch admin accounts to use passwordless authentication methods, with factors that cannot be easily get access to by attackers: smartcards or FIDO2 passkeys, for example.

Thanks for your reply. I'm not familiar with the krb source code and what's going on internally but I think I got some understanding about the ongoing work from the link you provided.

My usecase it to "help" my fellow IdM admins to not manage the IdM from the wrong machine. Our policy states that you should manage the IdM locally via dedicated jumphosts. But when you're in a hurry to fix a problem it may be easy to do "kinit admin" and use the relevant ipa commands from some host just to fix the problem, and that wouldn't be okay. As this is for internal use in our own networks, we don't have NAT between our networks. And the main goal is not to protect against an attacker.

I checked KDC source code. There are two sets of addresses we know about during ticket issuance:

- the remote address a client used to establish connection to us. It might be IPv4, IPv6, or something else (it will be UNIX domain socket in case of a local KDC, for example).

- the set of addresses the client puts into a ticket request. These will be used to check against the client's address in case of addressful tickets.

KDC policy plugin does have access to the former but not to the latter. It means KDC policy plugin cannot say 'this client address as seen by KDC cannot request this ticket'. It can only say 'this client address in the client request is OK or not OK for a request'.

There is another plugin type: audit plugin. This one gets all information and is called early in the processing stage, so technically it could decide whether a particular request is allowed or not based on the client remote address. There are two issues, though:

- audit plugin calls cannot influence control flow; AS-REQ audit does not return a state that could be processed to stop a ticket issuance;

- audit plugin call for AS-REQ happens *before* we parsed the original request, so the data was not yet validated.

So either plugin is not capable to handle this case.

On Пят, 15 ліс 2024, Magnus Sandberg via FreeIPA-users wrote:

Alexander Bokovoy wrote:

...

On Пят, 15 ліс 2024, Magnus Sandberg via FreeIPA-users wrote:

...

My usecase it to "help" my fellow IdM admins to not manage the IdM from the wrong machine. Our policy states that you should manage the IdM locally via dedicated jumphosts. But when you're in a hurry to fix a problem it may be easy to do "kinit admin" and use the relevant ipa commands from some host just to fix the problem, and that wouldn't be okay. As this is for internal use in our own networks, we don't have NAT between our networks. And the main goal is not to protect against an attacker.

I checked KDC source code. There are two sets of addresses we know about during ticket issuance:

• the remote address a client used to establish connection to us. It might be IPv4, IPv6, or something else (it will be UNIX domain socket in case of a local KDC, for example).
• the set of addresses the client puts into a ticket request. These will be used to check against the client's address in case of addressful tickets.

KDC policy plugin does have access to the former but not to the latter. It means KDC policy plugin cannot say 'this client address as seen by KDC cannot request this ticket'. It can only say 'this client address in the client request is OK or not OK for a request'. There is another plugin type: audit plugin. This one gets all information and is called early in the processing stage, so technically it could decide whether a particular request is allowed or not based on the client remote address. There are two issues, though:

• audit plugin calls cannot influence control flow; AS-REQ audit does not return a state that could be processed to stop a ticket issuance;
• audit plugin call for AS-REQ happens *before* we parsed the original request, so the data was not yet validated.

So either plugin is not capable to handle this case.

First of all, thanks for spending time answering my questions.

If I understand you correct the KDC policy sees the remote address the client uses in the connection to the KDC, if using IP protocols. Wouldn't that be enough to create the policy I'm thinking of? Also accepting the upcoming local UNIX socket.

It is the other way around. KDC policy plugin doesn't get access to the remote address the client actually used, only to the list of addresses it might have presented to the KDC as a part of the request. So it cannot decide based on where the request came from.