read

Infrastructure Notes - Azure AD Pass-through Authentication

Basic installation steps:

  1. AD connect install first, this can also configure the first PTA agent
  2. Deploy additional agents. Microsoft recommends at least three.

In production environments, we recommend that you have a minimum of 3 Authentication Agents running on your tenant. There is a system limit of 40 Authentication Agents per tenant. And as best practice, treat all servers running Authentication Agents as Tier 0 systems

With regard to separate ‘agents’, there is an installation package currently called AADConnectAuthAgentSetup.exe that you obtain by clicking through the Azure AD connect link from the image above. (Except for the first one if you let ADSync do it’s thing, the other agents are installed separate from the AD Sync package is all I’m trying to highlight).

There’s almost zero setup with the agents. You just need to provide credentials for Azure AD. Once you add another agent it’ll show up in the same place as the initial AD sync component after a few minutes.

pta

Basic operation of the Agent:

  1. When user enters their user-name \ password the Azure service encrypts the password with a public key.
  2. One of the on prem agents makes an outbound call to retrieve the password from the queue.
  3. The agent decrypts the password and attempts to validate with on-prem.
  4. The agent forwards the response to Azure AD.
  5. (If configured, MFA comes in here)

Other Agent Information

Agent Ports:

Authentication agents need the following ports allowed outbound: 80: CRL retrieval. 443: Outbound communication with Azure services. 8080: Agent status reporting (10 minute interval), if 443 is unavailable for some reason.

Agent outbound domains:

*.msappproxy.net and *.servicebus.windows.net otherwise you need to keep up to date with the Azure dynamic IP assignments which MSFT do keep up to date here: https://www.microsoft.com/download/details.aspx?id=41653.

login.windows.net and login.microsoftonline.com are required for initial setup.

All the CRL work is done via mscrl.microsoft.com:80, crl.microsoft.com:80, ocsp.msocsp.com:80, and www.microsoft.com:80

Status Check?

When PTA is configured and Azure believes it to be working it will look like this in the console:

pta

Kerberos?

Azure AD can leverage Kerberos. I havn’t explored this a lot yet, and have it disabled in the lab for right now but the footnotes are:

  1. A Computer principal is created in AD for this purpose.
  2. On the client side, javascript requests a ticket for this service account.
  3. The ticket is forwarded to Azure AD to prove that the user is in fact authenticated.
  4. (This even works on mac).

Authentication Logging on the Active Directory side

I found this interesting…

I was already logged on to a client machine called ‘client1’ with the domain administrator account for the lab (i know, i know). I then opened a browser to test PTA with a user called Barry, just by logging in to the Azure portal as the most simple example of something requiring me to use PTA.

Summary

  1. Event 4768: A Kerberos authentication ticket (TGT) was requested
  2. Event 4769: A Kerberos service ticket was requested
  3. Event 4648: A logon was attempted using explicit credentials
  4. Event 4624: An account was successfully logged on
  5. Event 4634: An account was logged off.

Detail

The first indication that this happened on my local domain controller was actually a request for a krbtgt for barry (event 4768).

A Kerberos authentication ticket (TGT) was requested.

Account Information:
	Account Name:		barry
	Supplied Realm Name:	DROPBEARSEC
	User ID:			DROPBEARSEC\barry

Service Information:
	Service Name:		krbtgt
	Service ID:		DROPBEARSEC\krbtgt

Network Information:
	Client Address:		::1
	Client Port:		0

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.

Right after that, i see a service ticket request for a domain controller (Event 4769).

A Kerberos service ticket was requested.

Account Information:
	Account Name:		barry@DROPBEARSEC.COM
	Account Domain:		DROPBEARSEC.COM
	Logon GUID:		{50b44c74-6432-b4c7-a267-a339c98b4167}

Service Information:
	Service Name:		DC1$
	Service ID:		DROPBEARSEC\DC1$

Network Information:
	Client Address:		::1
	Client Port:		0

Additional Information:
	Ticket Options:		0x40810000
	Ticket Encryption Type:	0x12
	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.

Then, i see the first solid indication that this login is via ‘AzureADConnectAuthenticationAgentService.exe’ as an explicit login attempt (Event 4648).

A logon was attempted using explicit credentials.

Subject:
	Security ID:		NETWORK SERVICE
	Account Name:		DC1$
	Account Domain:		DROPBEARSEC
	Logon ID:		0x3E4
	Logon GUID:		{00000000-0000-0000-0000-000000000000}

Account Whose Credentials Were Used:
	Account Name:		barry
	Account Domain:		DROPBEARSEC
	Logon GUID:		{50b44c74-6432-b4c7-a267-a339c98b4167}

Target Server:
	Target Server Name:	localhost
	Additional Information:	localhost

Process Information:
	Process ID:		0x1df8
	Process Name:		C:\Program Files\Microsoft Azure AD Connect Authentication Agent\AzureADConnectAuthenticationAgentService.exe

Network Information:
	Network Address:	-
	Port:			-

This event is generated when a process attempts to log on an account by explicitly specifying that account’s credentials.  This most commonly occurs in batch-type configurations such as scheduled tasks, or when using the RUNAS command.

Then we get the 4624: log on

An account was successfully logged on.

Subject:
	Security ID:		NETWORK SERVICE
	Account Name:		DC1$
	Account Domain:		DROPBEARSEC
	Logon ID:		0x3E4

Logon Information:
	Logon Type:		3
	Restricted Admin Mode:	-
	Virtual Account:		No
	Elevated Token:		Yes

Impersonation Level:		Impersonation

New Logon:
	Security ID:		DROPBEARSEC\barry
	Account Name:		barry
	Account Domain:		DROPBEARSEC
	Logon ID:		0x9A5EA99
	Linked Logon ID:		0x0
	Network Account Name:	-
	Network Account Domain:	-
	Logon GUID:		{50b44c74-6432-b4c7-a267-a339c98b4167}

Process Information:
	Process ID:		0x1df8
	Process Name:		C:\Program Files\Microsoft Azure AD Connect Authentication Agent\AzureADConnectAuthenticationAgentService.exe

Network Information:
	Workstation Name:	DC1
	Source Network Address:	-
	Source Port:		-

Detailed Authentication Information:
	Logon Process:		Advapi  
	Authentication Package:	Negotiate
	Transited Services:	-
	Package Name (NTLM only):	-
	Key Length:		0

This event is generated when a logon session is created. It is generated on the computer that was accessed.

The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).

The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.

The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The impersonation level field indicates the extent to which a process in the logon session can impersonate.

The authentication information fields provide detailed information about this specific logon request.
	- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
	- Transited services indicate which intermediate services have participated in this logon request.
	- Package name indicates which sub-protocol was used among the NTLM protocols.
	- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

Right away after that, the account is logged off with a 4634

An account was logged off.

Subject:
	Security ID:		DROPBEARSEC\barry
	Account Name:		barry
	Account Domain:		DROPBEARSEC
	Logon ID:		0x9A5EA99

Logon Type:			3

This event is generated when a logon session is destroyed. It may be positively correlated with a logon event using the Logon ID value. Logon IDs are only unique between reboots on the same computer.
Blog Logo

Chad Duffey


Published

Image

Chad Duffey

Blue Team -> Exploit Development & things in-between

Back to Overview