ADMT and FSMO roles

I recently ran a cross forest ADMT migration, because of subnetting conflicts between the two companies, not all domain controllers were accessible. In order to migrate SID history, the ADMT migration server must contact the FSMO master of the source domain. After several attempts and a sniffer trace, I found this to be true. Specifically its one of the domain level fsmo roles, so I assume it’s the pdc emulator. ADMT 3.2 

 

Advertisements

Check for existing user in active directory

This powershell script below allows me to take
an input file that looks like this (input-users.csv)

SamAccountName
ksk34
xyz444
jsmith
bjones

and make an output file that will look like this (out.csv)

ksk34,yes
xyz444,no
jsmith,no
bjones,yes

The client I was working at did NOT have any windows 2008 dcs, so i could not use the command get-aduser, instead I installed the quest tools and I am using get-qaduser

Basically, this script give me a yes or no to the question “does the user (samaccount) exist?” Special thanks to Raymond for helping me with the output (I’m still new at powershell)

$users = Import-Csv c:\scripts\input-users.csv
foreach ($user in $users)
{
 if (get-qaduser -SamAccountName $user.SamAccountName)
 {
 #Found...
 "$($user.SamAccountName),yes" | out-file out.csv -append
 }
 else
 {
 #NOT Found...
 "$($user.SamAccountName),no"| out-file out.csv -append
 }
}

========AND ANOTHER VERSION OF THIS LOOKS LIKE THIS====

$users = Import-Csv c:\temp\ALLSMTP1.csv
 foreach ($user in $users)
 {
 if (get-qaduser -email $user.SMTPaddress)
 {
 #Found...
 "$($user.SMTPaddress),yes" | out-file smtp-yes.csv -append
 }
 else
 {
 #NOT Found...
 "$($user.SMTPaddress),$($user.samaccountname),no"| out-file smtp-no.csv -append
 }
 }

Deployment of Certificates to Workstations for Wireless Authentication

There are three things to do…

1. Setup Group Policy to auto enroll workstations and servers with certificates
2. Install Enterprise Certificate Authority
3. Setup NPS to allows devices that have certificates issued by the CA to be allowed to connect.

I like to start with group policy first because when you install the CA, it starts handing out certs immediately.
Go to the Default Domain policy or I guess you could create one for this specifically (but I think that’s silly), and expand
Computer Configuration – Policies – Security Settings – Public Key Policies
Go to the properties of “Certificate Services Client – Auto-Enrollment” and change configuration model to “Enable”, then enable the two check boxes in the image below. The first check box allows certs to be auto renewed, since they are issued with a one year life span. The second check box allows certs to be updated if you should choose to modify the template (rare case).

Next, expand Computer Configuration – Policies – Windows Settings – Security Settings – Public Key Policies – Automatic Certificate Request Settings
From there, right click and create a new Policy, and choose the Computer template. Without this template, I find that certs will get issued automatically to member servers and domain controllers, but not workstations.

Regarding the type of template to use, Computer Template or Domain Controller Template, there is a nice chart listed on technet documentation here  and a mention of templates on technet forums here.
It should look like the image below:

The next process is to install the Certificate Authority. Here is my advice, by default the name of the certificate authority is the first part of your active directory dns domain name followed by your server name. For example, if your domain is contoso.com, and the server is dc1, then the name of the root certificate and the certificate authority will be contoso-dc1. Because it’s possible to move this to another server later on, I don’t like to tie in the server name with the CA name, so I rename it during the installation process of the CA and call it, following my example, Contoso-EnterpriseRoot-CA. That will be the online name and also the name of the root certificate.

Start server manager, and install the Certificate Authority role. During the installation wizard you will want at a minimum “Certificate Authority” and “Certificate Authority Web Enrollment” services checked.  If you plan on giving non-domain member devices (iPads) certificates, then install the “Network Device Enrollment Service” also. This last role service requires you to setup a “proxy” user account to request certificates on behalf of non domain member devices. I like to create a user called NetDeviceEnrollService or something similar to that and put more info into the description area.

During the installation, you will have an opportunity to rename your CA to what you want.

Once it’s installed, you don’t have to reboot the server or anything. In fact, if you open the local certificate store and look at the Trusted Certificate Authorities section, you should see the certificate listed there.

You should start seeing this on all servers and workstations…. why? Because the default setting in windows is to trust any root CA that is “registered in Active directory”. What you see below is a report from gpresult.exe utility on a member server.

That completes the certificate portion installation.
The next part is configuring the Network Policy Server (NPS) to issue certs.
Configure a wireless policy that uses MS-CHAPv2 in combination with certificates issued by the CA.

ICANN Board Votes to Launch New Generic Top-Level Domains

What does this mean to my active directory installation?
Well if you have installed your active directory domain with an internal dns name of .local, as many of us have, then you will want to purchase this domain when/if a provider (such as registar.com or network solutions or godaddy) makes the .local available.
Why?
When you create any ssl certificate request and send it off for approval, you MUST own those domains in order to get the cert request approved.
Right now, the .local does not exist on the internet, so the cert company says, yea,  no problem, .local is fake.
This is especially important when purchasing certificates with subject alternate names (SAN), like Exchange and Lync. The certificate has names of the external and internal domain names on it.

I know of a few clients who generically call the domain AD.LOCAL and obviously don’t own that name because it’s not for purchase…. yet.

At some point, GoDaddy or Registar or NetworkSolutions will purchase the .local top level domain and then there will be a rush to purchase your internal domain name.
I wish ICANN would have addressed the .local and consider it internal, like how 192.168.0.0 address is in IP addressing.
Maybe that’s one reason to have the internal domain name match the external domain name…. or at least owning both names.

2008 R2 Domain Controllers unable to communicate to root DNS servers

I upgraded a domain with two local domain controllers from 2003 to 2008 R2.
I installed two new dcs, then moved the fsmo roles over and flipped ip addresses.
That way i did not have to deal with issues of dns resolution for workstations (modify dhcp scope for DNS) or member servers.
When I did that, the new dcs had the old dcs ip address, and the old dcs had some other previously unused ip addresses.
At that point, the new dcs were being queried for names of external websites. The dcs were unable to resolve anything external.
For a quick fix, I configured one of the dcs to enable forwarding (rather than root hints servers) and all requests were forwarded to the ISP’s DNS servers.
That worked, but why could 2003 perform root hints communication, but 2008 could not I thought?
The answer turned out to be this technet article. It affects 2003 R2, 2008, and 2008R2

http://support.microsoft.com/kb/832223

Basically type this from an elevated cmd prompt
 dnscmd /config /enableednsprobes 0

No need to restart services or reboot anything.

Two issues: difference in implementation of dns server between windows version and some cisco firewall setting.
The cisco engineer enabled large packet size or something like that, but that still did not fix the issue.
So i ran the commands described in the above article, and all is good. I was able to turn off forwarders and use root hints as necessary.

Some strange setting on the cisco firewall that did not like the way 2008 operated dns.

“Some firewalls contain features to check certain parameters of the DNS packet. These firewall features may make sure that the DNS response is smaller than 512 bytes.”
Click on the image below to see it larger.
Note: You have to run the cmd prompt elevated (Runas Administrator)

Set Inheritable Permissions on user accounts

This script (I put in a pdf format, click here set-inheritance )
I put on a temp folder on a admin machines, and ran it. I called it set-inheritance.vbs
Note the line: strOU = “OU=TestOU,”
All the users in this ou have the below inheritance checkbox and turned on.
This fixes the issue with user not being able to use ActiveSync on Exchange.

See the permission issue image below:

PowerShell set the manager on users

I came up with the idea that if we set the “manager” on a user in AD, the users can look at resources, and see who the owner is.

The manager seems like a natural attribute to look at…..

In outlook when I look at the user (resource) in the Global Address list I see this.

The Manager of extest5 is quest migrator (and it displays the full name, not the user id)

This will be my “input file”

So we want to set the resource Manager in AD,

Let’s learn!

So I set it manually in ADUC (on the left) and look at the attribute on the right in ADSIEDIT.MSC

So I do some googling, I search for set manager attribute PowerShell

and I find that quest makes some extensions for active directory that are FREE and make my life easy. Oh, like Free beer, it’s free and it makes my life easy…. Or a little more relaxing… LOL.

You can look at this later, but this is it. http://www.quest.com/powershell/activeroles-server.aspx

So I download and install on a workstatation, that already has the PowerShell and Exchange 2007 management tools installed…. So this download adds this tool.

This gives me this shell prompt, nice blue…

So, I ran this command (I got to know this from googling)

Sure enough, Manager is the attribute, cool.

So let’s set one…. See if that works. I know extest4 is empty (I ran the above command and the Manager field was blank…. Or in the world of PowerShell we call that $null)

Sure enough, that was easy…. Oh boy, am I glad I don’t have to put in the Distinguished Name (DN) and I just can call out the userid (SamAccountName)

So I took one of my other PowerShell commands and built this:

NOTE that it says Resource-OwnerTest.csv, I took the big file and made one small entry to test it (I would hate to mess things up on 600 plus resources)

SPECIAL NOTE: I MADE SURE THERE WERE NO EMPTY LINES, OR THE COMMAND WILL GRAB ALL USERS AND SET LOTS OF ERRORS WILL OCCUR.

It worked!

Now I do it on all the users, this is the output

There were a few errors, for example, the one you see, is really Blahblha_SR (note the underscore)

I’ll find the errors, fix the list and re-run.

The only errors I can’t fix at this point is this: