Onsite Username/Password and Windows Authentication

Thanks for the heads-up Tony! Does this mean that you need to disable Anonymous authentication and only allow Windows Authentication in IIS? So you can't mix AD and not-AD connected users?

Support for AAD in OnSite would also be very great, we hear this wish/requirement a lot.

Hi Tony,

do you know which version this functionality broke? Is it relevant for 10.1.5? We've just upgraded a customer from 9.2 R3 to 10.1.5, and we're having some issues with using Active Directory username and password.

And like David says, does this mean you can't mix AD and non-AD users?

Tony,

Could you please elaborate a bit which parts that will and will not work as well as some status regarding the functionality, is this implemented in SO 10.1.5 or will it come in a later release?

1. When it comes to the AD-functionality, is there differences between 10.0.6, 10.1.2 and 10.1.5 (all onsite)? If so, what are the differences?
2. Will it still be possible to mix local AD-login via SSO as well as using pure SO-user-login or will only SSO be possible when having Win Auth enabled?

Best Regards
Marcus

Hi, Tony

At the moment we will wait to install 10.1.5 for customers, as many are still using AD authentication, and we need to prepare them, if this breaks. 

We tried setting up SSO for the only customer that has this version and so far no success.

We followed this guide

Single sign-on | SuperOffice Docs

Is there a newer one or is this still the go to guide?

Hi, this was bad news. I also want to know how to solve the mix of SSO AD logins and plain SO-users?
On prem customers using AD login would probably not just want to switch to SO-based username/password.

(Often at least one or 2 users in a setup uses password often an Admin account that we as partner use, and or the CRMX-account to be able to login to admin-client for)

//Anders

Hi,

Introducing these kind of breaking changes without even mentioning them in the release notes seems a bit odd? Makes me wonder if someone in R&D gone haywire all on his/her own initiative regarding authentication... 😉

Seriously, who dares to upgrade a customer that uses ADauth to 10.1.5 at all? 

How can system accounts still work mixed with AD accounts if the old username/password accounts cannot? Aren't they authenticated exactly the same way? Or do we have to resort to setting up double sites, one for winauth and one for anonymous, like in the old days? Or have I misinterpreted  everything? 🙃

Everyone here has lots of questions, I hope you're working on finding the answers, poor 😊 Tony 🙏🏼

Best regards,

Jan

I just learned about this forum thread after a failed attempt to upgrade a customer yesterday to version 10.1.5. We ended up on 10.1.2 after long time struggeling.

I agree that at least, there should be a warning in the release-notes. 

Ill second Marcus' questions above, and add "How does this change affect TravelGateway login? Is a system user enough?"

Hello,

I hope I'll be able to clarify some things here.

What has changed

In the previous SuperOffice versions, when you supplied credentials to the SuperOffice login dialog, NetServer tried to authenticate the user against SuperOffice database and when it failed, it tried also against AD. This system allowed for a mix of both SuperOffice logins and AD logins without any additional setup.

There were several issues with this functionality. The biggest problem was, if a user had the same username in SuperOffice and in AD, the AD account could be locked out after several wrong logging attempts.

As Tony mentioned in the first post, this functionality in NetServer to also try to log in a user to AD has been removed.

When the change was made

It has been removed in SuperOffice 10.1.5.

Can we mix SO loggins and AD loggins now?

No, at least not in one SuperOffice configuration. For AD authentication to work, Anonymous authentication needs to be turned off on IIS and you need to use Windows authentication.

Should you still need to use SO login for some users, you need to install second instance of SuperOffice Web and keep Anonymous authetication there.

Single Sign On

The Single Sign On guide is still valid, apart from one sentence: SSO will not work when using the recommended installation scenario, but the user may still authenticate with their AD username and password. - this is not valid since 10.1.5 and the guide will be changed accordingly soon.

Service and Pocket CRM

Customer Service & Pocket CRM must use a separate NetServer site where Windows Authentication is turned off. It can point to the same physical path as NetServer for Sales but with its own IIS Application with Windows auth turned off.

Travel Gateway

For Travel gateway system user is enough.

Hi Martin

Thank you for clarifying. The changes are needed and if it breaks it breaks.

I knew about this forum thread and the upcoming changes. 

The missing part here is the lack of notice in release notes.

Since we were not aware of the changes, when installing 10.1.5

