Security for the adventurous https://docs.microsoft.com/archive/blogs/secadv/feed.xml Just another Technet site Thu, 01 Mar 2018 17:33:03 GMT en-US hourly 1 Using Protected Groups to Secure Privileged User Accounts https://docs.microsoft.com/archive/blogs/secadv/using-protected-groups-to-secure-privileged-user-accounts Thu, 01 Mar 2018 12:33:02 GMT https://blogs.technet.microsoft.com/secadv/?p=3145 Benefits Members of the Protected Users group who are signed-on to Windows 8.1 devices and Windows Server 2012 R2 hosts can no longer use:
  • Default credential delegation (CredSSP) - plaintext credentials are not cached even when the Allow delegating default credentials policy is enabled
  • Windows Digest - plaintext credentials are not cached even when they are enabled
  • NTLM - NTOWF is not cached
  • Kerberos long term keys - Kerberos ticket-granting ticket (TGT) is acquired at logon and cannot be re-acquired automatically
  • Sign-on offline - the cached logon verifier is not created
If the domain functional level is Windows Server 2012 R2 , members of the group can no longer:
  • Authenticate by using NTLM authentication
  • Use Data Encryption Standard (DES) or RC4 cipher suites in Kerberos pre-authentication
  • Be delegated by using unconstrained or constrained delegation
  • Renew user tickets (TGTs) beyond the initial 4-hour lifetime

Requirements

The PDCe role should be hosted on a domain controller that runs Windows Server 2012 R2 to create the Protected Users security group. Hosts must run Windows 8.1, Windows Server 2012 R2 or later to provide client-side restrictions for Protected Users. Members of this group have no additional protection if they are logged on to a device that runs a version of Windows earlier than Windows 8.1. Domain controller-side restrictions for Protected Users require the domain functional level to be Windows Server 2012 R2 or later.

Action

Simply add users to the group, using UI tools such as Active Directory Administrative Center (ADAC) or Active Directory Users and Computers, or a command-line tool such as Dsmod group, or the Windows PowerShellAdd-ADGroupMember cmdlet To track events, enable the following logs on domain controllers:
  • Microsoft-Windows-Authentication/ProtectedUserFailures-DomainController
  • Microsoft-Windows-Authentication/ProtectedUserSuccesses-DomainController

Impact

Members of the Protected Users group must be able to authenticate by using Kerberos with Advanced Encryption Standards (AES). The built-in administrator as well as any account, which has a password that was changed at a domain controller that runs an earlier version of Windows Server, is locked out. Therefore, follow these best practices: Do not test in domains unless all domain controllers run Windows Server 2008 or later. Change password for each user before adding the account to the Protected Users group or ensure that the password was changed recently on a domain controller that runs Windows Server 2008 or later. Membership of the Protected Users also affect the Kerberos TGT lifetime and renewal times:
Kerberos Policy Default Protected Users
Maximum lifetime for user ticket 10 hours (600 minutes) 240 minutes
Maximum lifetime for user ticket renewal 7 days (10,080 minutes) 240 minutes
 

Validation – Success

