logo
Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Options
Go to last post Go to first unread
adamfasl  
#1 Posted : Wednesday, January 24, 2018 7:06:16 PM(UTC)
adamfasl


Rank: Newbie

Joined: 10/7/2010(UTC)
Posts: 7
Location: Kansas City, MO

We're interested in hooking up our Screenconnect on premise instance to Azure AD with the newly added SAML option.

Has anyone successfully done this? I looked through the KB and best I could tell there's no documentation on SAML yet.
Scott  
#2 Posted : Monday, February 5, 2018 12:25:18 PM(UTC)
Scott


Rank: Administration

Medals: Level 4: Wise Old Owl! Received 100 Thanks!

Joined: 3/28/2014(UTC)
Posts: 2,726
United States

Thanks: 3 times
Was thanked: 332 time(s) in 286 post(s)
As of last thursday or friday-ish we've added SAML documentation, it's available here.

If you have a second, please check it out and let me know if you're still having problems/questions.
ScreenConnect Team
joey52685  
#3 Posted : Friday, February 16, 2018 12:49:42 PM(UTC)
joey52685


Rank: Guest

Joined: 2/16/2018(UTC)
Posts: 4
United States

Was thanked: 1 time(s) in 1 post(s)
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.

Edited by user Friday, February 16, 2018 12:50:32 PM(UTC)  | Reason: Not specified

thanks 1 user thanked joey52685 for this useful post.
PhilFCS on 3/24/2018(UTC)
PhilFCS  
#4 Posted : Saturday, March 24, 2018 8:12:54 PM(UTC)
PhilFCS


Rank: Guest

Joined: 3/24/2018(UTC)
Posts: 3
United States
Location: Ohio

Thanks: 2 times
Was thanked: 1 time(s) in 1 post(s)
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 Go to Quoted Post
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.


tehiota  
#5 Posted : Monday, March 26, 2018 11:57:00 PM(UTC)
tehiota


Rank: Newbie

Joined: 10/30/2014(UTC)
Posts: 5
United States

Was thanked: 1 time(s) in 1 post(s)
Originally Posted by: PhilFCS Go to Quoted Post
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 Go to Quoted Post
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 >

UsernameAttributeKey - http://schemas.xmlsoap.o.../05/identity/claims/name
DisplaynameAttributeKey - http://schemas.microsoft...ntity/claims/displayname
EmailAttributeKey - http://schemas.xmlsoap.o.../05/identity/claims/name
RoleNamesAttributeKey - http://schemas.microsoft.../06/identity/claims/role
thanks 1 user thanked tehiota for this useful post.
PhilFCS on 4/11/2018(UTC)
PhilFCS  
#6 Posted : Wednesday, April 11, 2018 5:12:11 PM(UTC)
PhilFCS


Rank: Guest

Joined: 3/24/2018(UTC)
Posts: 3
United States
Location: Ohio

Thanks: 2 times
Was thanked: 1 time(s) in 1 post(s)
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.

On Azure AD, App Registrations, click Endpoints and copy the first URL (Federation Metadata Document)
On SC side, place this in the IdentityProviderURL
Fill in the next 4 "attributekeys" entries in this order:
http://schemas.xmlsoap.o.../05/identity/claims/name
http://schemas.microsoft...ntity/claims/displayname
http://schemas.xmlsoap.o.../05/identity/claims/name
http://schemas.microsoft.../06/identity/claims/role

The next field is what appears below the login dialog, so I put in "Azure AD" so the login page shows a button "Connect with Azure AD"

Now click the Generate button to get the SC XML data, in this data there is an EntityID url, copy that for use later it should look like this https://mycompany.screen...-84b8-6af1de93db8f/Login


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.

Click on Manifest, it should look something like this:
Code:
{
  "appId": "d8951471-ca41-4d68-8297-4c1c04414f73",
  "appRoles": [
  ],
  "availableToOtherTenants": false,
  "displayName": "Connectwise Control-FIT",
  "errorUrl": null,
  "groupMembershipClaims": null,
  "optionalClaims": null,
  "acceptMappedClaims": null,
  "homepage": "https://mycompany.screenconnect.com",
  "informationalUrls": {
    "privacy": null,
    "termsOfService": null
  },
  "identifierUris": [
    "https://mycompany.screenconnect.com/__Authentication/bbbbbbbb-aaaa-49e7-84b8-6af1de93db8f/Login"
  ],
  "keyCredentials": [],
  "knownClientApplications": [],
  "logoutUrl": null,
  "oauth2AllowImplicitFlow": false,
  "oauth2AllowUrlPathMatching": false,
  "oauth2Permissions": [
    {
      "adminConsentDescription": "Allow the application to access App Name on behalf of the signed-in user.",
      "adminConsentDisplayName": "Access App Name",
      "id": "0172d907-e1f9-4dba-8405-59f2b8e27b14",
      "isEnabled": true,
      "type": "User",
      "userConsentDescription": "Allow the application to access App Name on your behalf.",
      "userConsentDisplayName": "Access App Name",
      "value": "user_impersonation"
    }
  ],
  "oauth2RequirePostResponse": false,
  "objectId": "e8865a5a-3cfd-43fd-92d0-047a7283c456",
  "parentalControlSettings": {
    "countriesBlockedForMinors": [],
    "legalAgeGroupRule": "Allow"
  },
  "passwordCredentials": [],
  "publicClient": false,
  "replyUrls": [
    "https://mycompany.screenconnect.com/__Authentication/18fbcf4a-daf1-49e7-84b8-61d1de93db8f/Login",
    "https://mycompany.screenconnect.com"
  ],
  "requiredResourceAccess": [
    {
      "resourceAppId": "00000002-0000-0000-b000-000000000000",
      "resourceAccess": [
        {
          "id": "31137113-e858-46a1-bdf8-97ff7166d8e6",
          "type": "Scope"
        }
      ]
    }
  ],
  "samlMetadataUrl": null
}



