Kerberos Policy Settings

Kerberos is the authentication protocol used in a Windows domain environment to authenticate logons and grant accounts access to domain resources. An account can be a user or a computer because computers must also authenticate to the domain. Kerberos provides mutual authentication between a client and server or between two servers. Mutual authentication means the identity of both parties is verified. Kerberos is also the basis for authorization to network resources in a Windows domain.

Kerberos uses shared secret key encryption to ensure privacy, and passwords are never sent
across the network. Kerberos authentication and authorization uses the following components:
• Key Distribution Center—Every domain controller is a Key Distribution Center (KDC), which uses the Active Directory database to store keys for encrypting and decrypting data in the authentication process. The keys are based on an account’s encrypted password.
• Ticket-granting tickets—When an account successfully authenticates with a domain controller (a KDC), it’s issued a ticket-granting ticket (TGT). A TGT grants the account access to the domain controller and is used to request a service ticket without having to authenticate again.
• Service tickets—A service ticket is requested by an account when it wants to access a network resource, such as a shared folder. It contains the account’s access information, such as group memberships. A service ticket is sometimes called a “session ticket.”
• Timestamps—A timestamp is a record of the time a message is sent. Timestamps are used in Kerberos to determine a message’s validity and prevent replay attacks. When a computer receives a Kerberos message, the timestamp must be within 5 minutes of the current time on the receiving computer. The value of 5 minutes is the default and can be configured in Kerberos policy settings.

steps that take place when a user attempts to log on to a domain:

1. A user enters his or her username and password at a logon prompt.
2. A message is created containing the username and domain name. Part of the message is encrypted by using the shared secret key, which is based on the user’s password. The encrypted message includes a timestamp.
3. A domain controller (a KDC) receives the message and retrieves the password from the Active Directory database for the username in the message. It then decrypts the message’s encrypted part by using the user’s password. If the message is decrypted successfully, the user’s identity is verified. The timestamp is also decrypted. The time on it must be within the value specified in the Kerberos Policy setting “Maximum tolerance for computer clock synchronization” (5 minutes by default) for the server’s current time. If the user’s identity is verified and the timestamp is valid, the user is authenticated.
4. The domain controller sends the user a ticket-granting ticket (TGT), which includes a time- stamp that authorizes the user to access the domain controller and request service tickets. The timestamp is again checked for validity. The user account caches the TGT information for future communication with the domain controller. A TGT is valid until it expires or the user logs off. By default, it’s valid for 10 hours.

Example of Service ticket

For example, a user has just logged on to the domain and wants to access a shared folder on a file server. For this example, the KDC is DC1, and the file server is FS1. All messages include a timestamp, which is validated.
1. The user attempts to open a shared folder on FS1. The client computer sends a service ticket request to DC1 that includes the original TGT issued when the user authenticated and the name of the requested resource.
2. DC1 validates the request and sends a service ticket to the client, which contains the user’s access information, including group memberships.

3. The client sends the service ticket to FS1, which validates the ticket and then checks the
user’s permissions, based on the access information in the ticket.
4. If the user has permissions to the resource, the user is granted access, and the service ticket is cached on the client computer. Future requests to access FS1 are sent directly to FS1, using the cached service ticket. A service ticket is valid until it expires or the user logs off. By default, it’s valid for 10 hours.

Kerberos policy settings:

• Enforce user logon restrictions—If this setting is enabled (the default), the KDC validates every request for service tickets against the rights granted to the requesting account. This process takes extra time, and although it’s somewhat more secure, it might slow access to network resources, so it can be disabled if needed.

• Maximum lifetime for service ticket—This setting specifies in minutes how long a service ticket can be used before a new ticket must be requested to access the resource the ticket was granted for. The default is 600 minutes or 10 hours. The minimum allowed value is 10 minutes, and the maximum value is equal to the “Maximum lifetime for user ticket” setting.

• Maximum lifetime for user ticket—This setting is the maximum amount of time in hours a TGT can be used before it must be renewed or a new one must be requested. The default value is 10 hours.

• Maximum lifetime for user ticket renewal—This setting, specified in days, is the maximum period during which a TGT can be renewed. The default setting is 7 days. In this period, a TGT can be renewed without having to go through the full authentication process. After this period has expired (or the account logs off), a new TGT must be requested.

• Maximum tolerance for computer clock synchronization—This setting determines the maximum time difference allowed between a Kerberos message timestamp and the receiving computer’s current time. If the time difference falls outside this limit, the message is considered invalid. The default is 5 minutes. Timestamp messages are corrected for time zone, so it’s important to have the correct time zone set on all computers in the domain and have the domain controller clocks synchronized with a reliable source. By default, member computers are synchronized with the DC’s clock.

Password Settings Objects (Fine-grained Account policies , fine-grained password policies, PSO)

Another term for PSOs is “fine-grained password policies.”

For more info, check here: http://frankfu.click/microsoft/group-policy/group-policy-basic/

Service accounts

A service account is a user account that Windows services use to log on to a computer or domain with a specific set of rights and permissions.

