Resetting Default Domain Policy & Replacing EFS Certificate

I have inherited some pretty messy domains over the last couple years when it comes to GPO’s, and knowing the short and sweet way to reset the Default Domain and Default Domain Controller policies has come in handy.  As I hope you know, Microsoft only suggests only making changes to these policies for account, account lockout, password, and Kerberos policies.  I agree that it should stay clean, there is no reason not to break things out into different GPO’s in this day and age.  But alas let’s move on before this becomes a rant.

To reset either of the default GPO’s, you use the dcgpofix utility.  The syntax is quite simple, just take a backup of the GPO you’re resetting before you do it as I’m sure you already know.

Reset the Default Domain Policy:

Reset the Default Domain Controller Policy:

Reset both the Default Domain Controller and Default Domain Policy:

Wha-Lah you are done.  Go and set you account/account lockout/password/Kerberos settings as dictated by your organization.  You may run into an issue where the utility is unable to recreate the EFS certificate as seen below:

This is pretty simple, you will just have to create a new certificate for EFS and add it to the policy manually.  Now you can accomplish this in a number of different ways, but I’m going to show you the simplest (in my opinion) in which you create a self-signed certificate that will out live you.  Open up a PowerShell or Command Prompt as Administrator and move to the directory that you would want to save the certificate.  Once there run the following, where “CertName” is whatever you would like to name the certificate:

This will generate your self-signed certificate in whatever directory you’re sitting in.  Now you need to import it into your Default Domain Policy to be used for EFS.  Open your Group Policy Management Editor and navigate to “Computer Configuration\Policies\Security Settings\Public Key Policies\Encrypting File System”.  Once there right click EFS and select the “Add Data Recovery Agent…” option.

Move through the wizard selecting the “Browse Folders…” option to select your certificate.  You will likely get a pop-up saying “Windows cannot determine if this certificate has been revoked”.  This is just because it is a self-signed certificate, so select Yes when prompted to install the certificate.  Next your way through the rest of the wizard and you are all set.

Create a “Dynamic” AD Group using PowerShell

I had a request come to me today for an AD group that will always contain all of the users in a particular OU.  If you have come across my little place on the internet before, you are likely familiar that I do a lot of work with AD FS.  Keeping that in mind, I wanted to make sure only users that were synced with Azure AD/O365 from this OU were added to the group.  Additionally, if that user were no longer synced with Azure AD/O365 I wanted to remove them from the group to keep it tidy.  And thus I came up with the following script that I have run every hour:

 

Exchange Online Missing Mandatory Parameters: ArchiveGuid

I’ve been working with hybrid Office 365 environments for quite some time now and liked to think that I had come across most of the weird errors, but of course just when you think that there has to be another random msExch attribute to come along and muck things up.  I came across just such a case today, presenting itself with the following error in Office 365:

Exchange: Cannot process command because of one or more missing mandatory parameters: ArchiveGuid.

I did a little digging and came across this blog post that found the msExchRemoteReceipeintType attribute to be the culprit.  I cleared the value, kicked off a full dirsync and wha-lah!  Problem solved.

Copy AD User Group Membership to Another User

Had the guy on my service desk that handles all of the user creation come to me recently with this request.  Well when I say recently it was like a month or two ago, but you know how things go.  Anyhow I threw this script together rather quickly to copy the group membership of one AD user to another.  The basic breakdown is I ask for admin creds, prompt for what customer we’re dealing with so I know what DC to point to, specify the source user you want to copy, specify the target user you want to copy to, and finally confirm you’re sure that’s what you wanna do.  Simple!

 

Enabling Password Change in ADFS 3.0

I would like to start this off the same way that many posts on this topic do by defining the difference between password change and password reset.  Looking at the two terms they seem like the same thing, but in the wonderful nerdy world that we call our home they are two very different things.

Password Change, the topic of this post, is the ability for an Active Directory user to change their password when they know what their password currently is.  Password Reset is when an Active Directory user does not know their password and must provide alternate recovery methods, for example a phone number or security questions.  While Password Reset functionality is cool and completely possible with ADFS (psst Password Writeback), that will have to wait for another post.  Today we are focused on Password Change with ADFS, introduced in 3.0 to my knowledge, which is most commonly used for resetting expired passwords/newly setup accounts.  Without further ado, let’s dig into it.

1.  Start by logging into your ADFS server and opening AD FS Management.

2.  Expand out Service, select Endpoints, and scroll down to the Other section where you will find /adfs/portal/updatepassword/.

3.  Right click on it and choose Enable.  Restart the ADFS service and Password Change is now available on the corporate network!

4.  Chances are that you want to enable this for users on external networks (where it’s most useful).  Do this by right clicking the /adfs/portal/updatepassword/ endpoint again and selecting Enable on Proxy.  Restart the ADFS service again and Password Change will be fully enabled!

Modifying How Many Machines Non-Administrators Can Add to a Domain

When setting up imaging solutions, it is not uncommon to have a service account for adding machines to the domain.  Naturally, you don’t want this account to have access to anything.  Well non-administrators are only allowed to add 10 machines to the domain, so that puts you in a pickle.  To resolve this we use the ADSI Edit tool as seen below.

1.) Open ADSI Edit from the Administrative Tools or searching for it from Start.

2.) Right click the ADSI Edit option on the left and select “Connect to…”

3.) Leave the default options and select “OK”

4.) Right click your Domain Distinguished Name folder and select “Properties”

5.) On the Attribute Editor tab find the “ms-DS-MachineAccountQuota” attribute.  Set this to whatever you wish, the default being ten, or clear it to make it unlimited.  Select “OK” and you’re done.

Monitor Membership of Domain Groups with PowerShell

Let me start this one off by saying this is not an optimal solution, but in a pinch it gets the job done.  Also, I kind of rushed this so there is a lot of code and it could definitely be shortened up if so desired.

Now that that is out of the way, the following script monitors groups that you wish monitor on a white list basis.  This means it requires a lot of upkeep if you are in a rapidly changing environment, but luckily I am not.  It is quite simple to add groups should you need to so that’s a plus.  In the event of someone being added to one of the groups that isn’t on the corresponding white list, you will get an email notification.  I just deploy the script as a scheduled task that runs every hour.  Simple but effective.

 

 

Disable/Delete Computer Accounts Where LastLogon Older Than 6 Months/1 Year

Been doing some AD clean up lately and I wanted to automate the process for stagnant computer accounts.  To do so I wrote two PowerShell scripts that I run once a month as a scheduled task.  As you’ll see below, I did need to exclude a few machines that have a certain naming standard.

Disable Computer Account with LastLogon Older Than 6 Months:

Delete Computer Account with LastLogon Older Than 1 Year:

 

List Group Members Whose User Accounts are in a Specific OU

Wanted to pull a list of users who were a part of a certain group last week, but I only wanted the group members that were located in a particular OU in AD.  I accomplished this with the following script:

 

Step-By-Step Installation of Active Directory Federation Services (ADFS) using Azure AD Connect

ADFS setup can be nothing but a headache to set up when you are new to it.  You know it.  I know it.  We all know it.  So this is my step-by-step guide for setting up a basic ADFS configuration.  Now, this is going to detail a successful installation without any errors (which does happen once in a blue moon).  To see resolutions to the errors that I have encountered in the past, please reference this post.  I will try to keep adding things as I come across them, but no guarantees.

As with anything that needs to be configured, setting up your prerequisites is key to your success.  Often not setting up your prerequisites properly will become your greatest frustration.  For reference see the Microsoft Official Post, but I will also be going through them now.  For port requirements, see this post.

Prerequisites:

1.   Download Azure AD Connect and copying that to the internal box you will be installing the ADFS role on to be installed later.

2.  Enable TLS 1.2 (Server 2008R2 and later) and configure .Net to use it by adding the following registry values and restarting the machine (I do this on both the ADFS and the WAP box).

3.  Create a Forward Lookup Zone for the domain you are federating in your local DNS.  Add an A record (Host) for adfs pointing at your ADFS server.  This will have internal requests resolve directly to the ADFS server.  In your internal domains forward lookup zone, create an A record for your web application proxy (WAP).

4.  Modify the host file on your web application proxy (WAP) to resolve adfs.domain.com to your internal ADFS server.  Public DNS should resolve adfs.domain.com to the WAP Public IP.

5.  Run the following command on both the ADFS and WAP box to enable Windows Remote Management (WinRM):

6.  On the ADFS box, add the WAP box to you WinRM Trusted Host list with the following:

7.  Confirm WinRM is functional by running the following from the ADFS box:

8.  Obtain a valid SSL certificate for the ADFS subdomain of your federated domain (ex. adfs.domain.com).  See this post about creating a custom csr with an exportable private key from your web application proxy (WAP).  Make sure you use the Legacy key template.  Export that to a PFX with its private key and copy it to your ADFS server.

9.  Add the domain name you plan to federate to your domains UPN Suffixes via Active Directory Domains and Trusts.

10.  Download Microsoft Exchange Server (Current version is 2016 found here).  Copy that to the Domain Controller that holds the Schema Master role, open a command prompt window in that directory and run the following command:

11.  Create a Group on the domain you plan to federate to specify which user accounts will be synced.  This is optional as you can choose to sync all user accounts if you wish.

12.  Create a service account on the domain that you plan to federate and add it to the Domain Admins and Enterprise Admins groups.  You can split this into two accounts if you wish.

13. Pro-Tip: Check the time and date on your servers.

Installation:

1.  Run the Azure AD Connect .msi to install it and agree to the license terms when prompted and select next.

2.  Select Customize

3.  Select the “Use existing service account” option and input the service account credentials you set up during prerequisites and select Install.

4.  After a little while you will be brought to a User sign-in window.  Select the “Federation with AD FS and select Next.

5.  Insert Global Administrator credentials for your Azure AD/Office 365 and select Next.

6.  Add the local domain you wish to federate and select Next.

7.  Confirm the domain you wish to federate with is verified, that userPrincipalName is selected and select Next.  If your domain you wish federate with is not present/says Not Added you need to verify it in your Azure AD/Office 365 tenant.

8.  Confirm the options are selected as below and select Next.

9.  Select “Synchronize selected” option, add the DN of the your local AD group, confirm it resolves, and select Next.

10.  Leave everything unchecked and select Next.

11.  Upload your Certificate .pfx, confirm the appropriate Subject Names appear, and select Next.

12.  Input the FQDN of your ADFS server, select Add, and select Next.

13.  Add the FQDN of your WAP. select Add, and select Next.

14.  Input your service account credentials and select Next.

15.  If prompted, input your service account credentials again and select Next.

16.  Select the appropriate Azure AD domain to federate with and select Next (typically there is only one available).

17.  Select te “Start the synchronization process when configuration completes.” option and select Install.

Phew.  At this point go grab a cup of coffee, and maybe start praying a little bit.  Assuming everything was configured correctly, you will get a success message and be prompted to verify your DNS configuration.  Once that all checks out you’re off to the races!