Now you need to add some lines for the roles in your install, I'm working with the default two roles of Administrator and Host so here it what I add between the allowedRoles square brackets:

Code:
    {
      "allowedMemberTypes": [
        "User"
      ],
      "displayName": "Host",
      "id": "ae3ddf96-78c0-413c-9c08-c1e4eb4d5b7e",
      "isEnabled": true,
      "description": "Host",
      "value": "Host"
    },
    {
      "allowedMemberTypes": [
        "User"
      ],
      "displayName": "Administrator",
      "id": "5433acad-2209-46a1-967b-663ab311f646",
      "isEnabled": true,
      "description": "Administrator",
      "value": "Administrator"
    }



Here is what it looks like when you are done:
Code:
{
  "appId": "d8951471-ca41-4d68-8297-4c1c04414f73",
  "appRoles": [
    {
      "allowedMemberTypes": [
        "User"
      ],
      "displayName": "Host",
      "id": "ae3ddf96-78c0-413c-9c08-c1e4eb4d5b7e",
      "isEnabled": true,
      "description": "Host",
      "value": "Host"
    },
    {
      "allowedMemberTypes": [
        "User"
      ],
      "displayName": "Administrator",
      "id": "5433acad-2209-46a1-967b-663ab311f646",
      "isEnabled": true,
      "description": "Administrator",
      "value": "Administrator"
    }
  ],
  "availableToOtherTenants": false,
  "displayName": "Connectwise Control-FIT",
  "errorUrl": null,
  "groupMembershipClaims": null,
  "optionalClaims": null,
  "acceptMappedClaims": null,
  "homepage": "https://mycompany.screenconnect.com",
  "informationalUrls": {
    "privacy": null,
    "termsOfService": null
  },
  "identifierUris": [
    "https://mycompany.screenconnect.com/__Authentication/bbbbbbbb-aaaa-49e7-84b8-6af1de93db8f/Login"
  ],
  "keyCredentials": [],
  "knownClientApplications": [],
  "logoutUrl": null,
  "oauth2AllowImplicitFlow": false,
  "oauth2AllowUrlPathMatching": false,
  "oauth2Permissions": [
    {
      "adminConsentDescription": "Allow the application to access App Name on behalf of the signed-in user.",
      "adminConsentDisplayName": "Access App Name",
      "id": "0172d907-e1f9-4dba-8405-59f2b8e27b14",
      "isEnabled": true,
      "type": "User",
      "userConsentDescription": "Allow the application to access App Name on your behalf.",
      "userConsentDisplayName": "Access App Name",
      "value": "user_impersonation"
    }
  ],
  "oauth2RequirePostResponse": false,
  "objectId": "e8865a5a-3cfd-43fd-92d0-047a7283c456",
  "parentalControlSettings": {
    "countriesBlockedForMinors": [],
    "legalAgeGroupRule": "Allow"
  },
  "passwordCredentials": [],
  "publicClient": false,
  "replyUrls": [
    "https://mycompany.screenconnect.com/__Authentication/18fbcf4a-daf1-49e7-84b8-61d1de93db8f/Login",
    "https://mycompany.screenconnect.com"
  ],
  "requiredResourceAccess": [
    {
      "resourceAppId": "00000002-0000-0000-b000-000000000000",
      "resourceAccess": [
        {
          "id": "31137113-e858-46a1-bdf8-97ff7166d8e6",
          "type": "Scope"
        }
      ]
    }
  ],
  "samlMetadataUrl": null
}


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.





thanks 1 user thanked PhilFCS for this useful post.
tlphipps on 4/23/2018(UTC)
tlphipps  
#7 Posted : Monday, April 23, 2018 2:52:29 AM(UTC)
tlphipps


Rank: Member

Joined: 1/12/2015(UTC)
Posts: 24
United States
Location: Dallas, TX

Thanks: 4 times
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.
joey52685  
#8 Posted : Monday, April 30, 2018 4:50:59 PM(UTC)
joey52685


Rank: Guest

Joined: 2/16/2018(UTC)
Posts: 4
United States

Was thanked: 1 time(s) in 1 post(s)
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?

Edited by user Monday, April 30, 2018 4:56:07 PM(UTC)  | Reason: Not specified

tlphipps  
#9 Posted : Monday, April 30, 2018 4:58:23 PM(UTC)
tlphipps


Rank: Member

Joined: 1/12/2015(UTC)
Posts: 24
United States
Location: Dallas, TX

Thanks: 4 times
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.
joey52685  
#10 Posted : Monday, April 30, 2018 5:04:02 PM(UTC)
joey52685


Rank: Guest

Joined: 2/16/2018(UTC)
Posts: 4
United States

Was thanked: 1 time(s) in 1 post(s)
Originally Posted by: tlphipps Go to Quoted Post
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.
poynter  
#11 Posted : Thursday, May 10, 2018 1:31:52 PM(UTC)
poynter


Rank: Newbie

Joined: 9/21/2015(UTC)
Posts: 6
United Kingdom

Thanks: 2 times
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.

Any ideas?
Users browsing this topic
Forum Jump  
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.