locked
Access to the AppFabric dashboard if user is not administrator of the machine RRS feed

  • Question

  • Hi all,

    I was wondering if a user is not Administrator of the machine and the diagnostic logging has to be consulted, whatwould be the proper way to gain access to the monitoring data of the dashboard within the IIS of the non administator machine?

    Is there a codeplex tool that can mimic what the dashboard has to offer?

    Thank's

    Thursday, June 3, 2010 5:02 PM

Answers

  • Here is some additional information that may help set some context and add to your understanding of how to use domain security with Windows Server AppFabric.  It is from a whitepaper we are soon releasing to guide folks in how to set up a Web farm. One of the common issues surrounding that topic is security.   Hope this helps!

    AppFabric Security Model

    The three AppFabric conceptual security roles help us understand the AppFabric security model. These roles are purely conceptual so you will not find entities with these names on any of the Web farm servers. Rather, these conceptual roles manifest themselves in correspondingly mapped physical Windows security groups and SQL Server database roles based upon access and functionality requirements. You determine the membership in these conceptual roles as you architect a Web farm security solution.

    • Administrators – This role allows complete control over configuration, the use of applications and services, and access to monitoring and persistence data. The identities of the Event Collection Service (ECS) and the Workflow Management Service (WMS) are part of this conceptual group. You would typically map security identities in this category to the local AS_Administrators Windows security group if they were not on a domain.
    • Observers – This role allows viewing and enumerating of monitoring and persistence data, and the use of services and applications. You would typically map security identities in this category to the local AS_Observers Windows security group if they were not on a domain.
    • Users - This role is used by IIS at run time to assign security identities to its application pools hosting AppFabric services and applications. This gives the services contained in the applications access to persistence and monitoring databases and system services. You will typically map security identities used for the IIS application pools hosting your AppFabric services to this conceptual category.

    For more information about the AppFabric security model, see “Security and Protection” at http://msdn.microsoft.com/en-us/library/ee677202(v=MSDN.10).aspx.

    AppFabric Domain Security

    Now that we understand the AppFabric security model, let’s examine how to design security to support AppFabric on a Web farm. The local AS_Administrators and AS_Observers groups created during AppFabric setup on a single server should not be used to secure a Web farm using multiple AppFabric servers – use domain accounts instead. Be aware that the AppFabric installation and configuration programs will not create any domain accounts for you, so you must create them manually by using Active Directory. You will then specify them during the AppFabric configuration process.

    For the sake of consistency within this document we will use a hypothetical and generic domain named MyDomain. Within that domain we will create AppFabric-specific and arbitrarily named domain groups of MyAppFabricDomainAdministrators, MyAppFabricDomainObservers, and MyAppFabricDomainUsers. The MyAppFabricDomainAdministrator user account is a part of the MyAppFabricDomainAdministrators group, while the MyAppFabricDomainUser user account is a part of the MyAppFabricDomainUsers group.

    Here are steps to properly configure domain security before configuring Windows Server AppFabric hosting and management on multiple AppFabric server computers within that domain:

    1. Create domain Windows security groups representing each of the AppFabric conceptual roles (Administrators, Observers, and Users). Grant the users assigned to these groups the appropriate privileges associated with each AppFabric conceptual role, but at the domain scope level. For more information about managing groups in Active Directory Domain Services, see http://go.microsoft.com/fwlink/?LinkId=192515.
    2. After you create these domain Windows security groups, create and add domain user accounts to them based upon membership in the AppFabric conceptual roles. For example, you may create and add the MyDomain\MyAppFabricDomainAdministrator user account to the MyDomain\MyAppFabricDomainAdministrators group. For more information about managing users in Active Directory Domain Services, see http://go.microsoft.com/fwlink/?LinkId=192516.
    3. The service identities under which the Event Collection Service and Workflow Management Service will run on the various servers in the Web farm should be in the MyDomain\MyAppFabricDomainAdministrators group. Typically this will include the MyDomain\ MyAppFabricDomainAdministrator account. The “Log on as a service” privilege must be granted to the users in this group and enforced in the domain. This right allows a security principal to log on as a service. Any service that runs under a separate user account must be assigned the right. For information about how to add the “Log on as a service” right to an account, see http://go.microsoft.com/fwlink/?LinkId=192517.

    mm
    Wednesday, June 9, 2010 10:58 AM

