In a previous post I covered the basics of managed service accounts (MSAs) in Windows Server 2008 R2. Today, I will discuss  a bug that can prevent MSAs from being created in domains that include Read-Only Domain Controllers (RODCs) on screened subnets.

Both the Read-Only Domain Controller (RODC) and the Managed Service Account (MSA) are, for my money, delightful advancements in the Windows Server platform. We will recall that the RODC allows Windows administrators to deploy Active Directory domain controllers to unmanaged or lightly managed branch offices in a more secure fashion. The idea is that because the domain controller directory database is not writeable, a malicious user would thereby be prevented from making unauthorized changes to it.

The managed service account is great because it solves the (seemingly) age-old conundrum of how we can integrate domain password policy with dedicated service accounts for our applications and services.

(more…)

In this article you will learn the basics of managed service accounts in Windows Server 2008 R2.

Here’s the situation: You are called into consult for a client, and in examining their IT infrastructure you observe no organization as to how service accounts are deployed. For instance, some line-of-business (LOB) applications are using the domain Administrator as their service account identity, while others use the Local Service or Network Service identity.

Recently, the client began associating application services with dedicated domain user service accounts. However, because domain password policy forces password changes every 60 days, the manual reassignment of service account passwords created organizational headaches for the IT support staff.

How can you resolve this mess of a real-world situation?

(more…)

This last part in this series gives you some valuable tips when running BitLocker in an Active Directory environment.

BitLocker, like any other new technology, is a lot of trial and error. Here are the things I’ve learned using BitLocker that will hopefully help you out:

Test, test, test

I think, I encrypted my two test systems about 20 times each before I got comfortable with BitLocker. You may also want to consider making the IT staff that will be supporting BitLocker encrypt their own laptops as part of your pilot. The quickest way to identify issues is to use the technology yourself on a daily basis.

Backup, backup, backup!!!

Always, always, always, make sure you have a backup of a drive before you encrypt it with BitLocker. Always, always, always, make sure you keep a backup of data that resides on BitLocker encrypted drives. If you’re not using Folder Redirection and Offline File or running a some kind of third-party backup software on your clients, now is the time to investigate before encrypting your data. If you’ve got mobile users, you’re hopefully doing this already.

(more…)

Part 6 of 7 explains how to view the BitLocker Recovery Password in Active Directory, how to access TPM information and how to put BitLocker recovery information manually into Active Directory.

Now that we’ve used BitLocker to encrypt an operating system Drive, a fixed data drive, and a removable drive, we should have recovery information for all three drives in Active Directory.

View the BitLocker Recovery Password in AD

To view the information, first make sure that you’ve installed the BitLocker Recovery Password Viewer. Go into Active Directory Users & Computers and view the properties of your Computer object by double-clicking on it. Go to the BitLocker Recovery tab and you should now see the recovery keys for all of the drives encrypted on the system.

BitLocker Recovery Key in Active Directory

(more…)

BitLocker To Go is used to encrypt removable data drives such as flash drives. Part 5 in this series also discusses the BitLocker To Go Reader which is required to read encrypted data on legacy Windows versions.

Last, but certainly not least is encrypting Removable Data Drives. As we did with the Operating System Drives and the Fixed Data Drives, start by going to the Control Panel and finding the BitLocker Drive Encryption applet. Click “Turn On BitLocker”. Hopefully, you noticed that the User Account Control (UAC) shield is missing for encrypting Removable Data Drives. What does this mean? It means that users that do not have Administrative rights can encrypt their own removable devices!

BitLocker to Go

(more…)

In this article you will learn some strategies for troubleshooting the “Network accounts are unavailable” error in Mac OS X Lion computers that are bound to Active Directory Domain Services.

4sysops readers have spoken: there are serious integration problems between Apple Mac OS X 10.7 Lion and Active Directory Domain Services (AD DS). Specifically, we are seeing (a) sluggish binding between the Macs and AD; (b) super-slow domain logons; and (c) completely blocked domain logons.

The biggest indicator of this problem is the red dot icon and “Network accounts are unavailable” message in the Mac OS X Lion logon screen; this is shown in Figure 1.

The dreaded “Network accounts are unavailable” error in Mac OS X Lion

(more…)

This post in our Active Directory for BitLocker series explains how to encrypt operating system drives and hard disk data drives.

Now that we’ve updated Active Directory and created our Group Policy Object with our BitLocker, TPM, and Sleep settings, we’re ready to encrypt our first device. To begin, you’ll first need to make sure that your computer meets the hardware/software requirements (Please note that in the screenshots and instructions below, I’ve performed the procedure in Windows 7. The process should be mostly the same in Windows Vista.)

Encrypting an operating system drive with BitLocker

• Windows Vista Ultimate or Enterprise; Windows 7 Ultimate or Enterprise
• Trusted Platform Module (TPM) version 1.2 or higher
• BIOS that is compatible with the TPM
• TPM must be enabled in the BIOS – Some manufacturers enable the TPM automatically and others leave it disabled. You may need to refer to documentation from your vendor to enable the TPM.
• Two hard drive partitions: one drive for Windows and one as a boot volume. (A standard Windows 7 installation automatically creates the necessary partitions. Windows Vista will require use of the BitLocker Drive Preparation Tool – http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=7806.)
• Drive must be formatted as NTFS

(more…)

Part 3 in this series covers best practices for configuring BitLocker for Active Directory through Group Policy.

The last thing you’ll need to do before encrypting your next drive is to configure Group Policy. I copied the essential Microsoft’s Best Practices settings and added my own experiences at the end of the article. In a new or existing Group Policy Object, navigate to Computer Configuration, Policies, Administrative Templates, Windows Components, BitLocker Drive Encryption, and set the following:

