Do trusted Domains have to follow the Minimum Password Length policy in the Trusting Domain?


  • Example: If CONTASA has a minimum password length of 7 characters, can a password of 7 characters login to TRUSTED if TRUSTED has minimum password length policy of 14? CONTASA and TRUSTED domain have a one way trust configured.
    Monday, January 23, 2017 8:45 AM

All replies

  • Hello,

    No, these policies are internal for the domain where the user is created. Trust only means that the trusting domain will recognize your credentials and forward them to trusted domain for validation. Trusted domain does not automatically have to comply with trusting domain password policies.


    • Proposed as answer by BearEater Monday, January 23, 2017 9:05 AM
    Monday, January 23, 2017 8:59 AM
  • Hi,
    Totally agree with Avendil, maybe, you could refer to some details about how the trust works:
    When a request for authentication is referred to a domain, the domain controller in that domain must determine whether a trust relationship exists with the domain from which the request comes, as well as the direction of the trust and whether the trust is transitive or nontransitive, before it authenticates the user to access resources in the domain. The authentication process that occurs between trusted domains varies according to the authentication protocol in use.
    Generally, clients use Kerberos in domain for authentication, the authentication process is:
    • The Kerberos client requests and then receives a TGT from the KDC.
    • The Kerberos client uses the TGT to request and then receive a service ticket for the local workstation from the KDC.
    • The service ticket for a network resource would be encrypted with the system or service key depending on whether the resource is a system or service. The workstation has a system key created when the computer joined the domain. The service ticket for the workstation is encrypted with this key.
    • The local LSA builds an access token from the credentials contained in the service ticket and then grants or denies the user access.
    While the Kerberos works over trust, the process is:
    1. User logs on to Workstation using credentials from trusted forest. The user then attempts to access resource in trusting forest.
    2. Workstation from trusted forest contacts the Kerberos Key Distribution Center (KDC) on a domain controller in its domain and requests a service ticket for the resource server SPN.
    3. This DC in the trusted forest does not find the SPN in its domain database and queries the global catalog to see if any domains in the trusted forest contain this SPN. Because a global catalog is limited to its own forest, the SPN is not found. The global catalog then checks its database for information about any forest trusts that are established with its forest, and, if found, it compares the name suffixes listed in the forest trust trusted domain object (TDO) to the suffix of the target SPN to find a match.
    So as you can see that no password policy is involved in this process, hope that the process as above helps you on the questions.
    You could also see more details from:
    Best regards,

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Tuesday, January 24, 2017 7:48 AM
  • Hi,

    I am checking how the issue going, if you still have any questions, please feel free to contact us.

    And if the replies as above are helpful, we would appreciate you to mark them as answers, and if you resolve it using your own solution, please share your experience and solution here. It will be greatly helpful to others who have the same question.

    Appreciate for your feedback.

    Best regards,


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Monday, January 30, 2017 8:07 AM