Due to MS15-027, Netlogon operations against AD DCs has to be done with Kerberos authentication. This means we need to make sure a proper Kerberos config is created when trust is not yet set up to address AD DCs discovered at this time and need to authenticate with AD admin credentials or TDO object against AD DC to obtain a Kerberos ticket, not directly authenticating with NTLM.
MS15-027: https://technet.microsoft.com/library/security/MS15-027
KB3002657: https://support.microsoft.com/en-ca/kb/3002657
Alexander and team working on this item.
I talked to abbra, Kerberos will be now used for fetching POSIX IDs but not for the trust itself. So before release, the ticket should be postponed to next release, to finish the work completely.
One-Way trust patch set:
master:[[BR]] 2dd5b46 trust: support retrieving POSIX IDs with one-way trust during trust-add[[BR]] 5025204 trusts: add ACIs to allow AD trust agents to fetch cross-realm keytabs[[BR]] a9570e8 ipa-pwd-extop: expand error message to tell what user is not allowed to fetch keytab[[BR]] d5aa1ee trusts: add support for one-way trust and switch to it by default[[BR]] 14992a0 ipa-adtrust-install: allow configuring of trust agents[[BR]] aa21600 ipa-sidgen: reduce log level to normal if domain SID is not available[[BR]] 47e1de7 trusts: pass AD DC hostname if specified explicitly[[BR]] 03c2d76 ipa-adtrust-install: add IPA master host principal to adtrust agents[[BR]] 785f659 add one-way trust support to ipasam[[BR]]
As mentioned in comment:5, moving to next release to finish the move.
Metadata Update from @abbra: - Issue assigned to abbra - Issue set to the milestone: FreeIPA 4.5 backlog
Metadata Update from @mkosek: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1484683 (was: 0) - Issue close_status updated to: None
Metadata Update from @pvoborni: - Custom field rhbz reset (from https://bugzilla.redhat.com/show_bug.cgi?id=1484683)
Windows Server does not deny NTLMSSP-based negotiation over SMB2+ protocol dialect, so while we want to move to use Kerberos everywhere, it is not urgent. We've got SMB2+ as default in Samba client code with rebase of Samba to 4.7+ in RHEL/Fedora so we are just fine right now.
Moving to use Kerberos everwhere when establishing trust would be a nice improvement because it would allow us to see broken environments more easily (if Kerberos auth as AD admin does not work from IPA master, surely there are bigger issues at stake).
However, one thing stops us from solving this ticket. We don't have good means to debug Kerberos failures so it would actually have created a worse experience for admins as they wouldn't be able to debug such issues themselves. Before we fully switch, we need to evolve our debugging facilities in this area as one cannot selectively trace Kerberos code within IPA framework.
This was fixed with fixes for https://pagure.io/freeipa/issue/8655
$ git log --grep https://pagure.io/freeipa/issue/8655 --oneline
ae7cd47 trust-fetch-domains: use custom krb5.conf overlay for all trust operations 9d19c08 ipatests: use fully qualified name for AD admin when establishing trust fd15f60 ipaserver/dcerpc.py: enforce SMB encryption on LSA pipe if available e157ea1 ipaserver/dcerpc.py: use Kerberos authentication for discovery cf17b7a ipaserver/dcerpc: use Samba-provided trust helper to establish trust
Metadata Update from @abbra: - Issue close_status updated to: fixed - Issue set to the milestone: None (was: FreeIPA 4.5 backlog) - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.