Let me preface this by saying I'm not that familiar at all with Azure AD, and that this is basically something I've inherited.
We have Azure AD Sync set up to sync our on-premises AD to Azure.
We've recently upgraded our SSO solution, and it's now authenticating against Azure AD. We've ran into a problem as not all of our users attributes are syncing correctly.
All these users have their on-premises mail attribute set in the form of:
jdoe#subdomain.domain.com
However, for a majority of our users that we've tracked down to, anyone created after 2018/2019 does not sync their mail attribute to this format. Instead, their mail attribute in Azure is set in the following format:
SamAccountName#domain.com
Note that for our users SamAccountName and their mail attribute do differ in the format used for the naming schema.
Now, for those who were created pre 2018/2019, their mail attribute in Azure is syncing properly in the format of:
jdoe#subdomain.domain.com
The only thing we can think of is that pre that date, we had been using one automated solution to generate our users accounts, and then post that date we switched to a different provider.
That new generation process includes a once a day provisioning of accounts into Office365.
We need these attributes to be sync'd correctly with the jdoe#subdomain.domain.com format in order to work with one of our SSO integrations.
Any thoughts on what the issue is and how to resolve it?
Solution:
After some testing, it was determined that licensing for Office365 is the culprit.
When we would assign our users licensing (Specifically Office 365 A1 for students), the following two applications would cause the overwrite of that attribute:
Information Barriers
Exchange Online
As long as the user is not licensed for those applications, everything works as expected.
Related
Need to continuously sync(not just once) photos of users into AD environment, and then into Azure AD. According to the article below, this attribute is only synced one time on initial sync. These photos are updated by our Security group when someone gets a new badge and then we update the photo in AD. Can they sync these ongoing, on a continuous basis, using the AD Connect tool? If so, do we have a document that can assist my customer with this type of configuration/need?
https://support.microsoft.com/en-us/help/3062745/user-photos-aren-t-synced-from-the-on-premises-environment-to-exchange
As stated in the article, for now, the only method I see available for you to use, is the Set-UserPhoto cmdlet.
Br,
Our company has a Microsoft Azure account (Pay-As-You-Go).
We had a programmer that developed our web app. We gave him full access to our Azure account. So, he had access to everything.
We intend to hire another developer to make modifications to the web app, so he'll need access to the App Services and SQL Databases. Our intention is to just allow him access to those features.
We did our research and came across the documentation, Resources, roles, and access control in Application Insights. We followed it step by step, but there's an issue. Doc LINK
We tested the procedure by adding one of our IT staff's Microsoft account (personal Outlook.com account) and assigning him the Contributor role, and sent him an invite. He's not seeing the invite. We did the same for another staff, but it's the same problem.
Can we get some assistance please?
It was not working earlier .I tried with one gmail id. Now it is working perfectly fine and I am able to receive the invitation email.
To send invitation, you need to go to active directory. Add user's email as a guest under add user option (Add guest user).
I started with an Office 365 account, then merged my user list with Azure Active Directory. I have now setup a new (first time) domain controller, as I now wish to have apply some group policies to Office 365/Azure users.
I have a verified domain in Azure (we'll call it abcd.com), as well as a default abcd.onmicrosoft.com domain. In my local active directory I have a domain of corp.abcd.com an added an additional domain of abcd.com. I have changed a few users to [username]#abcd.com, and put in their e-mail address in the "Mail" field in the general tab in AD.
In my Azure AD - all users have the UPN format of [username]#abcd.com. I am trying to keep existing users and user names in AzureAD, and sync them with my local AD.
When I try to run the using AADSync, I get the following error (actual domain replaced with abcd.com below):
Unable to update this
object because the following attributes associated with this object have values
that may already be associated with another object in your local directory
services: [ProxyAddresses SMTP:ABossio#abcd.com;UserPrincipalName abossio#abcd.com;]. Correct or remove
the duplicate values in your local directory. Please refer to http://support.microsoft.com/kb/2647098
for more information on identifying objects with duplicate attribute values.
What is the best and easiest way that I can synchronize my Azure AD users with a local domain - for what it's worth, I have nothing important in my local AD or domain controller.
In another forum, a person suggested using the powershell script here:
http://365lab.net/2014/04/18/office-365-migrate-from-cloud-identities-to-dirsync/
First I deleted all users (which was a key step), then I manually recreated them, and ran the script above. I am now properly sync'd.
We have a number of Azure subscriptions with various co-administrators in our environment. To date, we have used people's Microsoft accounts to grant co-administrator rights, and of course many use their corporate [username]#[company domain] email address for these.
Some time ago, we enabled Azure directory, synchronized to our on-premise AD, where accounts have also been # - and all was good. When adding new co-admins, we simply had to choose if we wanted to use their MS account or their organizational account.
However, we're now seeing the following error when adding some users' Microsoft accounts to some subscriptions:
The Microsoft Account '[username]#[company domain]' cannot be made a co-administrator as its domain is the same as one of the Verified Domains of the target subscription's directory.
Has anyone else seen this - is it an intentional change in behaviour? It seems somewhat inconsistent...
i had the same issue, then I used the new preview portal and it worked.
try it out
According to Microsoft support, this change in behavior is intentional.
(Since posting the question, they have also sent email notifications that any co-admins with Microsoft accounts outside of the Azure Directory will be added as guest accounts in the subscription's directory.)
First, a little background: We have an intranet site based on WSS 3.0 that is hosted on a server in DOMAIN_A.LOCAL and set up to use Integrated Windows Authentication to authenticate users against Active Directory user accounts of DOMAIN_A.LOCAL.
This setup works just fine for users who are logged into Windows using an AD account from DOMAIN_A.LOCAL, but when users try to access the site from a PC logged into Windows using an AD account from a different domain (i.e. DOMAIN_B.LOCAL) the following problems occur:
The user must manually enter their credentials as DOMAIN_A\UserName rather than just UserName because otherwise, Internet Explorer automatically inserts DOMAIN_B and causes authentication to fail.
Once logged in, if the user does something that requires the browser to pass their authentication through to a client app, such as clicking on a Microsoft Office document in a document library in order to open it for editing, it appears that invalid credentials (presumably DOMAIN_B) are passed automatically, thus forcing the user to manually enter their DOMAIN_A credentials again.
My question, then is this:
Is there any way to implement a "default domain" type of behavior when using Integrated Windows Authentication (as can be done when using Basic clear text authentication) so that if a user on DOMAIN_B does not enter a domain before their user name, DOMAIN_A is inserted automatically for them?
Of course, I realize this deployment may be fatally flawed, so I am also open to suggestions for a different implementation.
In summary, the main problem stems from two different kinds of users needing to access the same content on one SharePoint site. The users in DOMAIN_A all have their own full-time workstations where they log into Windows as themselves. The users in DOMAIN_B unfortunately have to use shared computers that are logged on using generic "kiosk" type accounts that have no permissions in SharePoint -- thus the requirement that the DOMAIN_B users must provide their credentials on demand when accessing a given page in SharePoint. I would like to preserve the convenience of the Integrated Windows Authentication for the "static" users of DOMAIN_A while minimizing the amount of manual authentication that the "kiosk" users in DOMAIN_B have to endure.
DOMAIN_A.LOCAL must trust DOMAIN_B.LOCAL, otherwise users from DOMAIN_B.LOCAL will receivie a credential prompt since their DOMAIN_B.LOCAL account is unknown within DOMAIN_A.LOCAL.
Given that DOMAIN_B.LOCAL is for kisok users, you probably do not want to trust this domain.
You will need to extend the web application into a new zone and either implement forms based authentication, or use Windows Authentication with a reverse proxy such as ISA server.
I was searching the internet for SharePoint user accounts with multiple domains and came across an interesting tool called Microsoft Front End Identity Manager. Have you heard of it?
So… If your using a multi forest deployment where user accounts are distributed across two or more forests. This is often seen when two organizations merge and need to access domains from both organizations. You can use the distinguished name (ms-ds-Source-Object-DN) attribute in the user object to create an association between the user accounts. In this association one account is considered the primary account and the others are the alternates of the primary account. There is a tool called Microsoft Front End Identity Manager to create this relationship between user account objects. One feature of Microsoft Front End Identity Manager is that SharePoint server can maintain a list of alternate accounts by which the profile is identified. When you use either account to find the profile of a user, SharePoint server returns the primary account profile example (domain\username).
Probably not what you want to hear, but you may want to resort to forms based authentication.
Unfortunately if you want to retain the Microsoft Office integration (which is what it seems you want), you will have to stick with Windows Authentication. Using Forms Authentication will remove most of the features you seem keen to preserve, there is more information here.
Ideally you want to use the suggestion that Jason mentioned, which would be some sort of reverse proxy. However there would probably be a cost implication if you don't already have something like ISA server, so in reality it's probably best for the DOMAIN_B's to learn to type DOMAIN_B\ before their username.