The Sysadmins

Tips and tricks from the Sysadmins

Category: Active Directory (page 1 of 4)

Deploying Microsoft LAPS – Part 1

What is LAPS?

A lot of organisations will use the same local administrator password across all machines, which is a bad idea for a number of reasons. At a basic level, if this password is learnt, it allows anyone to install software as an administrator – at a higher level it facilitates things such as pass the hash, mimikatz and general reconnaissance against your machines (usually with the goal of elevating to Domain Admin).

If you currently deploy your Local Administrator Account via Group Policy Preferences, this makes things even easier for an attacker to obtain the shared local administrator password. The CPASSWORD value is easily searchable against SYSVOL and Microsoft provide the 32-byte AES key which can be used to decrypt the CPASSWORD. Alan has a great post here why you should stop using Group Policy Preferences for deploying Local Administrators.

So what can we do?

LAPS – Local Administrator Password Solution! This is Microsoft’s solution to managing Local Administrator account passwords across an organisation. LAPS solution features include:

• Sets a unique randomly generated password PER machine
• Automatically change the Local Administrator Password every x days
• Stores Local Administrator Passwords as an attribute of the Computer Object in Active Directory
• Password is protected in AD by AD ACL, so granular security model can be easily implemented
• Password is protected during the transport via Kerberos encryption

Deployment Steps

  1. Installs LAPS onto management machine
  2. Extend Schema and prepare Active Directory
  3. Deploying LAPS client to those machines you wish to manage
  4. Configure Group Policy to enable and set the relevant policies

This post will cover steps 1, 2 and 3.

Management Machine

First off, we’re going to install the management portion of LAPS. Download LAPS here and next, next through the installation. On the custom setting page choose all of the management tools. The AdmPwd GPO Extension is required if the machine you’re installing the management portion on will also be managed by LAPS.

Continue reading

Searching Group Policy

Today we’re looking at 3 easy ways to search Group Policy settings, primarily focusing on the Administrative Templates. With over 3000 settings (~3500 with Server 2012/Windows 8) you’re going to want to be aware of these methods!

1. Search with Microsoft’s GPSearch Site

Microsoft put this site up a couple of years ago, initially at http://gps.cloudapp.net/, this has now changed to http://gpsearch.azurewebsites.net and will enable you to search any of the Computer or User Administrative Template settings within Group Policy. They’re also linking to a Windows Mobile Application for searching group policy, it’s nice to see they’re putting out apps like this: http://www.windowsphone.com/en-gb/store/app/group-policy-search/d1615909-62e2-df11-a844-00237de2db9e.

SearchingGroupPolicy-6

2. Search with the Group Policy Management Console

You can search from within the GPMC MMC console itself by right clicking the Administrative Templates for the Computer or User segment and selecting filter options. The initial criteria is “any”, so you can simply type a keyword and filter the results based on that keyword, make sure you right click Administrative Templates and set the filter to “on”. The configured and commented options are quite interesting, I rarely see people commenting group policy objects or settings but this would allow you to only return commented or configured settings within a GPO.

SearchingGroupPolicy-2

SearchingGroupPolicy-3

SearchingGroupPolicy-4

3. Search with the Group Policy Settings Reference XLS(x)

I really like the spreadsheets that Microsoft have provided for searching Group Policy: http://www.microsoft.com/en-au/download/details.aspx?id=25250; the filters in place make it very simple to filter out what you’re looking for. I particularly like the “Reboot required” and “Logoff required” columns, very helpful. These spreadsheets are well worth a look as they tend to give you a little more information than the methods above.

SearchingGroupPolicy-7

Server 2012 – Active Directory Fine Grained Passwords Revisited

Fine grained password policies (FGPP) were introduced back in Server 2008, and the process for creating them, whilst not massively difficult wasn’t particularly intuitive. Microsoft have improved this a lot with Server 2012, custom password policies are now easier to create, assign and monitor.

How to Create a Password Setting

Open Active Directory Administrative Center, expand System, find the password settings container, select new and password settings.

2012-FineGrained-1

These settings should all be familiar to you, if you’ve ever set a domain password policy before with group policy. If not, please refer to this Technet page for more detail about each of the settings.

In this example I’ve disabled the account lockout policy, and added the Sales security group.

2012-FineGrained-2

To add users or groups, select add and find the object in Active Directory.

2012-FineGrained-6

View members of a password setting, or check if a user has a password setting applied

There are two easy ways to find which users or groups are assigned to a custom password setting, or if a user is a member of a password setting.

To find what users/groups are members of a custom password setting, simply find the policy in the password settings container and double click. View the “Directly applies to” box, to view the members (See the 2nd screenshot above for an example).

