- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-17-2024 11:02 PM
We are trying to set up SSO applications in Software Asset Workspace. We have connected to Microsoft Azure AD and there are two scheduled jobs that run daily without errors however the SSO Applications that we have Software Models for keep having the SSO Status "In Progress" where we were under the impression that that would change to Connected.
Why is it stuck with "In progress"?
When looking at the SSO Applications that were found when we published the integration profile we can set a date for "Analyze last activity from" however when setting the date less 35 days in the past (last month) we get the error "You selected a date in the future. Adjust the date to be within the past 60 days." Is the "60 days" in the message an error? Or how are we supposed to understand that phrasing?
Even after setting "Analyze last activity from" to a date within the 35 days the SSO Status remains "in progress" what do we need to do to change this status?
Thanks in advance
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-21-2024 12:32 AM
To really connect; The solution to the issue was to make sure that the user clicking the Get OAuth Token has the correct role in Microsoft Azure and for the Scope type in Microsoft Azure to be "Directory" the role that did it for me was the "Reports Reader"-role. So once I had a colleague granting me that role I was able to click the access Microsoft Azure and get the Oauth Token. I did this in an incognito-browser as I needed to make sure that it would ask me for my login informations. Mostly because my admin-account which I use to access our Software Asset Workspace and our SSO Applications does not exist within our Microsoft Azure environment and my main user-account did not have access to Software Asset Workspace at the time. As the administrator I clicked the Get Oauth Token and when asked for login informations I then used my normal user-account to establish the connection.
If the SSO Status is "In Progress" and does not seem to change; the solution was to commit two update sets which are found in this Knowledge Article:
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1583263
and then I wrote the following fix script:
var gr = new GlideRecord('samp_sso_application');
gr.addQuery('status', 'in_progress');
gr.query();
while (gr.next()){
gr.status = 'failed';
gr.update();
}
which then changed the SSO Status to failed. Now I could click on each of the failed SSO Applications and the "Connect"-button was there. Now I clicked on each individually but I think there would be a multi select option to connect all as well. There were a few that did not connect and what I did on those were to select a date on the "Analyze last activity from" datepicker that the system accepted for each of the failed SSO Applications and then ran the script again to make sure that the SSO Status was changed to Failed again and then clicked "Connect" again on each of the Applications within a few minutes they started to connect. I encountered another curiosity with the datepicker it usually complained that I had chosen a date the exceeded a 60 days span even though the selected date was within range but I ended up finding a date that was accepted.
That is more or less how I remember the process. I hope that it will be easier to cancel a SSO Application if the SSO Status does not change or that the connection fails automatically in the future so the user will know that something is wrong. I also hope that the "Analyze last activity from"-issue will be fixed.
I also hope that this solution will help others facing the same issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-21-2024 10:03 PM
Facing the exact same issue. The expected behavior is to see the application status as connected so that the "update Connected application" schedule job can bring the last activity details. However, the SSO status is stuck InProgress forever.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-21-2024 12:32 AM
To really connect; The solution to the issue was to make sure that the user clicking the Get OAuth Token has the correct role in Microsoft Azure and for the Scope type in Microsoft Azure to be "Directory" the role that did it for me was the "Reports Reader"-role. So once I had a colleague granting me that role I was able to click the access Microsoft Azure and get the Oauth Token. I did this in an incognito-browser as I needed to make sure that it would ask me for my login informations. Mostly because my admin-account which I use to access our Software Asset Workspace and our SSO Applications does not exist within our Microsoft Azure environment and my main user-account did not have access to Software Asset Workspace at the time. As the administrator I clicked the Get Oauth Token and when asked for login informations I then used my normal user-account to establish the connection.
If the SSO Status is "In Progress" and does not seem to change; the solution was to commit two update sets which are found in this Knowledge Article:
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1583263
and then I wrote the following fix script:
var gr = new GlideRecord('samp_sso_application');
gr.addQuery('status', 'in_progress');
gr.query();
while (gr.next()){
gr.status = 'failed';
gr.update();
}
which then changed the SSO Status to failed. Now I could click on each of the failed SSO Applications and the "Connect"-button was there. Now I clicked on each individually but I think there would be a multi select option to connect all as well. There were a few that did not connect and what I did on those were to select a date on the "Analyze last activity from" datepicker that the system accepted for each of the failed SSO Applications and then ran the script again to make sure that the SSO Status was changed to Failed again and then clicked "Connect" again on each of the Applications within a few minutes they started to connect. I encountered another curiosity with the datepicker it usually complained that I had chosen a date the exceeded a 60 days span even though the selected date was within range but I ended up finding a date that was accepted.
That is more or less how I remember the process. I hope that it will be easier to cancel a SSO Application if the SSO Status does not change or that the connection fails automatically in the future so the user will know that something is wrong. I also hope that the "Analyze last activity from"-issue will be fixed.
I also hope that this solution will help others facing the same issue.