Showing posts with label Active Directory. Show all posts
Showing posts with label Active Directory. Show all posts

Wednesday, January 7, 2015

Understanding Azure Active Directory

I'd like to share an article, Azure Active Directory for the Old-School AD Admin to everyone. Do you know what is the different between Active Directory on-premises and Azure Active Directory? Do I have to learn Azure Active Directory? What function is Azure Active Directory provided? How do I get some resources about Azure Active Directory?

In my opinion, Azure Active Directory for the Old-School AD Admin is a good article for us to understand Azure Active Directory. Please spend some times to read it.

This posting is provided “AS IS” with no warranties, and confers no rights!

Saturday, October 4, 2014

Domain Controller demotion on Windows Server Technical Preview (vNext)

A previous post, I promoted a server a domain controller. Basically, the steps are same as Windows Server 2012 and Windows Server 2012 R2 to promote a server to the first domain controller. How about demotion steps of Windows Server Technical Preview (vNext)? Basically, it's the same. Anyway, I will demote the last domain controller, DC10, on my lab.
Lab environment
1 and the last domain controller in tls1.lab environment.

Prerequisites
Create a checkpoint for DC10 to perform domain controller demotion by GUI and PowerShell.
Lab
Demote a domain control though GUI.
1. On DC10, log in as Domain Administrator.
2. Launch "Server Manager".
3. On "Server Manager", click "Manage > Remove Roles and Features".
4. On "Before you Begin" window, click "Next".
5. On "Server Selection" window, click "Next".

6. On "Server Roles" window, un-check "Active Directory Domain Services".

7. Then, click "Remove Features".


8. On "Validation Results" window, click "Demote this domain controller".


9. On "Credentials" window, check "Last domain controller in the domain".


Because there is only 1 domain controller in my lab environment, I checked "Last domain controller in the domain" option. If there is more than 1 domain controller in your environment, you don't need to check this option. "Force the removal of this domain controller" is same as "Force removal" option of previous Windows versions.

10. Click "Next".
11. On "Warnings" window, check "Proceed with removal".


12. Click "Next".
13. On "Removal Options" window, check "Remove this DNS zone (this is the last DNS server that hosts the zone)" and "Remove application partitions" options.


"Remove this DNS zone (this is the last DNS server that hosts the zone)" option is applied to the last domain controller. If not, we don't need to check it.

14. Click "Next".
15. On "New Administrator Password" window, enter a new local administrator password for this server.


16. Click "Next".
17. On "Review Options" window, click "Demote".


After demotion, the server will restart automatically.


Then, we can remove "Active Directory Domain Services" though "Server Manager".

Demote a domain control though PowerShell.
1. On DC10, log in as Domain Administrator.
2. Launch "PowerShell" as administrator.
3. Perform "Uninstall-ADDSDomainController -LastDomainControllerInDomain -DemoteOperationMasterRole:$True -RemoveApplicationParitions" to demote the last domain controller.
4. Enter a new local administrator password.


5. Enter "Y" to demote the domain controller.


Then, we can perform "Uninstall-WindowsFeature AD-Domain-Services" to uninstall the Active Directory Domain Services feature on the server.

This posting is provided “AS IS” with no warranties, and confers no rights!

Friday, September 26, 2014

Using PowerShell for Active Directory on Microsoft Virtual Academy (MVA)

A new Microsoft Virtual Academy (MVA) will talk about using PowerShell for Active Directory. Let's learn PowerShell technique to manage your Active Directory environment by PowerShell. This course is hosted by Jason Helmick, PowerShell MVP, and Ashley McGlone, Microsoft Senior Premier Filed Engineer.
 
If you are interested in PowerShell or managing Active Directory. Don't miss it and register to join this live event at the following web site. The event will be started on 29-Oct-2014 8:00 am - 12:00pm PDT.
 
 
This posting is provided “AS IS” with no warranties, and confers no rights!

Friday, June 20, 2014

Active Directory Migration Tool (ADMT) for Windows Server 2012 and Windows Server 2012 R2

Microsoft updated and re-released the Active Directory Migration Tool (ADMT). The latest version is 3.2. However, it supports the domain function level from Windows Server 2003 to Windows Server 2012 R2 for Active Directory Migration.

To download latest version of ADMT, administrators need to log in Microsoft Connect.

Download link


More information


This posting is provided “AS IS” with no warranties, and confers no rights!

Sunday, January 12, 2014

The trust relationship between this workstation and the primary domain failed

When we use a domain user account to log in a workstation, we might get the following error.

"The trust relationship between this workstation and the primary domain failed".


This issue can be found on Windows 2000 to Windows Server 2012 R2 environment. How to make this error? Basically, Active Directory and workstations store 2 password versions of domain computer accounts which are "current password" and "previous password". If 2 password versions of this domain computer account don't matched the password copy of this domain computer account in Domain Controller, Windows displayed "The trust relationship between the workstation and the primary domain failed".  

