Working with ADSI in C#

If you have a requirement to work with ADSI in C#, unfortunately, the default MSDN documentation on ADSI (Active Directory Service Interfaces) does not provide much guidance on accomplishing this: https://msdn.microsoft.com/en-us/library/aa746486.aspx

All of the sample articles refer to using either VBScript, Visual Basic 6.0 or Visual C++ 6.0!

Well, fortunately, you may also come across this article which points you to using the System.DirectoryServices assembly in .NET: https://support.microsoft.com/en-us/kb/315716

When you then search for examples using System.DirectoryServices, you may find examples such as this:

Invoking ADSI Methods
https://msdn.microsoft.com/en-us/library/ms180896%28v=vs.80%29.aspx

Invoking ADSI Properties
https://msdn.microsoft.com/en-US/library/ms180895%28v=vs.80%29.aspx

For the complete documentation on the System.DirectoryServices assembly, you can check out this MSDN article: https://msdn.microsoft.com/en-us/library/system.directoryservices%28v=vs.110%29.aspx

Cannot reset the secure channel password for the computer account in the domain.

I recently joined a computer on my network to a domain and after performing a reboot, I got the following error message:

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

Having encountered this problem before, I decided to try the fix outlined in this article: http://blog.blksthl.com/2013/03/18/fix-the-trust-relationship-between-this-workstation-and-the-primary-domain-failed/

Unfortunately, when I ran the command, I got the following error message:

"Cannot reset the secure channel password for the computer account in the domain."

I tried numerous other articles to resolve the issue, including this Microsoft support article: https://support.microsoft.com/en-us/kb/175024

Unfortunately, all of these attempts were in vain.

Finally, I was forced to remove the computer from the domain and rejoin the domain.  After re-booting the machine, I was able to log back into the domain!!

Where are the ADLDS/ADAM .LDF files?

If you are looking for the .LDF files that ADLDS/ADAM uses to import the various schemas while initially setting up an instance of ADLDS, you can find the various .LDF files (such as MS-User.LDF) in the following directory:

C:\Windows\ADAM

These .LDF files can give you an idea on how to compose your very own custom .LDF files as well as provide you with a better understanding of how the .LDF files work.

Configuring Active Directory Lightweight Directory Services (ADLDS) with SSL

I was recently attempting to set up an instance of ADLDS with SSL using a Self-Signed Certificate when I got this error message in my Windows System Event Logs:

Schannel
The SSL server credential's certificate does not have a private key information property attached to it. This most often occurs when a certificate is backed up incorrectly and then later restored. This message can also indicate a certificate enrollment failure.

I attempted to follow this article on how to set up LDAP over SSL: http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx 

I even took a look at this article to see if it would provide additional insight: https://support.microsoft.com/en-us/kb/321051

Of course, this article looked the most comprehensive in terms of guidance: https://msdn.microsoft.com/en-us/library/cc725767%28v=ws.10%29.aspx

However, none of these articles got me any further than I was before!

As it turned out, my ADLDS instance was using a non-standard port of 5001, therefore, I found this article about required ports for ADLDS with SSL: https://technet.microsoft.com/en-us/library/dd772723%28v=ws.10%29.aspx

Based on the above MSDN Article, I could only use SSL with ADLDS on port 636!!  No other port would work!!

Well, I decided to reinstall my ADLDS instance to use the standard ports of 389 and 636 and once again re-applied my SSL certificate.

As you can probably already guess, this resolved my problem!! I was using a port number that did not support SSL (LDAPS) all along!!

ASP.NET Forms Authentication with Active Directory Lightweight Directory Services (ADLDS)

Setting up ASP.NET Forms Authentication with Active Directory is relatively easy, however, I had a recent requirement to support Active Directory Lightweight Directory Services (ADLDS).

Unfortunately, it is very difficult to find information about how to provide connection string information for ADLDS.

