Authentication

This topic could get huge, so let's restrict it to the modes of authentication supported by IIS. They are:

Anonymous - a token is created in IIS to represent all anonymous users with the same anonymous account. The default account is IUSR_NetBIOSNameOfMachine

Basic - credentials are then transmitted in unencrypted Base64-encoded format. This means that they will be sent in clear text. The only way to prevent this is to wrap the credentials using SSL. Since the server receives unencrypted credentials, it can then use them to impersonate the caller and use the same credentials to access network resources.

Integrated windows - uses either NTLM or Kerberos v5. Kerberos is used if the following criteria are met:

The application is using the network service or a domain account (otherwise NTLM used if the application is running under a local user account).

A SPN exists for the domain account used to run the service with which the client is authenticating.

Client and server are W2K+, and are in the same or trusting domain.

NTLM Authentication





Note in the above diagram, the challenge is just a 16 byte random number, so the client then just encrypts it with the password hash of the user and returns it. Then, in step 5, the DC obtains the password hash for the user and then uses it to encrypt the original challenge. If this matches the original response from the client then the DC sends the server confirmation that the user is authenticated.



Kerberos Authentication




Breaking this down further:

1. When a user attempts to log on to client, the kerberos service on the client sends a kerberos authentication request to the KDC. This request will contain user name, service information for which the TGT is requested, and a time stamp that is encrypted with the user password.
2. The DC will decrypt the timestamp with the user password that it gets from AD. If the timestamp is then valid, the user is genuine. The KDC will then create a logon session key, and encrypts the copy with the user password. The authentication service then creates a TGT which includes user info and the logon session key. The authentication service will then encrypt the TGT with its own key and passes both the encrypted session key and encrypted TGT to the client.
3. The client will then decrypt the logon session key using the user password and caches it locally. Also stores the encrypted TGT in its cache. When accessing a network service, the client will send a request to the KDC ticket granting service (TGS) with information that includes the user name, an authenticator message encrypted using the user's session key, the TGT and the name of the service that they want to access.
4. The TGS on the KDC decrypts the TGT using its own key and extracts the logon session key. Using this logon session key it can decrypt the authenticator message (which is usually a timestamp). If this authenticator message is successfully decrypted, the TGS extracts user info from the TGT, and using this user info will create a service session key for accessing the service. One copy of the service session key is encrypted with the user's logon session key, and a service ticket is then created with the service session key and the user info. The service ticket is then encrypted with the server's password. The TGS then sends the encrypted service session key and service ticket to the client.
5. When the client accesses the service, it sends a message to the server containing the authenticator message (timestamp) which is encrypted using the service session key and the service ticket.
6. The server decrypts the service ticket and extracts the service session key, which it then uses to decrypt the authenticator message. It evaluates this. If the authenticator passes the test, the server encrypts the authenticator message using the service session key and then passes the authenticator back to the client. The client decrypts it and if it is the same as the original the service is genuine and the client proceeds with the connection.

Advantages of kerberos

• Mutual authentication - so client is assured that the service is not being impersonated.
• Delegation support - servers that authenticate clients using kerberos can impersonate those clients and use their security context to access network resources.
• Better performance than NTLM.
• In multiple domains, point to point trust relationships are not required.

SPNs
These enable mutual authentication, and allow clients to request tickets to then communicate with a particular service.
SPNs in AD maintain a mapping between the constructed name e.g. MyService/MyServer:1879 and the domain account under which the service you want is running. For this to be impersonated, an attacker would need to disable the real service and remove the actual server from the network. They'd then need to add a new computer with the same name and expose the duplicated service. Since Kerberos v5 uses mutual authentication, the client will not be able to use the duplicated service unless it knows the password for the domain account under which the actual service is configured to run.

Microsoft Secure Desktop

See here http://blogs.msdn.com/b/uac/archive/2006/05/03/589561.aspx for good explanation of how the secure desktop works.

Modifying security settings of GPO directly through SYSVOL

Occasionally you may need to remove some of the security settings applied to a GPO directly.
In this case, navigate to the policy folder in SYSVOL.
Then, inside the policy folder, choose Machine - Microsoft - Windows NT - Secedit and open up the GptTmpl.inf file.
So, for example, to remove all settings associated with services, delete the lines from [Service General Setting] to the end of the last service line.
Saving this file and then opening GPMC (ensuring that the GPMC console is pointing at the same DC that you made the edit on), you'll see that all system service settings have been removed.

When is this useful? Well, if you mess around with the service security settings and decide that you no longer want to touch security of the services through the GPO, it is pretty much impossible to reset to the default permissions without actually explicitly setting the default permissions on the service, at which point you're still controlling access permissions within the GPO.

Group Policy Preferences - Registry Items

 

Specifically focusing on the type of Action that can be selected, and the difference between Update and Replace. Microsoft has the following references to this topic. However, to make it clear the following tests several scenarios under a Replace action compared to an Update action:

Scenario: New registry item defined for HKLM\Software\Newkey. DWORD registry item defined here called NewItem1, with a value of 1.

The Newkey folder does not exist to begin with.

Test	Update	Replace
NewItem1 = 1 defined in GPO.	Registry key and value created in registry	Registry key and value created in registry
Manually add new items into registry under Newkey.	After GPO refresh they remain.	After GPO refresh they remain.
Update GPO so that NewItem1 = 2	Registry updated as well.	Registry updated as well.
Delete NewItem1 from registry.	GPO puts it back.	GPO puts it back.
Manually change NewItem1 = 5 in registry.	GPO changes it back to 2.	GPO changes it back to 2.
Rename NewItem1 to NewItem2 in registry.	GPO creates NewItem1 again, leaving NewItem2 in place.	GPO creates NewItem1 again, leaving NewItem2 in place.
Rename NewItem1 to NewItem5 in GPO.	New item created in registry so that both NewItem1 and NewItem5 are present.	NewItem1 is renamed to NewItem5 in the registry as well.
Delete NewItem1 registry item from the GPO.	Remains in registry.	Deleted from registry.

 

Group Policy Processing - Refresh intervals

Worth having this information to hand as I always tend to forget the default refresh intervals.
They are:

Standard computers - every 90 minutes with a random offset of 0 to 30 minutes. GPO for computers is also updated whenever a restart is performed.

Domain Controllers - every 5 minutes.

This can then be configured differently using GPO:

• Computer Configuration - Administrative Templates - System - Group Policy- Group Policy refresh interval for computers
• Computer Configuration - Administrative Templates - System - Group Policy - Group Policy refresh interval for domain controllers

The refresh interval can be as small as 0 minutes (which means it refreshes every 7 seconds), and as large as 45 days.

Refresh offset times can also be changed for between 0 minutes and 24 hours.

Starting an interactive command prompt as the local system

Occasionally you need to run some operations under the credentials of the operating system itself. For instance, if you lock yourself out of a service security descriptor by emptying the DACL, you'll only be able to run sc sdset .... under the SYSTEM account.

Under XP/2003 and before this could be done by running an interactive command prompt under that account via
at /interactive cmd

Under Vista/2008 this was perceived as a security hole and so running the command prompt interactively was stopped.

The easiest way to accomplish this now is to use psexec.
Once downloaded you can run:
psexec -i -s -d cmd

You can confirm that the subsequent command prompt is running under the SYSTEM account by typing whoami /user in it.

Group Policy Troubleshooting

Windows 7/2008 has a specific event viewer for Group Policy where you can see events focused solely on this.
If you click on the details tab for one of these events, and expand out the System part, you will see an Activity ID. An Activity is defined as something that may spark off several different events. For example, when group policy processing is refreshed, this is a single activity so by filtering on that specific Activity ID you can get all of the events associated with that activity.
Within a single Activity ID you will then see events for each of the GPOs that were processed.

If this is not enough information, you can create log files of all of the GPO processing information.
In the following example I'll set up logging of just group policy preference registry settings:

• Open up local group policy on a machine (this does not appear to feature in domain GPOs).
• Navigate to Computer Configuration - System - Group Policy - Logging.
• Double click the "Configure Registry preference logging and tracing".

Here you can define whether you want informational, warning or error messages (or all 3), where the trace files will be kept and their max size. Remember though that the folder path to the trace files is not automatically created so you need to ensure that the specified folder structure exists for anything to be captured.

Once configured all GPO activity relating to the registry part of GPP will be logged.

From this log file it is easy to see details such as when WMI filters apply or get ignored.

For instance, you will see something like this when a WMI filter is passed:
Starting filter [AND FilterWmi].
Adding child elements to RSOP.
Passed filter [FilterWmi].
Filters passed.

If it fails you'll instead see:
Starting filter [AND FilterWmi].
Adding child elements to RSOP.
Failed filter [FilterWmi].
Filters not passed.