User Profile
lucafabbri365
Brass Contributor
Joined Jan 31, 2019
User Widgets
Recent Discussions
ZAP (Zero-Hour Auto Purge) on internal traffic
Greetings !! Well I have ZAP enabled (Anti-spam inbound policy & Anti-malware policy) and it is working fine with some exceptions. Internal traffic that should be ZAP(ed) reports: "ZAP took no action due to a tenant policy (ZAP disabled)". I suppose there is something else that is preventing ZAP on internal traffic. Do any IP addresses whitelisted in the Connection filter policy (Default) bypass the Anti-spam inbound policy ? Any thoughts ? Thank you.Re: New external sender warning banner appearing
Hello Dan_Snape, yep, I know it is due to the external tag, but the message layout and position is different from what appeared before: Some of our users are still seeing the "old version" so I suppose it's something that is being rolled out these days. I prefer the "new version" because it is more evident and allows me to remove the warning set through the transport rule, which is annoying in all message previews. However is no mention of this change anywhere; that's why I asked.New external sender warning banner appearing
Greetings !!! Starting from this morning (2024-05-06) a new warning banner is appearing on messages received by external senders (just some Exchange Online users in the tenant are affected by this): I was unable to find any article that talks about this addition. Do you ? Thank you.Re: Teams external users with Teams accounts not managed by an organization...
Hello, it seems the issue is still occurring (since TSBenz started this post in far November 2022): we are experiencing the same issue. MS Teams admin center The communication is initiated by our Teams user vs. a Microsoft (consumer) Account; it receives the message, but while trying to approve it the error "Something went wrong. Please try again." appears: Any update about this issue?Block any email clients on Windows except Outlook Web
Greetings, I'm opening this discussion to speak about how to block access to Exchange Online from any email client (Outlook, Windows 10 Mail, new Outlook for Windows, third-party client) on Windows devices (either Intune-unmanaged, Intune-managed, Microsoft Entra joined, Microsoft Entra registered, Microsoft Entra hybrid joined). Outlook web is only allowed. TEST 1 My initial attempt, as mentioned in this post how to block the Outlook desktop app while allow them use the Outlook On the Web (OWA), was to block access through a Conditional Access policy. Target resources: Office 365 Exchange Online Conditions > Device platforms: Windows Phone, Windows, Linux Conditions > Client apps: Mobile apps and desktop clients, Exchange ActiveSync clients, Other clients Grant: Block access Results: I realized it isn't applicable because even if it meets the goal, however it is also blocking applications like Microsoft Teams. TEST 2 I modified the CA policy by allowing access from compliant devices or hybrid joined: Target resources: Office 365, Office 365 Exchange Online and Office 365 SharePoint Online Conditions > Device platforms: Windows Phone, Windows, Linux Conditions > Client apps: Mobile apps and desktop clients, Exchange ActiveSync clients, Other clients Grant: Grant access to Require device to be marked as compliant, Require Microsoft Entra hybrid joined device (Require one of the selected controls) Results: In this way, I can force clients to be compliant (Intune-managed) or hybrid joined, at least; however, I cannot control access from email clients (consider, for example, a scenario in which end-users have Outlook installed for opening file in MSG or EML format). TEST 3 The only way I found to achieve the goal was to take action on Exchange Online, by manipulating these properties for each mailbox via PowerShell (Set-CASMailbox) : MAPIEnabled = false (block Outlook) UniversalOutlookEnabled = false (block Windows Mail app) OneWinNativeOutlookEnabled = false (block new Windows Mail app) It seems even if blocked (2), however I can still configure and access to mailbox via Windows Mail. I also realized (Welcome Sir !!! 🙂) even if the above properties appear at Plan level (Get-CASMailboxPlan), however it isn't possible to set them (Set-CASMailboxPlan); but it is possible to disable, for example, IMAP and POP (?), This solution assumes running a PowerShell script for setting these properties on new mailbox creation. Any other suggestion ?Missing Office 365 apps on the App launcher after creating collection (Azure AD/Entra ID)
Greetings, I'm creating a new App launcher collection on Azure AD/Entra ID portal. The user performing this task has Global Administrator role with no license. The idea is to group Office 365 Apps (Outlook, Calendar People, Delve, OneDrive, SharePoint, etc.) into separate categories (collections) for a simpler user experience. Every time I add any Office 365 app in this new collection (e.g. Microsoft 365) and save it... ...the app disappears on page refresh/reload. This issue doesn't occur if the user (either Global Admin, Cloud Application Admin or Application Admin role) performing the task has an Office 365 license assigned. Is that an expected behavior? I don't understand why it is necessary to waste an Office 365 license for this administrative task. Thank you.Re: Password Expiration with AAD connect Password hash sync
Hello Sujesh1415, assuming you enabled the EnforceCloudPasswordPolicyForPasswordSyncedUsersfeature, as per Microsoft article http://Implement%20password hash synchronization with Azure AD Connect sync: "...Azure AD does not go to each synchronized user to remove the DisablePasswordExpiration value from the PasswordPolicies attribute. Instead, the DisablePasswordExpiration value is removed (None) from PasswordPolicies during the next password hash sync for each user, upon their next password change in on-premises AD". Microsoft recommends enabling EnforceCloudPasswordPolicyForPasswordSyncedUsers prior to enabling password hash sync, so that the initial sync of password hashes does not add the DisablePasswordExpiration value to the PasswordPolicies attribute for the users. But if you enabled the feature AFTER setting up password hash sync, then you have to choices for setting PasswordPolicies to None: Wait for the user’s next password change to occur on the on-premises AD Run a PowerShell script (once) to update it: Single user: Set-AzureADUser -ObjectId <user ID> -PasswordPolicies None​ All users: Get-AzureADUser -All $true | Set-AzureADUser -PasswordPolicies None​ Does it answer to your question ?Wipe with no logged user
Hello Community, I'm writing this post to submit at your opinion an issue related to device wiping through Intune. Scenario There are two Windows 10 21H2 devices, Azure AD joined (no Hybrid), managed by Intune (no Autopilot/hash imported) and assigned to end users. On both I launched a wipe with "Wipe device, and continue to wipe even if device loses power. If you select this option, please be aware that it might prevent some devices running Windows 10 and later from starting up again.". Their status appears as protectedWipe pending... The wipe didn't occur (waiting more that 30 minutes). They are both connected to wired network and can communicate to Internet. There is NO LOGGED user there. After I logged on Windows into one of them, then the wipe started. Does the wipe need a logged user to work ? I suppose, not (there is no reference about this on Microsoft articles - if yes, I didn't find it). Of course, there is a reason about this behavior. Please, any useful information could be appreciated. Meanwhile, I'll start investigating the Intune logs on the device. Thank you, LucaRe: [FIXED] How to prevent sign in page from asking new users for additional security verification
Hello all, is there a way to manage "additional security verification" prompt (no Windows Insider OS) ? Windows Hello for Business (Intune) is not configured; Azure > Properties > Manage Security defaults > already set to No. I noticed it is related to PIN request (for devices joined to Azure AD and managed by Intune): if end-user try to configure PIN, additional security info appears (of course, just first time). Is there a way to force/enable PIN request but disable security verification ?Re: Password Expiration with AAD connect Password hash sync
Hello KoflT, yours is a good question. Well, Fine-grained Password Policy is supported by Azure Active Directory Domain Services (Azure AD DS) for sure. Azure AD DS integrates with existing Azure AD tenant, but is a different service. Definition "Azure Active Directory Domain Services (AD DS) provides managed domain services such as domain join, group policy, lightweight directory access protocol (LDAP), and Kerberos / NTLM authentication. You use these domain services without the need to deploy, manage, and patch domain controllers (DCs) in the cloud." References https://azure.microsoft.com/en-us/updates/aadds-fgpp/ (Microsoft Azure) https://docs.microsoft.com/en-us/azure/active-directory-domain-services/overview#:~:text=Azure%20Active%20Directory%20Domain%20Services%20(AD%20DS)%20provides%20managed%20domain,(DCs)%20in%20the%20cloud. (Microsoft Docs) https://docs.microsoft.com/en-us/azure/active-directory-domain-services/password-policy (Microsoft Docs) Instead, we are speaking about password expiration on Azure AD tenant. This post https://social.msdn.microsoft.com/Forums/vstudio/en-US/5f10faf7-98ec-4681-96e9-4fc987a564e1/onpremise-password-policy-amp-azure-ad-password-policy?forum=WindowsAzureAD (Visual Studio forums) treats the same argument: basically, you can define a password policy per custom domain in Azure AD. I think the logic is the same I described previously: it depends on the password policy set for the custom domain where Azure AD user belongs and the password policy set for the same user, on-premise: if they match the behavior is the same (password will expire at same time), otherwise they will have different expiration time. Please, let me know if it's clear, or I can write down some practical examples. Bye, LucaRe: Password Expiration with AAD connect Password hash sync
ThomasK007, I try to give you a detailed answer. Until you have the EnforceCloudPasswordPolicyForPasswordSyncedUsers disabled (which is the default), an Azure AD user coming from on-premise AD (synced by AAD Connect) has its account password set to Never Expire. "Password expiration policy If a user is in the scope of password hash synchronization, by default the cloud account password is set to Never Expire. You can continue to sign in to your cloud services by using a synchronized password that is expired in your on-premises environment. Your cloud password is updated the next time you change the password in the on-premises environment." Reference: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-password-hash-synchronization#public-preview-of-the-enforcecloudpasswordpolicyforpasswordsyncedusers-feature | Microsoft Docs Once you enable the EnforceCloudPasswordPolicyForPasswordSyncedUsers feature and set the PasswordPolicies attribute to None (instead of DisablePasswordExpiration), the expiration time for an Azure AD user should be calculated referring to read-only attribute LastPasswordChangeTimestamp (you can retrieve it by using the Get-MsolUser cmdlet), depending on expiration policy. Now if you have AAD Connect with password hash sync, same password expiration policy set on both Azure AD and on-premise AD (e.g. 90 days), every time a password is changed on-premise AD, pwdlastset attribute is updated, the password itself synced with Azure AD and the LastPasswordChangeTimestamp updates accordingly - so they both expires at same time (maybe few minutes off); if you also have the password writeback functionality in place (link: https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-writeback | Microsoft Docs) the behavior described above works when the password is change from Azure AD and synced back to on-premise AD. It should be right (please, can someone else confirm that ?) I hope I was clear. Bye, LucaRe: Password Expiration with AAD connect Password hash sync
Hello TimLB, well, we implemented the EnforceCloudPasswordPolicyForPasswordSyncedUsers feature time ago, and set the same password expiration policy like on-premise AD (90 days*) but unfortunately, it was enabled with password hash sync already in place; so every time a new user is synced to Azure AD (initial sync of password) the PasswordPolicies attribute is set to DisablePasswordExpiration value by default. The (manual) solution is to change it via PowerShell: Single user: Set-AzureADUser -ObjectId <user ID> -PasswordPolicies None In bulk: Get-AzureADUser -All $true | Set-AzureADUser -PasswordPolicies None I hope Microsoft can find a more flexible way to manage it. * - There is a limit when there are multiple on-premise AD domains with different password expiration policy, all syncing with same Azure AD tenant through AAD Connect and sharing the same registered domain.
