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!

(2019-12-12) Delivered Session About “Moving Towards Passwordless Concept”

Posted by Jorge on 2019-12-12


Delivered session @DetronICT, invited by @ThierryVos about "Moving Towards Passwordless Concept" (preso and demos). About 30 tech enthusiasts listened until bitter end. Thanks for the invitation, and until a next time! Reward afterwards? Enjoying some beers together!

image

Figure 1: Initial Slide – Title/SubTitle

image

Figure 2: Introducing Me

image

Figure 3: The Agenda

image

Figure 4: The Agenda With Demos

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 / Office 365, Azure AD Connect, Azure AD Identity Protection, Azure AD MFA Adapter, Azure AD Password Protection, Conferences, Field Experiences, Group Policy Objects, Last Logon Information, Microsoft Authenticator App, Multi-Factor AuthN, MVP, Password Expiration Notification, Password-Less, Passwords, Passwords, Self-Service Password Reset, SSO, SYSVOL, Tooling/Scripting, Windows Azure Active Directory | Leave a Comment »

(2019-12-10) Azure AD Connect v1.4.38.0 Has Been Released

Posted by Jorge on 2019-12-10


Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

  • Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
  • Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
  • Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
  • Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

Download "Microsoft Azure Active Directory Connect" (Always The Latest Downloadable Version Only!)

IMPORTANT: N.A.

Azure AD Connect: Version Release History

1.4.38.0

Released: 12/6/2019

Released for download. Not available for auto-upgrade

Prerequisites for Azure AD Connect

More information about Azure AD Connect

