PowerShell tip #1 – Difference between Write-Host and Write-Output

When I started working on PowerShell, I noticed that many people are using two common methods to output strings. One is Write-Host and the other one is Write-Output. I decided to try both of them and noticed no difference…

Pstip1_1

But there is actually a difference. See, the below output:

Pstip1_2

And now this one:

Pstip1_3

What is the difference ?

In the first one you can see that we are directing the output to ‘gm’ (alias for Get-Member cmdlet) and it works. However in the second sample you can see that we are getting an error for  ‘gm’ saying that you must specify and object. This is because we used Write-Host this time.

In short, Write-host just writes whatever it has been asked to write to the console… that’s it. You cannot use it as an input of another command. Whereas Write-Output writes to the pipeline, so the next command can accept it as its input.

A cmdlet like Get-Service is actually equivalent to Get-Service | Write-Output.

Active Directory Recycle Bin

I was at first over joyed when I read for the first time that the Microsoft is going to incor­po­rate this Active Direc­tory Recy­cle bin in Win­dows 2008 R2..We all know how Win­dows recy­cle Bin have helped us in innu­mer­ous occa­sions. Wow.. a sim­i­lar thing with Active direc­tory, where we can restore the deleted object with ease… In this blog we can check how far first impres­sion that any IT admin have when he hears this term “AD Recy­cle bin” is correct.

As you guys are already aware, ear­lier IT admin­is­tra­tors can retrieve the deleted AD objects using Author­i­ta­tive restore, Non-Authoritative restore (sys­tem state restore) and Tomb­stone Rean­i­ma­tion. All these restora­tion meth­ods have com­mon draw back. I.e. it will not restore all the AD object attrib­utes back by default. You will need to do some sort of recov­ery mech­a­nism to get the attrib­utes back. In spite of this, all the above process are com­plex and time time-consuming task.
The fact that gives the restora­tion using AD recy­cle bin a cut­ting edge is that it can restore the AD objects with all the attrib­utes pre­served. Let’s check how Microsoft makes this pos­si­ble. This is actu­ally made pos­si­ble by 2 new AD object states.

1. Deleted AD object state (The default life­time is 180 days): It actu­ally replaces Tomb­stone AD state. The impor­tant dif­fer­ence of this state is that it leaves all the AD objects attrib­utes intact.
2. Recycle
AD object state: A new object state intro­duced with win­dows 2008. When the Deleted AD object state expires the object goes into Recy­cle AD object state. How­ever, the some of the AD objects attrib­utes will be stripped at this state.
Once the Recy­cle AD object state is expires the space occu­pied by the AD object is freed and will be recov­ered form AD DB dur­ing next online defrag­men­ta­tion of AD database.

Another inter­est­ing point to note is that AD recy­cle bin is not enabled by default. We need to enable it man­u­ally. Also you need to ensure that Domain and for­est func­tional level are at the Server 2008 R2 func­tional level.

Con­trary to the Win­dows Recy­cle bin, AD recy­cle bin is not rep­re­sented by a MMC. The deleted objects will not be acces­si­ble from AD man­age­ment tools. Most pre­ferred way for access­ing them will be by using Pow­er­Shell cmdlets

You can enable AD recy­cle bin fea­ture by using fol­low­ing cmdlet. Make sure that you replaces <your for­est root domain name> with your actual for­est root domain name.

PS: Process of enabling AD recy­cle bin is irreversible.

Enable-ADOptionalFeature –Iden­tity “CN=‘Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DN=<your for­est root domain name>” –Scope ForestOr­Con­fig­u­ra­tionSet –Tar­get “<your for­est root domain name>”

The below cmdlet can be used to get a list of all the deleted objects with its attributes.

Get-ADObject –fil­ter ‘isdeleted –eq $true –and name –ne “Deleted Objects“‘ –includ­eDelete­dOb­jects –prop­erty *
To restore an AD object, you need to know the objects dis­tin­guished name or GUID. Now, run the fol­low­ing cmdlet with the one of above para­me­ter as argu­ment.
Restore-ADObject –iden­tity
If you find this power shell com­mands hard to tame, there are cou­ple of third party tools avail­able. Over­all­so­lu­tions’ ADrecy­clebin and PowerGUI’s AD Recy­cle Bin.( I havent got a chance to test both of them !)

I hope this will help you guys to per­form a restore using AD recy­cle bin fea­ture incase needed

 

Blog by Harivishnu

Strategy for DNS server backup in an AD environment

If you are an Active direc­tory admin, there is no need to men­tion the impor­tance of DNS. A DNS sever is poten­tially the sin­gle point of fail­ure in an AD envi­ron­ment… where an inter­rup­tion of its ser­vice or cor­rup­tion of any DNS records can bring the whole ser­vice down. This demands the need for a proper backup strat­egy for DNS servers.
Most pre­ferred method for tak­ing back up of DNS server is to do a sys­tem state backup. But this can­not be use­ful in many cases as it requires you to restore AD, Reg­istry set­tings, DNS etc. while busi­ness require­ment only needs you to restore the DNS server.
Also there may be cases where the sys­tem state restore cat­a­log may be cor­rupted and you could not restore it. Per­son­ally, I have faced sit­u­a­tions where the clients are com­plain­ing about cor­rupt sys­tem state back­ups where the users are not able to restore the DNS data using it. So it is always best to keep an inde­pen­dent backup of DNS server along with your nor­mal sys­tem state backup.
Before men­tion­ing how these inde­pen­dent back­ups can be taken for DNS servers, it’s worth men­tion­ing about dif­fer­ent AD zones in an AD environment.

• Pri­mary and Sec­ondary zones.
• Active direc­tory inte­grated zone.

Microsoft rec­om­mends using Active direc­tory inte­grated zone in DNS servers on an AD envi­ron­ment.
Now let’s check how inde­pen­dent back­ups can be taken on DNS server.

Pri­mary and sec­ondary zones:

Here the zone infor­ma­tion will be stored in plain text files. The backup and restore process is pretty straight for­ward where you can take a copy of text file con­tain­ing the zone infor­ma­tion using XCOPY.
The below com­mand can be used to backup.

XCOPY %SYSTEMROOT%\system32\dns c:\backup\dns /y

To restore the pri­mary and sec­ondary zone infor­ma­tion, you only need to sim­ply copy the files from the

\backup\DNS folder to the %SYSTEMROOT%\system32\dns folder

Active Direc­tory inte­grated zones:

You may be aware that the zone infor­ma­tion for Active Direc­tory inte­grated zone will be stored in AD data­base rather than as a text file. So the first step in tak­ing the backup is to export the zone infor­ma­tion to a file.
DNSCMD /zoneexport test.com backup\test.com.dns.bak
The backup file will be placed in the %systemroot%\system32\dns\backup folder, and will be named test.com.dns.bak.

You can use the backup file just cre­ated to restore the AD inte­grated zone if needed. How­ever, the restore process is bit more complex.

The restora­tion is a 2 step process.

a. You need to cre­ate a pri­mary zone by using the backup file you have cre­ated ear­lier.
b. Converting the pri­mary zone to AD inte­grated zone.
Before per­form­ing the first step, you need to copy the backup file you had cre­ated to %systemroot%\system32\dns folder from the backup loca­tion. Now, exe­cute the fol­low­ing com­mand.

DNSCMD /zoneadd test.com /primary /file test.com.dns.bak /load

The above com­mand will setup a pri­mary zone in the DNS server using the zone infor­ma­tion in the file test.com.dns.bak
Now, you need to con­vert the pri­mary DNS zone you just cre­ated to an AD inte­grated zone. You can use the fol­low­ing com­mand for that.

DNSCMD /zoneresettype test.com /dsprimary

Done!!

Note: If you want to enable secure dynamic updates, then you must enter the fol­low­ing command:

DNSCMD /config test.com /allowupdate 2

As a gen­eral back up guide­line is always a best prac­tice to test the integrity of the backup files at reg­u­lar inter­vals by doing test restores on any test network.

Blog by Harivishnu

Fine Grained Password policies

Before you read this blog, it is rec­om­mended to have a basic under­stand­ing of:

Active Direc­tory fea­tures, Group poli­cies and pass­word pol­icy, Active direc­tory schema and objects. There are related Microsoft arti­cles avail­able for fur­ther infor­ma­tion. I have writ­ten this with the inspi­ra­tion from Hariv­ishnu to just pro­vide an overview of the fine grained pass­word pol­icy which we have recently imple­mented and tested in our test domain LEARNING.COM.

Are you famil­iar with active direc­tory pass­word policies?

It is an easy sub­ject for Win­dows admin­is­tra­tors. But for non win­dows peo­ple, Pass­word pol­icy is a way to enhance secu­rity by imple­ment­ing a set of rules related to your pass­word. As you all know our sys­tem pass­word has cer­tain cri­te­ria to be met. When you set a pass­word, it must meet the com­plex­ity require­ments. These com­plex­ity require­ments and other set­tings will be decided accord­ing the organization’s requirements.

In Win­dows 2003 account poli­cies will be set in a group pol­icy which is enforced to the entire domain. Due to this, all the users in a domain must fol­low the same pass­word com­plex­ity require­ments and set­tings i.e. you can­not have mul­ti­ple pass­word poli­cies in a win­dows 2003 domain. The screen shot of the group pol­icy shows the set­tings in Account Pol­icy. Account pol­icy has set­tings for pass­word pol­icy, account lock­out pol­icy and Ker­beros pol­icy. You can notice that all these set­tings come under the com­puter set­tings and not under user set­tings. So once the domain is set up, the local Secu­rity Accounts Man­ager (SAM) in each domain com­puter will be con­trolled using the above set­tings. That’s how it works in 2003 domain

Win­dows Admin­is­tra­tors always wanted mul­ti­ple pass­word poli­cies for dif­fer­ent kinds of user accounts. They have been asked to set dif­fer­ent pass­word com­plex­ity set­tings for a priv­i­leged account and a nor­mal user. But as I men­tioned ear­lier this is not pos­si­ble in win­dows 2003 and we will have only one pass­word pol­icy in each domain. It is now the time to say ‘yes’ to the require­ment. In Win­dows 2008 domain you can have mul­ti­ple pass­word poli­cies!! Fine grained pass­word poli­cies let you have dif­fer­ent pass­word pol­icy set­tings for dif­fer­ent sets of users. This will allow you to set stricter account lock­out and pass­word restric­tions for priv­i­leged accounts and looser ones for nor­mal users. Cool. Isn’t it?

How can you achieve that? The approach is entirely dif­fer­ent in 2008 Active direc­tory. Instead of hav­ing the Account Poli­cies in a group pol­icy, the set­tings have now moved out of group pol­icy. Account Poli­cies is no longer based on com­puter accounts. It is now pos­si­ble to tar­get indi­vid­ual users and groups of users to con­trol their pass­word restric­tions. You can use ADSI Edit (or any other LDAP Edit­ing tool) to mod­ify the Active Direc­tory object and its asso­ci­ated account pol­icy attrib­utes. In fact the set­tings are con­fig­ured in AD database.

Fine-grained pass­word poli­cies apply to user objects and global secu­rity groups. In order to store the fine grained pass­word poli­cies there are two new object cat­e­gories in the Active Direc­tory Domain Ser­vices (AD DS) schema: Pass­word Set­tings Con­tainer (PSC) and Pass­word set­tings Objects (PSO). Pass­word Set­tings Con­tainer (PSC) will be cre­ated by default under the Sys­tem Con­tainer of the domain, which is vis­i­ble in Active Direc­tory users and Com­put­ers with the Advanced Fea­tures enabled. As the name indi­cates it is the con­tainer used to store the Pass­word set­tings Objects (PSO). The default PSC can­not be renamed, moved or deleted. But you can cre­ate your own cus­tom addi­tional PSC. (Microsoft does not rec­om­mend this and cus­tom Pass­word set­tings Con­tain­ers will not be con­sid­ered when com­put­ing the Resul­tant set of pol­icy (RSOP)). Set­tings other than the Ker­beros set­tings can be defined in the Pass­word Set­tings Objects (PSO). These include the fol­low­ing pass­word set­tings and account lock­out settings:

  • Enforce pass­word history
  • Max­i­mum pass­word age
  • Min­i­mum pass­word age
  • Min­i­mum pass­word length
  • Pass­words must meet com­plex­ity requirements
  • Store pass­words using reversible encryption
  • Account lock­out duration
  • Account lock­out threshold
  • Reset account lock­out after defined time

In addi­tion, a PSO has the fol­low­ing new attributes:

  • msDS-PSOAppliesTo. This attribute has mul­ti­ple val­ues and shows the link to a user or group object
  • msDS-PasswordSettingsPrecedence. An inte­ger value, used to avoid con­flicts if mul­ti­ple PSOs are applied to a user or group.

You must define the set­tings under the above 9 cat­e­gories. All of them are must have attrib­utes. The msDS-PSOAppliesTo, a multi val­ued attribute con­tains link to user and groups objects. You can apply a PSO to mul­ti­ple users or groups i.e. you can cre­ate one pass­word pol­icy and apply it to dif­fer­ent sets of users or groups. A cou­ple of new attrib­utes msDS-PSOApplied and msDS-ResultantPso have been intro­duced to the user and group as well (msDS-ResultantPso for User). The msDS-PSOApplied attribute has a link back to the PSO.

You can apply a PSO to user either directly or indi­rectly through group mem­ber­ships. In this way user or group object can have mul­ti­ple PSOs linked, either due to the mem­ber­ship in mul­ti­ple groups with linked PSOs or because PSO applied to the object directly. But only one of them will take effect. msDS-PasswordSettingsPrecedence attribute helps to cal­cu­late the win­ning one from the con­flict. The PSO which is directly linked to the user object has the high­est pri­or­ity (You could not link mul­ti­ple PSOs directly to a user). If there is no directly linked PSO, the PSOs from the group mem­ber­ships will come in to the play. The PSO with the low­est prece­dence value (value of msDS-PasswordSettingsPrecedence) will take effect. A lower value of this attribute indi­cates that it has higher prece­dence. For Exam­ple: A user has no directly linked PSO and has two PSOs applied through group mem­ber­ships with a prece­dence of 2 and 4, the PSO with a prece­dence value 2 will take effect. If there are no PSOs linked to a user directly or indi­rectly, the default domain pol­icy will take effect. Things will be more com­plex if you have no directly linked PSO and have mul­ti­ple PSOs with the same prece­dence value (Microsoft rec­om­mends unique prece­dence value for each PSO). In this case the GUIDs of the PSOs will be com­pared and the PSO with the low­est GUID will be applied. The msDS-ResultantPso attribute will be cal­cu­lated based on the above rules. This shows the final PSO which got applied to the user.

Impor­tant Points to Remember:

  • Microsoft says the user­Ac­count­Con­trol set­tings like Reversible pass­word encryp­tion required, Pass­word not required, Pass­word does not expire will over­ride the set­tings in the resul­tant PSO.
  • Your domain must be run­ning in Win­dows 2008 func­tional level to uti­lize the fine grained pass­word pol­icy. This indi­rectly states that you can­not have win­dows 2000, 2003 Domain con­trollers in your domain.
  • Fine grained pass­word poli­cies are avail­able in all edi­tions of Win­dows 2008.
  • If you are not cre­at­ing fine grained pass­word poli­cies, the set­tings in the Default domain pol­icy will take effect (Just like your win­dows 2003 domain).
  • Only domain admin­is­tra­tors or del­e­gated users can cre­ate or mod­ify the PSOs.

The fine grained pass­word poli­cies can­not be applied to an orga­ni­za­tional unit. But you can cre­ate a global secu­rity group called shadow group and can add the users of an OU to the group. This shadow group can be used to apply the fine-grained pass­word pol­icy. If you move users between OUs, you must update the shadow group membership.

Troubleshooting Account Lockout issues in Windows

Special thanks to Harivishnu for sharing this blog post.

This topic was not in my mind until yes­ter­day, where one of my friends work­ing as an IT admin in a soft­ware com­pany rang me to tell an issue there cor­po­rate net­work is fac­ing now. Where the users are con­tin­u­ally get­ting locked out! Sadly, I could not give him any sug­ges­tions worth try­ing out.

After this, I did a lit­tle research on this topic and decided to put together a blog so that oth­ers can also ben­e­fit from this. I am going by the pre­sump­tion that every reader is aware of how to imple­ment an account lock-out pol­icy in a network.

