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.
Related
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)
We're getting a 400 error with the message "Tenant does not have a SPO license" when we try to access the Sharepoint-endpoints in the Microsoft Graph v1.0 API.
We've registered our Azure AD app and assigned Application Permissions (as opposed to Delegated) for the relevant endpoints, as we need to access the endpoints server to server (ie. outside the context of an authenticated user).
The tenant is connected to an Office 365 Business subscription, that we can assign to users, but the tenant in this case is the directory itself and we don't see how we can assign a subscription to that.
It seems there is precious little information available regarding this, and most of it applies to the delegated permissions scenario.
Any help would be greatly appreciated.
If you have purchased an O365 Business subscription, you may still need to be assign SPO (SharePoint Online) license for specific AAD user/ O365 user.
Use your admin account to log into O365 admin center and select a user and assign SPO license.
After clicking on "Edit", you can choose a SharePoint license to assign it to the user.
I am using Redgate Data Platform Studio to transfer data from on-premise SQL Server to Azure-hosted SQL Server. This web-based application has the ability to use an Azure Storage account (for data transfer purpose) simply by logging into my company's ADFS. The web application can successfully see storage accounts inside a subscription (let's call it Subscription A) owned by my ADFS user, when I log in to my company's active directory (via ADFS). Let's call my company's AD Directory A.
I also have subscription B owned by a Microsoft account NOT related to my company's Active Directory. This subscription B is managed by another Azure AD Tenant B, with that Microsoft account as the Service Administrator & Owner. To link the two directories, I used B2B State 3 configuration described here. So in Directory B, my Directory A user shows up as Guest User with the Source=External Azure Active Directory.
For the storage accounts in Directory B, I grant the built-in role "Storage Blob Data Contributor" and "Storage Account Contributor" to the Guest User (source=external AAD Directory A). Therefore, in both Microsoft Azure Storage Explorer as well as in portal.azure.com I can see storage accounts inside Subscription B.
BUT if I log in to the Redgate application using Directory A credential (via my company's ADFS), only storage account inside Subscription A shows up in the Redgate application. I already tried giving the guest user in Directory B the following roles to the user, even at the highest Subscription B level, but no luck:
As Co-Administrator
As Contributor
As Storage Account Contributor
As Storage Blob Data Owner
My question: is this the application's limitation of not being able to access subscription in another directory (B), or is there some configuration either in directory A/B and/or subscription A/B that I need to set?
Is this the application's limitation of not being able to access subscription in another directory?
As per my official document and my understanding you cannot assign your subscription among many directory.
As said on official document "Multiple subscriptions can trust the
same Azure AD directory, but each subscription can only trust a single directory".
See the below screen shot and refer here
Note: When you associate a subscription to a different directory, users that have roles assigned using role-based access control (RBAC)
will lose their access. Classic subscription administrators
(Service Administrator and Co-Administrators) will also lose
access. Please check the Important Note here
If you want to know more details please refer this docs
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,
I am having a very tough time figuring out the permissions in my database. My users gain access to the database through reports on SharePoint (via Impersonated authentication configured through Kerberos). Users, who are impersonated, are all added to AD Groups. And in my database, I am granting permissions to the AD GROUPS (as logins) and NOT to the individual users. I have 1000 users but 10 AD Groups. Each user is part of an AD Group.
The users currently cannot have access to the database – they are only able to see the database if I was to add them individually as logins (obviously not an option). If I add their AD Group, it doesn’t seem like it works. Again, they are authenticated through Kerberos as impersonated accounts. Here is a map of what I’m saying:
IF the AD GROUP has permission, why doesn't the user within has permission??
I reviewed this question, but I'm not sure where is the equivalent for SharePoint Integrated mode.