A service needs to log on with a service account if it runs in the background because a user doesn’t start it. When a user starts an application that runs interactively, the application uses the user’s credentials to access the system, so there’s no need for a service account.
In the past, two types of accounts have been used as service accounts: built-in and administrator-created. Built-in service accounts have few options for an administrator to configure different rights and permissions for different services, and the accounts are shared among several services. The OS manages the password for built-in service accounts automatically, much like the password for a computer account.

Starting in Window Server 2008 R2, Microsoft introduced managed service accounts (MSA) and group managed service accounts(gMSA) . A managed service account enables administrators to manage rights and permissions for services but with automatic password management. An MSA can be used on a single server. A group managed service account provides the same func- tions as managed service accounts but can be managed across multiple servers, as in a server farm or a load-balancing arrangement.

Working with Service Accounts

There are three built-in service accounts, each with its own rights and permissions:

• Local Service—Intended primarily for services and background applications that need few rights and privileges. This account runs as a member of the local Users group or the Domain Users group in a domain environment. If network access is needed, Local Service runs as an anonymous user.
• Network Service—Intended primarily for services that need local and network access. This account runs as a member of the Users or Domain Users group and accesses the network as an Authenticated User member, which provides more privileges than for an anonymous user.
• Local System—This account should be used with caution because it has privileges that are in some ways more extensive than the Administrator account when accessing local resources. When accessing network resources, the Local System account uses the local computer account’s credentials.

The advantage of using a built-in service account is that no management is needed, and the password is managed automatically. However, if a service requires more privileges than the Local Service or Network Service accounts have, you might need to use the Local System account, which in all likelihood offers more privileges than the service needs. The Services MMC shows services using all three types of built-in service accounts.

Using Administrator-Created Service Accounts

An administrator-created service account is simply a regular user account that you create for the purpose of assigning a logon account to a service. By using a regular user account, you can assign the service’s logon account only the rights and permissions it needs to run correctly. Here are some guidelines to keep in mind when you use a regular user account as a service account:

• Assign only the rights and permissions the service needs.

• Use a very complex password because a user doesn’t use this account to log on.

• Remove the account from the Users or Domain Users group if it doesn’t need that group’s rights and permissions.

• Set the password to never expire. If you leave the account subject to regular password policies, the service stops working if you fail to change the password when it expires. However, setting this option creates a security risk, which is why using managed service accounts, discussed next, is better.

• Never use the account to log on interactively.

• Use one account per service.

Service Principal Names

A service principal name (SPN) is a name that uniquely identifies a service instance to a client. Multiple instances of a service can be installed in a Windows Active Directory forest, and each instance must have a unique SPN. A service instance can also have multiple SPNs if clients can use different names to access it. An SPN is required for Kerberos authentication, and although administrators had to manage SPNs in the past, they’re managed automatically for managed service accounts in a Windows Server 2008 R2 or later domain functional level.

When a client wants to connect to a service, it finds the service based on the SPN, which consists of the following elements:

• Service type—The service type is usually something like LDAP, MSSQLSvc, or HTTP.

• Instance name—This element is usually the hostname or IP address of the host running the service.

• Port number—The port number, such as 80 for HTTP or 389 for LDAP. If the service uses the standard port number, you don’t need to specify this element.

• Service name—This element is usually the DNS name of the host providing the service. The service name and instance name are often the same, in which case the service name isn’t needed.

The SPN is specified with the following syntax:
service type/InstanceName:port number/ServiceName

e.g. HTTP/www.csmtech.local

If you’re using user accounts rather than managed service accounts, you might need to manage SPNs, but in most cases they’re created automatically. However, if you do have to change an SPN because, for example, a computer name changes or you need clients to be able to connect with a different name, you can do so with the setspn.exe command:
setspn.exe -s service/InstanceName ServiceAccount

For example, if you want to set the SPN for a service named LDAP on a server named ldsServ1.csmtech.local, using port 2300 and a service account called LDAPsvc, use the following command:
setspn.exe -s LDAP/ldsServ1.csmtech.local:2300 LDAPsvc

Working with Managed Service Accounts

An MSA is a new type of object in Active Directory that has the following attributes:

• Has a system-managed password

• Has automatic SPN support

• Is tied to a specific computer

• Can be assigned rights and permissions

• Can’t be used for interactive logon

• Can’t be locked out

The requirements for using an MSA include the following:

• It must be created in an Active Directory domain.

• The computer on which the MSA is used must be Windows 2008 R2 or Windows 7 or later.

• The Active Directory module for PowerShell must be installed.

• For automatic SPN support, you must be using a domain functional level of Windows Server 2008 R2 or later.

You create and manage MSAs with PowerShell; there’s no GUI tool for working with them. Follow these steps to use MSAs:

1. Create an MSA in Active Directory in the Managed Service Accounts folder (which can be seen in Active Directory Users and Computers if you enable Advanced Features on the View menu). You can also set one or more SPNs on the account when you create it by using the -ServicePrincipalNames option. To create an MSA named LDAPsvc, use the following PowerShell cmdlet on a DC:
New-ADServiceAccount -Name LDAPsvc