After searching far and wide on the Internet, I finally found a reference on how to do this through Google Books: https://books.google.com/books?id=Qt3TeJJkG5oC&pg=PA510&lpg=PA510&dq=adam+asp.net+connection+string&source=bl&ots=b07V6YlxOI&sig=yxN5oMyXlzgX7LBDhkHoqpWi1rc&hl=en&sa=X&ei=3lM3VY3RLLLgsAT564Ew&ved=0CDAQ6AEwAw#v=onepage&q=adam%20asp.net%20connection%20string&f=false

Though it references the older name of ADAM, the connection string information remains the same for ADLDS:

<connectionStrings>

   <add name="adamConnection" connectionString="LDAP://localhost:389/OU=ApplicationUsers,O=MyOrganization,DC=corsair,DC=com"/>

</connectionStrings>

<membership defaultProvider="adamprovider">

   <providers>

     <add

        name="adamprovider"

        type="System.Web.Security.ActiveDirectoryMembershipProvider"

        connectionStringName="adamConnection" connectionProtection="None" attributeMapUsername="userPrincipalName"

        connectionUsername="CN=ApplicationUsersAdministrator,OU=PartitionUserAccounts,O=MyOrganization,DC=corsair,DC=com"

        connectionPassword="pass!word1" />

   </providers>

 </membership>

If you want to use an instance of ADLDS that is secured with SSL, then the information remains largely the same:

<connectionStrings>

   <add name="adamConnection" connectionString="LDAP://localhost:636/OU=ApplicationUsers,O=MyOrganization,DC=corsair,DC=com"/>

</connectionStrings>

<membership defaultProvider="adamprovider">

   <providers>

     <add

        name="adamprovider"

        type="System.Web.Security.ActiveDirectoryMembershipProvider"

        connectionStringName="adamConnection" connectionProtection="Secure" attributeMapUsername="userPrincipalName"

        connectionUsername="CN=ApplicationUsersAdministrator,OU=PartitionUserAccounts,O=MyOrganization,DC=corsair,DC=com"

        connectionPassword="pass!word1" />

   </providers>

 </membership>

Notice that the LDAP connection changes only by the port number to 636, but still does not support LDAPS.

 

For the Membership Provder, the only attribute that changes is connectionProtection from “None” to “Secure”

Of course, the ApplicationUsersAdministrator account has to be a member of the Administrators group in ADLS in order for this to work (You can do this using ADSI Edit), however, once you have that set up you should be able to use ASP.NET Forms Authentication with ADLDS in much the same way as a normal Active Directory installation!

ASP.NET Forms Authentication with Active Directory using .NET 4.0/4.5

If you read this MSDN article on Forms Authentication with Active Directory, you will notice that still only addresses ASP.NET 2.0:  https://msdn.microsoft.com/en-us/library/ff650308.aspx

The Web.config element in fact still refers to .NET 2.0 assemblies.  Therefore, if you are using a newer version of the .NET Framework such as .NET v. 4.0 or .NET v. 4.5, then you may be wondering what the newer Web.config entry should be.

Well, it is remarkably similar to the original entry with just a change to the version information:

<membership defaultProvider="MyADMembershipProvider">

      <providers>

        <add

           name="MyADMembershipProvider"

           type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

           connectionStringName="ADConnectionString"

           connectionUsername="testdomain\administrator"

           connectionPassword="password"/>

      </providers>

</membership>

Alternatively, you can just use the following element:

<membership defaultProvider="ADMembershipProvider">

      <providers>

        <clear />

        <add name="ADMembershipProvider" type="System.Web.Security.ActiveDirectoryMembershipProvider" connectionStringName="ADConnectionString" connectionUsername="testdomain\administrator" connectionPassword="password" />

      </providers>

</membership>

That’s all you have to change!!

Managing Users in Active Directory Lightweight Directory Services using ADSIEdit

If you want to manage users for your Active Directory Lightweight Services instance using ADSIEdit, you may refer to these MSDN articles:

Manage an AD LDS Instance Using ADSI Edit
https://technet.microsoft.com/en-us/library/cc794959%28v=ws.10%29.aspx


