Recent Discussions
Convert On-Prem AD Users from Office 365/Azure AD to In-Cloud accounts
Hi We have currently setup a ADConnect Sync to Office 365, this is working well. We would like to start converting Sync'ed accounts in Office 365/Azure AD to "In Cloud" accounts. Can you advise or does anyone know how we might approach this? Or can point to alternative resources? We need to ensure the accounts in Office 365/Azure AD remain active and usable. Much appreciated PaulEncrypt button disappearing from Outlook
Hello, We seem to be having an issue with the Office 365 Office Message Encryption (OME) for a couple of customers. They are properly licensed with Business Premium and AIP Plan 1 and have the latest version of the Office desktop (1812.11126.20196). The button has just disappeared. Recently, it's been upgraded from the previous envelope with red circle to the new lock icon. Yesterday, it is now either grayed out or the tab has completely been removed from the "New" message window in the "Options" section. It was working fine the day before. Not sure if this is related to the recent update of the Office client, but other customers with the same set up are not experiencing this issue. The current affected customers still have the ability to use OWA to use the Protect/Encrypt button or mail flow rules I created for a work around. I have also tried using the Online Repair option, new Outlook profile, and uninstall and reinstall. These do not resolved the issue. Also, they do not have the AIP client software installed. I have not checked this out yet, has the other customers with the same licensing and set up or working as expected.
Using the extensionAttributes in Active Directory
So I'm working on expanding the data stored about User Objects in an Active Directory, but we are looking for possible candidates to store the data in, as a lot of the fields have already been used. We found the fields 'extensionAttribute(1-15)' and looked online for some information about them. I couldn't find a lot of information about them. What I found was they are a result of implementing Exchange to your system. Are they suited for adding extra data to an User Object? Will they not be removed at a point? Can I find some more documentation about them somewhere? Won't they be affected when we may want to implement other systems in the future?
How to: Enabling MFA for Active Directory Domain Admins with Passwordless Authentication
Administer on premise Active Directory Using Azure Passwordless Authentication removing Domain Admins passwords Hello Guys, I am here just to demonstrate that today is technically possible (Proof of Concept): Configure a modern MFA solution to access on prem Windows 10 PC Use that solution to protect privileged accounts passwords Eradicate from the domain the password presence for those privileged accounts (make impossible to use a password to log on to domain to prevent some king of password attacks) Have the ability to use multiple PAWs (privileged access workstation) with same MFA credential Have only one identity with one strong credential Same credential can be used on prem and in cloud (if needed) Connect to Domain Controller thorough RDP form the PAW using SSO (Single Sign On) Obtain above with a sort of simplicity and costs control I am not here to discuss if this document in any parts adhere to all principles and best practices of a secure administration environment, I just want to show a feature as a proof of concept. It’s up to you to integer this work into your security posture and evaluate impacts. No direct or indirect guarantee is given, and this cannot be considered official documentation. The content is provided “As Is”. Have look more deeply above points: Many customers asked me, after they have used Azure/Office 365 MFA: is it possible to use something like that to log on to the domain/on prem resources. The solution is today present : the use a security key (FIDO2) : Passwordless security key sign-in to on-premises resources - Azure Active Directory | Microsoft Docs. Please have a look also at Plan a passwordless authentication deployment with Azure AD | Microsoft Docs. I wanted to demonstrate that this solution can protect also Domain Admins group to protect high privileged accounts (important notice about is present in this document : (FAQs for hybrid FIDO2 security key deployment - Azure Active Directory | Microsoft Docs – “FIDO2 security key sign-in isn't working for my Domain Admin or other high privilege accounts. Why?”). After having substituted the password with one MFA credential (private key + primary factor) (here more information : Azure Active Directory passwordless sign-in | Microsoft Docs) we can configure a way to make the password not necessary for domain administration, very long and complex, and disabled: Passwordless Strategy - Microsoft 365 Security | Microsoft Docs With other MFA tool (e.g. Windows Hello for Business), if we want to use different PAWs (secured workstations from which the Administrator connects with privileged accounts Why are privileged access devices important | Microsoft Docs) we need to configure and enroll the solution machine per machine (create different private keys one for any windows desktop). With the described solution below the enrollment happens only once (the private key is only one per identity and is portable and only present inside the USB FIDO key) and is potentially usable on all secure desktop/PAWs in the domain. The dream is: to have one identity and one strong credential: this credential (private key installed in the FIDO physical key) is protected by a second factor (what you know (PIN) or what you are (biometric), it is portable and usable to consume services and applications on premises and in cloud To connect using RDP to another/third system after this kind of strong authentication is performed on the physical PC a password is needed (but we really want to eradicate the use of a password)….So.. We can use a Windows 10 / Windows 2016 and afterwards feature (Remote Credential Guard Protect Remote Desktop credentials with Windows Defender Remote Credential Guard (Windows 10) - Microsoft 365 Security | Microsoft Docs) to remove this limitation. If you have a certain hybrid infrastructure already in place (What is hybrid identity with Azure Active Directory? | Microsoft Docs, Configure hybrid Azure Active Directory join for managed domains | Microsoft Docs, etc.), the activation of this solution is simple and there are no important added costs (a FIDO key costs around 20 / 30 euros) The solution is based on 3 important features: AzureAD/Fido Keys, Remote Credential Guard and primarily Active Directory SCRIL Feature [ https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/passwordless-strategy#transition-into-a-passwordless-deployment-step-3 : "...SCRIL setting for a user on Active Directory Users and Computers. When you configure a user account for SCRIL, Active Directory changes the affected user's password to a random 128 bits of data. Additionally, domain controllers hosting the user account do not allow the user to sign-in interactively with a password. Also, users will no longer be troubled with needing to change their password when it expires, because passwords for SCRIL users in domains with a Windows Server 2012 R2 or early domain functional level do not expire. The users are effectively passwordless because: the do not know their password. their password is 128 random bits of data and is likely to include non-typable characters. the user is not asked to change their password domain controllers do not allow passwords for interactive authentication ...] Chapter 1 – Enable Passwordless authentication and create your key Enable the use of FIDO Keys for Passwordless authentication. In Azure AD \ Security \ Authentication methods, enable the use of a security key for a specific group and set the keys settings in accordance with the HW provider of the key (in my case Force Attestation and Key Restriction set to off). Confirm Hybrid Device Join. Confirm your Windows 10 2004+ PC are Hybrid Device Joined. Confirm users and all involved groups are hybrid Confirm all involved users or groups are correctly replicated by AD Connect, have Azure Active Directory properly configured and login in cloud works correctly Implement Kerberos Server to foster on prem SSO (Single Sign On) for on prem resources follow this guidance Passwordless security key sign-in to on-premises resources - Azure Active Directory | Microsoft Docs Enroll the key. Please don’t use Incognito Web Mode (sign out already connected users and use “switch to a different account”). If during enrollment errors come up, check if any user is already signed into the browser (in the new Edge use “Browse as Guest” that is different from “Incognito Mode”). Login to Office.com with the user you want to provide the USB KEY and reach My Account page In My Account page open Security Info and initialize the USB Key. https://mysignins.microsoft.com/security-info If not completed before, enable MFA authentication by using a phone (SMS) or Authenticator App (in this case the user was not already provided of MFA , so the systems automatically make you enroll the authenticator app in your phone) Now, because you have an MFA tool, you can create/enroll a security key: add method / USB Key. The browser challenges you to insert a key.. to inject your identity into it Create a new PIN ! Confirm touching the key Name the key Done - security Key is enrolled with your identity Perform an Office365 Passwordless Authentication Verify you are able to sign on to O365 using the Key w/o the use of a password. Please use Microsoft Edge, if already logged click right corner and “browse as a guest” Please remember to click in “Sign in Options” to trigger key authentication : Well done: you are logged in the cloud Passwordless! Chapter 2 – Enable on prem multifactor login Deploy a GPO – Group Policy Object- to enable FIDO2 on prem login with Windows 10 2004+. In your on prem environment we can enable the use of USB key credential provider (Windows has multiple credential providers: password, usb key, smartcard, et.). Enable and link this setting to your Windows 10 2004+ machines. Restart involved machines. Now you will see a new icon to login to the PC. Clicking on sign in option you can use this new credential provides – FIDO security key - . Insert the Usb key, type the PIN… On some FIDO Keys you can avoid PIN with biometric (fingerprint). You can use the same identity/credential in all the PC with the FIDO credential provider enabled. Remember that currently for on prem sign on only one user per key is available (you can’t have multiple identity on the same usb key). Please note that this kind of authentication is recognized by Azure/O365 cloud as one already claimed MFA so when you open your preferred application the connection is in SSO (you don’t have to re-authenticate or perform another strong auth). Please note that with the same key you can login to the cloud applications using MFA from external computers w/o any modifications (like kiosks, byod computers, etc). Please note that you have access to all on prem services because the Kerberos server we installed above is useful to foster the obtention of Kerberos tickets for on prem AD service consumption Chapter 3 – Use FIDO KEYS to protect privileged users (Domain Admins) and De-materialize their password. Now we are going to enable a FIDO key for the Domain Admin or configure FIDO KEYS to work with privileged users. The default security policy doesn't grant Azure AD permission to sign high privilege accounts on to on-premises resources. To unblock the accounts, use Active Directory Users and Computers to modify the msDS-NeverRevealGroup property of the Azure AD Kerberos Computer object (e.g. CN=AzureADKerberos,OU=Domain Controllers,<domain-DN>). Remove all privileged groups you want to use with FIDO KEYS. Consider one user might be member of different groups, so remove all wanted user is member of. I removed all groups with the exception of Domain Controllers .. Make the test user member of Domain Admins group Wait AD Connect Sync Time (normally at least of 30 min) Now enroll the FIDO Usb Key for the privileged account following Chapter 1 of this guide Now test the Login with the Domain Admin using the FIDO KEY and check the possibility to be authenticated to onprem services (e.g. Fileshares, MMC - ADUC Consoles, etc.). Try the high privilege like creating a new user…. Now that we have one alternative way to Sign In on prem and in cloud (instead of password) we can work on password eradication. Obviously, every application we want to use must not use passwords (work in SSO with AD or Azure AD). This is not a problem for a privileged accounts because these should not have any application access nut only accesses to administrative consoles We will enable SCRIL policy (Smart Card is required for interactive logons) for the privileged user: Smart Card is required for interactive logon = the user password is reset and made random and complex, unknown by humanity, the use of password for interactive login is disabled Test you can’t access with password anymore To complete and strengthen the password eradication we want to prevent the use of the password also for network authentications using the NTLM protocol, so we are going to make the user member of “protected users” group Protected Users Security Group | Microsoft Docs. This because if a bad guy reset that user’s password, he/she might use the NTLM protocol to log on using password, bypassing interactive log on. Protected Users disables the entire usability of NTLM protocol that is not needed to common AD administration. If you don’t want to disable NTLM protocol and If you have Domain Functional Level 2016 you can also enable NTLM rolling to make NTLM password hash to cycle every login and improve the password eradication What's new in Credential Protection | Microsoft Docs (Rolling public key only user's NTLM secrets) Probably you want to use that user to log in to privileged systems with Remote Desktop. By default, Remote Desktop Protocol requests the use of passwords … Here we don’t have a password to write because the password is unknown by humanity….. so … how to? The simplest way to solve the above problem is to use Remote Credential Guard feature if you have the needed requirements (..Windows 10, version 1607 or Windows Server 2016.. or above) What's new in Credential Protection | Microsoft Docs To enable it on the server we want to connect to, just add this registry key using the example command reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0 /t REG_DWORD From the client where we used the FIDO login, just run RDP with the parameter /RemoteGuard Now also the RDP remote authentication performs well without passwords!!! Now we signed in a Domain Controller using a MFA key and is no more possible to use a password for domain administration. Update1: using temporary access password might be possible to never assign even a beginning password to a Domain Admin neither need a phone authentication. Configure a Temporary Access Pass in Azure AD to register Passwordless authentication methods | Microsoft Docs As detailed above, create a Domain Admin on prem, immediately enable SCRIL and Protected Users, wait AD connect sync time, create a temporary password for that admin user (the temporary password can only be used to enable an MFA credential w/o using a Phone and w/o the risk of someone else accessing applications during the configuration phase). We recommend to maintain Azure Global Admins and Active Directory Domain Admins identities separately, so don't make synced Domain Admins member of Azure Global Admins role.Sensitivity button grayed out
Hi Previously the Sensitivity button was working fine in word 8latest ProPlus) - now its grayed out. Classifications Labels are defined and scoped/re-published to an O365 group/members through the compliance center - however, the button remains grayed out - got E3 licenses. The group also has a 'Team' and therefor SharePoint site where there are files that need to be classified Why is this suddenly stopped working? - how to troubleshoot this?
Enabling MFA on admin level access to On premise AD
Hello everyone. I've run into a puzzler and I'm hoping someone can give me a tip on how to solve this. I have received a "cyber security attestation" document from a major insurance provider and must be able to say yes to all of the items on it as a baseline to receive a policy. Here's the one I'm stuck on: multi-factor authentication is required for the following, including such access provided to 3rd party service providers: All internal & remote admin access to directory services (active directory, LDAP, etc.). I'm not aware of a way to set up any MFA for admin access to Active Directory itself, but I'm all ears if someone knows of a way. What I think the only viable solution would be is to set up MFA for access to any Domain Controller in the domain. In order for that to be adequate though, I then need to be able to prevent RSAT connections to Active Directory. I'm not sure if there's a way to restrict that or not, so that's where i'm currently stuck. Can anyone point me in the direction of a solution for either preventing RSAT access or (fingers crossed) enabling MFA on AD itself? Thanks, JoelEnriched NTLM authentication data using Windows Event 8004
Have you previously experienced NTLM authentications activities that came from unknown devices, such as Workstation or MSTSC? Would you like to discover the actual server being accessed inside the network? This information is now available in Azure ATP! Starting from Version 2.96, Azure ATP sensors parse Windows event 8004 for NTLM authentications. When NTLM auditing is enabled and Windows event 8004 are logged, Azure ATP sensors now automatically read the event and enrich your NTLM authentications activities display with the accessed server data. New Resource Access over NTLM activity is now available, showing the source user, source device and the accessed resource: Joye Parsons (1) is accessing CLIENT2 from W10-000100 device over NTLM. Enriched Failed log on activities providing the destination computer the user attempted, but failed to access: Joye Parsons (1) failing to log on to CLIENT2 from W10-000100 device over NTLM. In a future release, this data will also be available directly in authentication based Azure ATP security alerts such as Brute Force and Account Enumeration. Stay tuned for more updates. As always, your feedback and questions are welcome!Allow Use of Microsoft Authenticator OTP in Azure AD
Hi All, We wanted to enabled number matching and Passwordless with Microsoft Authenticator app and when I go to there I could see the below setting under configurations. But I wanted to make sure what that setting is and what it the recommended configurations for this "Allow Use of Microsoft Authenticator OTP" before configure in production environment. appreciate if anyone could help me on this. Thanks, DilanNew Blog Post | Microsoft’s Response to CVE-2021-44228 Apache Log4j 2
Microsoft’s Response to CVE-2021-44228 Apache Log4j 2 – Microsoft Security Response Center Microsoft continues our analysis of the remote code execution vulnerability (CVE-2021-44228) related to Apache Log4j (a logging tool used in many Java-based applications) disclosed on 9 Dec 2021. As we and the industry at large continue to gain a deeper understanding of the impact of this threat, we will publish technical information to help customers detect, investigate, and mitigate attacks, as well as guidance for using Microsoft security solutions to increase resilience against related attacks. We will update this blog with information and protection details as they become available. In addition to monitoring the threat landscape for attacks and developing customer protections, our security teams have been analyzing our products and services to understand where Apache Log4j may be used and are taking expedited steps to mitigate any instances. If we identify any customer impact, we will notify the affected party. Our investigation to date has identified mitigation steps customers could take in their environments as well as on our services.
AD Connect MSOL_ User + Suspected DCSync Attack
We use AD Connect in order to replicate our on premise AD accounts to Azure AD. The replication process is completed under the context of the 'MSOL_xxxxxxxx' user account. The AD Connect application is installed on a member server (i.e. not on a DC). AATP is reporting "Suspected DCSync attack (replication of directory services)" for the MSOL_ user account running on that member server. This appears to be a false positive. Is this a known issue/false positive?
Suspected brute-force attack and None of the passwords attempted where previously used passwords
Suspected brute-force attack (Kerberos, NTLM) and None of the passwords attempted where previously used passwords. This makes me wonder. It knows it is a password that was not used before. But did the account try to login 100x times with this password or did it do 100x times a try with 100 passwords that where not used before. If it is the 100 tries with just 1 never used password it is possible just someone who made a typo in a script (password) for example. If it was 100 different password it is a much bigger issue. I can not find this the documentation how i should read this. I am also not aware if there is a option to figure this out (kusto query for example). Anyone a idea?
Events
in 13 hours
Accidental changes and security compromises can quickly cascade across your tenant. Learn how to recover with confidence using Microsoft Entra Backup and Recovery.
Tune in to see how this Microsof...
Online
Purview Lightning Talks Join the Microsoft Security Community for Purview Lightning Talks; quick technical sessions delivered by the community, for the community.
You’ll pick up practical Pu...
Online
Recent Blogs
- We are excited to introduce the new home of the Microsoft Security Community! At aka.ms/securitycommunity, you can explore upcoming events, access technical content, and find new ways to connect wi...Apr 21, 2026
- 6 MIN READMicrosoft 365 Copilot is redefining how organizations work, bringing the power of generative AI directly into our secure productivity tools. As Copilot adoption accelerates, we’ve heard that you want...Apr 21, 2026
