Archive for Active Directory

Wow, that is a lot of delegating…seriously how many times can you say it in one sentence.  Today’s post is one that threw me for a loop.  As a domain admin I have the right to configure constrained Kerberos delegation.  There may come a time when you want to delegate that out to a user or group. 

My first thought was to assign the user/group Full Control on the OU that included the accounts.  At this point I would run the following command

setspn -a http/workstation01 adminprepbrian

Surely Full Control would grant me the permission to do this…Failed!!!  Insufficient access rights.  It is not a “permission” that is needed, it is a “User Right”.  So where do you go to assign rights to work with constrained delegation and what User Right is it?  Well, you won’t find it in the Local Security Policy.

The User Right that you need to grant is SeEnableDelegationPrivilege. Now where and how do I grant this User Right.  Well it turns out you still should delegate Full Control to the user/group that you want to grant this User Right too.  Then on a DC you must run the following command:

ntrights -u adminprepbrian +r SeEnableDelegationPrivilege

Just make sure to modify that domain/user to match your environment.  Now when I run the Setspn command it works because that account has the correct User Right.  You may have to wait for replication to occur if you are in a distributed environment.

Here are two ways for you to use PowerShell to raise your Forest Functional level to Server 2008 R2:

  • get-adforest | set-adforestmode -forestmode windows2008R2Forest –confirm:$false
  • set-adforestmode –identity netbiosname windows2008R2Forest –confirm:$false

Either way will work.  Enjoy

Tip of the day today is to view your Active Directory Tombstone period while using PowerShell

  1. From a PowerShell prompt, type
  2. (get-adobject "cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=AdminPrep,DC=Local" -properties "tombstonelifetime").tombstonelifetime

The result shows up in days…very cool. 

Just make sure to change dc=AdminPrep,DC=Local to match your domain.

SPNs seem to get more and more use these days so I thought it be nice to give an explanation of what SPNs are.

SPNs are used for mapping a service to a user account. You will find SPNs used predominantly with Delegation and Impersonation and a lot of times this is between a web server and another server hosting a service that requires Kerberos authentication.  The key here is that Kerberos authentication is required and thus this is primarily used within an organization or a trusted company.  An example of this would be when an end user logs on to a web server which then logs on to a SQL server.  The web server is trying to authenticate against the SQL server using the web users credentials but it doesn’t have the right to do that type of delegation.  If that were the case I don’t think online banking would be…well online.  :,,)  Now this is only the case when the web and SQL instances are on separate servers.  If they were on the same server you would not need to worry about SPNs.

Kerberos is the key here.  Kerberos authentication happens all the time and is very common.  The special part of Kerberos authentication is that it requires a ticket that ensures each party is who they say they are.  This ensures that a hacker can’t impersonate another user.  The only type of delegation that Windows allows is a Kerberos connection.  In short the user knows how to contact and authenticate with the web server but has no idea who the SQL server is but needs data from it and needs to authenticate…thus delegation and impersonation needs to occur.

An SPN is a name that Kerberos clients use to identify a service for computer that is also using Kerberos.  In fact you can have multiple instances of a service running on a system and each could have its own SPN. SPNs have a specific format that they use which looks similar to this – <service class>/<host>:<port>/<service name>  The only parts that are required are the serviceclass and host.  For example, HTTP/ would be an SPN registration for any page on that webpage.  You would use the port option if you wanted to specify a port with the service, like this – MSSQLSvc/  More info on the formatting of SPNs can be found here.

SPN names can use short NetBIOS names or long FQDN names.  I recommend always using FQDNs as you can have potential name conflicts in a multi-domain forest with short names.

For a more detailed looked into SPNs i’ve provided a few links below along with links to common issues.  However the first place you should go is to this TechNet article.

Service Principle Name (SPN) Resources and Issues

If you have been playing with the the AD PowerShell cmdlets you know that it requires a few things to run, first Windows Server 2008 R2 or Windows 7, the .NET Framework 3.5.1 and of course if you want to manage an AD domain you need Active Directory Web Services (ADWS) installed on at least one domain controller. 

By the way ADWS requires TCP port 9389

So how in the world does a Windows 7 system know how to find a DC running ADWS?  Well your client running PowerShell will use the normal DC locator process.  First the client will determine which site it is in nltest /dsgetsite and then it will determine the closest DC nltest /dsgetdc:<FQDN Domain>.  It is looking at the DC for the following flag:


More info on that flag can be found here.

Now what if you don’t have Server 2008 R2 DCs?  With Server 2003 and Server 2008 a problem occurs because the Net Logon service of those domain controllers does not recognize the DS_WEB_SERVICE_REQUIRED flag.  There are two hotfixes (one for what ever version of AD you are running) available to fix that in those environments.  Server 2003 and Server 2008

After you install this hotfix the AD PowerShell module and Active Directory Administrative Center will be able to locate DCs that have Active Directory Management Gateway Service installed, similar to Active Directory Web Services (ADWS) on a Windows Server 2008 R2-based computer.


I’ve pulled together a list of commands that can be used to help gather information from Active Directory.  Sure there are plenty of commands out there but the following are the ones that I use and stored into my own mental memory banks…no jokes on the lack of memory banks either  :,,)

Viewing local and remote FSMO roles:

local – netdom query fsmo

remote – netdom query /domain:%domainname% fsmo

List of your Domain Controllers:

Nltest /dclist:%userdnsdomain%

Cool stuff with groups

Determine the current group scope of a security group
dsget group %GroupDN% -scope –secgrp

Change a group”s scope to universal
dsmod group %GroupDN% -scope u

Change a universal group”s scope to global or local
dsmod group %GroupDN% -scope l | g

UPDATE – Microsoft appears to have taken this download down.  No word why or when it will be back up.

Looks like Microsoft just make the Windows 7 LDS (Lightweight Directory Services) client available.  You can find both 32 and 64 bit clients here.

For those that aren”t familiar with LDS, it is the Server 2008 replacement for ADAM, otherwise known as Active Directory Application Mode.  While i”m no developer LDS is a good platform that applications that require directory storage and access.  Have most of the components of Active Directory without the complete infrastructure needed for Active Directory.

Did I say free?  You bet I did.  Microsoft has done this for quite some time now and is something everyone should take advantage of.  Especially in today’s economy where training budgets are getting slashed. 

Here are three great labs that you can use to learn all about Server 2008 R2’s Active Directory. 

Windows Server 2008 R2: What”s New in Active Directory

Windows Server 2008 R2: Active Directory and Server Manager Remoting

Windows Server 2008 R2: Active Directory Recycle Bin, PowerShell V2, and Remoting


Do you have any cool free training resources?

Filed Under (Active Directory, Scripting) by on 05-11-2009

I know, all AD admins have trust issues…not just literal ones but we also think about the trusts we have in our Active Directory environment.  As you all know I”m a fan of quick easy ways to get info.  Today’s tidbit is how to use nltest to verify your trusts.

The following command and switches can be used to view all of your trusts.  You can perform them from any system in your domain, just specify the DC in the command.

nltest /server:dc_name /domain_trusts /all_trusts

Just replace the dc_name with your domain controllers name and it will list all of your trusts to the domain that the DC resides in.

Another tidbit I like to do is filter it by name if you have multiple namespaces.

nltest /server:dc_name /domain_trusts /all_trusts | find /i “name

Here you would replace name with the name of a domain or part of the namespace you are looking for. 

I’m sure a lot of you have been playing with PowerShell.  If not you better get on it!!!  I’m not as far along as I wish I was but there is help out there.  One great place is to see what others have done.  Microsoft’s TechNet Scripting Center has a place where you can upload your own scripts and search what others have done.  This is great for a community of learning developers…did I just say developers…ewwwww.  :,,)

This link provides a shortcut to filter just the Active Directory related scripts.  From here you can find scripts on Computer Accounts, Domains, Groups, Monitoring, OUs, Searching Active Directory, Sites and Subnets and User Accounts!

If you want to just view all the PowerShell scripts just hit this URL –  Here you will scripts on Active Directory, Applications, Backup and System Restore, Databases, Desktop Management, Group Policy, Hardware, Interoperability and Migration, Local Account Management, Logs and monitoring, Messaging & Communication, Multimedia, Networking, Office, Operating System, Other Directory Services, Printing, Remote Desktop Services, Scripting Techniques, Security, Servers, Storage, System Center, Using the Internet and Windows Update.  WOW that is a wealth of info.

Enjoy and please share if you have any cool ones yourself.