Use ADSI Edit to Manage an AD LDS Instance https://technet.microsoft.com/en-us/library/cc731156.aspx

These articles will provide you with the necessary information to connect to your ADLDS instance using ADSIEdit, but what if you want to actually add users to ADLDS?

Well, this article addresses that question:

Add an AD LDS User to the Directory https://technet.microsoft.com/en-us/library/cc772194.aspx

The problem with  the above article, though, is that it does not address how to Set the Password for the newly created user!!

Fortunately, someone else wrote an article describing how to accomplish this (though a bit outdated):
http://sureshatt.blogspot.com/2012/06/using-adsiedit-tool-with-active.html

Once you have created your new user in ADLDS, you simply right click on the user and select "Reset Password"!

In addition, even after resetting the password, the user in ADLDS, by default, is still not enabled!  So you still have to go about enabling the user account by updating the msDS-UserAccountDisabled attribute:

Finally, the userPrincipalName attribute is still not set by going through the wizard, so that also has to be set manually:

Fortunately, there is a much easier way to accomplish all of these manual steps in ADSI Edit by using PowerShell:

[CmdletBinding()]

Param(

 [Parameter(Mandatory=$true,Position=1)]

[string]$ADName,

[Parameter(Mandatory=$true)]

[string]$ADUPN,

[Parameter(Mandatory=$true)]

[string]$ADGivenName,

[Parameter(Mandatory=$true)]

[string]$ADSurname

)

#Example

#ADName John Doe

#GivenName John

#Surname Doe

#UPN jdoe@adlds.com

$ADLDSServer = "MYADLDSServer:5000";

$ADDefaultPwd = "P@ssword!";

$ADLDSPath = "CN=Roles,CN=AppPartition,DC=ADLDS,DC=COM";

Clear-Host

New-ADUser -Name $ADName -DisplayName $ADName -Server $ADLDSServer -UserPrincipalName $ADUPN -GivenName $ADGivenName -Surname $ADSurname -AccountPassword (ConvertTo-SecureString $ADDefaultPwd -AsPlainText -Force) -Enabled $true -PasswordNeverExpires $true -Path $ADLDSPath

 

Using PowerShell to create ADLDS Users is definitely much, much nicer and simpler!!

Understanding Windows DNS Forward Lookup Zones

Though I have been setting up domain controllers for years and years, I am still a relative newbie when it comes to understanding Microsoft Windows DNS, therefore, I thought it would be worthwhile to clarify some aspects of how Windows DNS works.

My previous blog post on DNS can get you started on some of the DNS terminology: http://samirvaidya.blogspot.com/2015/02/understanding-microsoft-dns.html

For the purposes of this article, we will basically be discussing only A and CNAME Records.  So, an A Record simply identifies a server with its IP Address.  A CNAME Record identifies a particular name with a particular server.

For example, a server called MyServer would have an A Record pointing to an IP Address of 10.0.0.10.

A CNAME Record would point the name DevServer to the MyServer A Record.

Well, now what is the purpose of a Forward Lookup Zone?

By default, Windows DNS will create a Forward Lookup Zone based on the domain that you have created and set up.

So, if you have a domain called mycorpdomain.com, your default Forward Lookup Zone would be also called mycorpdomain.com.

What this means is that all of your A and CNAME records will ultimately end in the suffix: mycorpdomain.com.

But what if you want to have a different suffix such as dev.mycorpdomain.com?  Well, that is where Forward Lookup Zones come in!!

You can create an additional Forward Lookup Zone called dev.mycorpdomain.com.  Beneath that new Forward Lookup Zone, you can then subsequently create corresponding A and CNAME records to point to your existing MyServer member server.

Therefore, once you have your new Forward Lookup Zone in place, you will be able to access MyServer by multiple Urls (in the case of a web server):

myserver.mycorpdomain.com  

myserver.dev.mycorpdomain.com