New Features And Improvements

    • We updated Password Hash Sync for Azure AD Domain Services to properly account for padding in Kerberos hashes. This will provide a performance improvement during password synchronization from AAD to Azure AD Domain  Services.
    • We added support for reliable sessions between the authentication agent and service bus.
    • This release enforces TLS 1.2 for communication between authentication agent and cloud services.
    • We added a DNS cache for websocket connections between authentication agent and cloud services.
    • We added the ability to target specific agent from cloud to test for agent connectivity.

    Fixed issues

    • Release 1.4.18.0 had a bug where the PowerShell cmdlet for DSSO was using the login windows credentials instead of the admin credentialss provided while running ps. As a result of which it was not possible to enable DSSO in multiple forest through the AADConnect user interface.
    • A fix was made to enable DSSO simultaneously in all forest through the AADConnect user interface

    I ran the MSI and upgraded from the previous version without any issues and ran at least one scheduled sync cycle! I do not have auto-upgrade enabled, therefore unfortunately I cannot say anything about this version.

    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 Azure AD Connect, Windows Azure Active Directory | Leave a Comment »

    (2019-11-24) Do You Really Need The IdP Initiated Sign On Page Enabled?

    Posted by Jorge on 2019-11-24


    Did you know, that if you navigate to https://<Your Federation Service FQDN>/adfs/ls/idpinitiatedsignon.aspx, and you see a page similar to the one below, that you have enabled the IdP initiated Sign Web Page in ADFS?

    image

    Figure 1: IdP Initiated Sign On Web Page In ADFS – ENABLED

    If not mistaken, the IdP Initiated Sign On web page is disabled by default. There is NO NEED to enabled that web page to use IdP Initiated Sign On. You only need to enabled that webpage if you really want to use the web page! Why is this difference so important? Having the web page enabled, discloses all the SAML based applications that are connected to ADFS and you nay not want to do that.

    To enable or disable it, please see (2014-10-24) Enabling IdP Initiated Sign-On In ADFS

    If you see te following web page….

    image

    Figure 2: IdP Initiated Sign On Web Page In ADFS – DISABLED

    image

    Figure 3: Event In The ADFS Admin Event Log Regarding The IdP Initiated Sign On Web Page In ADFS Being Used While Disabled

    Encountered error during federation passive request.

    Additional Data

    Protocol Name:
     

    Relying Party:
     

    Exception details:
    Microsoft.IdentityServer.Web.IdPInitiatedSignonPageDisabledException: MSIS7012: An error occurred while processing the request. Contact your administrator for details.
       at Microsoft.IdentityServer.Web.Protocols.Saml.IdpInitiatedSignOnRequestSerializer.ReadMessage(WrappedHttpListenerRequest httpRequest)
       at Microsoft.IdentityServer.Web.Protocols.Saml.HttpSamlMessageFactory.CreateMessage(WrappedHttpListenerRequest httpRequest)
       at Microsoft.IdentityServer.Web.Protocols.Saml.SamlContextFactory.CreateProtocolContextFromRequest(WrappedHttpListenerRequest request, ProtocolContext& protocolContext)
       at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.CreateProtocolContext(WrappedHttpListenerRequest request)
       at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetProtocolHandler(WrappedHttpListenerRequest request, ProtocolContext& protocolContext, PassiveProtocolHandler& protocolHandler)
       at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

    So how can you still use IdP Initiated Sign On?

    You can use the following URL for IdP initiated Sign On: https://<Your Federation Service FQDN>/adfs/ls/idpinitiatedsignon.aspx?loginToRp=<Application Identifier>

    Please be aware that the connected application MUST support IdP initiated Sign On for this to work. The identifier is an URI that may look like a URL or something else.

    And here you can see IdP Initiated Sign On still works after disabling the IdP Initiated Sign On Page.

    image

    Figure 4: Using IdP Initiated Sign On Using The loginToRp Parameter

    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 Federation Services (ADFS), IdP-Initiated | 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 | Leave a Comment »

    (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-10) Azure AD Connect v1.4.32.0 Has Been Released

    Posted by Jorge on 2019-11-10


    Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

    • Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
    • Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
    • Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
    • Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

    Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

    Download "Microsoft Azure Active Directory Connect" (Always The Latest Downloadable Version Only!)

    IMPORTANT: In one environment I upgraded from Azure AD Connect 1.3.21.0. I noticed that it triggered a Full Import on both the AD and AAD MA/Connector, and it also triggered a Full Sync on both the AD and AAD MA/Connector. Since the full imports/syncs may take some time, depending on the size of your AD/AAD environment in terms of number objects being synched, make sure that you have taken the necessary steps to support this or hold off on upgrading until you have found a convenient moment to do so.

    IMPORTANT: In one environment I upgraded from Azure AD Connect 1.4.18.0. I noticed that it triggered a Delta Import on both the AD and AAD MA/Connector, but it triggered a Full Sync on the AD MA/Connector and a Delta Sync on the AAD MA/Connector. Since the full sync may take some time, depending on the size of your AD/AAD environment in terms of number objects being synched, make sure that you have taken the necessary steps to support this or hold off on upgrading until you have found a convenient moment to do so.

    IMPORTANT: Due to an internal schema change in this release of Azure AD Connect, if you manage ADFS trust relationship configuration settings using MSOnline PowerShell then you must update your MSOnline PowerShell module to version 1.1.183.57 or higher.

    Azure AD Connect: Version Release History

    1.4.32.0

    Released: 11/08/2019

    Released for download. Not available for auto-upgrade

    Prerequisites for Azure AD Connect

    More information about Azure AD Connect

    New Features And Improvements

    • N.A.

    Fixed issues

    • This version fixes an issue with existing Hybrid Azure AD joined devices. This release contains a new device sync rule that corrects this issue (Updated sync rule: “In from AD – Computer Join”). Note that this rule change may cause deletion of obsolete devices from Azure AD. This is not a cause for concern, as these device objects are not used by Azure AD during Conditional Access authorization. For some customers, the number of devices that will be deleted through this rule change can exceed the deletion threshold. If you see the deletion of device objects in Azure AD exceeding the Export Deletion Threshold, it is advised to allow the deletions to go through. How to allow deletes to flow when they exceed the deletion threshold

    I ran the MSI and upgraded from the previous version without any issues and ran at least one scheduled sync cycle! I do not have auto-upgrade enabled, therefore unfortunately I cannot say anything about this version.

    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 Azure AD Connect, Windows Azure Active Directory | 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-11-08) Active Directory Security Scan Of Accounts

    Posted by Jorge on 2019-11-08


    This month will have a serious security focus in scanning your AD to determine all kinds of account configurations, see relations between those configurations and mitigate any security risks due to combined configurations. A simple example can be an account with unconstrained delegation configured while it has a weak/compromised password, etc, etc.

    To scan the accounts within an Active Directory forest, I will be releasing 5 PowerShell scripts.

    [Script 1] .\Scan-And-Check-All-Accounts-In-AD-Forest_01_Basic-Info.ps1

    Features:

    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>’))

    [Script 2] .\Scan-And-Check-All-Accounts-In-AD-Forest_02_Delegation-Info.ps1

    Features:

    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"

    [Script 3] .\Scan-And-Check-All-Accounts-In-AD-Forest_03_NC-Level-Permissions-Info.ps1

    Features:

    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")

    [Script 4] .\Scan-And-Check-All-Accounts-In-AD-Forest_04_Object-Level-Permissions-Info.ps1

    Features:

    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

    [Script 5] \Scan-And-Check-All-Accounts-In-AD-Forest_05_Account-And-Password-Hygiene-Info.ps1

    Features:

    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.)

    Interested in this? Stay tuned!

    Thanks!

    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, Delegation Of Control, IT Pro Tools, Kerberos Constrained Delegation, Last Logon Information, Passwords, PowerShell, Replication, Security, Tooling/Scripting | 1 Comment »

     
    %d bloggers like this: