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. Regards, // mem -- _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
