October 2007 - Posts

How cool is this?

RIPE, the Regional Internet Registry just concluded their annual meeting where ISPs, Network operators and other interested parties in Europe and surrounding regions get together.

Highlight of the closing event was an impromptu gig by Gary Feldman of Thus PLC which has been posted on You Tube. Who says geeks don't rock ay? Enjoy:

http://www.youtube.com/watch?v=_y36fG2Oba0

 

TechEd IT Forum In Barcelona

logo_people7

Anyone visiting my blog who's going to be at TechEd in Barcelona from the 12th - 16th of November, do let me know. I'll be there and looking forward to another exciting week learning stuff and trading "war stories" with my kinda geeks!

Guys not to miss at TechEd, in my opinion, Markus Murray of Trusec and of course Mr Steve Riley. These guys run their sessions in ways that keep you interested and always happy you attended. Always standing space only too so be sure to be early for the sessions ;-)

PING me and hope to see you there.

Creating Test AD users with Powershell- Improved!

Remember the PoSH add users to AD script? Well, it got picked up by “The Man” himself, Dmitry Sotnikov of PowerGUI fame and he rolled it into a one-liner:

 1..500 | ForEach-Object {
New-QADUser -ParentContainer ps64.local/test -Name “testuser$_“ -SamAccountName “testuser$_“ -UserPrincipalName “testuser$_@example.com“ -FirstName “testUser$_“ -LastName “example$_“ -UserPassword “password_123“ | Enable-QADUser
}

Steve Green and I, coincidentally, were having a go at getting it as short as possible and eventually came down to the same steps but Awesome to see “The Internet” at work!

Enjoy!

Group Policy meets Powershell in a big way!

Today I attended an invitational-only product demo given by Thorbjörn Sjövold the CTO of Special Operation Software of their up coming product Specops Command. This product, in it's pre Beta version, tries to resolve the "last mile" problem currently facing Powershell in Version 1. Today Powershell is installed on a management workstation and carrying out remote tasks or running Powershell scripts against remote machines requires Powershell installed on those machines, using wmi or rolling your own .Net methods.

With Specops Command, you still need Powershell installed on the machines but it takes away the pain of managing which of the versions of Powershell to install (there are different versions for XP SP2, WS03, Vista and also x32 and x64 versions for each OS).

Specops CSE's on the Workstation detect its version and download the appropriate version for install.

The main Features of the Specops Command Group Policy extension are:

  1. Auto Management of Native and 3rd party cmdlets on all workstations under the scope of the Specops Command policy
  2. The ability to configure the running  of cmdlets and scripts in the Security Context of the logged on User or Computer
  3. Script Execution Feedback  -> No longer "fire and forget" when running scripts with reporting of the execution results of all scripts  on all workstations under scope of the policy. Also, the ability to drill down into the results and identify down to line numbers in the code where an issue arose. you can also configure custom feedback where results are stored in a central repository and, I presume, can then be queried using regular methods. 
  4. Undo Scripts. This was one that "tickled my fancy". The ability to cache Powershell code on the client machine that ran when the Specops Command GP was no longer in scope! this can be used to return the machine to a default state or run in any configuration state you may decide on. 
  5. Very granular "Targeting" Mechanism for users and computers.
  6. Granular Scheduling of when the policy changes are applied.
  7. The ability to sign scripts and
  8. Verbose Enterprise Reporting.

Sometime in March this year, Special Operations Software entered a Collaboration agreement with Darren Mar-Elia's SDM Software who make GP management and troubleshooting tools. Both firms are heavily into Powershell and this is further proof that to be able to manage the modern Windows environments of the future (read 6 months at the most), Powershell knowledge will be vital.

Specops Command will, by an order of magnitude, enhance the ability to securely manage, with the scripted intelligence that Powershell provides, Windows environments in a manner that is more affordable and maintainable by Corporations.

Can't wait to get my hands on the early Beta! Stay tuned!!

Learn Powershell Today! And keep a lookout for the interesting things lots of clever people are doing with it.

Creating Test Users in AD - Another way...

My good friend and AD Mentor, Jorge de Almeida Pinto pointed me at a much simpler way to do this. Not with PoSH, admittedly, so not as exciting to me right now but it gets the job done and uses Joe Richard's ADMOD tool:

For groups: (replace # with number, replace $$ with US, GS, LS, UD, GD, LD)

ADMOD -replacedn XXX-DOMAIN-XXX:_default -sc adag:#;$$;"CN=<RDN>,OU=<OU>,OU=<OU>,XXX-DOMAIN-XXX"

For users:

ADMOD -replacedn XXX-DOMAIN-XXX:_default -sc adau:#;<PWD>;"CN=<RDN>,OU=<OU>,OU=<OU>,XXX-DOMAIN-XXX"

 

Enjoy!

Creating Test AD users with Powershell

Sometime last week on the Microsoft AD newsgroup, someone asked for a script to populate test users in Active Directory using a source text file with he user names and passwords. Of course, several people suggested VB scripts to do the task and Richard Mueller gave a pointer to an excellent script on his site.

Of course, I immediately started thinking of a way to do it PoSH style. The thinking, as always, was, "I bet Powershell can do this easier!"

The steps I came up with were:

1. Use Powershell to generate the csv ( I can even omit this step entirely and create the users on the fly)

2. Import the users into AD from the the csv

3. Enable the users

And here's my short PoSH script for the task:

#Create the csv and run in the headings

$outfilename = "out.csv"
"samAccountName,userPrincipalName,cn,sn,givenName,Password" | Out-File $outfilename -encoding ASCII

# Now, populate the csv for 500 users

for ($i = 1; $i -lt 500; $i++){
$samAccountName = "testUser" + "$i"
$userPrincipalName = 'testUser' + "$i" + '@example.com'
$cn    =    "testUser" + "$i"
$sn =    'example' + "$i"
$givenName = "testUser" + "$i"
$password = "password_123"

"$samAccountName, $userPrincipalName, $cn, $sn, $givenName, $password" | Out-File $outfilename -encoding ASCII -append
}

# Import the csv entries into AD as user objects

Import-Csv out.csv | ForEach-Object { New-QADuser -ParentContainer 'OU=test,DC=example,DC=com' -Name $_.samAccountName -samAccountName $_.samAccountName -userPrincipalName $_.userPrincipalName -FirstName $_.cn -LastName $_.sn -password $_.password }

# Enable the user objects

Get-QADUser -SearchRoot 'example.com/Test' | Set-QADuser  -ObjectAttributes @{userAccountControl='512'}

# EASY!

This script compared to Richards, is an order of magnitude shorter and I think, easier to comprehend for almost anyone. It can also be extended, as I will still do to it, to require the number of users to be created to be entered as a variable, connection credentials for AD to be requested and the OU to create the users in as some other variable. Error checking can also be included to make it more shareable.

 

Powershell: Real Glue!

Last Friday Quest software made GA the RC of the ActiveRoles ADcmdlets. This, to me, is another significant milestone in the evolution of Microsoft's new Command line language, Powershell. The versatility continues to amaze me and there is true community effort in extending it! An Extensible command line language the continues, like Perl did, to make the impossible possible and the difficult easy!

Get the RC here

I also stumbled on this blog which shows the "glue" capabilities of Powershell. An inventory system written in much more understandable code and much shorter than you could with most other languages.

Enjoy!

More on Euro DEC Part Deux..

One of my favorite sessions was given by Jorge de Almeida Pinto, a well known DS MVP, whose blog is one of the most interesting reads on AD on the web.

Jorge doing his thing..

His talk was on Read Only Domain Controllers (RODCs); what they are and the challenges in managing them. I'll try and give a précis of his session here.

The challenges RODCs attempt to resolve are:

  • DCs in insecure locations like remote branch offices
  • Storage of credentials on DCs in these locations
  • Non-Domain Admins might be delegated tasks on the DC or manage a server role or LOB applications

All these could potentially compromise the security of Active Directory.

Even with the "read only" nature of an RODC, it is NOT the same as an NT4 BDC:

  • An RODC should always be considered as Untrusted.
  • Its main goal is to improve security and mitigate risk
  • Role is promoted and not assigned (like the GC role)
  • Preferred in perimeter networks
  • Still need to be managed with patches, hotfixes and backup.

To tell you how different they are:

    • They have an RODC “filtered attribute Set” ; a negative list of attributes not replicated to RODCs
    • The Krbtgt account is unique for each RODC. So it can issue its own Kerberos tickets without compromising domain security.
    • They are not members of “strong” security group memberships like Enterprise Domain Controllers.

Prerequisites for installing RODCs

- Forest Functional Level 2 (WS03)

  • This is required for:
      1. Constrained Delegation for Replication
      2. Linked Value Replication

- ADPREP/RODCPREP

  • Executed on the Domain Naming Master FSMO (not mandatory, but preferred as it contacts this FSMO role)
  • Updates the permissions on application partitions for an RODC to be able to participate in replicating those (contacts an application partition replica)
  • Only needed when upgrading from W2K3 AD, not W2K AD (W2K does not support app partitions).

In earlier betas, there was a requirement for the WS08 DC, which must exist, to be the PDC FSMO role holder. This is no longer the case in the RC0 release. Can be any writable WS08 DC.

Installation is by GUI or the Command Line using DCPromo.

Issues regarding Installation of RODCs

  • The delegation of the permission to install an RODC cannot be done securely. Don’t do it.
  • Trust people who install RODCs!
  • Use a 2 stage process instead:
    • Trusted Admin Installs RODC
    • Delegated Admin joins to domain

RODCs can be Installed From Media

  • Passwords can be removed
  • Attributes belonging to the Filtered Attribute Set are removed
  • Media valid: Best Before < Creation date + Tombstone Lifetime

RODCs only replicate their own Domain NC with a WS08 DC

  • Reason is: WS03 DCS do not recognize the WS08 RODC password policy (they are unable to restrict the replication of certain passwords).

The Challenges

  • Unidirectional Replication. No changes (AD DS & DFS) are written to the RODC therefore writable DCs that are replication partners do not have to pull changes from the RODC and do not create inbound replication objects from RODCs (less work for Bridgehead servers).
    • This can create an inconsistent view of replication connection objects depending on which DC has the focus.
  • No automatic deletion of Lingering Objects on an RODC. Use: Repadmin /removelingeringobjects
  • RODC “Filtered Attribute Set”
    • Set of attributes in the schema for domain objects that will not replicate to an RODC
    • If DC is compromised and it tries to replicate attributes defined in the filtered attribute set from a WS08 DC, the replication request is denied.
    • If the DC tries to replicate from a WS03 DC, the request CAN succeed.
    • MAKE SURE FOREST IS AT FFL3 IF YOU WANT TO USE RODC FILTERED ATTRIBUTE SETS
    • System-critical Attributes cannot be added to the RODC filtered attribute set (a system-critical attribute has a schemaFlagsEx attribute value equal to 1)
  • LDAP writes to an RODC are referred to a writable DC; even to a WS03 DC.
  • More than 1 RODC in a specific site will lead to inconsistent logon experiences and is not supported.

Special Write action on an RODC:- password changes

  1. User in site with RODC changes password
  2. RODC refers password change to writable WS08 DC
  3. RODC inbound replicates the password using the “replicate single object” method.

RODC caches, by default, 2 passwords:

  1. The RODC computer account password
  2. The Kerberos account password

If an accounts password is not cached and the user tries to logon, the request is referred to a writable DC.

2 minutes later, or thereabouts, the RODC tries to inbound replicate the password from a WS08 DC which recognises the request is from a RODC and consults the Password Replication policy in effect for the RODC.

The Password Replication Policy determines if the creds can be replicated to the RODC and if so, the writable WS08 DC sends the creds to the RODC.

Next time the user tries to logon, the RODC services the request and signs the users TGT with its krbtgt account. Till the users password changes.

When a TGT is signed with the RODCs krbtgt account, the RODC knows it has a cached copy of the creds. If another DC signed the TGT, the RODC refers the request to a writable DC.

By limiting Credential caching to only users and computers who have logged on to the RODC, the potential risk to the Forest is limited.

Managing Password Replication Policy

  1. Using ADUC on a writable WS08 DC – properties of the RODC computer Account, the PRP tab
  2. Repadmin /PRP

To force replication: Repadmin /rodcpwdrepl

To remove a password from a RODC:

Because an RODC is considered untrusted, the concept that a password can be “removed or purged” from it is insecure.

  1. Change/reset/expire the password immediately
  2. Or wait for it to expire.

When caching accounts on an RODC make sure Computer and user accounts for the site are cached.

How to Deal with a Compromised RODC

When a RWDC is stolen, the immediate threat is all account credentials in the forest can be compromised.

Ulf backed this up by informing of a test he ran for a bank which showed they could crack all passwords of varying complexity and less than 8 chars in length within 2 hrs

To attempt to recover from the loss of a RWDC, you have to:

  1. Clean the metadata of the stolen DC
  2. Reset the password of all user accounts in the Domain
  3. Reset the domain wide KRBTGT account twice.
  4. Reset all DC accounts, all server accounts, all client accounts and all trust. Twice.

All very hard work and you still need to be aware of synched accounts or passwords in other Apps, systems, Domains or Forests.

To recover from a compromised RODC, you have to:

  1. Delete the krbtgt_instancename account of the RODC
  2. Cleanup AD metadata
  3. Reset all cached user and computer accounts

And all this can be done from the ADUC mmc when deleting the RODC account. The cached user and computer accounts can also be exported to a file.

With these RODC concepts, it can be seen how the branch office infrastructure is being better secured whilst trying to improve management.

Microsoft, we hear, are even experimenting with the idea of having an RODC on the Internet. All good stuff I say!

European Directory Experts Conference 23rd - 26th September 2007

The European Directory Experts Conference was held in Brussels the Capital of Belgium from the 23rd to the Th of September 2007. The AD geek show had been brought to Europe by NetPro and Gil Kirkpatrick, the NetPro CTO, and his Crew! It was a thrill to be in the midst of the guys I hang out with on the AD newsgroups on the web.

Arriving Brussels on the 23rd was something else!

 No Cars!

The city center had been closed to cars and other motor vehicles and any taxis or busses had to drive at a max of 30 miles per hour. It did feel weird watching the taxi having to weave through literally hundreds of bikes and horse drawn carts!

Car free day in Brussels!

The Keynote was given by Stuart Kwan and the Topic was the Identity Metasystem. This was the second time I was hearing Stuart give this kind of presentation but this time I think I really got it! How to get our infrastructure from being Directory Providers to Identity Providers and the "formal layers of indirection" that allow for secure transactions between organizations across insecure networks like the Internet. With connectivity being ubiquitous, the missing link is how you can be sure of the identity of the subject making a claim or assertion.

Stuart Kwan giving the keynote

He described the Identity Metasystem as being made up of

  • Identity providers which could be Kerberos or x.509 identity directories
  • Security Token Services (STS) which transforms user provided data into claims
  • Relying Parties which could be the applications using SAML which consume claims
  • The Subject or user who selects an identity, which is the data, to send to the STS
  • the WS -* protocols which glue all this together:
    • WS-Trust
    • WS-MetaDataExchange and
    • WS-SecurityPolicy

What this easily provides is apps that have identity driven behaviors based on the claims provided by a subject. 

This concept for Intranet apps is not exactly new and is well established. The clue here is extending that facility beyond the boundaries of organisations in a secure manner. The Challenge, as Stuart aptly put it, was to "Deproblematize Deperimitization":

  • Connect with people outside the network
  • Connect with less friction and increased security
  • In a situation where Knowledge Workers control trusts and are held accountable.

Products which today facilitate the Identity Metasystem in the Microsoft space include:

  • AD FS which made an entry in WS03 R2 and is "souped up" in WS08
  • Windows Cardspace which supports claims based apps
  • Windows Communication Foundation in .Net 3.0
  • AD RMS which ensures the security on data assets as they move through organisations
  • Applications like MOSS 2007 which are claims aware.

Interoperability with other directory systems and Federation Services and an extensible claims framework, the open content model, are key to getting these technologies more widely adopted.

Next up was Nathan Muggli, a Lead Program Manager in the AD Product Group at MS, who took us on a tour of AD in the WS08 Space.

Nathan Muggli

First thing he hit at was the name changes. AD Domain Services for AD as we knew it, AD Certificate Services, AD Federation services, AD Lightweight Directory Services for ADAM and AD Rights Management Services.

These AD services are now Server Roles in WS08.

They can also be run on WS08 Server Core which has a very limited UI.

Key themes in WS08 Directory Services he listed were:

1. Security

Top on his list of new security features were Fine Grained Password Polices  with Password Setting Objects (PSOs).

This feature allows, within a domain, the ability to set different password polices for individual Security Principals or Global Security groups.

No new complexity rules have been added.

Using PSOs allow for a scenario where within a domain, you can have, for example, admin password policies stipulating very strict settings such as expire every 2 weeks and require 15 character complex passwords, Service accounts to have incredibly long passwords (managed by some automated process) that expire every 90 days and still a much more lax policy for average users. This effectively puts an end to the need for a new domain where different password policies for Security Principals is a requirement.

No real restrictions exist as to the number of policies that apply to a user or global security group but the "last to apply" rule i.e. the lowest in precedence wins.

PSOs do not apply to OUs, Computers or non-domain objects.

PSOs are created using adsiedit or a similar tool in the Passwords Settings Container which can be found within the System container in the Domain.

Other tools have been created by DS MVPs notably one by Joe Richards and even a PoSH GUI utility by Dmitry Sotnikov the Quest Powershell Guru. 

Next up on his security list were the changes to Auditing. The Event logs can now tell:

  • Who made the change 
  • When the change was made
  • Object\Attribute Changed
  • Beginning and End values 

This is controlled by:

  1. A Global Audit policy
  2. System ACLs or
  3. The Schema 

2.  Manageability

- Upgrade

An in-place upgrade is allowed only from WS03 to WS08.

- NT4 Crypto is disabled by default essentially because of it weak DES encryption. this may cause issues with some apps and it can be re-enabled by group policy. An event is logged when an App tries to use NT4 Crypto and this can be used to try and track down errant -apps

- WS08 Domain and Forest Modes

Domain mode gives:

  1. DFS-R for Sysvol Replication
  2. FGPP
  3. AES 256-bit encryption for passwords

Forest mode gives:

  1. No new features
  2. Ensures Domains are at WS08 mode

- Deployment

DCpromo was completely rewritten. You can now:

  1. Decide DC role during DC Promo
  2.  Auto Configure DNS
  3. Cleanup Metadata
  4. Promote to a site
  5. Delegate the promotion of a Read Only DC (RODC) and,
  6. The Advanced Switch has also been got rid of. NTDSutil is used to create IFM staging data.

-Restartable AD

The AD service can now be stopped to install patches or do an offline defrag of the AD database.

And all this without stopping the server! Uptime stats will look a lot better.

A DC with a stopped Directory Service is similar to a member server.

To login, use the DSRM password.

- One thing that has made people unhappy though is the removal of NTbackup of yore..

Volume based backups are done in WS08 using the Volume Shadow Service.

-DR

Accidental deletion of object can now be prevented by selecting a tick box. He emphasized that this was nothing new and could be achieved using ACLs in W2K & WS03 (by setting the deny ACLs on the Delete and Delete Subtree Permissions for an object).

- Snapshots

Online Snapshots of AD can now be taken by VSS using NTDSutil. This snapshot can be mounted and browsed like a parallel AD.

That's it for PART 1