Alternate UPN name suffixes
UPN suffix is the name of the domain that is added after the ‘@’ sign when a domain user account is created. Two or more trees in a forest is one way to have multiple name suffixes. Such as frankfu.com and frankfu.net.
You can use Active Directory Domains and Trusts to add user principal name (UPN) suffixes for the existing user account. The default UPN suffix for a user account is the DNS domain name of the domain that contains the user account. You can add alternative UPN suffixes to simplify administration and user logon processes by providing a single UPN suffix for all users. The UPN suffix enables the user to log on with the format username@domain. The UPN suffix is used only within the Active Directory forest, and it is not required to be a valid DNS domain name.
Benefits:
- Simplify logons.
- Disassociating the domain name from the user logon name, therefore enhance logon security
Membership in Domain Admins or Enterprise Admins , or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.
To add UPN suffixes
- Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click Start , click Administrative Tools , and then click Active Directory Domains and Trusts .
- In the console tree, right-click Active Directory Domains and Trusts , and then click Properties .
- On the UPN Suffixes tab, type an alternative UPN suffix for the forest, and then click Add .
- Repeat step 3 to add additional alternative UPN suffixes.
To add alternate UPN suffix to an existing domain user account:
- Go to Administrative Tools > Active Directory Users and Computers.
- On Active Directory Users and Computers snap-in, from the console tree in the left pane, double-click to expand the domain name.
- From the displayed list, click to select Users container.
- In the right pane, right-click the user for which alternate UPN suffix is to be added.
- From the displayed context menu, click Properties.
- On the opened properties box, go to Account tab.
- On the selected tab, under User logon name section, choose the alternate UPN suffix from the drop-down list that was created earlier in Active Directory Domains and Trusts snap–in.
- Once selected, click OK to save the modified settings.
- Close Active Directory Users and Computers snap-in when done.
Error:
- I can logon successfully on the client computer with a normal account.
- If I logon to a DC, this message pop up:
“The sign-in method you’re trying to use isn’t allowed. For more info, contact your network administrator.”
This only happened on the domain controller, so it may be a policy for the domain controller instead of all domain computers.
Solution:
Logon to a DC with admin account. In the Group Policy Management window Click Group Policy Management
1. Click Forest <yourforestname>, Click Domains , Click <yourdomainname>
2. Click Group Policy Objects, Click Default Domain Controllers Policy, Right Click on Default Domain Controllers Policy and select Edit by click. This opens a Group Policy Management Editor window.
3. In the Group Policy Management Editor window, click Default Domain Controllers Policy (<yourservername>.<yourdomainname>)
4. Click Computer Configuration, Policies, Windows Settings, Security Settings, Local Policies, User Rights Assignments. This causes the right pane in the opens a Group Policy Management Editor window to populate with a list on policies.
5. In the right pane in the opens a Group Policy Management Editor window double click Allow log on locally. This opens an Allow log on locally Properties window.
6. In the Allow log on locally Properties window click the button Add User or Group.. This opens an Add User or Group window.
7. In the Add User or Group window type the name to be added or click Browse.. to search for a name.
8. After a valid user or group name is typed into the edit box in the Add User or Group window click OK. This brings you back to the Allow log on locally Properties window .
9. After all users and groups have been added to this policy click on OK or APPLY in the Allow log on locally Properties window.
10. At the prompt type gpupdate /force to apply the policy.
Additional considerations
- To perform this procedure, you must be a member of the Domain Admins group or Enterprise Admins group in Active Directory Domain Services (AD DS), or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, search for “using run as” in Help and Support.
- UPN suffixes should conform to DNS conventions for valid characters and syntax.
- You can also perform the task in this procedure by using the Active Directory module for Windows PowerShell. To open the Active Directory module, click Start , click Administrative Tools , and then click Active Directory Module for Windows PowerShell . For more information about Windows PowerShell, see Windows PowerShell (http://go.microsoft.com/fwlink/?LinkID=102372).
SID filtering
Reason:
The sIDHistory attribute is used when migrating accounts from one domain to another. But there is a security risk. Suppose ForestA is trusted by ForestB. An administrator in ForestA can edit the sIDHistory attribute of a user in ForestA to include the SID of a privileged account in ForestB. When this user logs on to a domain in ForestB, he or she has the same access as the privileged account.
SID filtering(SID filtering quarantining) is used to counter this risk. It is enabled by default on external trust; disabled on forest trusts.
It should not be used between domains in the same forest because it would break AD replication and automatic transitive trusts.
How it works:
It causes the trusting domain to ignore any SIDs that aren’t from the trusted domain. Essentially, the trusting domain ignores the contents of the sIDHistory attribute.
Configuration:
SID filtering should be enabled or disabled from the trusting side of the domain and should be used only between forests or with external domains.
netdom trust trusting_domain_name /domain:trusted_domain_name /quarantine: {yes|no}
Other consideration:
- It should not be used between domains in the same forest because it would break AD replication and automatic transitive trusts.
- Before AD migration, SID filtering should be disabled, but should be reenabled after the migration.
part2->