Shariq Sheikh | Port 389

Kerberos Delegation, constrained and unconstrained is a complex topic, and one that often comes up when Security implications of External/Forests Trusts are discussed. Few days ago, on ActiveDir a similar topic was shed light upon. In brief Brian Arkills sums it up below,

The other security implication that most folks seem oblivious to is the one that comes with unconstrained Kerberos delegation across a trust. When you’ve got a single domain/forest by itself, your domain admin group controls who/what can use delegation. Once you setup a trust to another domain, you extend that ability to the domain admins in the other domain(s). In other words, the domain admins in the other domain can choose to allow a user/computer in their domain to permit unconstrained Kerberos delegation using the user accounts in *your* domain. Almost everyone says unconstrained delegation is bad, and the assumption is that no one will use it. But there are no controls in the product to prevent its use, except by also preventing any delegation (i.e. by marking all or a subset of user accounts as ‘sensitive to delegation’). And of course, unconstrained delegation is the only way to use delegation across a forest trust meaning it’s the only game in town for certain scenarios.

A service that runs under an account that is trusted for Kerberos delegation can assume/impersonate the identity of a client requesting the service. This parameter sets the TrustedForDelegation property of an account object. This value also sets the ADS_UF_TRUSTED_FOR_DELEGATION flag of the Active Directory User Account Control attribute.

It is that marking of the user accounts as “delegation sensitive” with PowerShell is what I would like to share with you.

For user and computer accounts, as stated above the setting is enclosed under the useraccountcontrol bits.

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

We take the TRUSTED_FOR_DELEGATION and its associated value in decimal i.e 524288 and assign it a variable.

$NOT_DELEGATED=1048576

Using Quest Cmdlets, we use the Set-QADUser and use the bitwise exclusive operator to set the flag as sensitive (Thanks to Shay Levy for helping me with the correct bitwise syntax)

Get-QADUser user1  |
    Set-QADObject $_ -ObjectAttributes @{userAccountControl= ($_.userAccountControl -bxor $NOT_DELEGATED)}

For computer accounts, there is an explicit parameter for the Set-QADComputer Cmdlet i.e -TrustForDelegation

With ADWS (the native AD Cmdlets) the same parameter (being applicable to both i.e users and computers) for Set-ADUser and Set-ADComputer is called –TrustedForDelegation.

By default, when an account has been granted delegation privileges *every* user account can be “impersonated” in this way. However, with above you can mark certain user accounts as “delegation sensitive”, which means that those user accounts can never be used in a delegation scenario. Marking admin accounts as delegation sensitive is highly recommended. Generally, delegation is used with Kerberos, but there is an option to use protocol transition so that NTLM might be used on some of the hops (this is called S4U). Also note that for service accounts (user accounts), the delegation tab will only appear (allowing for the constrained delegation) when there is a SPN registered against that user account.

More reading here :

http://blogs.technet.com/b/askds/archive/2008/03/06/kerberos-for-the-busy-admin.aspx

http://blogs.technet.com/b/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx

Yes, the KMS client activation is supported in multi-domain environment in which the KMS host belongs to one domain and needs to cater to the clients in others.

For this to work, you need to create a ‘multi-string value’ registry key under “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform” called “DNSDomainPublishList” on your KMS Server.

When done, restart the “Software Protection” sppsvc service on your KMS host and watch for the Event ID 12294 log under application logs. You should one event for each domain you have asked KMS to publish itself in.

Additionally, under each domain you can use NSLookup to verify the _vlmcs SRV record.

nslookup -type=srv _vlmcs._tcp

KMS communication happens over TCP Port 1688, if the domains you have added are in other region and you would like to verify if clients can talk to your KMS host, then from a client on the other side use PortQry to ascertain that port is not being blocked

portqry –n FQDN_of_your_host –e 1688 –p both

If the environment does not support Dynamic DNS, then SRV Resource Records can be manually created to publish the KMS host.

The KMS SRV RR is created under TCP node of your DNS Domain.

On how to setup and configure KMS Server/host a Server Core, see my other post.

Other details can be found under Technet Library : http://technet.microsoft.com/en-us/library/ff793419.aspx

The schema version is revealed via the objectversion attribute off of the schema object from your configuration head of the forest i.e “cn=schema,cn=configuration,dc=yourdomain,dc=int”.

So using Quest Cmdlets, you can run this query :

Get-QADObject "cn=schema,cn=configuration,dc=yourdomain,dc=int" -ip objectversion | select objectversion

The –ip is the alias for includedproperties.

And, when using the native AD Cmdlets of Server 2008 R2 (ADWS), the syntax is slightly different ;

Get-ADObject "cn=schema,cn=configuration,dc=r2,dc=lab" -properties objectversion

Above, you see the query ran with Quest Cmdlets resulting in objectversion 31 which is against a Server 2003 R2 Forest, whereas the latter is for a Server 2008 R2 Forest i.e Schema version 47.

Another architectural poster from Microsoft that highlights the Hyper-V R2 components and features.

You may download it from here.

Whereas most of newly added cmdlets focus on  PKI and Email Address Management in v1.4, there are a few cmdlets and handful of new parameters that ought to come in very handy with your AD tasks. Below I review a few that I think are some great adds :

When you are enumerating a large number of objects in shell (without outputting results into a file), you might just want to have a quick idea of the ‘total’ number of objects meeting the criteria of you query.

Get-QADProgressPolicy

“displays a progress bar for long-running commands”

This progress bar overlays (highlights in and out) as your query is running. It also appears when you are performing a count using the measure-object cmdlet or the “.count” switch

You can set the progress bar setting and its threshold with

Set-QADProgressPolicy -ShowProgress $true -ProgressThreshold 2

The –activity parameter when relying on the progress bar allows you tag each line of progress with a number so that lengthy process is a bit more obvious with respect to the process to one or more cmdlet’s retrieved results.

Some new parameters :

Five new parameters for Get-QADUser

ExpiredFor

Inactive

InactiveFor

NotLoggedOnFor

PasswordNotChangedFor

Four new parameters for Get-QADComputer

Inactive

InactiveFor

NotLoggedOnFor

PasswordNotChangedFor

But what mechanism decides the “inactivity” benchmark to ask cmdlet to retrieve that information ?

You do.

Get-QADInactiveAccountsPolicy

You can change these settings,

Set-QADInactiveAccountsPolicy -AccountExpiredPeriod 0 -AccountNotLoggedOnPeriod 30 –PasswordNotChangedPeriod 120

Note : These settings are profile specific so ones you define these thresholds they will stay there until you change those settings again.

The NotLoggedOnPeriod is probably based on the LastLogonTimeStamp, but I will check and edit this post if its any different. If it is, remember it may not be accurate and should only be used for estimation. The LastLogonTimeStamp gets updated from the LastLogon (DC specific attribute) based on a 9-14 day swing period.

Also :

“This parameter overrides the logon-related inactivity condition of the Inactive or InactiveFor parameter. Thus, if the NotLoggedOnFor value of 60 is supplied in conjunction with the InactiveFor value of 30, the cmdlet searches for accounts that are expired for 30 or more days, or have the password age of 30 or more days, or have not been used to log on for 60 or more days.”

Previously if you had to use the Get-QADGroupMember cmdlet to retrieve the enabled accounts only, you had to pass the LDAPFilter, now you can use the same –enabled and –disabled parameter as you could with Get-QADUser cmdlet since v1.3.

This and much more. All details can be found here.

The folks who develop these cmdlets and work on adding new parameters do take the feedback very seriously. I have myself asked and gotten couple of requests met. You can do the same.

From version 1.2 with 49 cmdlets, to version 1.3 with 63 cmdlets and now on to version 1.4 that has 32 new cmdlets making it total of 95.

Here are the new cmdlets in v1.4 :

• Get-QADLocalCertificateStore
• New-QADLocalCertificateStore
• Remove-QADLocalCertificateStore
• Get-QADCertificate
• Where-QADCertificate
• Add-QADCertificate
• Import-QADCertificate
• Show-QADCertificate
• Edit-QADCertificate
• Export-QADCertificate
• Remove-QADCertificate
• Remove-QADPrivateKey
• Get-QADCertificateRevocationList
• Add-QADCertificateRevocationList
• Import-QADCertificateRevocationList
• Export-QADCertificateRevocationList
• Remove-QADCertificateRevocationList
• Get-QADPKIObject
• Publish-QADCertificate
• Unpublish-QADCertificate
• Publish-QADCertificateRevocationList
• Unpublish-QADCertificateRevocationList
• Add-QADProxyAddress
• Set-QADProxyAddress
• Remove-QADProxyAddress
• Clear-QADProxyAddress
• Enable-QADEmailAddressPolicy
• Disable-QADEmailAddressPolicy
• Set-QADProgressPolicy
• Get-QADProgressPolicy
• Set-QADInactiveAccountsPolicy
• Get-QADInactiveAccountsPolicy

With tons of new parameters and bug fixes. All details can be found under ‘ARMS Build History’ text file under the zip file.

http://www.quest.com/powershell/activeroles-server.aspx

Also Dmitry Sotnikov tweeted regarding the updated cmdlet references wiki :

http://wiki.powergui.org/index.php/QAD_cmdlets_reference

Often times you need to analyze your existing permissions (delegations) on your AD Objects within your domain/forest, perhaps you have just taken over an administrative role over AD and would like to quickly surface information regarding what group and user accounts have certain rights across the board in a pertinent domain. With PowerGUI and Kirk Munro’s “Reporting” PowerPack, you can generate nicely formatted HTML files (that expand and collapse) for each object that has delegated permissions within AD.

1. Download PowerGUI 2.1 from here

2. Get the Advanced Reporting PowerPack from here

3. Launch PowerGUI and import Advanced Reporting PowerPack

4. Click on the root node, go to New and click on the ‘Script Node’ sub-menu option

5. Name your script in the Title bar and type the following cmdlet in the body of the script

Get-QADObject -Type organizationalUnit -SecurityMask dacl | Get-QADPermission

6. By hitting OK the report will run. From the Action Pane (right) click on the ‘Create Report’ link, name the report and add the desired attribute you would like to export on the report

7.  Hit OK and and your HTML based report will be saved by default in your Documents\PowerGUI Exports folder.

You can create all sorts of reports from your AD, do any modifications to your scripts, the format how the Report Pack creates the HTML report and how it generates the data. Download PowerGUI and the Reporting PowerPack and start playing with it.

Often times there is a need to standardized Groups’ naming convention such as with migrations, when you don’t have a rich migration tool that can conform the names or when you don’t have a AD proxy management tool such as ARS in your normal provisioning process. Using Quest Cmdlets with PowerShell to rename groups is a snap. There are numerous ways you can fit the Cmdlets and different parameters to meet your need. In this post, I show you a few ways I have used to rename groups in bulk.

Following is an example where all (or most of your groups have a company name as prefix and now that the migration has occurred you would like to strip the company name out.

First, lets take a quick inventory to define your scope;

Get-QADGroup -Name companyname* -sizelimit 0 | ft name, SamAccountName

You can also define a specific OU to target a specific location;

Get-QADGroup -name companyname* -searchscope “onelevel” -searchroot “ou=Groups,ou=,dc=mydomain,dc=int” -sizelimit 0

Note that the ‘companyname’ string is the number of characters i.e 11 is what we are manipulating and stripping out here;

Get-QADGroup -name companyname* -searchscope “onelevel” -searchroot “ou=Groups,ou=,dc=mydomain,dc=int” -sizelimit 0 | Rename-QADObject -newName {$_.name.substring(11)} -whatif | Set-QADGroup -samAccountName {$_.samAccountName.substring(11)} -whatif

Always use the –whatif parameter to confirm what changes you are about to make before you process the change. If needed, export the results out to a CSV by adding the export-csv cmdlet at the end.  Note, in above the piping “|” can be written on the same line, ignore the wrapping due the site layout.

Similarly, you can chose to rename to rename by adding a new name or after you have stripped out the name completely, you can add a new prefix to your groups

Get-QADGroup -searchscope “onelevel” -searchroot “ou=Groups,ou=,dc=mydomain,dc=int” -sizelimit 0 | FOREACH {Rename-QADObject $_ -newName (“IT-” + $_.name)}

Above query will grab all the Groups from the defined path and will add “IT-“ as the prefix to all groups. Make sure to append the –samAccountName command to ensure that rename happens properly.

Few random pictures I took at The Experts Conference 2010

[View with PicLens]

There are two types of PowerShell versions out there. PowerShell v1 that dates back to 2006 and the PowerShell v2 that is bundled with Windows 7 and Windows Server 2008 R2, and also mysteriously released for down level clients such as Windows Vista and XP (under vaguely named Windows Management Framework (Windows PowerShell 2.0, WinRM 2.0, and BITS 4.0).

An easy of distinguishing both versions is to look for a PowerShell variable called $psversiontable. If it is not defined, then you are running v1. If it is there, you have v2. You can also look at a registry key to differentiate between v1 and v2: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine\PowerShellVersion.

Note that if PowerShell was installed as an update package you may not find it under installed software. You may have to look at the update packages. Also note that PowerShell v2 can be installed over v1 without having to uninstall v1 first. If you were running any CTP versions than the install may make you find and manually uninstall v1 first.

For small shops that do not leverage automated provisioning tools, they face challenge in keeping the attributes for Users and other objects in AD standardized. For similar situation, recently I was asked from Access Control team if there is an easy way to fix the displayName attribute for all users or to fill in the display name where its missing based on the Users’ first and last name. The answer is a simple PowerShell one-liner using Quest Cmdlets.

Using Get-QADUser cmdlet, you can define the location of all your users using the –searchlevel parameter or you can sweep the whole directory for all user accounts. And then pipe the results to the foreach and use Set-QADuser to fix the display names (in this example) based on the users’ first and last name

Get-QADUser mydomain.int/users -sl 0 | foreach {Set-QADUser $_ -DisplayName ("{0} {1}" -f $_.firstname,$_.lastname)}

The –sl 0 parameter defines the limit of users to 0.

What is Active Directory Tombstone Lifetime (TSL) ?

The tombstone lifetime in an Active Directory forest determines how long a deleted object (called a “tombstone”) is retained in Active Directory Domain Services (AD DS). The tombstone lifetime is determined by the value of the tombstoneLifetime attribute on the Directory Service object in the configuration directory partition.

Directory Services veteran and MVP Joe Richards has published a short blog entry demystifying the confusion a technet article has caused in regards to how to go about figuring a TSL on a particular domain. Note that new forests that are installed with Windows Server 2003 with SP1 and up have a default tombstone lifetime of 180 days.

Joe shares his ADFIND tool to lookup the current value of the TSL attribute (irrespective of what OS was used to build the forest). Note that as Joe pointed out if this attribute is not set (i.e empty value) then the TSL is 60 days. Here I show you how to lookup the TSL with PowerShell.

Using Quest cmdlets :

Get-QADbject “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=yourdomain,DC=int” includeallproperties | Select TombstoneLifetime

And with using native AD cmdlets (of ADWS) in Windows Server 2008 R2 :

Get-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=R2,DC=lab” -properties tombstonelifetime

Also within PowerShell, you can also use ADSI to lookup the TSL value.

[ADSI]$config=LDAP://cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,DC=R2,dc=lab

$config.TombstoneLifetime

Also, here is how you can use DSQUERY from the Windows Support Tools to lookup the TSL.

dsquery * “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=R2,DC=lab” -scope base –attr

tombstonelifetime

Note that I have used my test forest’s DN of R2.lab in above examples, be sure to replace the values with your forest’s DN. Above query should be typed in one line.

Server Core seems to be the perfect candidate for installing KMS. Key Management Service mediates your Volume Licensing with Microsoft Activation Services and acts as the man-in-the-middle for the activation for all your KMS clients that comprise of Vista, Windows 7, Windows Server 2008 and R2. With Windows 7 and Windows Server 2008 R2, what you have in KMS is Volume Activation 2.0. In contrast with KMS, what you have is MAK that stands for multiple activation key. MAK is targeted for clients that stay off the network whereas KMS is designed for your internal clients. Following I have a simple overview design of how it works.

My Windows Server 2008 R2 Server Core has a very small footprint, it is a single processor/20gb hd/512mb ram machine. The first thing you need is the KMS Host key from your Microsoft Volume Licensing site or from your TAM.
The command to register the machine as the KMS host is slmgr /ipk <your key>

Once it is registered, you need to activate the host itself. Run slmgr -ato
You can check the status and brief description of the KMS host by running slmgr –dli

The verbose information is provided via slmgr –dlv

Once KMS is setup, it will register its SRV record in DNS. You can verify from your workstation if it has done so via,

nslookup -type=srv _vlmcs._tcp

From then on clients will automatically be reverted to your KMS host for activation but as hinted in the drawing above, starting with Windows 7 and 08 R2, the minimum threshold (activation attempts/requests) that are needed to fully activate the KMS host is 25 Vista/Windows 7 clients or 5 Server 2008 (R2). This number can comprise of virtual and physical loads, previously this was limited to physical systems only. The slmgr -dlv will show you the total requests received.
Note that the KMS is desgined to let you better manage your internal activation for compliance reason. Micrsoft does not go receive any internal information from between the KMS host and KMS client. KMS has you abide your EA Volume Licenseing, check the VL Product Groups shown in the diagram that are pertinent for your environment. I find the group B to be most commonly required.

Important note : Installing/configuring the KMS does not open up the pertinent firewall port (default port 1688). From running “slmgr -dli” you will notice that it says that the KMS is listening on port 1688 but the rule is not enabled so you may do so like this.

netsh advfirewall>FIREWALL add rule name=”KMS” dir=in action=allow protocol=tcp
localport=1688
Ok.

For more information see this link.

As usual a good conversation spurred on ActiveDir on a much discussed scenario of virtualizing your DCs while be varied of the known pitfalls. While virtualized DCs are fully supported on either competing virtualization solution by Microsoft, one known subject I would like to highlight here is the proper time synchronization. You must make sure that your PDCe gets its time from an external time source and other DCs follow the PDCe. All DCs (including PDCe) must not sync their time with the virtualization host, whether its VMware ESX or that of Hyper-V. It was discussed how by default the VMware’s VM settting does not have the time synchronization enabled by default, and my brief look at the Hyper-V’s VM suggested that it is. In any case, you must make sure that setting is disabled, thus VM does sync its time with its host.

VMware time setting from the VMware tools within the VM:

Or under the VM settings from VIC :

Hyper-V setting from the VM settings :

A great resource to refer to, to learn how to configure an authoritative time source for your DCs – see this KB http://support.microsoft.com/kb/816042

One of the DNS improvements in Windows Server 2008 R2 is DNS Cache Locking in which if configured the cache entries are not allowed to be modified for the percentage of TTL.

Cache locking is a new security feature available with Windows Server® 2008 R2 that allows you to control whether or not information in the DNS cache can be overwritten. When a recursive DNS server responds to a query, it will cache the results obtained so that it can respond quickly if it receives another query requesting the same information. The period of time the DNS server will keep information in its cache is determined by the Time to Live (TTL) value for a resource record. Until the TTL period expires, information in the cache might be overwritten if updated information about that resource record is received. If an attacker successfully overwrites information in the cache, they might be able to redirect traffic on your network to a malicious site.

Cache locking is configured as a percent value. For example, if the cache locking value is set to 50, then the DNS server will not overwrite a cached entry for half of the duration of the TTL. By default, the cache locking percent value is 100. This means that cached entries will not be overwritten for the entire duration of the TTL. The cache locking value is stored in the CacheLockingPercent registry key. If the registry key is not present, then the DNS server will use the default cache locking value of 100.

You can configure the CacheLocking with DNSCMD utility from the command line (launched under elevated rights).

dnscmd /Config /CacheLockingPercent <percent>

You may also check the current percentage set for this setting with the /info switch of DNSCMD.

With above, the pertinent DWORD registry key is created under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters

However, in real world you push down this registry key via Group Policy Preferences to all your DNS servers. Values for the key are shown below.

A request came in from the Access Control team requesting that they be provided with the users that have been created in a particular office since last 90 days. As usual, PowerShell (with QAD cmdlets) has very simple one liners you can retrieve this information with.

You may also use this to export this data to a CSV file. Notice that when using the export-csv cmdlet you must choose the ‘select’ and define the attributes that should be exported. Format-Table (aliased above as FT) is used to display the information on the console.

GetQADUser-sizelimit 0 | where{$_.whencreated -gt (get-date).adddays(-90)}| select Name,WhenCreated,DN | Export-csv c:\Users90days.csv

There is always a couple of ways to accomplish the same task with further fine tuning your query. As you can see that above query would grab all the users in the domain, going by their whenCreated attribute and present you the pertinent users.

You can define the OU to search with the –searchroot parameter.

Get-QADUser –Searchroot ‘test.mydomain.int/Users/Chicago/’ | where{$_.whencreated -gt (get-date).adddays(-90)}

Alternatively, if you would to like find users account that have been modified since x number of days, you can try something like this.

$OU = <OU PATH>
Get-QADUser -LastChangedAfter (get-date).adddays(-7) -search $OU -sl 0 | ft name,whenchanged

Previously I had posted the 2003 AD and 2008 Features jigsaw posters, Mike Kline informed me that there is now a 2008 R2 Features poster.

You can download the 44x24in poster from here

An off topic post here as I err to sharing uniquely designed Windows 7 wallpapers.

View Full Album

As usual Joe shared a great insight that trusts well-doing can in one way be verified by checking the trust accounts for their last password resets. When trusts are created the accounts for them are by default created under ‘Users’ container, and are named as TrustedDomain$ and just like computer accounts, trusts reset their password every 30 days, and . He showed how to look up the ‘pwdlastset’ attribute using his ADFIND tool. Below I show you the PowerShell way.

$old=(get-date).adddays(-30)

Get-QADUser -SearchRoot ‘mydomain.int/users’ -Name “*$*” -IncludedProperties pwdlastset | where {$_.pwdlastset –gt $old}

You may also sort and view the results as below

Any trusts that have not reset their passwords in last 30 days are probably no longer valid. If you are using ADWS on Windows Server 2008 R2, then something like below should suffice, assuming you have already created the $old variable using the same command as above.

Get-ADUser -Filter ‘Name -like “*$*”‘ -Properties pwdlastset | where {$_.pwdlastset –gt $old}

Here is quick snippet of password set/reset ‘Set-ADaccountPassword’ cmdlet in 08 R2 via ADWS (native AD cmdlets) and a test screencast from me.

I highly recommend to use the built in cmdlet help to learn the syntax and available parameters. Whether you are using the cmdlet as an one-off task or trying to incorporate it into a script.

First we run, Help Set-ADaccountPassword -examples to look at what the options are and then use,

Set-ADaccountPassword -Identity Moyo -reset where the user id is moyo, and provide the new value of the password. Unlike many other functions where you must run the ADWS under elevated ‘administrative’ privileges, if you are running this cmdlet on your DC, you can run this under normal security context.

Previously I had briefly written about ADAC and today we take a look at some of the things you can accomplish by this new interface of Active Directory.

We start out by launching the ADAC, by running DSAC.exe from the run window

ADAC offers two views, the list view

and the tree view

There are several useful queries built-in which you can add from the ‘Add criteria’ button such as find all the users with expired passwords

And add multiple criteria to your query

From the task pane, you can create a new user

Its an ease of use to be able to fill in all the pertinent attributes from a single interface

Now you can raise DFL and FFL from one location, previously you had to raise the FFL from AD Domains and Trusts snap-in

From the Global Search page, you can simply also add your own LDAP query

You can add specific navigation nodes into your list-view such as the Users container and apply different filters (query) to do a comparison side-by-side, from the same ‘add navigation nodes’ window you can also add other trusted domains to manage multi-domain environment all in one place.

For more info. see http://technet.microsoft.com/en-us/library/dd560651(WS.10).aspx

Also watch this short webcast by Kevin Remde http://edge.technet.com/Media/Exploring-the-Active-Directory-Administrative-Center-SRV311-Part-1-of-5/

I had earlier posted about the Add-Computer cmdlet bug in Windows 7 RC builds which didn’t allow the computer to be added to the domain via PowerShell. With Windows 7 RTM, it is fixed and turns out to be pretty handy should you need to script the domain joins for your new builds. The command to add the machine is pretty simple.

The –passthru switch as chosen in the example shows the results.

Check out help for what you can do with this cmdlet such as when you need to add the computer account to a specific OU. Remember that adding machine via PowerShell to the domain does not require you to create the computer name before hand, but it pre-exists than its not an issue.

Few examples :

Add-Computer -domainname Domain02 -OUPath OU=testOU,DC=domain,DC=Domain,DC=com

Add-computer -workgroupname WORKGROUP-A

Add-computer -domainname Domain01; restart-computer   (this adds the restart option)

For more info. see http://technet.microsoft.com/en-us/library/dd347556.aspx

For reasons unknown to me the useful Rename-Computer cmdlet (shown in my earlier example) seems to have been removed past CTP3 builds and the RTM. Even though the technet reference for all Windows 7 PowerShell cmdlets still has it listed.

Here is a discussion I found.

http://social.technet.microsoft.com/Forums/en-US/w7itproinstall/thread/8cdf0302-a41d-4973-9bff-2923e7ad0178

I was reached out by Keith Powell from Microsoft about the Windows Server 2008 R2 Launch Event dubbed as “the efficiency launch event” on Sep 29th, 2009 at Hyatt Regency Downtown Chicago. It is going to be a virtual event live from San Francisco, with Steve Ballmer as the keynote speaker.

Similar events are going to be taking place in your or a city near you. Take a look at the link below and be sure to register and save the date. Take advantage of this free learning event.

http://www.microsoft.com/business/thenewefficiency/keynote/en/us/

ADMGS aka AD Web Services aka Powershell Native AD cmdlets which is originally a Windows Server 2008 R2 feature is out of beta and can be downloaded from here for DCs running down level OSs.

The Active Directory Management Gateway Service enables administrators to use the Active Directory module for Windows PowerShell and the Active Directory Administrative Center running on Windows Server 2008 R2 or Windows 7 to access or manage directory service instances that are running on Windows Server 2008 or Windows Server 2003 DCs.

“Note:    Installing the Active Directory Management Gateway Service on your Windows Server 2008–based or Windows Server 2003–based servers does not make it possible for you to install the Active Directory module or the Active Directory Administrative Center (which is available only on Windows Server 2008 R2 or Windows 7 operating systems) on these servers. “

For more info see http://www.shariqsheikh.com/blog/index.php/200907/what-is-active-directory-management-gateway-service-admgs/

My first technical blurb was published in the renowned WindowsITPro magazine today. It will also be in November’s print version.

http://windowsitpro.com/article/articleid/102795/dnscmd-versions-discrepancy.html

The Active Directory Groups Nesting restrictions is an often-discussed topic among my peers especially in a multi-domain forest and often a question raised in forums and mailing lists. Although there have been some great blogs written that dive deep into the technical restrictions, I personally needed a simple reference chart that I could refer to and which serves me as a memory refresher. Between the two types of Active Directory Groups, Security and Distributions, there are restrictions in both but this attempted reference chart covers only Security type. There are three scopes of Security Groups. Domain Local, Global, and Universal. A leading practice for each of these scopes for NTFS permissions is as follows. Domain Local Groups are used for permissions (ACLs), Users are populated in Global Groups, and Universal Groups are used to manage Global Groups. But often times there are needs to circumvent this model and cross nesting is required especially in a multi-domain forest or in a large environment with multiple forests. The nesting restrictions of each group that you must know about can be broken into three questions and subsequent charts below :

Please note that these nesting restrictions assume Window 2000 native or Windows Server 2003 DFL.

1. Which particular group will take other scope type (nested) as its member i.e from the same domain and from a trusted domain ?

Chart 1 for Question # 1

Chart 2 for Question # 1

2. Where can a particular group be assigned permissions (ACL) i.e only in the domain where it resides and also cross domains ? (trusted or other child domains within the same forest )

All three scope types can be used to assign permissions in the same domain where the groups reside.

Chart 1 for Question # 2

3. Which group will accept users and computers from same and trusted domain ?

All three scope types will accept Users and Workstation from the same domain where they reside.

Chart 1 for Question # 3

More information on the scope of these groups can be found here:

http://technet.microsoft.com/en-us/library/cc755692.aspx

To learn about a leading access control model known as AGDLP see :

http://searchwindowsserver.techtarget.com/tip/0,289483,sid68_gci1255549,00.html

A question was raised on ActiveDir, and I learned about an old TechNet Jigsaw on AD’s interworking.

Along with that, there was a new Windows Server 2008 AD Feature Components which I received at Tech-Ed 2007 and it illustrates the new and improved AD pieces introduced with Windows Server 2008. This poster covers ADLDS, ADFS, ADRMS, and RODCs.

And an additional poster on general new Windows Server 2008 Feature Components that covers TS, NAP, IIS 7.0, Virtualization, Server Core and BitLocker.

Both of the above illustrations and very good quality large size posters (30x20in) and are good to hang in your office/cube. Printing them on regular printer may distort the quality, so you may try the plotter . All three can be downloaded from the following links :

TechNet Magazine Active Directory Component Jigsaw Poster

Windows Server 2008 Component Posters (both)

P.S This is my first test post using WLW.

What is the AdminSDHolder and SDPROP ?

Ever wonder what controls the native permissions on the security principal such as Domain Admins and Administrators in Active Directory ? What if an owner changes the permission these entities have ? The permissions do come back. They must. John Policelli had a great article on the subject of AdminSDHolder and SDPROP in this month’s technet article. The magic is driven by the AdminSDHolder which is an object that resides under the System container of Domain NC. This object has a unique ACL which is used to control the permissions of security principals that are members of built-in AD groups, also known as “protected groups”. The SDPROP (Security Descriptor Propagator) is the process that runs in the background and complies all the permissions according to the AdminSDHolder.

Every hour, a background process called SDPROP runs on the domain controller that holds the PDC Emulator operations master role. It compares the ACL on all security principals (users, groups and computer accounts) that belong to protected groups against the ACL on the AdminSDHolder object. If the ACL lists aren’t the same, the ACL on the security principal is overwritten with the ACL from the Admin–SDHolder object. In addition, inheritance is disabled on the security principal.

John has done an excellent job on explaining the process and how it can affect you. I would like to show you the one-liners with which you can look-up who is part of that “elite” bunch in your AD with PowerShell (ADWS) on Windows Server 2008 R2 and as well with PowerShell (and Quest) in Windows Server 2003 domain.

For every recipient of this process i.e security principal such as user, group or computer, there is an attribute named “admincount” that gets marked as “1″ indicating that this principal via nesting or explicitly is part of a protected group in AD.

On Windows Server 2008 R2 where can you use (ADWS), the simple command to retrieve the user and group objects with admincount set as 1 is this.

Get-ADgroup -LDAPFilter “(admincount=1)” | select name

Get-ADuser -LDAPFilter “(admincount=1)” | select name

In domains that are pre-Windows Server 2008 R2, you can use similar QAD cmdlets.

Get-QADGroup -LDAPFilter “(admincount=1)”

Get-QADuser -LDAPFilter “(admincount=1)”

If you would just like to get the total number of users, you may count it like this.

(Get-QADuser -Ldap “(admincount=1)”).count

Another great read on AdminCount, AdminSDHolder, and SDPROP is right here from Mike B. Smith.

Some discrepencies pointed out by Joe in the technet article. He explains in great detail. http://blog.joeware.net/2009/09/08/1693/

I have created an Active Directory Custom Search Engine (using Google CSE). It searches for the relevant content based on the sites I have added. The point is to remove all the unnecessary hits you get from using the regular Google search and make sure you get hits from the most smart AD bloggers. I have also added a few PoSH blogs from folks who often write on the “AD management” with PowerShell. So far the engine only searches in the 35 sites I have added, I will be certainly adding more so feel free to leave a comment with your suggestion. Click here to get to it.

So next time you have an AD related query, just type it up in this search engine and you are likely to find what you are looking for. The searched site list is of the prestigious AD bloggers and writers (MVPs,ActiveDir and EE) whom its very likely to find a discussed topic from to your AD query. Personally, it serves me as a tool I could go back to when I remember that I had read about something particular on someone’s blog but can’t remember whose site it was.

Here is the list of searched sites and it will likely be growing.

http://blogs.dirteam.com/blogs/tomek/
http://blogs.dirteam.com/blogs/carlos/
http://blogs.technet.com/activedirectoryua/
http://blogs.dirteam.com/blogs/acefekay/
http://blogs.dirteam.com/blogs/paulbergson/
http://msmvps.com/blogs/UlfBSimonWeidner/
http://blogs.dirteam.com/blogs/sanderberkouwer/
http://blog.joeware.net
http://www.briandesmond.com/blog
http://www.bsonposh.com
http://blogs.msdn.com/adpowershell/
http://blogs.technet.com/heyscriptingguy/
http://jdhitsolutions.com/blog/
http://blogs.microsoft.co.il/blogs/ScriptFanatic/
http://blogs.msdn.com/powershell/
http://poshoholic.com/
http://jacksonshaw.blogspot.com/
http://tigermatt.wordpress.com/
http://www.highorbit.co.uk/
http://www.frickelsoft.net/blog/
http://dmitrysotnikov.wordpress.com/
http://adisfun.blogspot.com/
http://www.open-a-socket.com/
http://www.shutuplaura.com/
http://www.joekaplan.net/
http://www.sdmsoftware.com/blog/
http://imav8n.wordpress.com/
http://blogs.technet.com/josebda/
http://blogs.technet.com/askds/
http://blogs.microsoft.co.il/blogs/guyt/
http://www.gilkirkpatrick.com/Blog/
http://blogs.technet.com/grouppolicy/
http://blogs.dirteam.com/blogs/jorge/
http://blogs.technet.com/instan/default.aspx
http://blogs.technet.com/ad/default.aspx

Thanks to Mike Kline for sharing a couple of links.

Update :
Following links were shared by weemat

blogs.technet.com/filecab
blogs.technet.com/networking
blogs.technet.com/askperf
blogs.msdn.com/w32time

As named “domain modes” in Windows 2000 time, Domain Functional Level and Forest Functional Level (introduced in Windows Server 2003) list has grown with the inception of two new Windows Server 2008 functional levels. While Domain Functional Level limits the OS of the DCs, a raise to the Forest Functional Level (in a multi-domain environment) can only be achieved after all child domains’ DFL have been met. Both Functional Levels do not dictate the type of OS you can run on your member servers. They dictate which OS can run on a DC and introduce new functionality to AD as you move up the ladder. Such as, to be able to take advantage of AD Recycle Bin functionality all your DCs must be running Windows Server 2008 R2 and the FFL must be at 2008 R2.

There are now 6 different types of Domain Functional Levels;

1. Windows 2000 Mixed (supports NT4/2000/2003 DCs)
2. Windows 2000 Native (supports 2000/2003 DCs)
3. Windows Server 2003 Interim (supports NT4/2003 DCs)
4. Windows Server 2003 (supports only 2003 DCs)
5. Windows Server 2008 (supports only 2008 DCs)
6. Windows Server 2008 R2 (supports only 2008 R2 DCs)

And five forest functional levels:

1. Windows 2000 (supports NT4/2000/2003 DCs)
2. Windows 2003 Interim (supports NT4/2003 DCs)
3. Windows Server 2003 (supports only 2003 DCs)
4. Windows Server 2008 (supports only 2008 DCs)
5. Windows Server 2008 R2 (supports only 2008 R2 DCs)

See this for list of features for different Functional Levels.

You can get a free e-book in PDF format authored by Mitch Tulloch from Microsoft. This book covers Hyper-V, App-V, VDI and SCVMM 2008. Click below to register and download your copy.

Also, in this month’s issue of Technet magazine, there is an article on SCVMM R2 RC by Paul Schnackenburg. Its definitely a good read as it explains much awaited Hyper-V’s virtualization features such as Live/Quick Migration of VMs between hosts, self-service portal, new PowerShell VMM-specific cmdlets and much more.

You can read it here.

You can get an evaluation copy here.

Scott Schnoll had a great post on how to install the beta, with all the gotchas and a long list of pre-reqs.

http://blogs.technet.com/scottschnoll/archive/2009/04/15/how-to-install-exchange-server-2010.aspx

As Exchange 2010 will only run on Windows Server 2008 (64bit only), there were some known issues with the beta version with the Windows Server 2008 R2 (mainly newer builds than 7000), due to PowerShell and WinRM stacks being incompatible. That issues is well discussed here and hopefully those issues are now resolved with the RC.

http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/e73ec63f-d5f6-4c2d-8d96-51537493a0ff

And here is the system requirements list.

http://technet.microsoft.com/en-us//library/aa996719(EXCHG.140).aspx

Says the RID Master FSMO to a RODC. If you recall the RID Master’s sole job is to make sure that duplicate SIDs are not issued by domain controllers. Whenever a DC needs to create a SID, it takes the next available value from its own RID pool to create the SID with a unique value. The default pool size is 500 RIDs. When we run the RID pool test on a RODC, the test skips due to the DC being RODC and not having anything to do with the creation of the new objects.

dcdiag /v /test:ridmanager

Here is how the test is supposed to report back with the remaining pool of the allocated RIDs.

Windows Server 2008 R2 provides a web service that is required by ADAC and native AD-Cmdlets of PowerShell, that service in known as ADWS and its part of proverbial ADMGS framework. So ADMGS equals ADWS out-of-box. The service lets Server 2008 R2 AD PowerShell cmdlets and other applications work against the DCs with ADMGS installed. And its final version has been released with Windows Server 2008 R2 which hit RTM earlier this week. That ADMGS framework and comparison of changes from 2008 to 2008 R2 was briefly discussed in a Brian Desmond’s webcast a few months back.

Something not part of the original plan and considered due to high demand is that now you have ADWS add-on service/functionality available to manage your down-level DCs such as Windows Server 2003 and 2008 (non-R2). This means you don’t have to be at 2008 R2 FFL to run this.

Below is excerpted from ADPoSH Blog :

1. Visit http://connect.microsoft.com and enter the invitation ID ADWS-FDBT-CVJK on the home page.
2. Sign in using your live/hotmail ID
3. Active Directory Management Gateway Service download details and instructions will be available to you on MS Connect site – http://connect.microsoft.com/ADWS/

Once you have it installed, you can take advantage of native AD PowerShell Cmdlets. This certainly adds good competitiveness to the cmdlets world and Quest Active Roles QAD cmdlets finally have something to compete against.

For more information see : http://support.microsoft.com/default.aspx?scid=kb;en-us;969041&sd=rss&spid=12925

Microsoft earlier this month released the AD Risk Assessment Program Scoping Tool to public. My look at it tells me that this tool essentially more fancily does what ADRAP Sutiability Scripts did, which came with ADRAP Snapshot Tool, which of course came when you had the official ADRAP engagement and cut a check for it. As beneficial as ADRAP could be for a mid-to-large AD environment, I felt in my experience that it never had enough word of mouth. Very few people seem to have heard of it and there isn’t a lot information publicly available for the program, so until you have it done you have a very little idea on what the program offers. This tool is to do just that, it makes the program more public, it gives you a quick glimpse of what the program is about as well as it readies your environment for the actual ADRAP sweep, hence named Scoping Tool. Below you will see the simple 8 steps process that runs several checks on your AD environment and creates a nice HTML report at the end which you would supposedly send it to your TAM prior to the engagement. Regardless of whether you will have the engagement or not, I think this tool serves as a quick snapshot into your environment. This tool is however intended for premier customers.

Download the tool here

Get white papers regarding Active Directory Risk Assessment Program