"There were several issues with this functionality. The biggest problem was, if a user had the same username in SuperOffice and in AD, the AD account could be locked out after several wrong logging attempts."

I don't see how this is an issue, this is exactly what you want if multiple failed login attempts are tried the account SHOULD be locked. This is one of the reasons we recommend customers using AD login, so you don't have to do seperate user management in SuperOffice for when a user leaves or changes password.

Essentialy the setup of SuperOffice is now a lot more complicated when you have customers that use both AD login and SuperOffice. Previously you could have one installation for AD users, Non-AD users, Service and Mobile CRM. Now you always need 2. And is this even going to work correctly if AD users use one application and non-ad another? Does SuperOffice WebTools/Maillink handle this correctly? does Service handle it correctly that sometimes users need to be send to application 1 and others to application 2? (required to set a base url per user/group?). Was this tested?

And you mention that Mobile CRM needs an installation with anonymous auth enabled, how are AD users then supposed to login to Mobile CRM?

This might be connected, we have seen a strange behavior after upgrading to 10.1.15 for all customers that does not use Windows Auth (ourself included), whenever we logout / get timed out we get a Windows auth window, even though we dont have windows Auth enabled anywhere in the IIS.

Anyone else also expirenced it?

If we need two netserver installations for Mobile CRM, how does the mobile client know which netserver to use? 

If it need 2 different urls' it can be very confusing for the users to know which to use.

It is my understanding that Intune gradually is replacing AD membership of computers.  This will in practice mean that computer logs in with Azure AD instead of classic on-prem AD.

SuperOffice CRM Online has good support for Azure AD.  SuperOffice CRM for on-site only support classic on-prem AD.

It would be interesting to learn why customers choose to have some users in AD and some not:

• Is it a license issue where IT is using system users?
• Are only some of the users in on-prem AD and the rest in Azure AD
• Other?

Hi,

InTune is gradually replacing classic AD joined machine's for a lot of customers, but that doesn't mean that they suddenly can migrate to SuperOffice Online (or if that is even economically feasible). The fact that Azure AD login (Using OAuth flow which then includes MFA) is only supported in Online is already a major issue for some customers.

At many customers there is a mix of AD and non-AD users for various reasons, for example:
- Users without AD because they are for external access like consultants or developers
- 'Shared' Accounts that are purely used in a read-only role for people in a production facility or something to look up customer info

Currently we have a very simple setup at many customers, one IIS Site with two applications. One 'Sales' and one 'Service'. External apps, Mobile CRM and Service can all use the same netserver instance.

With this changes we would need atleast 3 applications:
- Sales with Window auth,
- Sales with anonymous auth for Service, Mobile CRM (how do you authenticate Mobile CRM with AD credentials?) and External Apps
- Service

For existing customers this also means that all Mobile CRM users will need to reconfigure since they need another netserver url. And I really wonder if WebTools/Maillink/Service can handle two sales applications where it differs per user which one is used.

hi, before lunch I did found out that a hotfix was relaase for 10.1.5 the 18th of september ? 

What did that solve? Relesenotes still say 13th september as relese date. (and no info on the notes about a hot release) 

Did get suspicious when finding new nuget-packages... released today...
Only first when pushing DL-button you find that information in the filename.

What is happening.

The timing is some what bad with strunglish onprem version since we fight the date of basic auth shutdown by MS...

//Anders

Hello all engaged SuperOfficers.

I must admit: We did a mistake.

We had the best of intentions when it comes to solving a problem and following best practices towards security. Our decision was too quick.

That does not help you right now, so we have decided to re-implement support for a mix of AD users and non-AD users in our Onsite solution

This will be done in version 10.1.6 with ETA 05.10.2022 and until this is released, you should use 10.1.2 for companies that uses AD to authenticate in SuperOffice Onsite.

In a longer term (I’m unable to state a date), we will aim at offering a similar way to authenticate in Onsite installations as we do in Online. This will be based on OpenID connect / Oauth. This will then replace the AD implementation we offer now.  

Thank you for your engagement.

PS! The Release item on the Community should be updated with correct information

Erik

That is great news, Erik.

For all subscribed/watching this thread, 10.1.6 has been released yesterday, crisis averted :)

I would like to ask the RnD team to add links with further information regarding the added "breaking changes"-items below, so they could be understood in detail.

• NetServer requires startup bootstrap prior to API invocations
  • Based on below mentioned answer this only affects the SOAP-API, which could be relevant info for Onsite-integrations.
• Removed LanguageInfoCache
• Changed ImpersonationContext
• Removed CacheBase, all caches to inherit new CacheBaseV2
• Modern authentication (OAuth 2.0) against SuperOffice Inbox and Service mailboxes over IMAP (Microsoft 365 only)
  
  • What differs exactly when it comes to the OAuth 2.0 functionality in 10.1.x vs 10.0.x as OAuth2-support is also included in 10.0.6?
  • I have heard it mentioned that 10.1.x now includes some kind of button that makes it possible to circumvent the Auto-Configuration workflow when adding a OAuth-connected mailbox in Service (which is great if it's true as the automatic workflow at least have given me some problems in a hybrid-environment)

When I asked this specific question for the 10.1.2-release internally, I got the below answer, which might answer some of the parts, but might not give the complete detail picture. But maybe some of these links should be included in the release info to make it easier to find complementary info at least?

1. NetServer requires bootstrap prior to API invocation

All relevant links and details are found in this announcement:
https://community.superoffice.com/en/technical/forums/general-forums/announcements/the-future-of-netserver/

Affects onsite integration that use the following NetServer nuget packages:
https://www.nuget.org/packages/SuperOffice.NetServer.Core
https://www.nuget.org/packages/SuperOffice.NetServer.Services

Integrations using REST web services are unaffected.

2. Modern authentication (OAuth 2.0) against SuperOffice Inbox and Service mailboxes over IMAP (Microsoft 365 only)

This is in product functionality that facilitates OAuth 2.0 authorization with Microsoft services and doesn't warrant additional details. Follow the link and read the specification contents to better understand OAuth details. All we did was implement a client that follows the standard (Authorization code) flow.

I'll forward your experience to the team responsible for this implementation and try to get some answers for you, or at least get you connected to the right person to ask.

3. The following question relates to NetServer core classes and functionality. Only affects people who build onsite plugins.

4. As for used URLs for the OAuth requirements

SuperOffice uses several endpoints under the following URL:
https://accessgateway-{env}.superoffice.com/

Where {env} is either sod, stage or prod.

5. The auto-config workflow (Marcus's own summary)

Here both MX-lookups and the Thunderbird auto-config database is used to try to identify a O365-related domain. If identified, you get redirected to Microsoft s Oauth2 based login.

The Thunderbird lookup uses the following endpoint:
https://autoconfig.thunderbird.net/v1.1/<the domain to search for>

Examples:
https://autoconfig.thunderbird.net/v1.1/office365.com (example of existing domain in the database)
https://autoconfig.thunderbird.net/v1.1/superoffice.com (example of non-existing domain in the database)

Few company domains are found in the Thunderbird-database, so the functionality is mainly based on the MX-lookup.

In some environments, potentially hybrid-environments (both using O365 and internal Exchange Servers), the MX-pointer might not identify as a Microsoft-related domain. In these cases it might be needed to use the "@onmicrosoft.com"-alias for an email account to enforce it to do a lookup related to a Microsoft-domain, to get to the login-page.

If I understand it correctly, this have been solved in SO 10.1.5 and above, by making it possible to click a button to get to Microsofts login page directly, without trying the auto-config-workflow.

The OAuth2-experience for Service - Complementary documentation needed

• What's completely missing in the docs (https://docs.superoffice.com/email/service.html) is the fact that using OAuth2-auth for a mailbox in Service, is dependant on a SO O365/Azure Enterprise App as a middlehand, that needs to be given app access to all mail boxes in a customers O365-environment. A detail that in itselfs could be seen as an issue in some security focused organizations and needs to be discussed with the customer. I have such a case right now.
  
  If there is any practical way of locking down the app access to only give access to certain mail accounts in the customers environment, maybe by using security policies or roles in O365, it would be in SuperOffice's interest to maybe give some helpful guidance how this could be implemented in O365, as I can see this to be a recurring discussion with larger customers.
  
  
• Adding at least the first OAuth-mailbox, might require the access to an O365 Global Admin at the customers for accepting the app. This information is needed for the correct planning and access to the right resources.
  
  
• The authentication workflow will involve a bunch of undocumented endpoints used in the communication. For onsite-environments that is locked down from internet, these explicit endpoints needs to be whitelisted in the firewall, so they need to be added to the documentation.
  
  
• An architectural overview diagram of the involved main-components and the workflows wouldn't hurt. :)