Top Level / Global

• Choose drive encryption method and cipher strength – Set to not configured.
• Prevent memory overwrite on restart – Set to not configured.
• Provide the unique identifiers for your organization – Set to enabled, and enter an identifier in the BitLocker identification field.

(more…)

Part 2 in this series about BitLocker and Active Directory explains how to update the Active Directory Schema, how to configure additional Access Control Entry (ACE) settings, and how to install the BitLocker Password Recovery Viewer.

If you installed a Domain Controller running Windows Server 2008 Beta 3 or later (Yes, this was taken directly from Microsoft documentation… I hope you didn’t have a DC running a beta product in your production Forest!), the required schema extensions here have already been performed.

Updating the Active Directory Schema for BitLocker

You can check to see if the attributes are available by running ASDI Edit and looking for the BitLocker recovery object CN=ms-FVE-RecoveryInformation. This should give you an idea of what you’ll see: Screenshot 1 is a Windows Server 2003R2 SP2 Domain Controller; screenshot 2 is a Windows Server 2008R2 SP2 Domain Controller. As you can see, the Server 2008R2 DC has the required schema extensions and the Server 2003R2 DC does not.

BitLocker Active Directory -  Windows Server 2003 R2 DC Schema

(more…)

This article reviews the Lepide Active Directory Management and Reporting tool, which is an alternative to the built-in Active Directory management tools in Windows Server 2008.

Lepide Active Directory Management and Reporting Tool

(more…)

SysAdmin Anywhere is a free Active Directory management tool for computers, user accounts, and groups. The tools also support Active Directory reporting.

Submitted by Igor Markin

The program allows you to manage users, groups, client computers, servers and domains. Metro interface makes the program easy. You do not need to install software on the server.

Active Directory Management -SysAdmin Anywhere

(more…)

Rate this tool: (5 votes, average: 4.00 out of 5)

 Loading ...

Submit a free admin tool | Free admin tools index | Browse free admin tools

In the third article of this series about AD login scripts in Mac OS X scripts you will meet the major players in the third-party development space concerning the application of Active Directory Group Policy to Mac OS X-based client computers.

In this article we conclude our survey of the ever-challenging world of applying Active Directory logon scripts to Mac OS X users and client computers. To get up to speed on our discussion, please take a moment to examine the previous installments of the series.

In this brief essay we will meet the major players in third party Windows-Mac integration development. Two of the following three companies described have accomplished the seemingly impossible: applying honest-to-goodness Active Directory Group Policy policies to Mac and Linux boxes! Without any further ado, let’s get to work.

Quest Authentication Services

Quest Authentication Services Managed Client Extensions for Group Policy is unique inasmuch as it gives you, the Windows systems administrator, the ability to not only extend traditional Active Directory environment access policies (password and account lockout policies, Kerberos settings, etc.) to the Mac, but also enables you to get to the Workgroup Settings that are ordinarily locked in Mac OS X Server.

(more…)

In the second part of our series of Active Directory login scripts in Mac OS X you will learn how to deploy the contents of Active Directory logon scripts to Mac OS X clients by using Open Directory, the LDAP directory service in Mac OS X Server.

In this article we continue our trolley ride through the wild and wooly world of applying Active Directory logon scripts to Mac OS X users and client computers. To get up to speed on our discussion, please read the inaugural installment: Deploying Active Directory Logon Scripts in Mac OS X Part 1: Basic Approaches

In part 1 we confronted the awful truth that, at least without relying upon third-party tools, we must re-create our Active Directory logon scripts (which typically perform actions such as mounting SMB shares and print queues) for our Mac clients.

Today we turn our attention to the Mac OS X Server 10.5 Snow Leopard operating system, and how we can leverage Open Directory, Apple’s implementation of Lightweight Directory Access Protocol (LDAP) directory services, to deploy enterprise login scripts.

(more…)

In this article you will learn some traditional methods for “applying” Active Directory logon scripts to Mac OS X client computers.

Here is the scenario: You manage a Windows Server 2008 Active Directory domain that includes both Windows 7- and Mac OS X-based client computers. Your Active Directory login scripts connect your Windows users to various corporate file shares and print queues. However, you need to make these resources available to your Mac OS X clients as well. How do you accomplish this goal?

Well, what are you waiting for? Let’s get to work at answering that question!

The Bitter Truth

As you know, a login script is a script file that contains a sequence of commands to automate our users’ environments. Naturally, the “logon” part of the login script means that the script file is applied during, well, user domain logon.

(more…)

If you’re running a Wi-Fi network in your enterprise Windows network, 802.1x is certainly the way to go - it moves away from pre-shared keys and lets us centrally manage access to your wireless network. In this article I’ll start to take you through how to set up your own 802.1x Wi-Fi network on a Windows Active Directory domain.

Benefits of using 802.1x for Wi-Fi authentication

If you’re running Wi-Fi to provide access to you enterprise, you need to ensure that it is as secure as possible, and also keep access to the wireless network manageable. At home you probably use a pre shared key (PSK) to grant/restrict access to the wireless network, while this is fine for a network with only a handful of client devices, we need something a bit more durable in the enterprise – Imagine having to change the key on 100+ workstations when a disgruntled employee leaves your business! Using 802.1x / WPA2-Enterprise technology we can control access to our wireless network in a much more granular fashion, by selecting groups of users or computers from active directory that will be granted access – if a user’s AD account is disabled, so is their ability to access the wireless network. We can also use group policy to push out the Wi-Fi settings, completely centralising all aspects of you wireless network deployment. (more…)