2012-FineGrained-3

To see if I particular user has a custom policy against it, simply right click the user within the Active Directory Administrative Center and select view resultant password settings. If there is a password setting against the user, it will open the policy to expose the current settings.

2012-FineGrained-4

If a user does not have a custom password policy, it will show you a message stating “User does not have resultant fine grained password settings. Please check the user’s domain password settings.”

2012-FineGrained-5

Much easier, I’m sure you’ll agree.

Server 2012 – Add Additional Domain Controller to a 2008 R2 Domain

When you try and run DCPromo from the explorer shell on Windows Server 2012, you will receive the following message “The Active Directory Domain Services Installation Wizard is relocated in Server Manager. For more information, see http://go.microsoft.com/fwlink/?LinkId=220921.”

Dudewheresmydcpromo

No DCPromo, what now?! DCPromo is deprecated in Windows Server 2012, so adding an additional Domain Controller is slightly different than in earlier versions. The new process is still straight forward, and the wizard will even extend the schema (to version 56) for you- meaning it’s a one-stop process. Adding a Windows Server 2012 Domain Controller requires a Windows Server 2003 forest functional level or higher on your existing forest.

Promoting a Server 2012 to a Domain Controller

1. Open Server Manager, select Local Server on the left hand side then choose Manager -> Add roles and Features.

Server2012-DC1

2. Next.

Server2012-DC2

3. Next.

Server2012-DC3

4. Select the server you wish to promote.

Server2012-DC4
Continue reading

ADMT Series – Misc. Cannot open database ADMT – The login failed

If you install ADMT under a different user, you may receive this error when trying to access the ADMT MMC console:

Unable to check for failed actions. : DBManager.IManageDB.1 : Cannot open database "ADMT" requested by the login. The login failed.

To resolve this you will need to install the Microsoft SQL Server management Studio, download available here: http://www.microsoft.com/en-us/download/details.aspx?id=7593

Run the installer and select New SQL Server stand-alone installation or add feature to an existing installation.

Choose Add features to an existing instance of SQL Server 2008.

Select Management Tools – Basic (it’s greyed out here as I’ve already got them installed).

Follow the rest of the installation through, when complete run the SQL Server Management Studio and connect to the SQLEXPRESS instance.


Continue reading

ADMT Series – 11. Computer Migration Wizard

This post will cover the process of migrating computers from the source domain to the target domain. After you migrate a batch of local user profiles, migrate the corresponding batch of user workstations.

ADMT Supported Operating Systems for Computer Migration

ADMT 3.2 – supports the migration of computers that run Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 R2.

ADMT 3.1 – supports the migration of computers that run Windows 2000 Professional, Windows XP, Windows Vista, Windows 2000 Server, Windows Server 2003, and Windows Server 2008

ADMT 3.0 – supports the migration of computers that run Windows 2000 Professional, Windows XP, Windows NT 4, Windows 2000 Server, and Windows Server 2003.

Computer Migration

From the ADMT machine, run ADMT and select Computer Migration Wizard.

Select the source and target domain, you can also select which specific domain controller to use.

Select computers from the domain or use an include file. This may be quite useful if you’re doing an OU at a time as you can export objects of an OU via ADUC (right click -> export list).
Continue reading

ADMT Series – 10. Security Translation Wizard – Local Profiles

This post will cover the Security Translation Wizard from the context of migrating local user account profiles into the target domain. This step is crucial if you want your users to maintain the same local profile. The Translation Wizard needs to be run before migrating the computers. If you decide to skip this step, the users will receive a new profile when they logon to the target domain for the first time:

Be aware this process can take some time, I’ve seen it take up to 40-45 minutes on some older laptops.

Translation Security Wizard – For Local Profiles

From the ADMT machine, run ADMT and select Security Translation Wizard.

Next.

If you have migrated the source domain user accounts, you can select Previously Migrated Objects- this will pull the list of the source and target SIDs from the ADMT database for mapping across the new permissions. This is probably the best method if you have migrated the users across, or if you don’t need granular control over the process.

You can use a SID mapping file to link two accounts from the source and target domain. In the migration I recently went through, the accounts had already been created in the target domain, and there was no requirement for SID history. I decided that merging the user accounts wasn’t necessary. As I hadn’t migrated the users I was unable to use the previously migrated objects option, as ADMT has no history of the account SIDs in the ADMT database. A SID mapping file was used instead.

The SID Mapping file can be in the following formats:

OldSID,NewSID

or

OldSID,TARGET\USER

or

SOURCE\USER,TARGET\USER

For demonstration purposes I have migrated a bunch of users accounts so I can choose the previously migrated objects option.
Continue reading

Older posts