A tech blog by Jason Olson
Periodically it is a good idea to audit/review your user accounts in Active Directory to find unused accounts. This helps find terminated employees you might not know about, or role accounts which aren’t being used anymore. Sometimes you’ll discover temporary accounts which were setup for testing and have been abandoned.
It is very easy to query active directory for this, simply open a command line on your domain controller and enter:
dsquery user -inactive
You’re all set.
No, that’s not bad grammar… It is just a reminder that it is important for all windows systems to have “good time” and all be pulling from an accurate time source. In Active Directory based networks it is critical that all of your systems be no greater than 5 minutes apart from each other. Without this, it can lead to sporadic issues with users being unable to connect to resources on the network.
The best way to configure this for our clients is for the domain controllers to be pulling time from a reliable time source (such as pool.ntp.org) and then for domain servers and workstations to pull from the domain controllers.
Just a reminder about passwords for clients where we have enabled “Passwords must meet complexity requirements”. I received a call today from another tech needing help, and here are the specific criteria:
When this setting is enabled user passwords will have the following requirements:
• The password is at least six characters long.
• The password contains characters from three of the following five categories: English uppercase characters (A ” Z); English lowercase characters (a ” z); base 10 digits (0 ” 9); non ” alphanumeric (For example: !, $, #, or %); Unicode characters.
• The password does not contain three or more characters from the user’s account name. If the account name is less than three characters long then this check is not performed because the rate at which passwords would be rejected would be too high. When checking against the user’s full name several characters are treated as delimiters that separate the name into individual tokens: commas, periods, dashes/hyphens, underscores, spaces, pound-signs and tabs. For each token that is three or more characters long, that token is searched for in the password, and if it is present, the password change is rejected. For example, the name “Erin M. Hagens” would be split into three tokens: “Erin,” “M,” and “Hagens.” Since the second token is only one character long it would be ignored. Therefore, this user could not have a password that included either “erin” or “hagens” as a substring anywhere in the password. All of these checks are case insensitive.
In this specific instance, the problem was that the user was trying to use part of their name in their password.
Checking for strength:
By default in Windows 2003, a roaming profile only assigns permissions to the named user and the local system account, the administrators do not have permissions to this folder, and there is a security check before loading the folder that indeed only those two accounts have access to that profile. Additionally the user is the owner of the folder and all sub-folders/content.
When troubleshooting profile problems, you will need to click on the advanced tab under security and take ownership of the folder, which you can do as a local administrator, however once you do this the profile may break. After that, you will typically assign the administrator group full access to the folder.
Once you are done, please be sure to remove the administrator under security, as well as change the ownership of the folder and sub-folders/content back to the named user. Otherwise you may experience problems with the profile.
This default behavior can be changed via Group Policy or via the Registry, which will permit additional users, and bypass the security check, but it is not recommended.
This is an except and overview of the detailed article at: http://technet.microsoft.com/en-us/library/cc757013(WS.10).aspx
Here is a quick one for today – we received a call from an executive that they are immediately and are in the process of terminating the employment of an employee. They wanted their account disabled. A junior technician disabled the account and was done. However, what caught the customer by surprise was that the user was still on their computer working – how could this be?
Basically Windows workstations cache the credentials and the only time it will try to authenticate is when it tries to use a network resource, at which point their network access will be denied. However, there is nothing you can do to a user account to prevent them from accessing their workstation if they are already logged on and/or are off the network. The only way to lock them out of their computer is to reboot the system or otherwise force them to authenticate to the domain controller. On that note, what about remote laptop users. Say it is a sales person with a desktop and a laptop. And they left the laptop at home, how do you prevent access? You can chose to disable cached credentials so they must always authenticate against the domain controller via a VPN or another method.
Enjoy!
