Tag Archives: active directory

Disabling NTLM in your Windows environment

NTLM (NT Lan Manager) has been around for quite some time and is a source of problems for network defenders as there are a number of issues with this form of authentication. NTLM credentials are usually stored in memory and can be easily extracted by an attacker using a tool like Mimikatz and the credentials can be also be used in pass the hash attacks. Tools like Responder can harvest NTLM credentials over the network just by pretending to be that network share a user tried to access within your network. So, getting rid of NTLM should be a priority for many but where do you start?

Even though Kerberos is now the default authentication protocol, most companies and organisations cant simply turn off NTML support. There are a lot of applications and systems that rely on NTML authentication to function properly.

So, what can you do as a security administrator to move away from NTLM? The number one thing is to get the facts on who and what is actually using NTLM for authentication. In Active Directory, there is a specific GPO setting that actually allows you to audit all those NTLM requests that would be blocked if NTLM was not allowed. Those events are logged and can be viewed in the Event Viewer on your domain controller or member server. By enabling this audit trail you can start to see what is actually using NTLM for authentication. If you have large environment with legacy applications my guess is that there will be a lot of entries in that particular log. The GPO as well as the other two GPO’s mentioned later on in this post are located at:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Network Security: Restrict NTLM: Audit NTLM authentication in this domain

You can set the value to audit only domain accounts or all accounts. If you use local accounts, make sure to set the value to all accounts for a complete log of NTLM use in your environment.

Once the GPO is active, the NTLM authentication requests are logged to the operational log located in Application and Services\Microsoft\Windows\NTLM log on every server where the GPO is set.

Second, once you know who and what that uses NTLM in your environment, see if you can migrate them to use kerberos instead, perhaps by using SPN. From personal experience, even really big commercial products sometimes have yet to migrate from using NTLM to Kerberos, some products require an upgrade or configuration changes. It all comes down to knowing which applications are relying on NTLM authentication which you now have a way of logging and find out.

Some applications will probably not be possible to migrate and if you have to keep them running, you can make an exception for just those applications, that is the third step. By allowing an exception, you can allow a particular server ot use NTLM for authentication even if NTLM has been disabled in your domain. This is very useful for minimising your NTLM authentication needs to a minimum. Look at the GPO listed below.

Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain

Now that you know what uses NTLM, have either migrated or made an exception for them, you can finally disable NTLM all together by setting this GPO.

Restrict NTLM: NTLM authentication in this domain

This is the final step required to disable NTLM for your domain all together except for the exceptions you are forced to make for legacy applications. Hopefully you do not have to make any exceptions at all.

Be aware though that if you have missed something, it is a good chance that “something” will break. Also, this is not something you configure on friday morning and expect to be done by friday afternoon, it takes time. However, once complete, you have made it harder for the attackers as NTLM is no longer available as an attack vector at all or at least severely reduced. Kerberos is not without issues either, but that will be discussed in another blog post.

Tired of users who spreads malware using USB devices?

Then perhaps you should get them a USB-device that will teach them a serious lesson, no I am just kidding, let me explain.

A russian security researcher nicknamed Dark Purple seems to be inventing a killer USB device, or more a computer frying USB device. It is an interesting way to use a USB device, thats for sure. You can you read more about it here. It is not for sale, at least not yet, but it is quite fascinating to read about it.

If you wish to employ a little less drastic counter-measures, there are some.

  • Use Active Directory to simply deny the use of USB devices

I know, it sounds impossible, but it is not. It all depends on whether you want to take on the administrative burden of managing exceptions or not. Yes, in a large organisation it will most likely be quite impossible. Even though, it is worth knowing that Active Directory can mitigate the threat from USB devices.

  • Malware Protection Engines

Same as the above actually, the rely on the class ID and serial numbers of the USB devices wether to allow it or deny access. The same administrative burden awaits.

I am not even gonna suggest using superglue on the USB ports since it is almost never an option, but instead say that most important thing you can do about USB devices is training and NOT allowing your users to do their day to day work running with local admin privileges. Then make sure you disable autorun and if possible, never allow code execution on removable devices. Stick with those and the USB threat is at least mitigated. Unfortunately, the USB threat is here to stay and will remain a threat to most organisations for a long time.

Password complexity in Active Directory

Password complexity in Active Directory is something you either switch or off for your entire domain, right? It is right, but that does not mean that you have to enforce password complexity for all of your users. Instead you can use fine grained password policies to map certain password requirements for different users or groups. This kind of policy can not be linked to an OU as a GPO can, it is mapped directly against users or global security groups.

