I just had a call from a client who was concerned that he couldn’t add client access licences (CALs ) for his new Exchange Server in the Licensing administrative tool. I’ve never really used this tool so I had to do some research before I could answer his question. Microsoft knowledge base article 824196 describes the license logging service (LLS) but the key points to note are all in the article summary:
- LLS was originally designed to help administrators manage licenses for Microsoft server products that are licensed on a per-server basis (the server CAL model).
- LLS was introduced with Windows NT Server 3.51 but it is disabled by default in Windows Server 2003.
- Because of design constraints and evolving licencing terms, LLS cannot provide an accurate view of the total number of per-user CALs purchased, compared with the total number of CALs that are used on a single server or across the enterprise.
- LLS will not be included in future versions of the Windows operating system.
Basically, it seems that LLS is a hangover from Windows NT and nowadays there is no real reason to use it in Windows Server 2003.
A few weeks back I was at a Microsoft TechNet UK event where John Howard demonstrated the free tools provided by Microsoft to troubleshoot and diagnose account lockout and management issues for Windows NT, 2000 and 2003:
- acctinfo.dll (also included with the Windows Server 2003 resource kit tools) is installed using the
regsvr32 acctinfo.dll command and extends the functionality of the Active Directory users and computers MMC snap-in, with an Additional Account Info page on the user object properties to assist in isolating and troubleshooting account lockouts and to change a user’s password on a domain controller in that user’s site. This extra page contains a variety of information, including:
- The last time the password was set.
- Domain password policies.
- Password expiration date.
- Lockout status.
- Last good and bad logons.
- alockout.dll can be used to create a log file to assist in diagnosing the cause of account lockout problems. It should be copied to the %systemroot%\system32 folder on the computer experiencing the lockout problems (usually a user’s workstation) and the
appinit.reg script run to add alockout.dll to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs key. Once the computer is restarted and an account locked out, a log file called alockout.log will be created in the %systemroot%\debug folder. This tool should not be used on servers that host network applications or services (in particular it should not be used on Exchange servers, because it may prevent the Exchange store from starting).
aloinfo.exe displays the password age for user accounts to allow determination of accounts which are about to expire in order to anticipate problems before they occur. It is a command prompt tool, with two options:
aloinfo /expires /server:servername returns a list of user names followed by the age of their password.
aloinfo /stored returns a list of services and the accounts used as well as mapped drives for the currently logged on user.
enablekerblog.vbs can be used as a startup script to enable Kerberos logging (as described in Microsoft knowledge base article 262177) on all clients running Windows 2000 or later (it actually sets HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\Kerberos\Parameters\LogLevel to 1, which once removed will disable Kerberos logging). When looking at Kerberos authentication issues, it is worth checking to see that the Kerberos key distribution center service is started on all domain controllers, that time synchronisation is working correctly from the PDC emulator at the root of the forest down to all client machines (Kerberos authentication will fail if the time is skewed by more than 5 minutes by default), and that both Kerberos and LDAP have service location records defined in DNS (check with
nslookup _kerberos._udp.domainname and
eventcombmt.exe (also included with the Windows Server 2003 resource kit tools) searches event logs on multiple computers and collects event records matching specified criteria (useful for gathering specific events from event logs on several different computers to one central location).
lockoutstatus.exe (also included with the Windows Server 2003 resource kit tools) determines all the domain controllers that are involved in a lockout of a user in order to assist in gathering the logs. It can be useful in identifying if lockout problems are arising from Active Directory replication issues, as typically this means there will be two or more entries for different domain controllers.
nlparse.exe can be used to extract and display desired entries from the netlogon log files generated by
lockoutstatus.exe or alockout.dll, parsing the logs for specific return status codes and directing the output to a comma-separated value (.CSV) file. It is also possible to enable netlogon debug logging with the
nltest.exe Windows support tool, or via the registry, as described in Microsoft knowledge base article 109626.
Implementing and troubleshooting account lockout (WindowSecurity.com).
Microsoft account lockout and management tools.
Microsoft has published the Windows NT 4.0 and Windows 98 threat mitigation guide, which identifies security issues in networks that include computers running Windows NT 4.0 and 98, explaining the best hardening strategies that an organisation can use until they are able to upgrade these operating systems.
One of the shortcomings of the
net user command in Windows is the inability to set the password never expires flag on an account (account expiry options can be set, but not password expiry and the full syntax is described in Microsoft knowledge base article 251394).
There are 13 flags on an NT SAM/Active Directory user account which may be manipulated using VBScript (for further details of the 13 flags, see Microsoft’s sample scripts or there is some useful information about the object model at the Motobit Software website).
This script can be used to set the password never expires flag on a specified account. I’ve tested it against the local SAM database on a Windows XP PC, but in theory it should work on all versions of Windows NT (2000, XP, 2003 Server, etc.) and also against Active Directory accounts if you run it on a domain controller.