Resolving Active Directory Account Lockouts

Account lockouts can be a real pain to fix if you don't know where the lock is coming from. In these days of mobile computing very few users restrict themselves to a single PC or device. Often IT departments have to allow multiple devices to utilise the same user account credentials whether that be on the company Desktops, Laptops, Smartphones or even home user equipment. The problem is that when you have so many devices it gets a bit tricky to see where the lock has come from and users inevitably begin to think there may be some kind of conspiracy against them when their account keeps locking; even if it is their fault!

Tools Required

To perform all steps in this guide you will require a few tools:
A PC with Admin Pack installed (for Active Directory access) and Acctinfo.dll installed(http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=18465)


Causes of Account Lockouts

The most obvious scenario is that the user is continuously inputting the incorrect username/password combination - but that's far to easy. Other scenarios include:

• The user has changed passwords once they have logged on but have not logged back on again to re-sync their account.
• A stored username/password in a program, perhaps one that requires separate proxy authentication is requesting access to the Internet and supplying an incorrect password.
• A third party device, such as an Iphone connecting to webmail via RPC over HTTP with the incorrect password stored.
• The user has mapped a network drive on a different machine using their credentials and choose “Save Password” option, which has now expired.
• A scheduled task running with an invalid password.

Finding Where the Account Lockout Originated

The first thing is to make sure you know where the account lockout is coming from. Use Active directory with the ACCTINFO.DLL tab and check the time of the last “bad logon”.

Clicking on “Account Lockout Status” will bring up a list of domain controllers, allowing you to ascertain which domain controller the user locked out on first.

Right click the domain controller the account locked out on and choose event viewer, then organise by user and click on the username. You will see a "Failure Audit" at the time of lockout.

 

You will then be given the name of the machine the account has locked out on as well as an Idea what program may have caused the lock, see “Logon attempt by” field.

Sometimes this can be a very generic system process which will result in you having to perform further troubleshooting steps on the user’s machine.

Finding the Cause of the Lockout on the User Machine

Finding the cause of account lockouts on the local machine can be quite difficult due to the number of potential causes of this problem but some general advice is as follows:

• Clean out the Temporary Internet Files and stored passwords in Internet Explorer.
• Clean out the windows credential manager by running "Control keymgr.dll" from the run prompt and deleting all stored passwords.
• Check the users “My Computer” for drive mappings created by the user; if there is anything out of the ordinary remove the mapping.
• Check for unusual software that may require individual proxy server configurations such as Google Earth, or any programs that perform periodic updates.

Drastic Measures if you still can't find the lock

From the Account lockout tools copy alockout.dll to the user’s c:\Windows\System32 folder. Remotely connect to the users registry using regedit and navigate to this key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Windows

Create a new REG_SZ key called "AppInit_DLLs" and set its value to “alockout.dll"

Now restart the PC and wait for the account to lock out again. Once it locks check the C:\WINDOWS\Debug folder for a file called “Alockout.LOG”.

If you open this file with Notepad you should see a list of applications which attempted to pass network credentials along with details on which was successful and which failed. Check what time the users account locked out in ACCTINFO.DLL and the look for the corresponding entry on the list, this will be the application causing the problem.

The final step is to find this application on the user’s computer and find a way to either remove the cached credentials or in worst case scenario it may be necessary to remove the program all-together.

SCCM Operating System Deployment Task Sequences

In  the past few months my business has been working on the move away from XP/Altiris to a Windows7/SCCM 2007R3 environment. I was working closely with an outside contractor to get the infrastructure in place and getting SCCM up and running, but before this was even completed I was tasked to begin considering how to perform operating system deployment (OSD). Looking at SCCM from a newbie perspective I will talk about the challenges I faced in getting my OSD to work successfully.

After some investigation I soon found out that SCCM offers multiple ways to deploy an operating system to new machines and also machines already on your network. So far I have tested and implemented the following:

• PXE boot environment with unknown computer support - I have put a password on this at the moment so that users can't unknowingly image a newly added machine. This is useful where you might be in a scenario where you unbox and build multiple machines at one time, you really don't want to be messing around writing down MAC addresses to import for hundreds of PCS at a time.

• Bootable WinPE CD/USB stick, this method means you don't have to enable a PXE server on the network and is useful in environments like mine that already have multiple PXE servers. Unfortunately this means you will have to manually import the machine MAC address and put it into the OSD collection before it can be installed.  The disadvantage here is that you end up with a duplicate system in SCCM once it is renamed, but providing you have scavenging set up it should disappear reasonably quickly.

• If the PC you image is an existing PC with a previous OS (WinXP) you can simply for an install of the SCCM Client and then put the machine into the OSD collection. This can be very handy, but again it will create a duplicate machine in SCCM, which will be marked as "obsolete". This appears to be by design to avoid endless build cycles.

• Stand-alone task sequence media on CD/USB stick for the entire task sequence onto a DVD - this method works well for remote/small offices that don't have any server infrastructure, but SCCM task sequences can be rather large, in my case I need 3 DVDs worth to fit my standard image. It looks like high capacity USB flash drives are more feasible in this scenario.