This comes in very handy particularly when you want to delineate your environments.  Therefore, you could have various Forward Lookup Zones for dev.mycorpdomain.com, qa.mycorpdomain.com, staging.mycorpdomain.com, prod.mycorpdomain.com and so on.

That is pretty much all there is to understanding Forward Lookup Zones with Windows DNS!!

Does the ActiveDirectory Membership Provider support local Windows NT credentials?

I was recently setting up a project to use the ASP.NET Active Directory Membership Provider and I was not sure whether or not the Active Directory Membership Provider would support local Windows NT credentials. 

I decided to take a look at the MSDN article for the Active Directory Membership Provider: https://msdn.microsoft.com/en-us/library/system.web.security.activedirectorymembershipprovider%28v=vs.110%29.aspx

Based on the article, it seemed that Windows NT connections would not be supported, but I decided to give it a try anyway.

Once I hit the Membership.ValidateUser method, I encountered the following error message:

Therefore, it seemed that Windows NT credentials would not be supported after all!

So, there you have it!  You can only use the Active Directory Membership Provider with Active Directory and ADAM/ADLDS (Active Directory Lightweight Directory Services)!!

System.DirectoryServices Connection Strings for Windows Active Directory and Local Computers

If you are looking for possible connection strings that you can use for your C# application to support Active Directory as well as the Local Windows NT Database, this MSDN article provides great information about how to appropriately connect to each of these stores:  https://msdn.microsoft.com/en-us/library/system.directoryservices.directoryentry.path%28v=vs.110%29.aspx

In addition, if you are using an Active Directory Membership Provider for ASP.NET, the Connection Strings in the above cited MSDN article will also provide information on how to connect to your Active Directory stores!

Secure ASP.NET Web API with Windows Active Directory and Microsoft OWIN Components

If you are looking to secure your ASP.NET Web API using OWIN/Katana with just "plain old" Windows Active Directory, unfortunately, you will only find articles like the following on securing your application:

http://www.cloudidentity.com/blog/2013/12/10/protecting-a-self-hosted-api-with-microsoft-owin-security-activedirectory/

https://msdn.microsoft.com/en-us/magazine/dn463788.aspx

As you can tell from the above articles, these articles specifically address "Azure Active Directory"!

But if you want to secure your application with just standard Windows Active Directory, you won't find much guidance in that arena.

Fortunately, plugging in Windows Active Directory support into your OWIN/OAuth Pipeline is not that much more difficult than using standard Forms Authentication with Active Directory as I have outlined in my previous article: http://samirvaidya.blogspot.com/2015/03/aspnet-mvc-forms-authentication-with.html

The main element to take away from standard Forms Authentication is the use of the Membership API to validate your Active Directory User Credentials and plug it into the OWIN/OAuth Pipeline. 