Connecting to server using RDP. Using the DNS name of the server results in Kerberos being used for authentication Log Name: Microsoft-Windows-Authentication/ProtectedUserSuccesses-DomainController Source: Microsoft-Windows-Kerberos-Key-Distribution-Center Date: 2/5/2018 10:38:39 PM Event ID: 303 Task Category: None Level: Information Keywords: User: SYSTEM Computer: RootDC01.Litware.com Description: A Kerberos ticket-granting-ticket (TGT) was issued for a member of the Protected User group. Account Information:     Account Name:        BBanner     Supplied Realm Name:     User ID:            LITWARE\BBanner Authentication Policy Information:     Silo Name:     Policy Name:        AuthPol - Tier_0_Accounts_Devices     TGT Lifetime:        240 Device Information:     Device Name: Service Information:     Service Name:        krbtgt/LITWARE     Service ID:        LITWARE\krbtgt Network Information:     Client Address:        ::ffff:10.10.20.24     Client Port:        49204 Additional Information:     Ticket Options:        0x78     Result Code:        0x0     Ticket Encryption Type:    0x7     Pre-Authentication Type:    2 Certificate Information:     Certificate Issuer Name:     Certificate Serial Number:     Certificate Thumbprint: Certificate information is only provided if a certificate was used for pre-authentication. Pre-authentication types, ticket options, encryption types and result codes are defined in RFC 4120.   Log Name: Microsoft-Windows-Authentication/ProtectedUserSuccesses-DomainController Source: Microsoft-Windows-Kerberos-Key-Distribution-Center Date: 2/5/2018 10:38:39 PM Event ID: 304 Task Category: None Level: Information Keywords: User: SYSTEM Computer: RootDC01.Litware.com Description: A Kerberos service ticket was issued for a member of the Protected User group. Account Information:     Account Name:        BBanner@LITWARE.COM     Account Domain:        LITWARE.COM     Logon GUID:        {9fdc2786-483a-81c3-17ce-43276cb9e55e} Authentication Policy Information:     Silo Name:     Policy Name: Device Information:     Device Name: Service Information:     Service Name:        ROOTMS04$     Service ID:        LITWARE\ROOTMS04$ Network Information:     Client Address:        ::ffff:10.10.20.24     Client Port:        49205 Additional Information:     Ticket Options:        0x7B     Ticket Encryption Type:    0x1F     Failure Code:        0x0     Transited Services:    - This event is generated every time access is requested to a resource such as a computer or a Windows service. The service name indicates the resource to which access was requested. This event can be correlated with Windows logon events by comparing the Logon GUID fields in each event. The logon event occurs on the machine that was accessed, which is often a different machine than the domain controller which issued the service ticket. Ticket options, encryption types, and failure codes are defined in RFC 4120.   Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 2/5/2018 10:40:40 PM Event ID: 4768 Task Category: Kerberos Authentication Service Level: Information Keywords: Audit Success User: N/A Computer: RootDC01.Litware.com Description: A Kerberos authentication ticket (TGT) was requested. Account Information:     Account Name:        BBanner     Supplied Realm Name:    LITWARE.COM     User ID:            LITWARE\BBanner Service Information:     Service Name:        krbtgt     Service ID:        LITWARE\krbtgt Network Information:     Client Address:        ::ffff:10.10.20.24     Client Port:        49239 Additional Information:     Ticket Options:        0x40810010     Result Code:        0x0     Ticket Encryption Type:    0x12     Pre-Authentication Type:    2 Certificate Information:     Certificate Issuer Name:     Certificate Serial Number:     Certificate Thumbprint: Certificate information is only provided if a certificate was used for pre-authentication. Pre-authentication types, ticket options, encryption types and result codes are defined in RFC 4120.  

Validation – Failure

When connecting over RDP, using the ip address of the server results in NTLM being used for authentication, which results in a failed authentication. Log Name: Microsoft-Windows-Authentication/ProtectedUserFailures-DomainController Source: Microsoft-Windows-NTLM Date: 2/5/2018 10:50:23 PM Event ID: 100 Task Category: None Level: Error Keywords: User: SYSTEM Computer: RootDC01.Litware.com Description: NTLM authentication failed because the account was a member of the Protected User group. Account Name:    BBanner Device Name:    ROOTMS01 Error Code:    0xC000006E   Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 2/5/2018 10:50:23 PM Event ID: 4822 Task Category: Credential Validation Level: Information Keywords: Audit Failure User: N/A Computer: RootDC01.Litware.com Description: NTLM authentication failed because the account was a member of the Protected User group. Account Name:    BBanner Device Name:    ROOTMS01 Error Code:    0xC000006E   Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 2/5/2018 10:50:23 PM Event ID: 4776 Task Category: Credential Validation Level: Information Keywords: Audit Failure User: N/A Computer: RootDC01.Litware.com Description: The computer attempted to validate the credentials for an account. Authentication Package:    MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Logon Account:    BBanner Source Workstation:    ROOTMS01 Error Code:    0xC000006E ]]> Using Authentication Policies to Restrict Privileged User Account Logons https://docs.microsoft.com/archive/blogs/secadv/using-authentication-policies-to-restrict-privileged-user-account-logons Thu, 01 Mar 2018 07:48:34 GMT https://blogs.technet.microsoft.com/secadv/?p=305 Authentication policy silos and the accompanying policies provide a way to contain high-privilege credentials to systems that are only pertinent to selected users, computers, or services. Silos can be defined and managed in Active Directory Domain Services (AD DS) by using the Active Directory Administrative Center and the Active Directory Windows PowerShell cmdlets. The following example shows how to use authentication policies and authentication policy silos to allow privileged user accounts to log on ONLY to domain controllers and to privileged access workstations (also called jump servers, administrative servers/workstations, etc. The rationale is to restrict Tier 0 accounts to Tier 0 servers and not allow interactive logon to less secure machines. For more information on the tier model, see https://aka.ms/tiermodel
Note Most examples on the internet use policies to:
  • Specify a TGT lifetime.
  • Specify the silo using an access control condition
