Post the ignite sessions last month on Microsoft Teams, we have enhancements on security perspective that can be enabled which adds extra protection in any organization.
Inviting the external guest users to the teams channel have been a welcoming option for all of us which increases the communication between them and surges the productivity. However, there are few security guidelines that needs to be followed to ensure that our data is always secure even when they are shared outside the boundary. For instance, a guest account getting compromised where he is a member of a finance team will become a major security incident in any organization.
This article outlines the steps that can be carried over to enhance the security on Microsoft Teams guest accounts by enforcing the multi factor authentication.
Below are the steps to enforce the MFA on guest accounts:
First create a dynamic distribution group and target the guest account
Login to Azure AD Tenant with Admin privilege’s- Go to Groups – Create new group – make them security – membership type make them dynamic.
Now we need to add a dynamic query where the property is usertype and the value is guest.
Once done populate the rule syntax and save them.
After some time now, we could see that the populated guest users in our Azure AD tenant will become the members of this group. Since it’s a dynamic query all the new upcoming accounts will be getting occupied automatically.
Create conditional access policy for guest accounts:
Now we need to create a conditional access policy for the Microsoft Teams guest accounts.
Navigate to enterprise applications – click on conditional access.
Now we need to target the dynamic group on this conditional access policy.
In cloud apps select Microsoft Teams , also better to select Sharepoint online which will enforce MFA for these Sharepoint guest users as well.
In conditions we are selecting only the locations. Further it can be manipulated based on the business prerequisite.
In the access control we are selecting only require MFA and the IT policy.
Now we have the MFA enforced on the guest accounts and we will see the action of this configuration from the invited user.
Experience of the guest users enforced with MFA:
In order to simulate this behavior , we are just adding one guest user a teams channel
Post after that the invited user receives a welcome email and this is usual behavior for any invited Azure AD guest user accounts.
When clicking to login the user will be prompted to register and enroll in MFA.
User will be prompted to enter the mobile number in the invited tenant for MFA and needs to complete the initial authentication process.
If we have enabled the IT policy user will be prompted to read and accept the IT policy.
Finally the user is logged in with the guest account and able to participate on the invited team through a secured way of authentication.
With very nominal steps through the conditional access it creates a overall better security for Microsoft Teams.
By default Office 365 DMARC validation for internet emails that fails for policy P=Reject will make the email to land in junk folder of the recipient mailbox.Microsoft 365 will treat DMARC policies of quarantine and reject in the same way, which means that if the sender’s DMARC policy is set to reject or quarantine, the emails that fail DMARC will be sent to the junk folder of the recipient mailbox.
Microsoft believes that the main agenda of doing this is to ensure that any legitimate emails which misses in DMARC alignment shouldn’t be lost and its better to get them delivered to recipient junk mail folder. There are few cases wherein few organizations would still need the DMARC policy to be stringent due to their security regulations.
Microsoft validates DMARC and overrides the failure with a header value for a domain whose DMARC TXT record has a policy of p=reject oreject. Instead of deleting or rejecting the message, Office 365 marks the message as spam.
To test it further we are publishing SPF, DKIM and DMARC record for the domain ezcloudinfo.com as below:
SPF record: Adding only Exchange online as authorized sender.
DKIM Record: Having the Signing key only for office 365
DMARC Record: Having strict policy of P=reject
For a successful email from a legitimate sender where it has passed spf, dkim & dmarc we see the below value for DMARC.
dmarc=pass action=none
Now we are triggering an email from a registered mailchimp account for ezcloudinfo.com where we do not have the SPF and DKIM records added in our DNS records.
The email from mailchimp from sender address sathish@ezcloudinfo.com gets landed in junk email.
We can see the header value of above email and the DMARC validation is failed.
WorkAround:
We received a workaround which can be accomplished to reject the emails that fails with DMARC validation from redsift cyber security analysis .
Create a Transport Rule:
Include the below value oreject or action=oreject or dmarc=fail in the message header include option.
Reject the message with the custom status code.
Now if we send a test email after this transport rule from an unauthorized sender the email will be rejected and could see the below NDR message.
So after this transport rule any spoof emails that are coming from a domain that is DMARC protected will not be delivered to the spam folder. They will all be rejected and never reach the recipient.
In this article we will have a look at enabling Azure AD password protection policy in On Premise Active Directory Server.
By Default this feature is enabled for cloud only users with a basic filter of Azure AD password protection with global banned password list.However if we still require Azure AD password protection with custom banned password list for Cloud only users then we would need to have at-least Azure AD Basic License the default value is below.
We have below options in password protection policies:
Lockout Threshold: How many failed sign-ins are allowed on an account before its first lockout. If the first sign-in after a lockout also fails, the account locks out again.
Lockout Duration in Seconds: The minimum length in seconds of each lockout. If an account locks repeatedly, this duration increases.
Enforce custom list: When enabled, the words in the list below are used in the banned password system to prevent easy-to-guess passwords.
Custom banned password list: A list of words, one per line, to prevent your users from using in their passwords. You should include words specific to your organization, such as your products, trademarks, industries, local cities and towns, and local sports teams. Your list can contain up to 1000 words. These are case insensitive, and common character substitutions (o for 0, etc) are automatically considered.
Enable Password protection on active directory: If set to Yes, password protection is turned on for Active Directory domain controllers when the appropriate agent is installed.
Mode: If set to Enforce, users will be prevented from setting banned passwords and the attempt will be logged. If set to Audit, the attempt will only be logged.
The Visual representation of how this process works is beautifully shown below from Microsoft technet Source
Below are the prerequisites for enabling the password protection on Active Directory:
For enabling this service on On Premise Active Directory it requires an Azure AD premium license.
A proxy service agent needs to be installed on a member server running windows server 2012 R2 or later.
Domain controllers where the Azure AD password protection DC agent service will be installed must be running Windows Server 2012 or later.
All servers running the azure AD components must be fully patched in-order to have Universal C runtime installed.
Network connectivity must be present between the Azure AD proxy server and one domain controller running Azure agent Service.
An Azure AD global administrator account is required to register and consume this service for On Premise AD in Azure AD.
A local domain admin privilege account is required to register windows server AD with Azure AD.
Domain running the DC agent service must use the DFSR replication type for SysVol Replication.
Azure AD password protection proxy service server must have access to the below Microsoft Protection Endpoints.
After download we will have 3 installers as below.
Azure AD Password Protection Proxy Service – It acts as a proxy agent which will forward outgoing requests from domain controllers to Azure AD and incoming requests from Azure AD to the on premise domain controller.
DC Agent password filter dll – Will receive all the password validation requests and forward them to the main component running in onpremise Domain Controller which is Azure AD password protection DC agent.
Azure AD password protection DC agent- Receives the password validation request from the filter agent and processes them with the currently present local password policy and returns the validation response Pass/Fail. This core services queries the Azure AD password protection proxy service to check and download the new versions of password policy.
First step we need to install the proxy agent on a member server which in the same domain.
Once installation is completed Import the Module –
Register the Proxy configuration on a static Port-
Below command can be run to make the proxy service communication and DC Agent Service to run on a static specific port. This option is preferred to keep a static single port communication from this proxy service server and the Domain Controller and not to have IP to IP communication between them.
Install the DC agent on the Domain Controller. After the installation is complete only a restart is required and no further configuration is required at this stage.
After this login to Azure AD and enabled the password protection on Windows server Active Directory. Always strictly recommended to start only in Audit mode to understand the current password security and user compliance from the logs.
Once enforced in audit mode we get the below confirmation message in Azure Password protection DC Agent Event logs.
We can verify the password protection agent settings by below commands
Its always better to start this operation by only keeping them in Audit mode since it will create a major impact in the environment without proper end user awareness about enforcing this password policy change.
Also we can monitor the logs in event viewer in below location
A user resetting the password with the compliant characters will get a successful log as below
If there was a non-complaint password reset by a help-desk operator it would be logged in the audit mode and mention it did not meet the compliant standards.
When the same password is provided to end user and when the end user resets them with non-compliant values then those entries also will be logged in the event viewer.
A Successful password policy update from Azure AD can be seen below from the Azure AD password protection proxy server.
We can also see that a separate Container is created in ADSI Edit and can see 2 certificates folder created with thumbprint name.
Important Notes:
As a best practice its not recommended to go with enforce mode initially since the end users will have tough time adopting the password policy immediately.
Once the audit mode is enabled better to circulate email floaters about the upcoming password policy change which will create better awareness.
The custom banned password policy is capable of having 1000 entries. We can gradually increase the value which will make this roll out in a smoother way.
If we are updating the global banned password in the azure portal they are pushed down to the on premise agents in a polling interval of 1 hour time period.
To Register-AzureADPasswordProtectionForest cmdlet to succeed at least one Windows Server 2012 or later domain controller must be available in the proxy server’s domain.
Once any web application is deployed its always recommended to perform a thorough security testing to identify if there are any security risks.
In this article im just sharing my experience to disable RC4 and SSLV3 for applications hosted on Windows Servers.
We can use the below URL site to test the server configuration for HTTPS protocol https://www.ssllabs.com/ – that will test your server’s configuration for the HTTPS protocol
Why RC4 needs to be disabled ?
RC4 should not be used, due to crypto-analytical attacks.
It’s been more than 25 years since Ron Rivest invented his RC4 stream cipher but still being used by legacy clients and browsers.
How RC4 Encryption Works:
A ciphersuite consists of a key exchange algorithm, an encryption method and an integrity protection method.
RC4 is a stream cipher, so it encrypts plaintext by mixing it with a series of random bytes used to encrypt it. But, the bytes used to encrypt the plaintext aren’t really as random as they should be, at least at the beginning of the process.
That makes it possible for an attacker to figure out the plaintext of an encrypted message with access to enough TLS requests. The problem is that there are biases in the keystream, making life easier for an attacker.
Why its not Disabled by default on Windows Server 2008 R2, 2012 R2 ?
Unfortunately, servers default configuration tends to support backward compatibility as well over security.
They are enabled by default only for supporting older versions of browsers and operating systems.
Basically we need to disable this on apps running Windows Server 2008 R2 , 2012 R2 and IIS.
Preventive Measures for RC4 Attack:
As a security its always recommend to use TLS 1.2 or above. So its better to disable them and support only the latest type of encryption.
Disable Ciphers by adding the below registry entries on the server hosting the application.
SSLv1 was never publicly released.
SSLv2 was quickly found to be insecure.
SSLv3 was created, and, together with the newer TLSv1/1.1/1.2, it is still currently being used to secure the transport layer of the Internet.
Weakness of SSL V3:
Last year Google Engineers found the major loophole in SSLV3 with an exploitation technique known as POODLE Attack.
This is a plaintext recovery attack that focuses on HTTP headers and exploits a weakness in the SSLv3 protocol when used with block ciphers.
Its a protocol vulnerability attack.
So now its recommended to disable the SSLV3 on server side. Preventive Measures for SSLV3 Attack:
Disable SSL V3 by adding the below registry entries on the server hosting the application.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server] “Enabled”=dword:0000000
Always advisable to have encryption of more than TLS 1.2.
Note:
1) If you have this security enabled on the reverse proxy application through which your services are published, then the session for those connections will be terminated there itself.
But still its better to have this disabled on all the applications which are serving the clients.
2) Its very important to note that before disabling this type of connections we need to make sure that the application is not serving any clients with this encryption.If at all its found we need to make that application to work on TLS1.2 or later.
