I've been unable to get this working with Azure AD. I have a case open with ConnectWise. They said they are aware of an issue and will get back to me. This is the cloud version, but I assume it's the same.

Any update? I'm trying the same and having a lot of issues with figuring out what is supposed to go in the Screenconnect fields.

Originally Posted by: joey52685

I've been unable to get this working with Azure AD. I have a case open with ConnectWise. They said they are aware of an issue and will get back to me. This is the cloud version, but I assume it's the same.

Any update? I'm trying the same and having a lot of issues with figuring out what is supposed to go in the Screenconnect fields.

Originally Posted by: joey52685

I've been unable to get this working with Azure AD. I have a case open with ConnectWise. They said they are aware of an issue and will get back to me. This is the cloud version, but I assume it's the same.

If you were able to get it working let me know.

I was able to get SC On-Prem with Azure AD. Values:

IdentityProviderURL - <You have to get this from your TenantID when you Register the Application >

I worked with Ryan from SC and we got it working, if you are having trouble the first thing to do is blow away your App Registration and start fresh. If I don't mention changing a setting then leave it on default options.

Back on the Azure AD side, create a new App Registration, for the Sign-on url just use the url for your screenconnect installation (ex: https://mycompany.screenconnect.com)Goto Settings properties and change the App ID URI to the value you copied out of the SC XML Manifest file (ex: https://mycompany.screen...-84b8-6af1de93db8f/Login )Click Reply URLs and add the same URL (https://mycompany.screenconnect.com/__Authentication/bbbbbbbb-aaaa-49e7-84b8-6af1de93db8f/Login ) to this list do not remove the entry that is already there.

Return to Azure AD and click Enterprise Applications, click the app you just registered.Click Users and Groups and add the AD groups or users to assign to each role type.There is no need to change anything else on this interface.

What I noticed in recreating the app registration from scratch is that for some reason something I clicked on changed the manifest on the Azure side to have 2 additional user roles that did not exist on the SC side, which might have been why it didn't seem to work.

Also if you are wondering where did you get the id values for the Administrator and Host in the manifest, they're just random, they just have to be unique to your instance, so copy mine or make up your own it shouldn't matter.

I just wanted to post and say THANK YOU to PhilFCS for the writeup. CW should take your instructions and add them to their official docs. This was a great walkthrough and it's working perfectly for us after following your steps. Thanks for sharing.

Got this working with some help from SC support. Basically the same as PhilFCS's instructions.

BUT ScreenConnect doesn't log out of Azure AD when you log out of ScreenConnect. The result is that you can sign back into ScreenConnect without re-authenticating. Obviously this is a major security issue and we haven't put this feature into production because of it. Is everyone else seeing the same behavior? Anyone have a fix?

Yes, we see the same behavior, but I'm not sure I agree about it being a major security issue. This is the nature of how Single-Sign-On works. You're authenticating to the identity provider and as long as that token is active/live, you can 'login' to any systems protected by that identity without being forced to re-authenticate. We enjoy logging into Azure AD (O365) one time in a browser session and then having full access to the O365 suite and all connected apps (like CW Control) without being forced to re-auth constantly. All of our staff are forced to use MFA for Azure AD so we have that added layer of security as well.

In general, our staff are accessing these systems from their work-provided laptop. On the rare occasion they use a 3rd-party machine (home, relatives, client, etc.), they are instructed to never 'remember' their sessions. And due to MFA we're relatively well protected there too.

Yes, we see the same behavior, but I'm not sure I agree about it being a major security issue. This is the nature of how Single-Sign-On works. You're authenticating to the identity provider and as long as that token is active/live, you can 'login' to any systems protected by that identity without being forced to re-authenticate. We enjoy logging into Azure AD (O365) one time in a browser session and then having full access to the O365 suite and all connected apps (like CW Control) without being forced to re-auth constantly. All of our staff are forced to use MFA for Azure AD so we have that added layer of security as well.

In general, our staff are accessing these systems from their work-provided laptop. On the rare occasion they use a 3rd-party machine (home, relatives, client, etc.), they are instructed to never 'remember' their sessions. And due to MFA we're relatively well protected there too.

All of our other enterprise apps in Azure AD redirect to the Azure SAML logout URL on logout, Screenconnect is an outlier. If we want to remain logged in we just close the tab without logging out.

This is an issue on external workstations. Domain-joined machines utilize Seamless SSO with AADConnect they never get prompted for credentials, so less of a concern on domain machines.

Followed those instructions, but when click on connect.. get SAML Configuration Error (https://login.microsoftonline.com/.../federationmetadata/2007-06/federationmetadata.xml): Text node cannot appear in this state. Line 1, position 1.

Frustrating, made it all the way through the guide at https://docs.connectwise...n/Set_up_SAML_with_Azure for configuring SAML with Azure, ran into the error "SAML Configuration Error (https://login.microsoftonline.com/008cf2cb-...d44/federationmetadata/2007-06/federationmetadata.xml): Text node cannot appear in this state. Line 1, position 1." Searched all over, this thread came up, someone had the problem but didn't post what the solution was, and I even upgraded from 6.6 to the latest 6.9 as part of troubleshooting.

Finally try to get Chat support online (they're not there), recreated both ends of the configuration, and finally finally, I poked around at the previous article in the docs on SAML at a high level (not AzureAD, which I found specifically when searching Google for integration docs), I got to https://docs.connectwise...rces/SAML_single_sign-on which says "Important: SAML single sign-on is not available on Linux and Mac servers."

That's really frustrating that it was on a completely different page than the AzureAD setup instructions! I assume the error I'm getting is because I'm running on Linux, yet I just wasted about 2 hours configuring and troubleshooting because the big warning was on a completely separate page :-(

You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.