On ma, 08 huhti 2019, D wrote:
Thank you for the info Alexander, the blog post helped clear up some ambiguity. Makes sense now.
I have no qualms about renaming the hosts to live under the ipa subdomain instead of the main domain, and SSO is not required.
The idea is, SSH into linux boxes from arbitrary location using AD password, respecting uid/gid/homedir listed in unixAttrs, and respecting AD group memberships. We like indirect IPA integration instead of direct integration because of the centralized management features and the trust views.
So, can I expect the configuration below to work properly if the clients were moved to example.ipa.splat.acme.com, and if DNS for this subdomain were managed by the IPA servers?
It doesn't necessary needed to move DNS to IPA servers, just the clients to be registered in a DNS domain claimed by IPA in terms of AD forest topology. It helps to realise that IPA in trust to AD is seen by AD DCs as 'just another AD deployment' so all rules in AD apply here.
So moving clients to that domain is enough because then two things will happen: - AD clients will be able to request Kerberos tickets from their DCs towards IPA clients automatically
- most importantly, SSSD will be able to perform ticket verification in the case of a password-based authentication
The latter is what breaks your setup, it seems. When authenticating a user from AD, SSSD will always obtain a Kerberos TGT for that user's account and use it to request a service ticket to host/... principal on the machine. This service ticket is then will be used to validate that we weren't spoofed during authentication step. See 'krb5_validate' option in man page for sssd-krb5(5). In the case of IPA client belonging to a DNS zone owned by AD domain, SSSD will not be able to validate the ticket because it wouldn't even be able to obtain a service ticket to host/... as AD user in the first place.
Of course, you could switch 'krb5_validate' off but this means whoever is able to spoof your authentication exchange process, will have greater chances to own your clients.
Thank you for your time, D
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, April 8, 2019 11:49 AM, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On ma, 08 huhti 2019, D via FreeIPA-users wrote:
Hello, We're currently evaluating FreeIPA for handling the linux side of idm, with AD as the upstream provider. At this time, it seems everything is working well, but SSH into both ipa clients and servers as AD users does not. Sumit has provided a few suggestions in the past which have been addressed. The setup is stock with the following config:
M$ AD 2016, FreeIPA 4.6.4, sssd 1.16.2-13, all el7.6
Verified Two-way trust between IPA and AD
AD domain is splat.acme.com, IPA domain is ipa.splat.acme.com
All ipa-clients are on the splat.acme.com domain, and all users are username@splat.acme.com
Only ipa-servers are on the ipa.splat.acme.com domain.
In our setup, UID == GID, not sure if that matters.
In SSSD, under ipa.splat.acme.com ldap_search_timeout and krb5_auth_timeout have been increased.
With this setup (IPA clients are in a DNS domain owned by AD), no single sign-on as AD user will be possible from AD workstations to IPA clients. This is by Active Directory design where an AD domain owns the DNS zone named as the AD domain. One cannot punch holes or delegate Kerberos authentication to resources located on the hosts in this DNS zone to any other Kerberos realm (or other AD domain).
See https://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain for technical details. See https://www.redhat.com/en/blog/i-really-cant-rename-my-hosts for higher level and business-oriented overview of the problem and possible solutions (to which SSO is not possible with Kerberos anyway).
/ 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-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...