Password Management (part 3)

By Ashwin Venugopal -

 




To read part 1, please click here
To read part 2, please click here









Windows Hello for Business

In Windows 10, this technique can replace passwords with strong two-factor authentication on PCs and mobile devices allowing users authenticate to an AD or Azure AD account. It can easily address following problems with passwords:
  1. Strong passwords can be difficult to remember, and users often reuse passwords on multiple sites.
  2. Server breaches can expose symmetric network credentials (passwords).
  3. Passwords are subject to replay attacks.
  4. Users can inadvertently expose their passwords due to phishing attacks.  

Windows Hello can be considered as the most personal way for your users to sign-in to their Windows 10 devices with just a look or a touch i.e. users can easily acquire enterprise-grade security without any necessity of typing a password. 

Using Windows Hello

If you want to use Windows Hello, you have to login with the help of an already setup PIN and after that you can click the Start button, then select Settings > Accounts > Sign-in options to set up Windows Hello. Once you are successfully set-up, you can sign in with the help of a quick swipe on your fingerprint reader or glance at your camera.

Note- Windows Hello features will only appear if your computer includes hardware to support it.

Azure AD Smart Lockout

It generally assists in locking out bad actors trying to guess your users' passwords or use brute-force method to get in by easily recognizing sign-ins coming from valid users and treat them differently than the attackers as well as other unknown sources. 

Smart lockout can also track the last three bad password hashes to avoid incrementing the lockout counter for the same password and if anyone enters the same bad password multiple times, then, this behavior will not cause the account to lockout. However, using smart lockout does not mean that a genuine user cannot be locked out, to prevent this-

  • Each Azure AD data center tracks lockout independently. A user will have (threshold_limit *datacenter_count) number of attempts, if the user hits each data center. 
  • Smart lockout uses familiar location versus unfamiliar location to differentiate between a bad actor and the genuine user.  

If you successfully setup smart lockout policies in Azure AD, the attacks can be easily filtered out before reaching the on-premises AD.

Smart Lockout Integration with Pass-through Authentication 

While using pass-through authentication, you should ensure that:

  • The Azure AD lockout threshold is less than the AD account lockout threshold by setting its values at least two or three times longer than the Azure AD lockout threshold.
  • The duration of Azure AD lockout must be longer than AD reset account lockout counter after duration.    

Verify On-premises Account Lockout Policy

  1. Open the Group Policy Management tool.
  2. Edit the group policy including your organization's account lockout policy, for example, the Default Domain Policy.
  3. Browse to Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policies.
  4. Verify your Account lockout threshold and Reset account lockout counter after values.   

Manage Azure AD Smart Lockout Values

You can use the following steps:

  1. Sign in to Azure portal and navigate to Azure Active Directory > Authentication methods > Password protection.
  2. Set the Lockout threshold, according to the failed sign-ins allowed on an account before its first lockout (by default it's 10).
  3. Set the Lockout duration in seconds, to the length in seconds of each lockout (by default it's 60 seconds).

Note: If the first sign-in after a lockout also fails, then the account will be locked again and if it's done repeatedly, then the lockout duration will increase.

How to determine if Smart Lockout is working?

Whenever the smart lockout threshold is triggered, the following message will appear while the account is locked:

Your account is temporarily locked to prevent unauthorized use. Try again later, and if you still have trouble, contact your admin.








To read part 1, please click here
To read part 2, please click here





Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning...
Read more