Zone Assignments and GPO settings

Let's say you have a handful of websites that you want to assign to particular zones. You have an internal site you want everyone's browser to handle in the Intranet zone. You have a few external sites/vendors that your users need to interact with and those must be in the Trusted zone. Or even if you set your drive mappings in your login scripts to use the FQDN of the file server, and Windows/Office automatically treats every file on those drive mappings as "Internet" files and won't trust them (you need to set your domain in the Intranet zone).

 There are a couple of ways to handle this type of situation. First, you could just teach all the users how to do their own zone assignments, which is never a fun task. You could script the changes, adding the sites directly to the ZoneMap in the HKCU in the registry.  Or you could push it all out via Group Policy.

 There are two ways to push these settings via Group Policy; the strict way and the flexible way, depending on what you're trying to accomplish.

 If you want to set the Zone Assignments and not allow the user to modify them in any way, create a new policy and navigate to User Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page.  Locate the "Site to Zone Assignment List" setting. If you disable this setting, no user will be able to set any zone assignments. If you Enable the setting, you can set the zone assignments for the user.

 HOWEVER, THEY WILL NOT BE ABLE TO MODIFY (ADD) ANY ZONE ASSIGNMENTS. 

Also, their existing zone assignments will be lost.  This is important. The user will not be able to add that one-off site that they need and will have to wait on you to add it to the GPO. However, sometimes it is necessary to do this. If you are ok with this, enable the setting and click the "Show" button next to "Enter the zone assignments here". I tend to enter my domain assignments using a wildcard, so any child/sub domains are covered. Of course, you can enter specifics here as well.

For the "Value", you must enter a number from 1-4 that designates what zone to put the domain in. They are:
1 = Intranet Zone
2 = Trusted Sites Zone
3 = Internet Zone
4 = Restricted Sites Zone

After you are finished, assign the GPO to the OU's you want to apply it to.

Let's say you want to be flexible.  You know there are a few users out there that might need to use another vendor's site for whatever reason and they don't want to wait for you to add it to the GPO.  Or an existing vendor made a change to their website and requires it to be in the Trusted Zone suddenly.  Or your helpdesk wants to troubleshoot an issue by moving site assignments around.  We want to assign sites and still allow the user to add their own.

TO ALLOW USERS TO ADD THEIR OWN SITES, DO NOT SET THE "SITE TO ZONE ASSIGNMENT LIST" SETTING.

Leave that setting to Not Configured.  I learned this the hard way.  Instead, navigate to User Configuration\Preferences\Windows Settings\Registry.  Right-click and choose New - Registry Item.

1. For Action, choose Update.
2. For Hive, choose HKEY_CURRENT_USER
3. For Key Path, enter Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\blogger.com  
1. Replace blogger.com with the domain you want to add.
2. If you want to cover the entire domain, just put the domain name.
3. If you want to cover only a sub domain, put it instead (example: client.blogger.com)
4. If you want to cover only www, put that as well (example: www.blogger.com)
4. For Value Name, you have a few options.
1. You can use a wildcard to cover anything .blogger.com (*.blogger.com)
2. You can specify a protocol (http, https).  This will only cover that one protocol (example: www.blogger.com, with Value http = http://www.blogger.com)
5. Value type: REG_DWORD
6. Value Data: Enter the value of the zone you want to assign.
1. 1 = Intranet Zone
2. 2 = Trusted Sites Zone
3. 3 = Internet Zone
4. 4 = Restricted Sites Zone
7. Base: Decimal.

Let's say you want to add an IP address or an IP range.  This is a bit trickier but it is possible.  First, your Key Path will be different.  Instead of "Domains" under ZoneMap, you will be placing the registry setting in Ranges.  Also, for each "Range" you will have to create a sub-key and it will require two settings instead of one.

If you run into an issue or need to know how to add a specific setting, you can always add the Zone Assignment on your computer and look in the registry to see how it works.   You can also do this to verify that the GPO is applying correctly.

Open Regedit and go to:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

Your domain will each be a subkey under "Domains".  Your IP addresses will be under "Ranges".

Using DSADD.exe to Bulk Create Users in Active Directory

So I had to add about 70 user accounts to Active Directory in preparation for a new call center. Sounds like boring, tedious work if you ask me. Well, it would be without the magic of dsadd.exe, a command in Windows 2003 command line that allows you to create Active Directory objects, such as users, computers, groups, contacts, and OUs. My focus here is on adding multiple user accounts.

Focusing on my needs, I wanted to add the user, set the display name, set a password, set a description, set the office, their title and department, and their logon script while forcing a password change and the ability to change the password. I also wanted these accounts to start disabled since it might be a week or two before the users are ready for them. Have the accounts created in the proper OU would also be nice. Also, my users would be logging with accounts based on their phone extension numbers, since high turnover is a concern.

So, I set up a user, called cc70215. Since I want him in his proper OU, I set him up as cn=cc70215,ou=Users,ou=CallCenter,dc=sysadminhell,dc=com. This was no big deal, I already had the list of users, just copy/paste and some text replacement set up the list of users. With all I wanted to do, I set up the command as such:

DSADD user cn=cc70215,ou=Users,ou=CallCenter,dc=sysadminhell,dc=com -display cc70215 -pwd mypassword -office "Call Center" -title "Customer Service Associate" -dept Collections -loscr cc_li.vbs -mustchpwd yes -canchpwd yes -disabled yes

A success message will return if successful and navigating to the CallCenter, Users OU will reveal my new account. But this is a pain to set up 70 times. And it was 30 minutes before time to go home. So, I got dirty a bit and cheated with the batch script FOR command. First, I got all my users in a comma-separated list. I also had to put quotes around each user. A quick text replacement in my favorite text editor (Notepad2) did the trick. Then I created a batch file, and put in the following:

FOR %%D in ("cn=cc70216,ou=Users,ou=CallCenter,dc=sysadminhell,dc=com", "cn=cc70217,ou=Users,ou=CallCenter,dc=sysadminhell,dc=com", "cn=cc70218,ou=Users,ou=CallCenter,dc=sysadminhell,dc=com", "cn=cc70219,ou=Users,ou=CallCenter,dc=sysadminhell,dc=com", "cn=cc70220,ou=Users,ou=CallCenter,dc=sysadminhell,dc=com") DO DSADD user %%D -display %%D -pwd mypassword -office "Call Center" -title "Customer Service Associate" -dept Collections -loscr cc_li.vbs -mustchpwd yes -canchpwd yes -disabled yes

For this example I only used 5 users, but you get the point.

Put a pause and exit in there and run it as a domain admin. With all luck, your accounts will show up in no time. Now, I did find one issue with this method. Here I'm telling it to set the -display (Display Name) with the variable %%D. What this does is set the Display Name for the account as "cn=cc70216,ou=Users,ou=CallCenter,dc=sysadminhell,dc=com", which is not ideal. Since I was under some time constraints, I just changed the Display Name for the new accounts manually (took me about 10 minutes to prep the script, 2 minutes to run it, then another 10 to fix the Display Name issue). Researching other ways to do this now that I have some free time, I could have done this via wscript (using arrays), used the built-in Windows command CSVDE.exe (see this Technet article for more info), or bought one of several different commercial applications. Even with the one flaw, it did all I wanted it to do for free and under 30 minutes.

Account Lockouts and Password Resets Delegation Taskpad

So I've been struggling a little bit with delegation and taskpads. A little background: We're creating a new call center, eventually holding 200 users, and adding any additional support staff is out of the question. About every 20 users there will be a supervisor, and there will be 2 or 3 guys supervising them. They're also going to be working weekends, which would add a lot of headache on me and my crew (we don't have a weekend help desk, just one guy on call). So delegating password resets and account unlocks is pretty critical for our sanity (not to mention speedier service for the end user).

Following the articles I posted earlier, setting up a taskpad view and even setting up the unlock rights/password change rights wasn't too difficult. Getting the password task was also easy, but finding a way for the end user to unlock an account without having to go into the account's properties was more of a challenge. I tried numerous scripts, wrote some scripts, but couldn't get it to work for some reason. Finally, I found the article How can I add an "unlock user account" option to the Active Directory Users and Computers context menu? at the Petri IT Knowledgebase. I followed the instructions exactly step-by-step and I ended up with a nice (and working) Unlock User option when right-clicking on a user account. After that, adding it to the taskpad view was as easy as adding the Reset Password function.

A quick overview of how I set these up:

Set up delegation for account lockouts and password resets.

1. Create an AD group, populate with those folks whom you want to have delegation rights.
2. Right click the OU you want to delegate, click "Delegate Control".
3. Add your created group when prompted in the wizard.
4. Choose to create a custom task.
5. Choose ONLY user objects as the scope of what you want to delegate.
6. For permissions, choose only General and Property-specific. Check "Change password", "Reset password", "Read lockoutTime", and "Write lockoutTime".

Note: If you want to check who has what delegation rights, or if you want to edit an existing delegation, check the security of the OU in question. In Active Directory Users and Computers, click View, Advanced Features. Then right-click the OU and choose properties. Click the Security tab, then Advanced. There you should see who has what permissions on this OU.

Create a taskpad.

1. Open mmc.exe (Start, Run, mmc.exe).
2. Add Active Directory Users and Computers to your view.
3. Choose the OU you're delegating.
4. Right-click the OU and choose new window from here. This is the view you want your users to ONLY see.
5. Click Action, New Taskpad View.
6. Choose the style you like (I like the Vertical list, Text).
7. If you want them to be able to view the sub-OUs (child OUs) with the same view, select "All tree items that are the same type as the selected tree item" and "Make this the default taskpad".
8. To edit or add your tasks, right-click the OU and choose Edit Taskpad.
9. Choose the Tasks tab and click the New button.
10. To add the Reset Password task, choose Menu command.
11. Highlight a user account in the left window and choose Reset Password in the right window.
12. Put in a description, choose and icon, and you're set to go.
13. To add the Unlock User task, follow these instructions from the Petri IT Knowledgebase website. Do that first. Then repeat steps 9 - 12, but choosing the Unlock user task.

Lock it down.

To customize views, click the MMC icon next to the File menu. Choose Customize View. Select what you want your users to see. I personally remove everything except Console tree and Taskpad navigation tabs.

After you're ready to deploy, click File and choose Options. In Console mode, select User mode - limited access (I use single window). Uncheck Allow the user to customize views (this is optional depending on what you want your users to do). Then save. Your users shouldn't be able to do much more than reset passwords and unlock accounts.

To edit your saved .msc, right click it and choose Author. This will open it in editing mode.

Delegation Day

We have a new call center coming up and one of the projects I'm working on is Active Directory Delegation. This would allow me to give supervisors and call center managers the ability to reset the passwords and unlock the accounts of their users without calling me or my guys. Here's some resources:


Here's Microsoft's .doc guide regarding delegation:

Best Practices for Delegating Active Directory Administration

This Microsoft article tells you how to delegate the Unlock Account Right. (2003 users, skip the part about editing the Dssec.dat file; 2003 has that already enabled, and the setting isn't even there anyways):

How To Delegate the Unlock Account Right

This MS article is more of a collection of other MS articles regarding delegation:

How to Delegate Basic Server Administration To Junior Administrators

When looking at using Active Directory Delegation for those non-technical, look at using Taskpads:

Making use of Active Directory Taskpads

(I'm only linking to one page of a pretty decent article, so check out the rest of it as well.)

This is the best taskpad article I've found:

How can I easily perform management operations in AD from a customized Taskpad?

This is a quick article of someone whom needed to Delegate Unlock Account rights and describes his fun. He has some vbs script code that integrates into the taskpad that will take the highlighted user, unlock them, and log who unlocked whom on a domain controller. I'm currently looking at using this, but at the moment I'm getting errors:

WindowsITPro, Unlock User Accounts

Active Directory Replication over Firewalls

Active Directory Replication over Firewalls: "This white paper explains how to get replication to function properly in environments where an Active Directory directory forest is distributed among internal perimeter networks (also known as DMZ, demilitarized zones, and screened subnets) and external (Internet-facing) networks."

Ran into this issue when attaching a remote office over a gateway-to-gateway VPN involving two ciscos. The firewall still treated the VPN as an external network, and applied firewall rules to it. We didn't follow this (basically added a rule to allow all traffic from this VPN, then lock it down via switch acls) but it's good info to have.

Microsoft's daylight-saving time (DST) patch -- Does it matter to AD?

Microsoft's daylight-saving time (DST) patch -- Does it matter to AD?