locked
HTML5 Portal Issues with Trusted Domain RRS feed

  • Question

  • Hello,

    Has anyone else had issues with the new HTML5 Self Service Portal and External Trusted Domains?  We are running the Update Rollup 8 release with the KB3134286 hotfix.  The other components are running Update Rollup 9.  We've imported the Portal.mpb onto the primary management server, currently at version 7.5.3079.607.

    In particular, I'm seeing strange behavior when users on two domains with identical usernames logon to the Self Service Portal.  In this particular instance, I pulled users in as Configuration Items via the AD connector from both domains.  For example, say we have the usernames DOMAINA\jsmith and DOMAINB\jsmith for the same user.  The AD connector has pulled the information for both accounts and they are each their own Configuration Item.

    In this particular scenario, let's say that user DOMAINA\jsmith submits a generic Incident Request via the portal.  When I look at the IR in the Service Manager Console, the Affected User is actually marked as DOMAINB\jsmith.  If the user DOMAINB\jsmith logs into the portal, he will see the ticket that was submitted under DOMAINA\jsmith.  The same seems to holds true for the reverse as well--IR submitted by DOMAINB\jsmith would be visible to DOMAINA\jsmith.

    Moreover, say that user DOMAINA\jsmith then attempts to add user input to the IR that he just submitted.  The attempt will result in the message "Your Request update failed".  However, if you then login with DOMAINB\jsmith and add user input, the operation is successful.  On the HTML5 portal server, whenever DOMAINA\jsmith attempts to update the IR that he submitted and it fails, I see Event ID 26319 in the Operations Manager log with the following error:

    "An exception was thrown while processing ProcessDiscoveryData for session ID uuid:[unique user ID];id=1.  Exception message: the user DOMAINA\jsmith does not have sufficient permission to perform the operation..."

    Oddly, this is not the behavior for the older SharePoint\SilverLight portal that we have running side-by-side.  IRs submitted under DOMAINA\jsmith appropriately appear in the console with the Affected User set to DOMAINA\jsmith.  In addition, only IRs submitted by DOMAINA\jsmith appear when logged onto the SharePoint\SilverLight portal.  Likewise, if the user logs on with DOMAINB\jsmith to the SharePoint\SilverLight portal, the IR submitted by DOMAINA\jsmith is not visible.

    Has anyone else experienced this with the new HTML5 portal?  I've been unable to find any similar posts in my search on this particular issue.

    Tuesday, March 1, 2016 4:05 PM

