https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/interactive-logon-message-text-for-users-attempting-to-log-on
Can an interactive login be done for every staff member's windows account via Azure AD?
• Yes, you can surely configure an interactive logon message for those devices that are joined to Azure AD domain and are logged in with cloud user identity. Also, please note that this can also work in Hybrid Azure AD joined devices, i.e., devices joined to on-premises AD as well as Azure AD. For this purpose, you will have to enroll these devices in Intune MDM by purchasing Intune licenses for your Azure AD joined devices.
• Through the Intune portal, you will have to follow the below steps to configure the interactive logon message for Intune enrolled Azure AD joined Windows devices: -
a. Sign in to the https://endpoint.microsoft.com/. To create a new Configuration profile, Select Devices --> Windows --> Configuration profiles --> Create profile.
b. In the ‘Create a profile’ section, Select Platform as Windows 10, and later and in Profile, Select Profile Type as Settings catalog. Click on ‘Create’ button.
c. On the Basics tab, enter a descriptive name, such as Interactive logon Message for users. Optionally, enter a Description for the policy, then select Next.
d. In Configuration settings, under Settings catalog, click Add settings, then select ‘Local Policies security options’ to see all settings in this category.
e. Then select Interactive logon Message Title for Users Attempting to Log On, Interactive logon Message Text for Users Attempting To Log On and then after adding your settings, click the cross mark at the right-hand corner to close the settings picker.
f. Then under Assignments, In Included groups, click Add groups and then choose Select groups to include one or more groups. Click Next to continue. You can assign a tag to filter the profile to specific IT groups in-Scope tags. Add scope tags (if required) and click Next. In Review + create, review your settings. When you select Create, your changes are saved, and the profile is assigned.
In this way, we can configure the interactive logon message for Azure AD logged in users on Windows devices.
Related
I have created guest users in my Azure AD tenant by sending invitations via email following this link https://learn.microsoft.com/en-us/azure/active-directory/external-identities/b2b-quickstart-add-guest-users-portal.
The guest users are added to my tenant once they accept the invitation.
Now I have assigned some applications to the guest users that they can access.
To enhance the security, I want to enable two-factor authentication for the guest users when they are accessing the application.
Is it possible to enable MFA for the guest users? If yes, can anyone guide me with the steps
Yes, it is possible to enable MFA for guest users.
To achieve your requirement, please follow the below steps:
Make sure whether you have Azure AD premium P1 or P2 license which is necessary to create conditional access policy.
To create conditional access policy,
Go to Azure portal -> Azure Active directory -> Security -> Conditional access -> Policies -> New policy.
In Grant tab, Select "Grant access" and Check mark "Required Multi factor authentication". Enable policy by selecting it On and Create.
I have tried in my environment, after creating policy I signed in as a guest user from Incognito window and it prompted for two factor authentication like below:
I would like to know how can I add a windows AD group into a custom claim on Azure AD? I am looking to use AD groups for applications running on a platform that uses role-claims or custom claims to enable applications to have access groups or AD groups separately.
• You can add the custom group claims in a token configuration for your application deployed in Azure AD as follows. Also, since you are adding AD groups, it is considered that those groups are synchronized from on-premises AD through Azure AD Connect to be used as group claims in token configuration.
To configure group claims, go to your configured application in Azure AD enterprise applications, click on the application and select ‘Single Sign On’ User Attributes & Claims Add a group claim Use the radio buttons to select the ‘Security groups’ option as below
To emit groups using Active Directory attributes synced from Active Directory instead of Azure AD objectIDs select the required format from the drop-down. Only groups synchronized from Active Directory will be included in the claims.
To configure the group claim as a custom claim role by giving it a custom claim name, select the box ‘Customize the name of the group claim’ as below while also checking the box ‘Emit groups as role claims’ to use the group as a role claim in your application. Please take into consideration that if the option to emit group data as roles is used, only groups will appear in the role claim. Any Application Roles the user is assigned will not appear in the role claim.
Thus, you can configure AD groups as role claims for an application in Azure AD. Please find the documentation link for reference: -
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims#add-group-claims-to-tokens-for-saml-applications-using-sso-configuration
We have an application which parses the Audit Logs emitted by Azure AD. More specifically we are parsing the 'Update application' log to detect when a new Role has been added to an Application (see example below).
We would like to find out more information about the "DirectAccessGrantTypes" and "ImpersonationAccessGrantTypes" fields. If someone can point us to documentation for this that would be great.
[{"EntitlementEncodingVersion":2,"EntitlementId":"654a4f1f-1b7f-4354-a6d6-fcf7346af0ec","IsDisabled":true,"Origin":0,"Name":"Data Manager","Description":"Manager for test app","Definition":null,"ClaimValue":"DataManager","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[20],"ImpersonationAccessGrantTypes":[],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]},{"EntitlementEncodingVersion":2,"EntitlementId":"3d03256d-cf0c-4553-b8af-98d7ebbee1f2","IsDisabled":false,"Origin":0,"Name":"Application Manager","Description":"Admin for test app","Definition":null,"ClaimValue":"ApplicationManager","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[20],"ImpersonationAccessGrantTypes":[],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]},{"EntitlementEncodingVersion":2,"EntitlementId":"88d0d3e3-b661-4760-aea3-f4548db1ff96","IsDisabled":false,"Origin":0,"Name":"Read","Description":"Allow users to add a admin consent","Definition":null,"ClaimValue":"Read","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[],"ImpersonationAccessGrantTypes":[{"Impersonator":29,"Impersonated":20}],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]}]
From article > View reports & logs in entitlement management - Azure AD | Microsoft Docs
When Azure AD receives a new request, it writes an audit record, in
which the Category is EntitlementManagement and the Activity is
typically User requests access package assignment. In the case of a
direct assignment created in the Azure portal, the Activity field of
the audit record is Administrator directly assigns user to access package, and the user performing the assignment is identified by the
ActorUserPrincipalName.
Application Impersonation is basically an administrator-managed, not user-managed permission.
Impersonate access grants logs gives information ex:count., of users given consent by the admin to access the application to impersonate user.
ImpersonationAccessGrantTypes gives count or info of access grants by admin on behalf of user whereas DirectAccessGrantTypes gives info about the users who directly access the application ,as they are already assigned by admin.
Reference:
Multiple Client applications authorisation to WebApi (microsoft.com)
I have a question. Does anybody know what the exact off-boarding process would look like for an Azure AD user that is synchronized from an on-premise AD (Windows server AD, see picture below)?
I know what it's like for a normal Azure AD user (I got the information from here: https://www.agileit.com/news/offboarding-office-365/), but I would need to know if there are any differences (for example: differences to completely delete a user, differences in saving OneDrive content, ..).
Here is the process of offboarding a normal Azure AD user (summarized in my own words):
Sign the user out of OneDrive (initiate sign-out in Microsoft 365 admin center)
Logging the user out of all current sessions:
- Resetting user password in the Microsoft 365 admin center: Create or generate a new password
Save mailbox content:
- Either:
- Migrate the mailbox to another user
- Place the mailbox on Litigation Hold (In-Place Hold, via the Exchange Admin Center)
- Converting to a shared mailbox
(if the offboarding employee has a company owned mobile device) blocking and wiping the employee’s mobile device:
- Wipe data & block under Mobile devices (via Exchange Admin center)
Block access to Office 365 data (after logging the user out of his current sessions) via Microsoft 365 admin center
Remove the Office 365 license from the user (via Microsoft 365 admin center)
Remove the license so the payment for it stops (via Microsoft 365 admin center)
Deleting the user account (via Microsoft 365 admin center)
If any of you guys know any differences, please help me out. Thank you!
most of your points about azure ad user apply to a sync'ed ad user as well.
some of the differences would be after logging user out of all current sessions, they wouldn't be logged off of on prem sessions that are logged in via on-prem ad.
I believe the main difference comes in when / how you delete the user. if you disable the user on prem, and it no longer syncs that user to aad, that user will be deleted from aad. along with all the ramifications of deleting the user on aad, mailbox deleted, etc. Basically treat on-prem ad unsync as a delete operation on azure ad. that's the biggest difference.
one of the caveats with both aad and ad deletion is, if you turn the mailbox into a shared mailbox, it still has to be anchored to a user. so if you deleted the user that its anchored to, the mailbox will be in an orphaned state. so be careful with that.
as for one drive, when the user is deleted from aad, their "manager" will automatically get access to their onedrive content for some period of time, usually 30 days, because the content is deleted.
Again, so if you stop syncing a user to azure ad from on-prem, azure ad treats it as a delete operation.
All this to say, all the other steps in that article are azure/o365 related, so follow all those steps, and for the last step of delete, don't delete it from azure ad. Just unsync it or delete from on prem.
When I log onto the Microsoft Graph Explorer with my Microsoft account and run the following query https://graph.microsoft.com/v1.0/users/ I get the correct user returned.
On Azure AD (using the same login) I created an application with a key and when I sign in through c# using Microsoft.IdentityModel.Clients.ActiveDirectory.ClientCredentials with a token for resource https://graph.microsoft.com and run the same query I get a completely different user. They are out of sync and I'm baffled.
Any ideas? Should I create a new Azure account as I've had the Azure account from day 1 and I'm only doing this now to test for a client request.
Don't create a new Azure account. When you are using Graph Explorer, are you signed in with a user from your Azure AD tenant? If not, Graph Explorer will default to use a demo tenant for your queries.
Also (if you have more than one tenant) you need to make sure that you select the correct tenant as part of the token acquisition (from https://login.microsoftonline.com/{tenantId | tenantDomain}. If you want the results to match between Graph Explorer and your app, the tenant the signed-in user belongs to (for Graph Explorer case) and the tenant used by your app needs to be the same.
UPDATE based on comment below:
I think I know what's going on here. In graph explorer, you are signing in with your personal account - and it's showing you profile data of that personal account, including the unique ID for this account in the Microsoft Account system. In this case you aren't signing into an Azure AD tenant at all. Microsoft Graph supports access from both personal and commercial accounts.
Now, additionally, I'm guessing when you signed up for an Azure subscription, you used this personal account. When you do that, it creates an Azure AD tenant, and creates a guest user in that tenant that is (linked to) your personal account - this account is also configured as an admin account. This mechanism allows you to sign in with your personal account (authenticated by the Microsoft Account system) into an Azure AD tenant, because the personal account maps to this guest user in your tenant. In your application, you are getting an app token to your Azure AD tenant. When you query the tenant for users, you don't see any user with the same id or email address as you did with graph explorer. However if you actually look at the userPrincipalName, you'll see it should be a mangled form of the original email address of your personal account. This indicates that this Azure AD user account in your tenant is a guest/external user (similar to a foreign principal).
Hope this helps,