By default, the machine account password changes every 30 days.


We can change this policy by Local Security Policy or Group Policy.

Some case will make this error.

1. The computer account was reset.


2. Administrators restore the backup or snapshot which is older than 60 days.

Quote from "Machine Account Password Process":

Now consider the scenario, when a machine is not connected to the network for a long period. Supposing on the client:
  • Old password = null
  • Current password = A
  • New random password = B
And on the machine account in AD:
  • unicodePWD = A
Remark: unicodePWD is a password copy of domain computer account

After 30 days when the Scavenger thread runs, the value would be:
  • Old Password = A
  • Current Password = B
At 60th day the same process happens again. So now  the newly generated password is C and the values are"
  • Old password = B
  • Current Password = C
Now when the client connects to AD, it will try the current password to authenticate. When that fails with error. Otherwise machine should be able to reset its password once it boots even after say 90 days.

End quote from "Machine Account Password Process":

There are 3 methods to fix this issue.


1. Disjoin and rejoin the computer to the domain.

Using this method, some services or applications cannot be started.


2. Perform "netdom resetpwd" to reset the machine account password in a domain computer.

According to KB325860, this procedure is most frequently user on domain controllers, but also applies to any Windows machine account.

I will try to perform it in my lab.

Lab environment
  • 1 domain controller named DC01 in contoso.com which is installed Windows Server 2012
  • 1 member server named App01 is a member server of contoso.com which is installed Windows Server 2012
Goal
Perform "netdom resetpwd" to fix "The trust relationship between the workstation and the primary domain failed" issue.


1. On DC01, log in as Domain Administrator.
2. Launch "Active Directory Users and Computers".
3. Locate "App01" and then right-click it.


4. Select "Reset Account".
5. On a pop-up window, click "Yes".


6. Click "OK".


7. Go to App01, log in as Domain Administrator.


Because the computer account has been reset, I cannot log in as any user of this domain. To fix this, we have to log in as Local Administrator and then perform "netdom resetpwd".

8. Log in as Local Administrator.
9. Launch "Command Prompt" as an administrator.


10. Perform "netdom resetpwd /s:DC01 /ud:Contoso\Administrator /pd:*" to reset and upload the local machine password to DC01 which is the domain controller.


11. Type the password of the domain administrator and then press "Enter".


12. Perform "nltest /sc_verify:contoso.com" to verify the trust.


13. Log out Local Administrator and log in as Domain Administrator.


As a result, the user can log in the workstation by using a domain user account.

Remark: There is no "nltest" and "netdom" command in some Windows versions like Windows Server 2003. You need to download and install the support tools before using it.

Remark: If you would like to reset a local machine password of a domain controller, please follow KB325860 to perform the additional steps.


3. Joe Richards, the MVP of Directory Services, wrote a detail article and a tool, MachinePwd, to fix this issue. If you are interested, please read his blog and follow his steps to fix it. 

References and more information:




This posting is provided “AS IS” with no warranties, and confers no rights!

Tuesday, December 31, 2013

Promote the first domain controller in Server Core environment by PowerShell in Windows Server 2012 or later

In Windows Server 2012 or later, administrators can promote a domain controller by erforming some cmdlets in PowerShell console. Administrators might not perform cmdlets to deploy a domain controller in GUI environment. However, if a server is in server core environment, administrators have to perform PowerShell cmdlets to promote a server to a domain controller.

Goal
Promote a server which was installed Windows Server 2012 Server Core to the first domain controller in Active Directory forest. 

Prerequisites
  • A server named DC01
  • An IP address and preferred DNS server of DC01 is 192.168.4.11/24

Steps
1. On DC01, log in as local Administrator.
2. On "Command Prompt", perform "PowerShell" to enter PowerShell console.


3. Perform "Install-WindowsFeature AD-Domain-Services -IncludeAllSubFeature -IncludeManagementTools" to install features and management tools of Active Directory.


4. Perform "Test-ADDSForestInstallation -DomainName <Domain Name> -ForestMode Win2003 -DomainMode Win2003 -InstallDns" to run the prerequisite checks for installing a new Active Directory forest with Forest and Domain functional level at Windows Server 2003.


You have to enter a "SafeModeAdministratorPassword" for this test.

The "Status" of this test is "Success" so we can continue promoting a server to a domain controller.

Remark: Windows Server 2012 supports the following Forest and Domain functional level: Win2003, Win2008, Win2008R2 and Win2012 and Windows Server 2012 R2 supports: Win2008, Win2008R2, Win2012 and Win2012R2.


Remark: "Test-ADDSForestInstallation" and other related cmdlets are under "ADDSDeployment" module.


5. Perform "Install-ADDSForest -DomainName <Forest domain name> -DomainNetbiosNAme <NetBios Name> -ForestMode Win2003 -DomainMode Win2003 -InstallDNS" to promote the first domain controller in a new forest.