This was introduced in Windows 2008 and is a great way of managing different password requirements for different user groups. It will not let you configure what complexity actually means but there are various other options that you can configure, such as number of login attempts, password length, lockout period and more.

In Windows 2012 a new tool called Active Directory Administrative Center was introduced and this tool contains a GUI for configuring fine grained password policies. Managing fine grained password policies was previously done using either Powershell or ADSI-Edit. Now it can be done with a GUI which makes it easier for you as an administrator.

Password complexity prevents some of the worst passwords from being used, but still it allows a password such as P@ssw0rd as a valid complex password. Password complexity requirements depend on two things, making sure your users know how to construct a good complex password and also allows them to remember it. If those dependencies are not met, your users will most likely choose poor complex passwords or write them down. Either way, password complexity becomes quite useless and in the worst case, gives you a false sense of security.

Read more about Microsofts view on password complexity as well as how to implement fine grained password complexity policies using the Windows 2008 way, or the 2012 way.

Using virtualized domain controllers only

For a long time there has been a question whether it is best practice to have a least one physical server acting as a domain controller even if you are running a virtualized environment. Some say you should, but if you are looking at this issue without having legacy software to deal with, I think you can do with only virtual domain controllers.

This requires a few things of course, one being that your domain controllers must run Windows Server 2012, and that can of course be an issue for many. Second, you need to have a virtualized environment that is distributed and preferably uses HA and DRS in Vmware, but you can do without HA and DRS, they simply speed things up a bit in case of failure. I do not cover Hyper-V in this post, but the idea is basically the same.

Third, your vSphere hosts must be using NTP to sync their time against a reliable source. Time syncing and issues with time drift has been a major concern in virtualized environments for years. One could easily think that you should use Vmware tools to sync your domain controllers with vSphere, but actually you should not. Instead you should set the domain controller that has the PDC role to sync it’s time using NTP (w32time basically) against the same time source as your vSphere hosts. Then let your other domain controllers sync against the PDC. As the PDC role can be moved to different domain controllers, use a WMI filter to make sure that the domain controller that runs as a PDC always syncs time. Thanks to Markus Lassfolk for teaching me this, good tip.

There are two other things I would like to cover in this post, and those being domain controller cloning which allows for the safe cloning of domain controllers instead of having to go through the installation and dcpromo thing. A domain controller may have other software running on it as well as specific settings which would be nice to just keep when deploying an additional domain controller. Again, your Windows Server version must be 2012 for this to work. There are a few steps to do when cloning a domain controller and I will not cover them here. I just want to point out that the possibility exists. For more details about any of this, see the link at the bottom of the post.

Last but certainly not least is the question about what happens when you perform a restore from snapshot on a domain controller? In the past, before Windows Server 2012, this could cause some serious issues. Active Directory keeps track of all the changes it implements, such as adding users and so on, but when a domain controller is restored to an earlier date, that logic fails. It fails because the restored domain controllers simply put use the wrong change numbers, number that the other domain controllers have already marked as used. This means that the domain controllers are out of sync with each other which is not good. So, what has happened with 2012 of Windows Server? With 2012 Microsoft introduced VM-Generation ID, which is a way to keep track of the state of the virtual machine, whether it has been cloned or restored from a snapshot. Active Directory then uses this information to realize if the domain controller is up to date or not, before the domain controller processes transactions. That way, a domain controller which is restored from a snapshot will make sure it syncs all the changes from the other domain controllers before attempting a write operation. This is a great feature which will make life a lot simpler.

As for Vmware, you must be running vSphere and Virtual Center 5.0 update 2 at least, to support this. This is just a brief overview of the concept, but please read the Virtualizing Active Directory Domain Services On VMware vSphere for all the details.

No logon servers available to service the logon request with auto logon

This can happen for a number of reasons, but the main issue seems to be with DNS settings. However, if you have auto logon enabled using a domain account, simply wait. When the message occurs on the screen that “No logon servers available to service the logon request”, Windows will automatically try again after 2 minutes. I have had this issue, but it resolved itself after a 2 minute waiting period.

Of course this is irritating, so what to do if you are sure your DNS settings are correct? Well, try these two GPO settings:

1. Computer configuration -> Administrative templates -> System -> Logon -> “Always wait for the network at computer startup and logon”

2. Computer configuration -> Administrative templates -> System -> Group Policy -> “Startup policy processing wait time”

This value should be set to a value like 120 which is 2 minutes of waiting time.

Do the above, and your domain auto logon error should disappear.