none
Identity flow for AppAdvisor and AppDiagnostics

    Question

  • Hi,

    I have installed SCOM in various environments and always had to fiddle around with the authentication settings, app pool identity and security settings in IIS to get it working.  It never worked out of the box.

    Is it possible to describe the standard "identity flow" from the AppAdvisor and the AppDiagnostics web pages to all other resources like the database, reporting server, etc..  With "Identity flow" I mean which account is used where, which groups are used for authentication, what kind of authentication method is used. 

    That would help tremendously.  We use a remote database, not a local one.  I guess that most of the corporate customers use this kind of setup.  So Kerberos certainly comes into play here.

    Thanks,

    Peter


    • Edited by Peter Cabus Wednesday, June 27, 2012 7:14 AM
    Wednesday, June 27, 2012 7:13 AM

Answers

  • I might be fairly long to answer this on a forum, but let me try to address at least some of it. I might not be able to go in extreme details of everything as I am not the developer, but I'll try to cover the basic flows as I understand them.

    Configuration:
    During setup we create schema in the database(s) and roles, we also add IIS Identity / Computer to the roles (depending on the topology) in SQL.
    So, by default, the application pool that gets created as part of the Web Console setup should have access to the databases.
    You'll see there is an apm_datareader and an apm_datawriter database roles both in opsDB and in DW.

    My test environment also uses a remote SQL and works with a vanilla install. In my environment, I have "ApplicationPoolIdentity" running the application pool for AppDiagnostics and AppAdvisor, and DOMAIN\MACHINENAME$ is added to those roles.

    So far so good, right?

    Now, the two web apps work slightly differently.

    Appdiagnostics is the simplest one, so lets' start there.
    When you access it, you have to authenticate so that it can be checked against the SDK Service if you are a member of role "Operations Manager Application Monitoring Operator" (or better, such as "Operations Manager Administrator") in order to actually "let you in". Once you are authorized to see the data, AppDiagnostics works, you see your events, etc... the database layer always sees the connection coming from the application pool's identity.
    Essentially, you have two flows:

    1. Browser --> Web Site (your user's identity gets used by the web site to see if it can let you in or not, checking against the SDK)
    2. Web Site (pool) --> Database (happening with AppPool's credentials)

    AppAdvisor is more complicated.
    The initial flow is the same one (authentication, call to SDK, etc)... but then, Advisor is acting as a "proxy" between the web frontend itself that lets you select certain report and their parameters... and SQL Server Reporting Services, which has its own authentication model... which in turn gets changed by SCOM, and even just "regular" SCOM reports setup can be tricky!
    So this is really not easy... but the KEY part here is that we introduce one hop:

    1. Browser --> Web Site (a first check against your user's identity gets used by the web site to see if it can let you in or not, checking against the SDK)
    2. Web Site --> SSRS (we need to carry the user's identity up to here, as SSRS that is used by SCOM enforces another identify and authorization check against the SDK)
    3. SSRS --> Database (here we can go with the SSRS's AppPool's credentials)

    Due to this extra hop, and especially depending if the web console AND the SSRS web sites are also on the same box or not, it is possible that Windows Authentication would not be enough and you would have to switch the consoles to use Forms-based auth, as suggested here http://social.technet.microsoft.com/Forums/en-US/scomapm/thread/fa9b53f3-1555-4478-b56b-12c52deed45a to make it work.

    Hope that helps,

     



    Thursday, June 28, 2012 3:53 AM
  • I understand: Kerberos delegation, constrained delegation, SPNs and what not. Unfortunately we have NOT TESTED with  all those configurations; the only configuration which is proven to work is FORMS AUTHENTICATION, NOT Windows, at this point. You might get it to work, but it isn't something we have explicitly validated and support.

    As for NLB - you can balance the web console, but AppDiasnostics and AppAdvisor require affinity of "sticky bit" - this is documented here http://technet.microsoft.com/en-us/library/hh298606.aspx

    You can NOT load balance the SSRS with OpsMgr - we only support a single SSRS, given the way we modify the security model, unfortunately.

    • Marked as answer by Peter Cabus Saturday, June 30, 2012 10:40 AM
    Friday, June 29, 2012 4:23 PM

All replies

  • I might be fairly long to answer this on a forum, but let me try to address at least some of it. I might not be able to go in extreme details of everything as I am not the developer, but I'll try to cover the basic flows as I understand them.

    Configuration:
    During setup we create schema in the database(s) and roles, we also add IIS Identity / Computer to the roles (depending on the topology) in SQL.
    So, by default, the application pool that gets created as part of the Web Console setup should have access to the databases.
    You'll see there is an apm_datareader and an apm_datawriter database roles both in opsDB and in DW.

    My test environment also uses a remote SQL and works with a vanilla install. In my environment, I have "ApplicationPoolIdentity" running the application pool for AppDiagnostics and AppAdvisor, and DOMAIN\MACHINENAME$ is added to those roles.

    So far so good, right?

    Now, the two web apps work slightly differently.

    Appdiagnostics is the simplest one, so lets' start there.
    When you access it, you have to authenticate so that it can be checked against the SDK Service if you are a member of role "Operations Manager Application Monitoring Operator" (or better, such as "Operations Manager Administrator") in order to actually "let you in". Once you are authorized to see the data, AppDiagnostics works, you see your events, etc... the database layer always sees the connection coming from the application pool's identity.
    Essentially, you have two flows:

    1. Browser --> Web Site (your user's identity gets used by the web site to see if it can let you in or not, checking against the SDK)
    2. Web Site (pool) --> Database (happening with AppPool's credentials)

    AppAdvisor is more complicated.
    The initial flow is the same one (authentication, call to SDK, etc)... but then, Advisor is acting as a "proxy" between the web frontend itself that lets you select certain report and their parameters... and SQL Server Reporting Services, which has its own authentication model... which in turn gets changed by SCOM, and even just "regular" SCOM reports setup can be tricky!
    So this is really not easy... but the KEY part here is that we introduce one hop:

    1. Browser --> Web Site (a first check against your user's identity gets used by the web site to see if it can let you in or not, checking against the SDK)
    2. Web Site --> SSRS (we need to carry the user's identity up to here, as SSRS that is used by SCOM enforces another identify and authorization check against the SDK)
    3. SSRS --> Database (here we can go with the SSRS's AppPool's credentials)

    Due to this extra hop, and especially depending if the web console AND the SSRS web sites are also on the same box or not, it is possible that Windows Authentication would not be enough and you would have to switch the consoles to use Forms-based auth, as suggested here http://social.technet.microsoft.com/Forums/en-US/scomapm/thread/fa9b53f3-1555-4478-b56b-12c52deed45a to make it work.

    Hope that helps,

     



    Thursday, June 28, 2012 3:53 AM
  • Hi Daniele,

    thanks for the detailed information.  I'll do some testing and troubleshooting and let you know how it goes.

    Peter

    Thursday, June 28, 2012 11:29 AM
  • Update:

    We did a re-install of the web console and got it all working but with some limitations. 

    Our setup is as follows:

    • We have a database cluster (MS SQL 2008 R2) with the Ops DB running on one SQL node and the DWH running on the other.
    • The Web console is installed on one mangement server.  The reporting server is installed on another server.
    • We have user accounts comming from two domains, one "main" domain and a "pre-production" domain. 
    • Alle servers are installed in the pre-production domain. 
    • The Web console was installed with mixed security.

    Results

    • The App Diagnostics web ran without any modification.  We can use accounts from the main domain and the pre-production domain.
    • The App Advisor web had to be modified.  Anonymous authentication and form-based authentication had to be activated.  Windows authentication had to be disabled. 
    • Access is only possible for users belonging to the "pre-production" domain.  We get error messages when we try to use user accounts from the main domain.

    Windows Authentication and NLB

    When we go to production, the plan is to install the servers in the same domain as the users.  This will probably get rid of some of the issues that we are currently having.  But we will move to an NLB-based setups for the web server that runs the web console.  And we want to move to Windows Integrated Security.  So that means Kerberos (multiple servers), domain accounts for the application pools (another requirement from Kerberos), re-registration of the correct SPNs on these domain accounts, DNS A-record to access the webconsole, updating the URLs in SCOM, ...  This will be a slightly more complex concept.

    That's it for now.

    Peter


    Friday, June 29, 2012 10:55 AM
  • I understand: Kerberos delegation, constrained delegation, SPNs and what not. Unfortunately we have NOT TESTED with  all those configurations; the only configuration which is proven to work is FORMS AUTHENTICATION, NOT Windows, at this point. You might get it to work, but it isn't something we have explicitly validated and support.

    As for NLB - you can balance the web console, but AppDiasnostics and AppAdvisor require affinity of "sticky bit" - this is documented here http://technet.microsoft.com/en-us/library/hh298606.aspx

    You can NOT load balance the SSRS with OpsMgr - we only support a single SSRS, given the way we modify the security model, unfortunately.

    • Marked as answer by Peter Cabus Saturday, June 30, 2012 10:40 AM
    Friday, June 29, 2012 4:23 PM