locked
ADFS 3.0 authenticate fails if the user is in a child domain RRS feed

  • Question

  • Our forest has two domains; one domain is a child domain of the first. The ADFS 3.0 server is in the parent domain.

    Users in our child domain can authenticate to ADFS 3.0 with WIA; however, authenticate fails if the user uses forms authenticate.

    Wednesday, February 3, 2016 10:38 PM

All replies

  • Are you using of the following customizations:

    Do you have some logs to share?


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.


    Sunday, February 7, 2016 12:53 AM
  • Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          2/8/2016 11:52:37 AM
    Event ID:      4625
    Task Category: Logon
    Level:         Information
    Keywords:      Audit Failure
    User:          N/A
    Computer:      server.ad.domain.edu
    Description:
    An account failed to log on.

    Subject:
     Security ID:  domain\sso$
     Account Name:  sso$
     Account Domain:  domain
     Logon ID:  0x43CA8FC

    Logon Type:   3

    Account For Which Logon Failed:
     Security ID:  NULL SID
     Account Name:  
     Account Domain:  

    Failure Information:
     Failure Reason:  Unknown user name or bad password.
     Status:   0xC000006D
     Sub Status:  0xC0000064

    Process Information:
     Caller Process ID: 0x464
     Caller Process Name: C:\Windows\ADFS\Microsoft.IdentityServer.ServiceHost.exe

    Network Information:
     Workstation Name: server
     Source Network Address: -
     Source Port:  -

    Detailed Authentication Information:
     Logon Process:  W
     Authentication Package: Negotiate
     Transited Services: -
     Package Name (NTLM only): -
     Key Length:  0

    This event is generated when a logon request fails. It is generated on the computer where access was attempted.

    The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

    The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

    The Process Information fields indicate which account and process on the system requested the logon.

    The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

    The authentication information fields provide detailed information about this specific logon request.
     - Transited services indicate which intermediate services have participated in this logon request.
     - Package name indicates which sub-protocol was used among the NTLM protocols.
     - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
        <EventID>4625</EventID>
        <Version>0</Version>
        <Level>0</Level>
        <Task>12544</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8010000000000000</Keywords>
        <TimeCreated SystemTime="2016-02-08T17:52:37.798449100Z" />
        <EventRecordID>120480</EventRecordID>
        <Correlation />
        <Execution ProcessID="472" ThreadID="3760" />
        <Channel>Security</Channel>
        <Computer>server.ad.domain.edu</Computer>
        <Security />
      </System>
      <EventData>
        <Data Name="SubjectUserSid">S-1-5-21-436374069-484763869-1343024091-24369</Data>
        <Data Name="SubjectUserName">sso$</Data>
        <Data Name="SubjectDomainName">domain</Data>
        <Data Name="SubjectLogonId">0x43ca8fc</Data>
        <Data Name="TargetUserSid">S-1-0-0</Data>
        <Data Name="TargetUserName">
        </Data>
        <Data Name="TargetDomainName">
        </Data>
        <Data Name="Status">0xc000006d</Data>
        <Data Name="FailureReason">%%2313</Data>
        <Data Name="SubStatus">0xc0000064</Data>
        <Data Name="LogonType">3</Data>
        <Data Name="LogonProcessName">W</Data>
        <Data Name="AuthenticationPackageName">Negotiate</Data>
        <Data Name="WorkstationName">server</Data>
        <Data Name="TransmittedServices">-</Data>
        <Data Name="LmPackageName">-</Data>
        <Data Name="KeyLength">0</Data>
        <Data Name="ProcessId">0x464</Data>
        <Data Name="ProcessName">C:\Windows\ADFS\Microsoft.IdentityServer.ServiceHost.exe</Data>
        <Data Name="IpAddress">-</Data>
        <Data Name="IpPort">-</Data>
      </EventData>
    </Event>

    Monday, February 8, 2016 6:25 PM
  • I solved this one it was a permissions issue; the service account wanted permission to change passwords.

    Monday, March 7, 2016 8:00 PM
  • Can you elaborate on that resolution? The ADFS service account does not need the right to reset password an any moment. Where exactly was it blocking?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Tuesday, March 8, 2016 10:11 PM
  • I added the ADFS service account to the Account Operators group.
    Monday, May 2, 2016 5:57 PM
  • Can you provide additional details? There is no technical reason why this would have fixed the issue.

    For others reading this post. Please do not give to the ADFS service account any permissions anywhere else than on the ADFS database (well and the private key containers in the Program Data containers, but that comes by default anyways). Let's try to do some more root cause analysis here.

    It seems that you are using a gMSA account, correct? What let you think that you need to be able to reset user's password?


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Monday, May 2, 2016 7:31 PM
  • ADFS can by default authenticate users within a forest, without any special or exotic permissions. Between forests you need a 2-way trust

    also see:

    https://jorgequestforknowledge.wordpress.com/2013/09/24/ad-user-accounts-for-which-the-adfs-sts-can-generate-security-tokens/


    Cheers,

    Jorge de Almeida Pinto

    Principal Consultant | MVP Directory Services | IAM Technologies

    COMMUNITY...:

    DISCLAIMER: This post is provided "AS IS" with no warranties of any kind, either expressed or implied, and confers no rights! Always evaluate/test yourself before using/implementing this!

    Thursday, May 5, 2016 8:43 PM
  • I agree with Pierre.

    DO NOT IMPLEMENT THE SOLUTION SPECIFIED BY THE ORIGINAL POSTER

    DO NOT GIVE THE ADFS SERVICE ACCOUNT ANY SPECIAL/EXOTIC PERMISSIONS IN AD OR ANYWHERE ELSE AND DO NOT MAKE IT A MEMBER OF ANY POWERFULL ADMIN GROUP OR THE DEFAULT AD ADMIN GROUPS


    Cheers,

    Jorge de Almeida Pinto

    Principal Consultant | MVP Directory Services | IAM Technologies

    COMMUNITY...:

    DISCLAIMER: This post is provided "AS IS" with no warranties of any kind, either expressed or implied, and confers no rights! Always evaluate/test yourself before using/implementing this!

    Thursday, May 5, 2016 8:46 PM