Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-4847

Establishing trust with AD domain using shared secret fails in FIPS mode

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • rhel-8.4.0
    • ipa
    • None
    • None
    • rhel-sst-idm-ipa
    • ssg_idm
    • None
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • Known Issue
    • Hide
      .FIPS mode does not support using a shared secret to establish a cross-forest trust

      Establishing a cross-forest trust using a shared secret fails in FIPS mode because NTLMSSP authentication is not FIPS-compliant. To work around this problem, authenticate with an Active Directory (AD) administrative account when establishing a trust between an IdM domain with FIPS mode enabled and an AD domain.
      Show
      .FIPS mode does not support using a shared secret to establish a cross-forest trust Establishing a cross-forest trust using a shared secret fails in FIPS mode because NTLMSSP authentication is not FIPS-compliant. To work around this problem, authenticate with an Active Directory (AD) administrative account when establishing a trust between an IdM domain with FIPS mode enabled and an AD domain.
    • Done
    • None

      Description of problem:
      When trying to establish trust with AD domain with IPA in FIPS mode creation of Windows side of trust fails with "Access denied"

      Version-Release number of selected component (if applicable):

      ipa-server-4.9.1-1.module+el8.4.0+9665+c9815399.x86_64

      How reproducible:
      Always

      Steps to Reproduce:
      1. Execute test suite: freeipa/ipatests/test_integration/test_trust.py
      2. Look at results of test case "test_establish_forest_trust_with_shared_secret"

      Actual results:
      transport.py 513 DEBUG RUN ['powershell', '-c', '[System.DirectoryServices.ActiveDirectory.Forest]::getCurrentForest().CreateLocalSideOfTrustRelationship("testrelm.test", 1, "qwertyuiopQq!1")']
      transport.py 558 DEBUG bash: line 2: /home/Administrator/env.sh: No such file or directory
      transport.py 558 DEBUG Exception calling "CreateLocalSideOfTrustRelationship" with "3" argument(s): "Access is denied.
      transport.py 558 DEBUG "
      transport.py 558 DEBUG At line:1 char:1
      transport.py 558 DEBUG + [System.DirectoryServices.ActiveDirectory.Forest]::getCurrentForest() ...
      transport.py 558 DEBUG + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      transport.py 558 DEBUG + CategoryInfo : NotSpecified: ( [], MethodInvocationException
      transport.py 558 DEBUG + FullyQualifiedErrorId : UnauthorizedAccessException
      transport.py 558 DEBUG
      transport.py 214 ERROR Exit code: 1

      Additional info:
      The test succeeds in non-FIPS mode in otherwise equivalent environment.

            [RHEL-4847] Establishing trust with AD domain using shared secret fails in FIPS mode

            Francisco Trivino Garcia added a comment -

            We are considering working on this ticket in a future release

            Francisco Trivino Garcia added a comment - We are considering working on this ticket in a future release

            pm-rhel added a comment -

            Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

            pm-rhel added a comment - Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

            Josip Vilicic (Inactive) added a comment -

            Hi Triviño,

            Do you know if it looks like this bug might get fixed in time for RHEL 8.8?

            Take care,

            Josip

            Josip Vilicic (Inactive) added a comment - Hi Triviño, Do you know if it looks like this bug might get fixed in time for RHEL 8.8? Take care, Josip

            Sergey Orlov (Inactive) added a comment -

            Tests for trust with shared secret should be skipped in FIPS mode: https://bugzilla.redhat.com/show_bug.cgi?id=1930796

            Sergey Orlov (Inactive) added a comment - Tests for trust with shared secret should be skipped in FIPS mode: https://bugzilla.redhat.com/show_bug.cgi?id=1930796

            Florence Renaud added a comment -

            Upstream ticket:
            https://pagure.io/freeipa/issue/8715

            Florence Renaud added a comment - Upstream ticket: https://pagure.io/freeipa/issue/8715

            Alexander Bokovoy added a comment -

            This warrant more investigation which may prove it would be not possible to use a shared secret trust in FIPS mode.
            I added a documentation note for RHEL 8.4.

            Alexander Bokovoy added a comment - This warrant more investigation which may prove it would be not possible to use a shared secret trust in FIPS mode. I added a documentation note for RHEL 8.4.

            Sergey Orlov (Inactive) added a comment -

            Created attachment 1756632 [details]
            logs with rc4 disabled on Windows side

            Sergey Orlov (Inactive) added a comment - Created attachment 1756632 [details] logs with rc4 disabled on Windows side

            Alexander Bokovoy added a comment -

            So, according to the network traffic for non-FIPS mode, AD DC attempts to auth to IPA DC with NTLMSSP. That's blocked in FIPS mode because RC4 (NTLM hash) is not allowed in FIPS mode, so that should be expected.

            The difference: in case of non-FIPS we respond with with STATUS_MORE_PROCESSING_REQUIRED, NTLMSSP_CHALLENGE which leads to eventual STATUS_LOGON_FAILURE and then use of a different method. In FIPS mode we don't do that and AD DC never goes further with a different method.

            Alexander Bokovoy added a comment - So, according to the network traffic for non-FIPS mode, AD DC attempts to auth to IPA DC with NTLMSSP. That's blocked in FIPS mode because RC4 (NTLM hash) is not allowed in FIPS mode, so that should be expected. The difference: in case of non-FIPS we respond with with STATUS_MORE_PROCESSING_REQUIRED, NTLMSSP_CHALLENGE which leads to eventual STATUS_LOGON_FAILURE and then use of a different method. In FIPS mode we don't do that and AD DC never goes further with a different method.

            Sergey Orlov (Inactive) added a comment -

            Without FIPS both variants works.
            I have provided network traffic capture for establishing trust using PowerShell.

            Sergey Orlov (Inactive) added a comment - Without FIPS both variants works. I have provided network traffic capture for establishing trust using PowerShell.

            Sergey Orlov (Inactive) added a comment -

            Created attachment 1756403 [details]
            network traffic for CreateLocalSideOfTrustRelationship without FIPS

            Sergey Orlov (Inactive) added a comment - Created attachment 1756403 [details] network traffic for CreateLocalSideOfTrustRelationship without FIPS

              ftrivino@redhat.com Francisco Trivino Garcia
              sorlov@redhat.com Sergey Orlov (Inactive)
              Francisco Trivino Garcia Francisco Trivino Garcia
              IPA QE Bot IPA QE Bot
              Louise McGarry Louise McGarry
              Votes:
              0 Vote for this issue
              Watchers:
              11 Start watching this issue

                Created:
                Updated: