Office 365 configuration sso

You must use the federated domain in the wizard with an admin user in that federated domain.

[quote=“codedmind, post:11, topic:6000”]
member = ah.list_groups(objectid=member_id)
[…]
univention.office365.azure_handler.ResourceNotFoundError: Resource ‘da857017-fc00-4c7e-b7dd-3e7577d1e59b’ does not exist or one of its queried reference-property objects are not present.[/quote]
One of the existing office365-groups has a member-object that is neither user nor group. The script can’t handle that.
I’m interested in fixing that: Can you look at the groups in Azure and check what members they have - if there is something that is neither user nor group?

Hello,

But can i set the primary domain as federated domain?

About the groups i have three types, Security Group, Distribuition list and Security Group in the office 365 in azure active directory i have three differents names Security, Distribuition and Office.

Using powershell do you know any cmd to list the groups resources id? Maybe that way is easy to identify the group

Sorry - no idea - please refer to the Microsoft documentation for that.

@troeder can you guide me if that resource should be find in office365 or in azure?
I view all the groups details inside azure and none of them have that id

Thanks

@troeder ok i find it!!! that resource ID is from an external contact address…
In exchange we can create a contact for example a contat user@company.com will have an external smtp address user@otherdomain.com and all the email that arrive to user@company.com will be delivery in user@otherdomain.com without cost an emailbox and for sequence a license…

So that resource is a MailContact instead a UserMailBox

Any way to solve this?

The connector currently does not support contact entries (see Bug #41257). This means, that you probably currently not be able to synchronize groups. User-sync should not be affected.

Here is a modified version of print_users_and_groups.txt (5.6 KB)
I had to rename it to *.txt, so the forum would allow the upload :wink:
You can rename it back and make it executable, or just run it with
python print_users_and_groups.txt
Please try it out.

Hello troeder.

With that it works without error.

About the other problem (users being created with federated domain instead of primary) should i change the primary domain, federated it and after that make it primary again.

The actual problem with users being created with the federated domain is that the smtp settings is wrong so i must went to the office portal for each user and change/add the smtp of primary domain…

Bump

Almost a year pass and i return to this topic again.
I still have some difficults to understand the best approach.

In azure i have now 3 domains
Domain.onmicrosoft.com
PrimaryDomain.com
SecondDomain.com

The ucs domain is domain.local

After install the connector i follow the instructions and must use the seconddomain.com because only with this domain i can run with sucess the .bat script.

After everything went ok, i try and create a test user with office 365 template, the user was created and the primary email in ucs is test.o365@domain.local and in office 365 the address is test.o365@seconddomain.com

So my problems:

  • what can (if is possible) i do so the users when created area created with the primarydomain.com instead seconddomain.com
  • For the old users what variable i should fill and where so the office 365 username can be fill?

Thanks

As I wrote in comment 12, primarydomain.com must be a federated domain. Here are some resources how to achieve that:

The userPrincipalName (UPN, username in Azure) is calculated from the mailPrimaryAddress (the primary email address in UCS). The local part of a UCS users email address (the part before the @) will be the userPrincipalName for Azure.

@troeder thanks for the reply… isnt the ucs wizard that mark the domain as federated? Since the primarydomain is primary i can’t run the wizard against that domain so i cannot make it federated…

No, that is something that must be done in the Azure Portal. See linked articles.

@troeder sorry wasking again… but the azure connect is an windows server app…

This app could be run only once to federate the domain and the be uninstalled or must be running always?

I don’t have any windows server in prodution…

No application is needed. The configuration change to make a domain federated can be done in the web browser. Please read the linked documentation.

@troeder thanks for the help.

I already read the all links, and only see references to azure ad connect (that is and windows app) via web azure portal in the domain that i what to move to federated i have a link that download the same app

image

@troeder anyway (a variable for instance) to change the smtpaddress for the user? I don’t have the mail module in ucs

I remove the seconddomain

So in azure i have domain.com and onmicrosoft.com, made this one as primary,
run the wizard using domain.com
wizard went ok and domain.com was federated
Can not make domain.com as primary…

More feedback

Using domain.com as federated and using microsoftdomain as primary i can’t login directly via smtp server (for instance printers copy to mail, return authentication error, because the user is something@domain.com)
When login to portal,office.com with something@domain.com i get forward to the ucs local page to do the login again.

So, i guess to solve my situation i need federated the externaldomain.com and some magic so when i created the user in UCS the mailaddress can be @domain.com otherwise must went to office portal and change the smtp address for each created user… as it is, after create the user even if i set Primary e-mail address in UCS advanced create mode the user is created in office 365 with externaldomain.com

Other problem with this is that old users (created in office 365) don’t sync with the ucs directory, instead new users are created…

Anyone can tell me what is the script the create the user in the office portal after the user is created in the ad?

For instance can we create a variable for other verifiied domains that exist in office 365 and choose one of that domains for the user creation?

The reason is, that no password is ever synchronized from UCS to Azure. If you need to login to a office365/azure account with username+password you’ll have to set the password in the Azure portal.

UCS does not know about existing office365/azure users. It is a bit complicated process to connect those to UCS users.

Yes - that is a single sign on (SSO) feature using SAML. All authentication is done by the UCS server, your UCS password never reaches Microsofts servers. You client must be able to resolve ucs-sso.domain.com to your UCS servers IP address.

The problem here is that my printers have configured old o365 users (for instances noreply@domain.com) so users could scan to mail directly from the printer, using the domain.com as federated the printer cannot authenticate (event printer can resolve ucs-sso)

I think i’m able to manage that, be setting immutableid in azure (tricky… but i tested with one user and it succed, maybe lucky… don’t know.

Yep the problem are with the old users that already exists in o365 and the matching (because in my case that users already exist in ucs too but the connector don’t mixed instead create new ones)

About this … what i have done and is working is edit the azure_handler.py file

nano /usr/share/pyshared/univention/office365/azure_handler.py
Search for def create_user and i put

attributes["userPrincipalName"] = attributes["userPrincipalName"].replace('@FEDERATEDDOMAIN','@WANTEDDOMAIN')

With that i’m able to create the office user with the desired domain instead of the federatedone.

Use as your one risk… i’m using it for the past 6 months and eveything is ok. If you change keep in mind to see when the o365 connector is updated if the script change, normally it will happen.

Mastodon