All replies

  • Hello,

    This is very strange, I would like to suggest you update all SCSM component to UR9 and check the result.

    Please create one account in each domain with the same name and test again.  

    Regards,

    Yan Li


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    • Edited by Yan Li_ Wednesday, March 2, 2016 6:00 AM
    Wednesday, March 2, 2016 5:26 AM
  • Hi Yan,

    All SCSM components are actually running UR9 at the moment.

    Wednesday, March 2, 2016 4:13 PM
  • Hello,

    I would like to suggest you create a new account in both domain with the same account name and then test it again, it the issue still exist, then you may need to debug HTML5 process inside. In addition, you may post this feedback on the Microsoft Connect site:

    https://connect.microsoft.com/

    Regards,

    Yan Li


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, March 10, 2016 6:13 AM
  • I found the reason for this and I think it's a bug. I was not seeing anything in "My Activities" and have examined SQL traces to see what happens.

    To filter out items the portal uses queries based on the logged on User Id (from EnterpriseManagementObjectView). To determine that User Id a query is used that only uses the Name of the user, but not the domain. The first row returned is used which could obviously be the wrong domain.

    Sample query from the trace, which in our case returns 3 users from 3 different domains:

    exec

    sp_executesqlN'-- MTV_Select_eca3c52a-f273-5cdc-f165-3eb95a2b26cf <TypeIdForFiltering,UserName_6AF77E23_669B_123F_B392_323C17097BBD0>

     

    SELECT [SourceView].[Id] AS [Id], [SourceView].[Name], [SourceView].[Path], [SourceView].[FullName], [SourceView].[DisplayName], CONVERT(bit,1) AS IsManaged, CONVERT(bit,0) AS IsDeleted, [SourceView].[LastModified], [SourceView].[TypedManagedEntityId], [SourceView].[MonitoringClassId], CONVERT(bit,0) AS TypedMonitoringObjectIsDeleted, NULL AS HealthState, NULL AS StateLastModified, CONVERT(bit,1) AS IsAvailable, NULL AS AvailabilityLastModified, CONVERT(bit,0) AS InMaintenanceMode, NULL AS MaintenanceModeLastModified, NULL AS SourceEntityId, [SourceView].[TimeAdded], [SourceView].[LastModifiedBy]

    FROM dbo.MTV_System$Domain$User AS MTV_System$Domain$User

    INNER JOIN dbo.EnterpriseManagementObjectView AS SourceView

         ON [MTV_System$Domain$User].[BaseManagedEntityId] = [SourceView].[Id]

    INNER JOIN (

                  SELECT DISTINCT [BaseManagedEntityId]

                  FROM dbo.[TypedManagedEntity] TME WITH(NOLOCK)

                  WHERE TME.[ManagedTypeId] = @TypeIdForFiltering

                  AND TME.IsDeleted = 0

                ) AS TypeIdForFiltering

         ON TypeIdForFiltering.[BaseManagedEntityId] = SourceView.[BaseManagedEntityId]

    WHERE MTV_System$Domain$User.[UserName_6AF77E23_669B_123F_B392_323C17097BBD] =  @UserName_6AF77E23_669B_123F_B392_323C17097BBD0

    '

    ,N'@TypeIdForFiltering uniqueidentifier,@UserName_6AF77E23_669B_123F_B392_323C17097BBD0 nvarchar(256)',@TypeIdForFiltering='10A7F898-E672-CCF3-8881-360BFB6A8F9A',@UserName_6AF77E23_669B_123F_B392_323C17097BBD0=N'STEFAN'

    Thursday, March 10, 2016 8:59 PM
  • Thank you, Stefan! That certainly seems like a viable explanation for the behavior! Hopefully a fix shows up in a hotfix or update rollup.

    I hope this isn't an issue in Service Manager 2016 either. I'm actually in the middle of bringing up a test environment in Azure with two domains and identical usernames to test. With a projected release of Fall 2016, we may just wait for Service Manager 2016 for production rollout.

    Tuesday, March 15, 2016 2:53 PM
  • I just finished setting up a completely separate test environment with two domains in separate forests (CONTOSO and WOODGROVE).  CONTOSO has an outgoing selective trust with WOODGROVE, which is exactly what I have in my dev/test environment.  I then added a SQL server to host the Service Manager 2016 Management Server database, another server to host the Management Server itself, and one more server to host the Self Service Portal.

    Unfortunately, I get the same exact issue in Service Manager 2016 that I had in my Service Manager 2012 R2 setup--incident requests submitted under CONTOSO\testuser show up when WOODGROVE\testuser logs in, and vice-versa.

    Hopefully this gets fixed in both the 2012 R2 and future 2016 release.

    Wednesday, March 16, 2016 6:18 PM
  • For the 2016 TP4 issue, I submitted the feedback to ServiceManager@microsoft.com.
    Wednesday, March 16, 2016 6:54 PM
  • I just started another virtual environment from scratch with Azure Dev Labs to test Service Manager 2016 TP5.  It's still not fixed there either.  I did see that Update 3 for the Self Service Portal is now out for Service Manager 2012 R2, but a fix to this issue is not listed there either.  Moreover, according to Abishek Verma in this post, this is the last major update for 2012 R2.

    https://blogs.technet.microsoft.com/servicemanager/2016/05/11/update-3-is-available-for-the-system-center-2012-r2-service-manager-self-service-portal/

    I honestly can't believe this isn't fixed yet in the 2012 R2 release version.  Users with identical usernames from different domains work just fine in the older SharePoint/SilverLight portal, but do not work in the Server 2012 R2 HTML5 portal at all.  I can't believe this is still present in the 2016 TP5 version either, and I'm sure release of the remaining System Center 2016 products are coming this fall, possibly lining up with the Ignite conference.

    It's an easy issue to re-produce, consisting of only 2 domain controllers hosting two different forests with an external, outgoing, one-way, selective trust from the domain hosting the Service Manager installation to the other domain.

    I will again e-mail the team at ServiceManager@microsoft.com to report the bug in TP5.

    Thursday, June 9, 2016 4:22 AM
  • I have got same problem after update :(
    Saturday, January 7, 2017 10:31 AM