While silos are used to:
  • Define accounts. Conversely the silo is assigned to each of the user and computer accounts
  • Define the authentication policy
However, in the example, below, silos are not used. An authentication policy alone is used to:
  • Define user accounts. Conversely the policy was assigned to each of the user accounts
  • Specify a TGT lifetime
  • Specify the devices the users can authenticate to, using an access control condition

Requirements

  • Windows Server 2012 R2 domain functional level
  • Clients must run Windows 8, Server 2012 and later to support Kerberos armoring (which is part of Dynamic Access Control)

High-level steps:

  1. Enable support for claims, compound authentication, and Kerberos armoring on domain controllers using group policy.
  2. Enable support for claims, compound authentication, and Kerberos armoring on clients using group policy.
  3. Create an authentication policy that configures the following:
    1. User accounts
    2. TGT lifetime for the user accounts
    3. Access control conditions that restrict devices
  4. Assign the authentication policy to each of the user accounts

Detailed steps:

1. Configure domain controllers to support claims and compound authentication for Dynamic Access Control and Kerberos armoring Do this by enabling the following group policy setting and linking the group policy object to the domain controllers organizational unit: Computer Configuration\Policies\Administrative Templates\System\KDC - KDC support for claims, compound authentication, and Kerberos armoring: Always provide claims
2. Configure the client computers to request claims, provide information required to create compounded authentication and armor Kerberos messages. Do this by enabling the following group policy setting and linking the group policy object to the OUs that contain the machines to which the user(s) will be allowed to log on to: Computer Configuration\Policies\Administrative Templates\System\Kerberos - Kerberos client support for claims, compound authentication and Kerberos armoring
3. Open the Active Directory Administrative Center (dsac.exe). Click on Authentication in the left pane. The selected Authentication node is visible for domains which are at Windows Server 2012 R2 DFL
4. In the main pane select Authentication Policies. Then, in the Tasks pane, click on New under Authentication Policies. Select Authentication Policy from the context menu.
5. Configure the policy with the following information: Display name: AuthPol - Tier_0_Accounts_Devices Description: This policy restricts directory service administrator accounts to authenticate against domain controllers and Privileged Administrative Workstations alone Only audit policy restrictions: Select for testing, before rolling out to production Protect from accidental deletion: checked
6. Under the Accounts section, use the Add button to add the users. Group objects cannot be selected using the object picker.
7. Under the User section, check the box Specify a Ticket Granting Ticket lifetime for user accounts and enter a value in minutes for Ticket-Granting-Ticket Lifetime (minutes)
8. Also, under the User section, specify access control conditions that restrict devices that can request a Ticket Granting Ticket for the user accounts assigned to this policy.
9. Under the User section, click the Edit button. In the Edit Access Control Conditions window, click the Add a condition link on the bottom left corner.
10. In the Member of each drop-down box, select Member of any
11. Click the Add items button. Use the object picker to select the Domain Controllers security group.
12. Once again, click Add items and this time in the object picker, select the Computers object type as well.
13. Search and select the server(s) you want the user(s) to be able to log on to.
14. This is what the result should look like in the Edit Access Control Conditions window:
15. This is what the result should look like in the User section of the authentication policy properties:
16. Click OK on the authentication policy properties window. Within the Active Directory Administrative Center browse to the user account added in step 7, right-click the object and click Properties. Click Policy on the left and on the main pane, in the Authentication Policy section, select Assign Authentication Policy Silo and using the drop down, select the policy.
17. Repeat the last step for each user account added in step 7.
  Validation – Failure Audit Mode When a user assigned an authentication policy attempts to log on to a machine to which he/she is not allowed access, the attempt succeeds but the following event is logged on the domain controller:
Log Name: Microsoft-Windows-Authentication/AuthenticationPolicyFailures-DomainController Source: Microsoft-Windows-Kerberos-Key-Distribution-Center Date: 2/5/2018 10:19:58 PM Event ID: 305 Task Category: None Level: Information Keywords: User: SYSTEM Computer: RootDC01.Litware.com Description: A Kerberos ticket-granting-ticket (TGT) was issued, but it will be denied when Authentication Policy is enforced because the device does not meet the access control restrictions. Account Information:

Account Name:        BBanner Supplied Realm Name: User ID:            LITWARE\BBanner

Authentication Policy Information:

Silo Name: Policy Name:        AuthPol - Tier_0_Accounts_Devices TGT Lifetime:        240

Device Information:

Device Name:

Service Information:

Service Name:        krbtgt/LITWARE Service ID:        S-1-5-21-156393716-1274321063-4078162134-0

Network Information:

Client Address:        ::ffff:10.10.20.24 Client Port:        49204

Additional Information:

Ticket Options:        0x7B Result Code:        0x12 Ticket Encryption Type:    0x7 Pre-Authentication Type:    0

Certificate Information:

Certificate Issuer Name: Certificate Serial Number: Certificate Thumbprint:

Certificate information is only provided if a certificate was used for pre-authentication. Pre-authentication types, ticket options, encryption types and result codes are defined in RFC 4120.
  Enforced Mode When a user assigned an authentication policy attempts to log on to a machine to which he/she is not allowed access, the attempt fails with the following error: This is accompanied by the following events on the domain controller:
Log Name: Microsoft-Windows-Authentication/AuthenticationPolicyFailures-DomainController Source: Microsoft-Windows-Kerberos-Key-Distribution-Center Date: 2/5/2018 11:39:12 PM Event ID: 105 Task Category: None Level: Error Keywords: User: SYSTEM Computer: RootDC01.Litware.com Description: A Kerberos Ticket-granting-ticket (TGT) was denied because the device does not meet the access control restrictions. Account Information:

Account Name:        BBanner Supplied Realm Name: User ID:            LITWARE\BBanner

Authentication Policy Information:

Silo Name: Policy Name:        AuthPol - Tier_0_Accounts_Devices TGT Lifetime:        240

Device Information:

Device Name:

Service Information:

Service Name:        krbtgt/LITWARE Service ID:        S-1-5-21-156393716-1274321063-4078162134-0

Network Information:

Client Address:        ::ffff:10.10.20.24 Client Port:        49218

Additional Information:

Ticket Options:        0x78 Result Code:        0xC Ticket Encryption Type:    0x7 Pre-Authentication Type:    0

Certificate Information:

Certificate Issuer Name: Certificate Serial Number: Certificate Thumbprint:

Certificate information is only provided if a certificate was used for pre-authentication. Pre-authentication types, ticket options, encryption types and result codes are defined in RFC 4120.
Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 2/5/2018 11:39:12 PM Event ID: 4820 Task Category: Kerberos Authentication Service Level: Information Keywords: Audit Failure User: N/A Computer: RootDC01.Litware.com Description: A Kerberos Ticket-granting-ticket (TGT) was denied because the device does not meet the access control restrictions. Account Information:

Account Name:        BBanner Supplied Realm Name: User ID:            LITWARE\BBanner

Authentication Policy Information:

Silo Name: Policy Name:        AuthPol - Tier_0_Accounts_Devices TGT Lifetime:        240

Device Information:

Device Name:

Service Information:

Service Name:        krbtgt/LITWARE Service ID:        S-1-5-21-156393716-1274321063-4078162134-0

Network Information:

Client Address:        ::ffff:10.10.20.24 Client Port:        49218

Additional Information:

Ticket Options:        0x78 Result Code:        0xC Ticket Encryption Type:    0x7 Pre-Authentication Type:    0

Certificate Information:

Certificate Issuer Name: Certificate Serial Number: Certificate Thumbprint:

Certificate information is only provided if a certificate was used for pre-authentication. Pre-authentication types, ticket options, encryption types and result codes are defined in RFC 4120.
]]> Parsing DNS server log to track active clients https://docs.microsoft.com/archive/blogs/secadv/parsing-dns-server-log-to-track-active-clients Mon, 22 Jan 2018 20:33:49 GMT https://blogs.technet.microsoft.com/secadv/?p=35 Enabling Debug Logging You may need to enable debug logging on all DNS servers to make sure you capture all client queries.
  1. Open the DNS management console and connect to the Windows DNS server.
  1. Right-click the DNS server, click properties and go to the Debug Logging tab.
  1. Type in a filename and path for the log file and change the maximum size (bytes), if needed, and click OK. In the example below, I set the size to 536870912 which is 512MB.
  1. Finally, restart the DNS server service
 

Anatomy of the log file

The first 29 lines contain a description of each of the columns in the log Below that, you will find one line for each packet exchanged between the DNS client and server, with the values space-delimited:  

Parsing the log file

  1. After the span of a business cycle, copy the log file(s) to another machine.
  2. Download Log Parser 2.2 from https://www.microsoft.com/en-us/download/confirmation.aspx?id=24659 and install it.
  3. Launch a command prompt as administrator and change the directory to C:\Program Files (x86)\Log Parser 2.2 which is the default install location.
  4. Run the following command, replacing the highlighted section with the path to your stored log file:
LogParser -i:TSV -nskiplines:30 -headerRow:off -iSeparator:space -nSep:1 -fixedSep:off -rtp:-1 "SELECT field9 AS IP, REVERSEDNS(IP) AS Name, count(IP) as QueryCount FROM "C:\Temp\DNS\dns.log" WHERE field11 = 'Q' GROUP BY IP ORDER BY QueryCount DESC" See below for a description of the various switches:
  • -i:TSV - Input format (tab-separated values)
  • -nskiplines:30 - Number of initial lines to skip (30)
  • -headerRow:off - Treat first row of each file as a header (OFF)
  • -iSeparator:space - Separator character between fields (SPACE)
  • -nSep:1 - Number of separator characters between fields (1)
  • -fixedSep:off - The 'nsep' parameter is assumed to indicate the minimum number of separator characters between fields
  • -rtp:-1 – Rows to print (-1 = all rows)
  • "SELECT
    • field9 AS IP – Set header of column 9 to “IP”
    • REVERSEDNS(IP) AS Name - Resolve IP address and set a new column with header “Name” to the corresponding host name.
    • count(IP) as QueryCount - Stores the number of number of instances of “IP” in a column with header “QueryCount”.
  • FROM "C:\Temp\DNS\dns.log" WHERE
    • field11 = 'Q' – Only pick instances where packets are of type “Standard Query”
  • GROUP BY IP
  • ORDER BY QueryCount DESC"
  And here is what the output looks like:

IP                                        Name                                  QueryCount

-------------- ------------------------------------- ----------

10.10.20.71                     10.10.20.71                                 41

10.10.20.21                     RootMS01                                  27

127.0.0.1                          RootMS02                                 27

10.10.20.12                     ChildDC01                                 23

202.12.27.33                   M.ROOT-SERVERS.NET      21

192.36.148.17                   i.root-servers.net                    4

199.7.83.42                      l.root-servers.net                    4

192.112.36.4                    G.ROOT-SERVERS.NET       4

192.203.230.10               e.root-servers.net                    3

192.58.128.30                  j.root-servers.net                    3

199.7.91.13                       d.root-servers.net                    3

192.228.79.201                b-2016.b.root-servers.net     2

128.63.2.53                       h.root-servers.net                   2

198.41.0.4                         a.root-servers.net                    2

192.33.4.12                       c.root-servers.net                    2

193.0.14.129                     k.root-servers.net                    1

192.5.5.241                       f.root-servers.net                      1

  Statistics: ----------- Elements processed: 255 Elements output:    17 Execution time:     4.25 seconds   Using this data, my customer was able to identify all machines that had the DNS servers’ ip addresses assigned statically, and were able to point them to the new appliances. Doing so, prevented any downtime due to the change.]]> Hello world! https://docs.microsoft.com/archive/blogs/secadv/hello-world Wed, 13 Sep 2017 18:19:30 GMT https://blogs.technet.microsoft.com/secadv/?p=1 Technet. This is your first post. Edit or delete it, then start blogging!]]>