6. Enter a "SafeModeAdministratorPassword" for this domain controller.

Remark: "SafeModeAdministratorPassword" is applied to recover the domain controller when entering "Directory Services Restore Mode".

7. Press "Y" to continue promotion.


Then, the server started to promote a server to be a domain controller and then will restart automatically.



Remark: We can also add other parameters for "Install-ADDSForest" cmdlet to change the default log path and the default NTDS database path. For more information, please enter "Help Install-ADDSForest -Full".

8. After DC01 restarted, log in as Domain Administrator.
9. On "Command Prompt", perform "PowerShell" to enter PowerShell console.
10. Perform "Get-ADForest". 


As a result, DC01 has been promoted to the first domain controller.

This posting is provided “AS IS” with no warranties, and confers no rights!

Monday, December 30, 2013

Sam-Account-Name limitation

According to TechNet of Microsoft, sAMAccountName is domain-wide uniqueness and 20-character limit for user objects. This character limitation of sAMAccountName cannot be changed because it is controlled by SAM Rule.

When I perform "Help New-ADUser -Full" in PowerShell of Windows Server 2012 or Windows Server 2012 R2,   the help of New-ADUser provided the same information about SamAccountName parameter for me.


Remark: Make sure the help file has been updated. If not, you cannot see the above information.

Test the uniqueness
Create 2 user accounts with more than 20-character in Active Directory.

1. On a domain controller, log in as Domain Administrator.
2. Launch "Active Directory Users and Computers".
3. Start to create a new user in Users container.


4. Next to "Full name" and "User logon name", enter "DevelopmentMSSQLSVC01".


First, "DevelopmentMSSQLSVC01" is more than 20-character and then User logon name (pre-Windows 2000) which is SamAccountName is stop at "0" because "0" is the 20 character of this account name.

5. Click "Next".
6. Provide and enter a password for this account.


7. Click "Next".
8. Click "Finish".
9. Start to create the second user in Users container.
10. Next to "Full name" and "User logon name", enter "DevelopmentMSSQLSVC02".


User logon name (pre-Windows 2000) of "DevelopmentMSSQLSVC02" is same as "DevelopmentMSSQLSVC01". 

11. Click "Next".


The pop-up window noticed that the pre-Windows 2000 which is SamAccountName have chosen so we have to change it to another one. Because all characters of "DevelopmentMSSQLSVC02" in pre-Windows 2000 logon is same as "DevelopmentMSSQLSVC01", it's proved that the SamAccountName must be unique.

12. Click "OK".
13. Click "Cancel".

For more information:

This posting is provided “AS IS” with no warranties, and confers no rights!

Monday, September 9, 2013

Locate a locked Active Directory user account attribute by LDAP

In "Search and unlock an Active Directory user account by PowerShell", we can easily locate a locked user account and unlock it. However, I would like to know which attribute related to a locked Active Directory user account.

In order to find this Active Directory attribute, I tried to use "Ldp" to locate it.

Test environment
1) 2 user accounts in Active Directory users container named User1 and User2.
2) Enabled "Account Lockout Policy" by GPMC in my testing domain.



3) 2 Server named DC01 and MS01. DC01 is a domain controller and MS01 is a member server.

Lab
1. Log on and Log off User1 and User2 on MS01.
2. On DC01, log in as Domain Administrator.
3. Launch "Ldp" by performing "ldp" in a Command Prompt.


4. On the menu of "Ldp", click "Connection > Connect".



5. On "Connect" window, next to "Server", enter "localhost".



6. Click "OK".
7. On the menu of "Ldp", click "Connection > Bind".



8. On "Bind" window, click "OK".



9. On the menu of "Ldp", click "View > Tree".



10. On "Tree View" window, next to "BaseDN", select the domain directory partition.



11. Click "OK".
12. On left pane of "Ldp", expand "Domain name > CN=Users,DC=domain,DC=local".
13. Double-click "CN=User1,CN=Users,DC=domain,DC=local".



14. Double-click "CN=User2,CN=Users,DC=domain,DC=local".


We can all attributes of both accounts.

15. Try to use a wrong password to log in User1 on MS01 three times.
16. Back to DC01, double-click "CN=User1,CN=Users,DC=domain,DC=local".



There is a new attribute, lockoutTime, to be added in User1 and this value is greater than 0.


17. Launch "Active Directory Users and Computers".
18. Navigate to "Users" container, double-click "User1".
19. On "User1 Properties" window, select "Account" tab.
20. Check "Unlock account. This account is currently locked out on this Active Directory Domain Controller".


21. Click "OK".
22. Back to "Ldp", double-click "CN=User1,CN=Users,DC=domain,DC=local".


As a result, the attribute, lockouttime, was reset to 0. 

I assumed that If I use ldap to query the attribute of users, lockouttime, is greater than 0, user accounts are locked.

This posting is provided “AS IS” with no warranties, and confers no rights!