Therefore, if you use a code sample from my earlier OAuth article references (http://samirvaidya.blogspot.com/2015/03/aspnet-web-api-owinkatana-and-jwt.html), you can simply modify the ValidateClientAuthentication method to include code such as the following:

public override Task ValidateClientAuthentication(OAuthValidateClientAuthenticationContext context)

{

    try

    {

        var username = context.Parameters["username"];

        var password = context.Parameters["password"];

        //Use the Active Directory Membership Provider to authenticate the user credentials

        if (Membership.ValidateUser(username, password))

        {

            context.OwinContext.Set("otc:username", username);

            context.Validated();

        }

        else

        {

            context.SetError("Invalid credentials");

            context.Rejected();

        }

    }

    catch

    {

        context.SetError("Server error");

        context.Rejected();

    }

    return Task.FromResult(0);

}

That is all there is to it!!

Unable to establish secure connection with the server

I was recently working on using Forms Authentication with Active Directory when I suddenly received the following error message:

Unable to establish secure connection with the server

I double checked my connectivity to the server and everything looked OK to me.  However, the computer that I was testing with was not connected to the target Domain.

Was there any workaround other than joining my workstation to the same Domain as the Active Directory server?

Well, as it turns out there is!

You can simply add the following setting to the Active Directory membership provider configuration in the Web.config file:

<membership defaultProvider="ADMembershipProvider">

  <providers>

    <clear />

    <add name="ADMembershipProvider" type="System.Web.Security.ActiveDirectoryMembershipProvider" connectionStringName="ADConnectionString" attributeMapUsername="sAMAccountName" connectionUsername="mydomain\domainuser" connectionPassword="domainPassword!"  />

  </providers>

</membership>

Then, you may have to switch the LDAP/Active Directory connection string to the following:

 

<connectionStrings>

<add name="ADConnectionString" connectionString="LDAP://10.10.10.1:389/DC=mydomain,DC=com"  />

</connectionStrings>

 

After doing this, I was able to connect successfully to the Domain even when my computer/workstation was not joined to the Domain!

ASP.NET MVC Forms Authentication with Active Directory

If you want to implement Forms Authentication with Active Directory using ASP.NET MVC, this is an excellent article on how to accomplish this: http://www.schiffhauer.com/mvc-5-and-active-directory-authentication/

Unfortunately, it is missing a key point that is addressed by this MSDN article: https://msdn.microsoft.com/en-us/library/ff650308.aspx

In order to be forced to the User Login View, you have to also include the following section in the Web.config file:

<authorization> 

    <deny users="?" />

    <allow users="*" />

</authorization>

If you forget to include this section in your Web.config, you will not be automatically redirected to your Login screen. 

 

Even if you include this code in your FilterConfig.cs file, the Login redirection will still not occur:

 

public static void RegisterGlobalFilters(GlobalFilterCollection filters)

{

    filters.Add(new HandleErrorAttribute());

    filters.Add(new AuthorizeAttribute());

}

Therefore, make sure you do not forget the authorization section in your Web.config file!!

Migrating Active Directory to new hardware in a hosted environment

I recently had a requirement to move our existing Active Directory server to completely brand new hardware.

Unfortunately, we were moving to a hosted environment where support costs a significant amount of money.  Therefore, asking them to have them do the migration for us would be pretty much out of the question.

Therefore, I began to research available options for performing an Active Directory migration.

Well, the first article I came across was this one: https://technet.microsoft.com/en-us/library/cc771290%28v=ws.10%29.aspx

Well, unfortunately, they don't provide much guidance or information specifically on migrating Active Directory to new hardware.  Therefore, I pretty much had to read between the lines and try and figure out what would and would not work.

 Well, I went ahead and tried a System State backup and that would not restore to dissimilar hardware.

The other recommended option was a Full Server Recovery of the Domain Controller: https://technet.microsoft.com/en-us/library/cc772519%28v=ws.10%29.aspx

Unfortunately, it requires access to the underlying Console of the environment as well as the Windows media to perform the recovery.  Neither of these would work in a hosted environment.

The next thing I found was the Active Directory Migration Tool: http://www.microsoft.com/en-us/download/details.aspx?id=19188

https://connect.microsoft.com/site1164/program8540

Unfortunately, it required a SQL Server database and quite a bit of setup time as well as installation on a server outside of the Active Directory environment.

Therefore, I had to start search for solutions that would not require as much setup time and could be done pretty much on our own.

That is when I came across Easeus ToDo Backup Advanced Server/Backup Technician:

http://www.todo-backup.com/business/advanced-server-backup.htm

 http://www.todo-backup.com/business/technician-backup.htm

These tools would allow us to take System Backups from one server and move them to another server without all of the headaches and hassles of the other solutions.

I can simply install Easeus ToDo Backup on the underlying Server OS and after going through a backup on one server, perform a Recovery/Restore on the other server.

 Unfortunately, it seems to require Console Access during the restoration period, so we were forced to do a restoration into a Hyper-V environment that we owned, but perhaps Easeus will soon be able to provide a solution that does not require underlying Console Access, thus making it ideal for hosted environments!!

In any case, after I restored my Domain Controller to the Hyper-V Virtual Machine, I changed the IP Address and DNS Server entries to point to itself.

Everything seemed to be working properly when I attempted to join another server to the domain.

I then encountered this error message: "Cannot complete this function" as described in this article: http://blog.mpecsinc.ca/2013/08/domain-join-error-cannot-complete-this.html

Well, as it turns out, I had migrated only 1 of the Domain Controllers in the Forest.  There were originally 2 DCs in the Forest, so when I attempted to join a domain with 1 of the DCs missing, the error was being thrown!

Therefore, I ended up migrating the 2nd DC in the Forest as well and after making the appropriate IP Address and DNS Server changes, I could then successfully join another server to the domain!  Woo hoo!!
 

Using ADExplorer to examine LDAP attributes/properties for Active Directory

If you have had to work with querying your Active Directory repository using .NET/C# or even SharePoint, you may have come across my earlier article which demonstrates how to connect to Active Directory using LDAP Browser: http://samirvaidya.blogspot.com/2014/02/using-ldap-browser-to-examine-ldap.html

However, I just came across a slightly easier tool provided directly by Microsoft in the SysInternals suite called ADExplorer: https://technet.microsoft.com/en-us/sysinternals/bb963907

It provides an easier way to connect directly to Microsoft Active Directory than LDAP Browser and provides much of the same information provided by LDAP Browser!

The login dialog is much simpler than the connection wizard provided by LDAP Browser:

Once you log in, you get all of the nice LDAP query attributes that you can use to plug into your C#/.NET Application!!

Exporting and Importing Active Directory Users using PowerShell

If you are performing any type of Active Directory migrations or setup, you will want to be able to easily setup and create users.

Fortunately, this is relatively easy to do using Windows PowerShell.

If you want to export existing users out of your Active Directory repository that includes most of their relevant details, the best way to do this is to export their information to a CSV file like so:

Import-Module ActiveDirectory

$SearchBase = "OU=Service Accounts,DC=mydomain,DC=COM"

$ExportFile = "C:\Exports\ServiceAccounts.csv"

$users = Get-ADUser -Filter * -SearchBase $SearchBase -Properties * | Select-Object -Property Name,SamAccountName,Description,EmailAddress,GivenName,Surname,Enabled,Organization | Sort-Object -Property Name

$users | Export-Csv $ExportFile –NoTypeInformation

Subsequently, when you are ready to import your users back into Active Directory, you can use the following script:

 

$ADFilePath = "C:\Exports\ServiceAccounts.csv";

$DomainName = "@mydomain.com";

$ImportADGroup = "Service Accounts";

Import-Module ActiveDirectory

Function Add-NewADUser

{

    <#

Param([string]$ADName,

    [string]$SAMAcctName,

    [string]$ADUPN,

    [string]$ADEmail,

    [string]$ADGivenName,

    [string]$ADSurname,

    [string]$ADGroup,

    [string]$ADOUPath

    )

#>

    Param(

    [Parameter(Mandatory=$true,Position=1)]

    [string]$ADName,

    [Parameter(Mandatory=$true)]

    [string]$SAMAcctName,

    [Parameter(Mandatory=$true)]

    [string]$ADUPN,

    [Parameter(Mandatory=$true)]

    [string]$ADEmail,

    [Parameter(Mandatory=$true)]

    [string]$ADGivenName,

    [Parameter(Mandatory=$true)]

    [string]$ADSurname,

    [Parameter(Mandatory=$true)]

    [string]$ADGroup,

    [Parameter(Mandatory=$true)]

    [string]$ADOUPath

    )

    #Example

    #ADName John Doe

    #GivenName John

    #Surname Doe

    #SAMAccountName jdoe

    #UPN jdoe@mydomain.com

    #ADOU OU=Service Accounts,DC=mydomain,DC=com

    #ADGroup Service Accounts

    $ADDefaultPwd = "P@ssw0rd1!"

    New-ADUser -Name $ADName -DisplayName  $ADName -SamAccountName $SAMAcctName -UserPrincipalName $ADUPN -EmailAddress $ADEmail -GivenName $ADGivenName -Surname $ADSurname -Organization $ADGroup -AccountPassword (ConvertTo-SecureString $ADDefaultPwd -AsPlainText -Force) -Enabled $true -PasswordNeverExpires $true -Path $ADOUPath

    Add-ADGroupMember $ADGroup $SAMAcctName

}#Function Add-NewADUser

Clear-Host

$ADUserList = Import-Csv $ADFilePath 

ForEach ($ADUser in $ADUserList)

{    

     $userPrincipal = $ADUser.SamAccountName + $DomainName

    Add-NewADUser -ADName $ADUser.Name -SAMAcctName $ADUser.SamAccountName -ADUPN $userPrincipal -ADGroup $ImportADGroup -ADEmail $ADUser.EmailAddress -ADGivenName $ADUser.GivenName -ADSurname $ADUser.Surname

}#ForEach

 

In regards to importing Active Directory Users, there are a wide variety of ways that are shown on the Internet for importing from a CSV file such as using the $_."samAccountName" notation, but the problem about this, is that the PowerShell ISE offers no Intellisense for any of these properties.

 

Therefore, my favorite part of using the script above is that I actually get Intellisense/Autocompletion for the Property Names in the CSV file by using the following line in the script:

 

$ADUserList = Import-Csv $ADFilePath 

Therefore, when I am typing my values in my ForEach loop, I can automatically select the correct property names!

How cool is that??

Joining a VM to a Windows domain on a Bridged Network

In the past, I have always set up Networked VMs using NAT Mode since that would ensure that the VMs can properly communicate with each other when I join them to a domain as well as ensuring no name conflicts on the network.

The procedure for joining a VM to a Domain using Bridged Networking is surprisingly similar as joining them using NAT mode with a few caveats:

1. After you update the Primary and Secondary DNS Servers on your Domain Member Server to the IP Addresses of your Domain DNS Servers, make note of both the NetBIOS Name as well as the FQDN of your Domain.
2. Make sure that none of your Windows Firewall rules are not blocking connection attempts from the Domain Controller(s) and the Member Server.
3. If the FQDN of your Domain does not conflict with an existing domain name on the Internet (such as google.com or microsoft.com, mycompany.com etc.), then you may be able to join your Domain Member Server using the FQDN of your Domain.  If not, then you should try using the NetBIOS name instead.  

If you are unsuccessful joining the Member Server to the Domain using the FQDN, you may get error messages similar to the following:

Therefore, you should attempt to join the Domain using the NetBIOS name instead.  If everything is configured correctly, you should be able to join the Member Server to the Domain.

So, what is the main benefit of using Bridged Networking vs. NAT Mode?  Well, if you are setting up multiple VMWare Host Machines that are hosting VMs, you can set up a network across VMWare Hosts just as you would do if you were setting up normal physical machines/workstations on the network!!  This is especially useful if you are a developer and want to test out numerous environments and do not have enough physical memory on a single workstation machine to host multiple VMs needed for that environment configuration. 

For example, if you wanted to set up a SharePoint Farm, you could set up a Domain Controller and a SharePoint Application Server on one VMWare Host and on another VMWare Host, you could create a SharePoint WFE (Web Front End) and a SharePoint Search Server or Office Web Apps Server.  Being able to leverage Bridged Networking allows you to split out your VM environments across as many physical VMWare Hosts as you have available!!

Windows Machine SIDS DO MATTER!!!

As you may already know, the tool NewSID was retired some time ago because there appeared to be a "myth" that Machine SIDs matter and this no longer matters with more recent releases of Windows.

Sadly, this is not a "myth" at all and for those who think otherwise are greatly mistaken as is evidenced by the Windows OS itself!!!

I heavily use VMWare Virtual Machines for my development and therefore copying and pasting VMs over and over again is a common operation I perform frequently.

As you can probably guess, copying and pasting the same VM over and over again retains the original SID of the VM if you have not performed sysprep on the machine prior to creating the template VM. 

You can verify this for yourself by running the PsGetSid Utility that is part of the SysInternals Suite: https://technet.microsoft.com/en-us/sysinternals/bb897417.aspx

In any case, I attempted to create one machine as a domain controller and a subsequent VM as a member server.  When I then attempted to join the member server to the domain, I received the following error message:

If you read the article which the link points to: http://support.microsoft.com/kb/816099, even though it refers to Windows Server 2003, it definitely indicates that duplicate SIDs cause problems particularly with Active Directory.  Since I was using Windows Server 2012 R2 on both VMs, I assume that this issue still persists even in the latest version of the Windows OS. 

The simple solution to this problem, of course, is simply to run sysprep on the machine (which can be found at C:\Windows\system32\Sysprep\sysprep.exe). 

When you run sysprep, you will want to choose the Generalize option:

Choosing this option will generate a new SID for the machine as well as remove any Windows-specific settings such as Windows Activation status.  Therefore, after running sysprep, you will once again have to activate the virtual machine.

Once the machine has been assigned a new SID, you can successfully add the server as a member server to your Active Directory domain!

Understanding Microsoft Windows DNS

If you are unfamiliar with managing Microsoft DNS, it is a bit of a learning curve to get up to speed on exactly what DNS accomplishes and how to use it appropriately in the management of your Microsoft networks.

First of all, a DNS Zone is a set of DNS records used to resolve domain name resources related to a domain (such as microsoft.com or google.com).


The types of DNS Records are the following:

• SOA - Start of Authority:  Holds information about the nameservers that are authoritative for a zone as well as how long the records are cached (the TTL).
• NS - Name Server: Identifies all the servers that hold records for a specific zone
• A - Host: Provides Host name to IPv4 address resolution
• PT - Pointer: Resolves IP Address to Host Name
• CNAME - Alias: Creates an Alias or alternate DNS for a specified host name
• SRV - Service Locator:  Points to specific services that are needed within Active Directory
• MX - Mail Exchanger: Allow mail servers to be able to identify servers that are responsible for handling mail for a remote domain.

In most instances, you will either be creating either A or CNAME records for your Active Directory instances.

If you have a computer/server that has more than IP Address, you will probably need to create an A record to point to that specific IP Address.  This will most likely be needed in scenarios where you are hosting multiple web sites on a single web server and you have a requirement for SSL certificates which require unique IP Addresses.

If you have a computer/server that only has a single IP Address and you simply want to be able to access content on the server from a variety of friendly domain name entries, then you will likely need to create a CNAME record.  For example, if the name of your web server is called DEV, but you want to specify a more user friendly Url to access the website, you might provide a CNAME record such as sharepoint-dev.mydomain.com or aspnet-dev.mydomain.com.  This will allow your end users to understand what type of server they are accessing without having to physically change the name of the server to accommodate this.

The target principal name is incorrect. Cannot generate SSPI context.

I was recently setting up a SQL Server 2014 AlwaysOn Availability Group when I got the following error message while attempting to add a Replica for the Availability Group via SSMS (SQL Server Management Studio) with Windows Authentication:

Interestingly enough, I could log into the SQL Server just fine using SQL Server Authentication, but the authentication was failing while using Windows Authentication.  Of course, for a SQL Server AlwaysOn Availability Group, I needed to use Windows Authentication, otherwise it wouldn't work!

Therefore, I did some research and it seemed that most of the issues regarding this issue dealt with problems regarding the domain.

I remembered that I had joined this particular server to the domain without first removing it from the domain.  From prior experiences, I remembered that this can cause problems if I re-join a computer to the domain with the same exact name. 

Therefore, I decided to do the following:

1. Leave the domain by joining a workgroup and rebooting the server
2. Deleting the computer object and all of its children (deleting the subtree) in Active Directory
3. Re-joining the server to the domain

Once I did that, I was able to successfully log into my other SQL Server using Windows Authentication to add it as a replica for my Availability Group!