On 17.01.23 10:07, Alexander Bokovoy wrote:
On ti, 17 tammi 2023, Ronald Wimmer via FreeIPA-users wrote:
On 16.01.23 21:46, Alexander Bokovoy wrote:
On ma, 16 tammi 2023, Ronald Wimmer via FreeIPA-users wrote:
On 16.01.23 20:16, Alexander Bokovoy via FreeIPA-users wrote:
On ma, 16 tammi 2023, Ronald Wimmer via FreeIPA-users wrote:


On 16.01.23 15:48, Alexander Bokovoy via FreeIPA-users wrote:
On ma, 16 tammi 2023, Ronald Wimmer via FreeIPA-users wrote:
I have a setup where we have four IPA servers. Two of them are able to talk to the AD Domain Controllers directly. I set them up as AD Trust controllers.

The other two IPA servers can only talk to these IPA servers and not to the AD DCs directly. Thats why I wanted them to have the Trust Agent Role only.

Trust Agent also should be able to talk to AD DCs. If those servers
cannot talk to AD DCs, they cannot be trust agents.

So it seems that I have misunderstood how trust agents can be used. I thought AD communication is only done on trust controllers whereas trust agents are some kind of proxies.

They aren't proxies but since they don't run DC services expected by
Active Directory domain controllers, they cannot be contacted by AD DCs to perform normal LSA RPC calls. So they are agents in this sense: they cannot participate in DC to DC communication with Active Directory DCs. Identity resolution on agents is performed by SSSD which talks to LDAP
services of AD DCs, not the other direction.

Thanks for clarifying that. But what's the benefit of using trust agents then?

Just that: when trust is established and you don't need anything to act
from AD DC side, use of trust agents reduces an attack surface as no
Samba services would be running on that system.


What I tried to accomplish was putting two IPA servers in the same firewall zone as the windows AD DCs. Another two IPA servers reside in the same zone where potential IPA clients are. Clients should have communicated only with the IPA servers within the same zone. (Of course, IPA servers could have communicated amongst each other) - Am I right that there is no possibility of realizing such a scenario? (because clients always need to be able to talk to the AD DCs?)

There is no way to achieve that without IPA servers being able to talk
to AD DCs. You are right as well: clients must always be able to talk to
AD DCs for authentication, e.g. Kerberos. This part can be routed via
KDC proxy on IPA server side, though but IPA server itself has to have
direct access to AD DCs.

IPA trust agents need to talk LDAP and Kerberos to AD DCs, IPA clients
only need to talk Kerberos to AD DCs and LDAP/Kebreros to IPA servers.


Could you briefly explain why Kerberos is needed? When I read kerberos I always have passwordless login in mind. But isn't it used somehow for password-based logins as well? (Do you know a source that explains that without going too much into all the technical details?) I need to know a little more about that...

SSSD for both 'ipa' and 'ad' providers requires Kerberos authentication.

If you are using Kerberos authentication to some front-facing
application, that is consumed by that application.

When you need to actually login to the system at a console, be it a
desktop or a terminal console, you would be asked to login with a
password. On IPA-enrolled systems that means using SSSD through a PAM
interface and provide a password. PAM module pam_sss will pass it
through to the SSSD backend and that one will initiate Kerberos
authentication using this password against a domain controller. There
are few cases when in IPA case SSSD might opt to LDAP authentication but
this is certainly not a normal setup.

If you want a not-so-technical source, I'd recommend reading Microsoft
Active Directory overview documents. This example from AD authentication
services protocols overview is describing a password-based login in AD
environment:
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-authsod/b221998b-242b-41ef-a116-891c73fd2410

The whole MS-AUTHSOD document is a great starting point.



What could be a solution for my scenario. Use a trust controller and a trust agent in the same firewall zone as the Windows AD DCs? The clients would only need to communicate to the AD DCS via Kerberos and to the trust agent via LDAP and Kerberos, right?

Put IPA servers in the same firewall zone as the AD DCs. Configure your
IPA clients to use KDC proxy on IPA servers when talking to AD DCs.
Enable IPA clients to only talk to IPA servers.

Thanks a lot for taking the time to answer my questions! I do highly appreciate that!

Cheers,
Ronald
_______________________________________________
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

Reply via email to