All replies

  • Hi all,

    Upon installing AppFabric and the SQL on the same box, I understand that the group AS_Administrator is used to access the dashboard and access the data within the monitoring database in AppFabric.

    But what if the SQL box is located on a different machine? Since this is a local group, It seems that I cant see any of the monitoring data.  What would be the proper way for me to access the monitoring and peristence data in the dashboard when configured using a SQL server on a different machine?

    Thursday, June 3, 2010 4:31 PM
  • The normal scenario is that you create domain users and use those, instead of the workgroup users.

    Another scenario you can try, although I don't know if it'll work, is create the exact same usernames and have those have the exact same passwords. This used to work on some occasions, don't know if they'll work in this scenario and under the more recent versions of Winodws.

    Friday, June 4, 2010 11:40 AM
  • That's what we did.  We chose the option of using AD logins.

    But now we have to be sure the correct roles are set in SQL Server in order for us to be able to manage the Database.

    So I figured out the AD administrator group should have the same SQL server Roles than what the local AS_Administrator user had.

    The persistence and monitoring service should have the same SQL server Roles than what the MACHINE\local service user had.

    Am I correct in that respect?

     

    Friday, June 4, 2010 2:45 PM
  • The dashboard is populated using a monitoring database.  If you used our configuration tool with the default provider then it is backed by a SQL monitoring database.  In order to use the dashboard, your user must be a member of the ASMonitoringDbReader role in the SQL database.  For single machine scenarios, the AppFabric configuration tool pre-populates that setting with the local AS_Observers group.  Add your user to this local group and the dashboard will work for the basic setup.  Thanks.

    Adam

    Monday, June 7, 2010 5:55 PM
    Moderator
  • Sorry, hit the button too fast.  For your second question, there is no codeplex tool but the SQL implementation of the monitoring database provides clean views that make it easy to consume the data using standard SQL clients.

     In fact, the AppFabric samples (link below) show 3 different ways to consume the data:

    1. SQL Server Reporting Services
    2. Excel
    3. Programatically using C# and the Entity Framework

    http://www.microsoft.com/downloads/info.aspx?na=40&p=1&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=467e5aa5-c25b-4c80-a6d2-9f8fb0f337d2&u=http%3a%2f%2fgo.microsoft.com%2ffwlink%2f%3fLinkID%3d167153

     Hope this helps.  Thanks.

    Adam

    Monday, June 7, 2010 5:58 PM
    Moderator
  •  

    Thank's Adam,  I understand by your answer that users in the AS_Observer group in a single machine scenario will be able to go into IIS and hit the Dashboard icon and they will be able to monitor the workflow instances.

    Bit this is assuming theusers are administrator of the machine so they can get access to IIS right?

    And what about this scenario where the SQL database is not located on the same box and the app server is not allowing access to the developpers? That means no access to IIS.

    Best regards, Luc

    Tuesday, June 8, 2010 12:42 PM
  • Thank's Adam,

    I'll have a look at them and see if it can be of any help.

    Regards

    Luc

    Tuesday, June 8, 2010 1:07 PM
  • You are correct about IIS Manager.  By default, you'll need to be a local administrator to open IIS Manager and view the dashboard.  But this is an IIS Manager security layer.

    If you don't (and can't) have access to IIS then you'll have to go against the database views directly as I stated in the last post.  If the database is off box then you'll have to ensure that the domain user is a part of the ASMonitoringDbReader SQL Role.

    Tuesday, June 8, 2010 9:30 PM
    Moderator
  • Here is some additional information that may help set some context and add to your understanding of how to use domain security with Windows Server AppFabric.  It is from a whitepaper we are soon releasing to guide folks in how to set up a Web farm. One of the common issues surrounding that topic is security.   Hope this helps!

    AppFabric Security Model

    The three AppFabric conceptual security roles help us understand the AppFabric security model. These roles are purely conceptual so you will not find entities with these names on any of the Web farm servers. Rather, these conceptual roles manifest themselves in correspondingly mapped physical Windows security groups and SQL Server database roles based upon access and functionality requirements. You determine the membership in these conceptual roles as you architect a Web farm security solution.

    • Administrators – This role allows complete control over configuration, the use of applications and services, and access to monitoring and persistence data. The identities of the Event Collection Service (ECS) and the Workflow Management Service (WMS) are part of this conceptual group. You would typically map security identities in this category to the local AS_Administrators Windows security group if they were not on a domain.
    • Observers – This role allows viewing and enumerating of monitoring and persistence data, and the use of services and applications. You would typically map security identities in this category to the local AS_Observers Windows security group if they were not on a domain.
    • Users - This role is used by IIS at run time to assign security identities to its application pools hosting AppFabric services and applications. This gives the services contained in the applications access to persistence and monitoring databases and system services. You will typically map security identities used for the IIS application pools hosting your AppFabric services to this conceptual category.

    For more information about the AppFabric security model, see “Security and Protection” at http://msdn.microsoft.com/en-us/library/ee677202(v=MSDN.10).aspx.

    AppFabric Domain Security

    Now that we understand the AppFabric security model, let’s examine how to design security to support AppFabric on a Web farm. The local AS_Administrators and AS_Observers groups created during AppFabric setup on a single server should not be used to secure a Web farm using multiple AppFabric servers – use domain accounts instead. Be aware that the AppFabric installation and configuration programs will not create any domain accounts for you, so you must create them manually by using Active Directory. You will then specify them during the AppFabric configuration process.

    For the sake of consistency within this document we will use a hypothetical and generic domain named MyDomain. Within that domain we will create AppFabric-specific and arbitrarily named domain groups of MyAppFabricDomainAdministrators, MyAppFabricDomainObservers, and MyAppFabricDomainUsers. The MyAppFabricDomainAdministrator user account is a part of the MyAppFabricDomainAdministrators group, while the MyAppFabricDomainUser user account is a part of the MyAppFabricDomainUsers group.

    Here are steps to properly configure domain security before configuring Windows Server AppFabric hosting and management on multiple AppFabric server computers within that domain:

    1. Create domain Windows security groups representing each of the AppFabric conceptual roles (Administrators, Observers, and Users). Grant the users assigned to these groups the appropriate privileges associated with each AppFabric conceptual role, but at the domain scope level. For more information about managing groups in Active Directory Domain Services, see http://go.microsoft.com/fwlink/?LinkId=192515.
    2. After you create these domain Windows security groups, create and add domain user accounts to them based upon membership in the AppFabric conceptual roles. For example, you may create and add the MyDomain\MyAppFabricDomainAdministrator user account to the MyDomain\MyAppFabricDomainAdministrators group. For more information about managing users in Active Directory Domain Services, see http://go.microsoft.com/fwlink/?LinkId=192516.
    3. The service identities under which the Event Collection Service and Workflow Management Service will run on the various servers in the Web farm should be in the MyDomain\MyAppFabricDomainAdministrators group. Typically this will include the MyDomain\ MyAppFabricDomainAdministrator account. The “Log on as a service” privilege must be granted to the users in this group and enforced in the domain. This right allows a security principal to log on as a service. Any service that runs under a separate user account must be assigned the right. For information about how to add the “Log on as a service” right to an account, see http://go.microsoft.com/fwlink/?LinkId=192517.

    mm
    Wednesday, June 9, 2010 10:58 AM
  • This is awesome! Very usable! Can't wait for the whitepaper!
    Dennis van der Stelt
    http://bloggingabout.net/blogs/dennis/
    http://twitter.com/dvdstelt/
    Thursday, June 10, 2010 6:27 PM