On prima face, account lock out seems to be a good thing to imple­ment as it will be dif­fi­cult for the attack­ers to launch a brute force attack. At the same time it can cause issues where the users will be con­tin­u­ously logged out. It can be due to (any one of) the fol­low­ing reasons

  • Sched­uled tasks try­ing to use old credentials.
  • Drive map­pings try­ing to use old credentials.
  • Dis­con­nected TS ses­sions that had used stale cre­den­tials to connect.
  • Ser­vice con­trol man­ager cash­ing old ser­vice account password.
  • It can also be due to the obvi­ous rea­son such as fail­ure of active direc­tory repli­ca­tion between DCs.

So how to go about in such a sit­u­a­tion… Thank fully, Microsoft pro­vides a free set of tools which can be used to trou­ble shoot account lock-out issue, it is called Account Lock­out and Man­age­ment Tools (ALTools.exe). after extract­ing the tool kit, you can install the tools in any work sta­tion or server as per the situation.

1. AcctInfo.dll

You need to reg­is­ter this dll on the sys­tem where you are using the ADUC con­sole to man­age the domain. Reg­is­ter­ing this dll will add a new tab called Addi­tional Account Info to user account prop­er­ties Active Direc­tory Users and Com­put­ers (ADUC). The extra tab con­tains many use­ful fea­tures such as.

  • Pass­word last set timestamp.
  • Pass­word expiry timestamp.
  • User Account Control.
  • Locked date
  • Unlock date
  • Last Logon time stamp.

2. ALockout.dll

This is an inter­est­ing tool that I have found use­ful in deal­ing with account lock out issues. This will cre­ate a log­file that you can use it for diag­nos­tics. For that you need to reg­is­ter this dll on the machine where you are expe­ri­enc­ing account lock-out issues. When the account lock-out occurs again you can check the logs at the fol­low­ing loca­tion %WinDir%\debug\ALockout.txt. How­ever, you must be famil­iar with Net­l­o­gon log­ging to decode it.

3. AloInfo.exe

This tool can be used for 2 pur­poses by using dif­fer­ent switches.

It can be used to list pass­word age for the user, so that we can deter­mine which accounts are about to expire.

aloinfo /expires /server:server-name

The tool can also be used to dis­play the cre­den­tials for all mapped dri­ves for the cur­rently logged-on user.

aloinfo /stored /server:server-name

Here is the list of other tools included in ALTools.exe:

  • EventCombMT.exe — used to com­bine event logs from mul­ti­ple com­put­ers to a sin­gle location.
  • NLParse.exe — used to parse Net­l­o­gon files.
  • EnableKerbLog.vbs — to enable Ker­beros logging.
  • LockoutStatus.exe

PS: when we con­nect to a remote com­puter by select­ing the Remem­ber Pass­word check­box, it gets stored some­where right? You can man­age such logon infor­ma­tion for net­work loca­tions and web­sites for your machine.

This can be done by typ­ing the fol­low­ing com­mand on the com­mand prompt.

rundll32.exe keymgr.dll, KRShowKeyMgr

I hope this blog will aid you in trou­bleshoot­ing lock­out issues more effectively

Active Directory Server Installation Checklist

Thought of shar­ing a check­list which could be fol­lowed while installing a domain con­troller (AD server). I have cre­ated and fol­lowed this while pro­mot­ing domain con­trollers in my test environment.

Sr Require­ment Detail (Rec­om­mended minimum) Sta­tus
1 Hard­ware configuration Proces­sor Server Class
RAM 2 GB
Net­work 100 MBPS
2 Disk require­ments 40 GB
3 Oper­at­ing System Ver­sion Server 2003 R2 Std
Host­name Fol­low nam­ing convention
Time and Zone Proper Zone and Time is a must
C Drive 20 GB
D Drive 20 GB
i386 folder Copy to D Drive as install media may not be avail­able all the time
4 Anti Virus Lat­est Update
5 Sta­tic IP Assign a sta­tic IP
6 DNS Con­fig Con­fig­ure DNS IP of the domain you want join
7 Ports and Firewall Make sure that the required ports are open
8 DNS ser­vice Just install but do not configure
9 Enable Remote access Enable remote access
10 Oth­ers Sup­port Tools Install
Log Parser Install
GPMC Install
Multi NIC Dis­able mul­ti­ple NICs