2. Associate the MSA with a member computer that will use the MSA. To allow a computer named ldsServ1 to use the service account, run this cmdlet on a DC:
Add-ADComputerServiceAccount -Identity ldsServ1 -ServiceAccount LDAPsvc

3. Install the MSA on the target computer by using the following cmdlet on the computer running the service. If the computer isn’t a domain controller, you need to install the Active Directory module for Windows PowerShell.
Install-ADServiceAccount -Identity LDAPsvc

4. Configure the service on the target computer using the MSA. On the computer running the service, open the Services MMC, open the service’s properties, and click the Log On tab. Specify the name of the account in the format domain\MSAname, or click Browse to select the account. Clear the password fields because the password is managed by the OS, and then stop and start the service.

Other PowerShell cmdlets you can use to work with MSAs include the following:

• Set-ADServiceAccount—Change an existing MSA’s settings.
• Get-ADServiceAccount—Show an MSA’s properties.
• Remove-ADServiceAccount—Delete an MSA.
• Reset-ADServiceAccountPassword—Reset the MSA’s password on the computer where the account is installed.
• Uninstall-ADServiceAccount—Uninstall the account on the computer where the account is installed.
• Test-ADServiceAccount—Test the account to be sure it can access the domain with its current credentials or can be installed on a member computer.

Working with Group Managed Service Accounts

Managed service accounts can be used on only a single server. If a service is running on multiple servers, as in a server farm or load-balancing configuration, you can use a gMSA and still get all the benefits of an MSA. Group managed service accounts can be used only on computers running Windows Server 2012 or later with a domain functional level of Windows Server 2012.
gMSAs aren’t actually different types of accounts from regular MSAs, but when you create them, you must use an additional option to specify which servers can use the account.

To create a gMSA named LDAPsvc that’s available to ldServ1, ldsServ2, and ldsServ3 (all members of the ldsServers global group),

New-ADServiceAccount -Name LDAPsvc -PrincipalsAllowedToRetrieveManagedPassword ldsServers

You can also specify which servers can use the account after it’s created by using the Set-ADServiceAccount cmdlet.

After the account is created, you need to go to each server using the account and run the Install-ADServiceAccount cmdlet, using the same syntax described in the preceding section.

Virtual Accounts

Virtual accounts, introduced in Windows Server 2008 R2, are the simplest service accounts to use because you don’t need to create, delete, or manage them in any way. Microsoft refers to them as “managed local accounts.” To use them, you simply configure the service to log on as NT Service\ServiceName with no password  because Windows manages the password. The service name isn’t necessarily the name displayed in the Services MMC. You can find the service name in the General tab of the service’s Properties dialog box.

Virtual accounts access the network with the credentials of the computer account where they’re used. If the service needs to access network resources, you give permission for that resource to ComputerName$ (replacing ComputerName with the name of the computer). In most cases, it’s better to use MSAs than virtual accounts if the service must access network resources because giving the computer account permission can be a security risk. For purely local services, however, virtual accounts are simple to use and effective.

Kerberos Delegation

Kerberos delegation is a feature of the Kerberos authentication protocol that allows a service to “impersonate” a client, relieving the client from having to authenticate to more than one service. In other words, if a client has authenticated to a service successfully, the service can then use the user’s credentials to authenticate to another service on the client’s behalf.

For example, say a user logs on to an Outlook Web Access account. The user authenticates with the Outlook Web Access service, but the user’s actual mailbox is on another server. Without delegation, the user would then have to authenticate to the server where the mailbox is located, too. With Kerberos delegation, the Outlook Web Access service can perform the authentication on the user’s behalf.

Kerberos delegation is available when you use a domain account as a service account, and the account has been assigned an SPN. The Delegation tab is added to the account’s Properties dialog box; this tab isn’t available for a regular user account that hasn’t been assigned an SPN.

The Delegation tab has three main options:

• Do not trust this user for delegation—The account can’t use Kerberos delegation.

• Trust this user for delegation to any service (Kerberos only)—The account can be used for delegation to any service but only by using the Kerberos authentication protocol.

• Trust this user for delegation to specified services only—This option is called constrained delegation because it limits the delegation to specific services running on specific computers. Constrained delegation can be limited to the Kerberos protocol, or you can specify using any authentication protocol.

Kerberos delegation is a convenient feature, especially when using multitiered applications where users connect only to a front-end interface, such as a Web server. It relieves administrators of having to find a way for users to authenticate to servers that might not be directly accessible to them.

Create users in bulk:

PS C:\> Import-Csv C:\data\new-users.csv | New-ADUser -PassThru | `
Set-ADAccountPassword -Reset `
-NewPassword (ConvertTo-SecureString -AsPlainText “Pa$$w0rd” -Force) `
-PassThru | Enable-ADAccount

The command takes the string “Pa$$w0rd” and converts it from plain text to a secure string so that it can be used by the –NewPassword parameter of the   Set-ADAccountPassword cmdlet  The –Force parameter is needed to suppress the confrimation prompt generated by use of the –AsPlainText parameter