Task sequence media is easily created, simply go to "Operating System Deployment" > "Task Sequences" > select your OSD task sequence and click "Create Task Sequence Media"

You can then select the type of media to create or create an ISO of the image for later use. Coming from an Altiris background I have to say I was very impressed easy this was and how well this solution worked.

I've got ahead of myself a little bit here, the largest part of this was the creation of the task sequence to begin with. I was fortunate that I had a base Windows 7 install.wim. Unfortunately it had only been tested on a handful of different models of PCS. After an evaluation of my asset management database I found that I actually had 11 distinct types of desktops that would support Windows7 in my environment. At this point I got a bit of headache, thinking back to Altiris and the multiple images for Windows XP. I wanted to get away from this and have "one image to rule them all".

One Image to Rule them All

The first thing I did was to test my Boot.wim with each device to ensure two things:

1. Each device could successfully boot to WinPE image.
2. By pressing F8 during PE boot and using the command prompt I could verify that WinPE could see the Hard Disk Drive and Network Card.

Fortunately all devices booted to WinPE without issue, but some were missing the network card driver or storage controller. These would have to be injected to the Boot.wim before we could continue. This can either be done by mounting the image using DISM in Microsoft MDT2010, or in SCCM you can go to "Boot Images" > right click on your boot.wim and go to properties, then press the "Windows PE" tab, press the "Sun" icon and then select the drivers you want to be injected. In order for the drivers to appear on this list you will have to firstly import them.

Now I had a working preinstall environment I could then begin testing deploying my main image. The next thing I done was to visit the manufacturer websites and download all existing drivers for the products I wanted to move to Windows 7. I downloaded the drivers for eleven models in total and stored them neatly on my SCCM server, sorting by model and device type. I then had another decision to make.

Order Vs Chaos

After some research it would appear there are two ways to approach driver management. One being "Chaos" whereby you simply import every driver possible and then allow every machine being built to scan then entire available driver database.  The "Order" solution is a very controlled environment whereby you import drivers for each model into a package and apply only that specific package to its relevant model. Being lazy I liked the sound of Chaos, but In practice I found this method to be much slower at building machines; the more drivers there are available the longer Windows takes to sort through and determine which driver is the most suitable.

Fortunately, SCCM makes importing drivers very easy. Simply create a new folder in the drivers section, right click, select import and browse to the location you stored the drivers for that specific model.

I was surprised to find that even when you select x64 drivers only that the packages also seem to contain XP, Vista, x86 drivers too. If you are going to import the packages for an x64 image like mine make sure to remove these drivers.

Either click new package to create a specific package or select an existing package, ensure to tick "Update distribution points when finished" to ensure your drivers get sent to PXE for immediate use.

Trying to adopt the "Order" method was causing me to run into issues. SCCM doesn't like it when you try to import a duplicate driver. It turns out that it's quite common for several HP laptops and desktops to share the exact same hardware, this was causing an error when trying to import this driver even although I just wanted to put that driver into my specific machine package. To get around this I installed patch KB2213600 which will allow SCCM to import duplicates.

With this method I was left with eleven different driver packages which I could apply. The next question would undoubtedly be how does SCCM know to apply that specific driver package? 

Using  a WMI query to select the model name from the system bios as a condition for installation allows only this package to be installed.

It's not only drivers that benefit from this functionality, what about the differences in software between laptops and desktops? You won't want to install certain software such as a VPN client or a mobile connectivity suite on your desktops!  Luckily there are a couple of easy ways around this.

Below shows and example using the "IsLaptop" variable - note that this is only availble when you have MDT integration. Before checking for this variable you will need to perform a "Use Toolkit Package" and  a "Gather" from the MDT menu. 

This also seems to work bothways. IE you can use "isDesktop"

You can also check for the presence of a battery.

Hardware Based Applications

When I had created all my packages and performed some test builds I noticed that there were some systems that just wouldn't install the drivers without its accompanying piece of software. ATI and Nvidia graphics packages seem to be the worst culprits, as both rely on their "Catalyst control centre" and "Nvidia Control Panel" to offer any advanced functionality. Bluetooth drivers were also the same as each device requires its own custom Bluetooth stack. I read elsewhere that these types of programs were called "Hardware based applications" being that they blur the lines between drivers and software. I found the simplest way to deal with these is to treat them like any other piece of software. Referring to the suppliers documentation *cough* and after fiddling about I found all the required silent install switches.

So far I'm about 90% there towards finalising the build. There are always little tweaks to go back and add. The other big part of this will be a brand Active Directory/Group policy re-structure which will go a long way to configuring this build. I don't want to add too many registry fixes into the build, but inevitably these will keep coming. At this point my OSD task sequence looks like this.

Please note that grey items are currently disabled experimental steps I was toying with. In the end I don't think I really need these. Using the above I can perform a zero touch installation on a new out-of-box PC or reimage an existing machine by simply dropping the PC into the OSD collection.

Like I said, I'm still an SCCM newbie and I would appreciate any advice on improving this.

Andrew