locked
Active Directory Integration with WebsitePanel v1.1.0 thoughts... RRS feed

  • General discussion

  • Hi All, I thought i'd share my installation thoughts on getting Active Directory Integration working in a multi-server environment with WebsitePanel v1.1.0.  This information is based on our experiences installing a fresh WebSitePanel infrastructure on Windows Server 2008 R2 and connecting to a newly created forest designed to support Exchange Hosting Mode (SP1 /hosting switch).  This information is based on information obtained by various users on this forum.  Credit should ultimately go to them for providing the guidance that this little help sheet originates from.

    I'd welcome other peoples comments, suggestions, feedback and corrections :)

    When you install the first WP Server and in the documentation, it suggests that you should allow WSP to auto-generate the password in the AD due to the strong password creation mechanism.  This is all well and good for the WPPortal and WPEnterprise accounts, but when you install in a multi-server environment, there are some changes that need to be made to the WPServer account so its better to define a password for this account, rather than accept a default random password that you cannot obtain later on.

    When you install the second and subsequent servers with WP Server, you cannot select AD integration as the account has already been created.  As a result of unchecking AD integration at this point, a local WPServer account is created.  If this server (as was in our case) is your IIS Server, then WP will map this local user account to the "WebSitePanel Server Pool" Application Pool in IIS.  Furthermore, it will bind the local WPServer the local Administrators group and local IIS_IUSRS group.

    For AD Integration to work, you will need to change the local Administrators Group Membership and identity of the Application Pool in IIS to point to to DOMAIN created WPServer account, not the WPServer account.  To change the application pool in IIS 7.5, you will need to know the WPServer account password to achieve this.

    The steps to cover here are:

    1.  Go to local users and groups of the server and add DOMAIN\WPServer to the IIS_IUSRS Group.

    2.  Add DOMAIN\WPServer to the local Administrators Group.

    3.  Go into IIS and change the identity of the "WebSitePanel Server Pool" from .\WPServer to DOMAIN\WPServer.  You will need to know the password of the DOMAIN\WPServer account to achieve this.

    Once you have performed both these actions, you are ready to integrate IIS with AD Integration in WSP.

    Once in WSP Portal, go in to Configuration -> Servers, then add your server.  If you have already added your server, click on the server you have added and expand the Active Directory Section.

    Ensure that the following settings are defined per this thread:

    http://dev.websitepanel.net/administrator-guide/ad-integration

    In WSP on server properties page for "Active Directory Settings" select: 
    Authentication Type: None
    Root Domain: AD_DOMAIN (enter full-qualified AD domain name)
    Usernname: <empty>
    Password: <empty>

    Once this is completed, you can now integrate IIS 7.5 in to Active Directory OU's.  Our preference has been initially to use Hosted Organizations as our primary OU and then create Users and Groups containers therein.  

    In Configuration -> Servers -> <server> -> IIS 7.0 there is a section called "Other Settings".

    In there you can define the Active Directory containers within the domain defined on the server earlier.

    For us, we created Hosted Organizations/Users and Hosted Organizations/Groups.

     

    Now click on update.  If your Application Pool is not set correctly or you have not set the correct group permissions, you will receive this error:

    Could not check/create Organizational Units: The specified domain either does not exist or could not be contacted

    Further, if you ignore this error (like we did) and try to continue setting up hosting plans and hosting spaces, then you will get errors.  One of them is below (as an extract).  

    System.Web.Services.Protocols.SoapException: System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.Exception: Error executing 'ADD' task on 'abc.com' WEB_SITE ---> System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> Object reference not set to an instance of an object. 

    Of course this error could refer to other issues, but we discovered that if you come across a problem in WSP and you ignore it, there will be implications when trying to connect to associated services.

    Anyway that's it! Once you have made the necessary changes for multi-server environments, you should be able to create hosting plans and create websites and FTP accounts etc without any hassle.  

    I hope this information will be helpful to others out there as there is no official documentation on installing WSP in a multi-server environment and with AD Integration and a lot of the errors we encountered on this forum and on other threads are left unanswered.  

     

    As a final note, we noticed that in our AD environment running hosted exchange, there are AD replication delays which can affect WSP.  Lets say you create a user and delete it in AD.  If you have a replicated environment, then we would advise to wait for the replication delay to propagate before readding the user or site etc., as this can generate errors that'll send you in to a panic, when in actual fact there is no problem.  We noticed this with Hosted Exchange Mode in particular, when adding and removing organizations from our multi-tenant setup.

     

    Jason Kelton.

     

     

    • Changed type Inesa Fain Monday, January 17, 2011 9:35 PM
    Sunday, January 16, 2011 3:24 AM

All replies

  • Thanks for the information Jason, however we are still having trouble with our Active Directory DNS integration. That is of course if we are not understanding it correctly.

    We are running WIN2K8 R2 Active Directory using Hyper-V. We have multiple VPS's set up to run various WSP services (eg. Database server, mail server, etc...).

    Lets say VPS1 is where our Primary DNS is set up and VPS2 for Secondary.

    When we configure the WSP DNS services (prim & sec) and add to our Virtual Server for some reason the DNS entries are going into the Secondary DNS only.

    No matter what settings and IP address combinations we try in the DNS service we cannot get the Primary to update (even on it's own).

    I was wondering if we Tick the Active Directory box i assume we will still see both our Primary and Secondary DNS update it's records? Or is this out misunderstanding of Active Directory Integrated Zones?

    Any help on the exact configuration (screen grabs for Prim & Sec?) would be appreciated.

    Tuesday, February 1, 2011 1:18 AM
  • If you are using AD-Integrated DNS, the "traditional" concept of primary and secondary DNS does not apply. AD-Integrated DNS means the zones are stored in a dedicated AD partition and are replicated using AD replication mechanisms. All domain controllers and their AD-Integrated DNS services are equal (more or less - FSMO roles do involve some differences, but that doesn't apply to DNS).

    I would not recommend using the AD DNS servers as your DNS hosting service, which is what it sounds to me like what you are trying to do. These are domain controllers; they contain security sensitive information and should not be exposed to the outside world.
    If you were - for example - to become the victim of a dns flood attack and your AD DNS shuts down, you're dead in the water. Nothing works anymore.

    @Jason: Security sensitive operations in AD trigger immediate forest-wide replication. Otherwise you could potentially run into scenarios (in large AD deployments) where you would disable an account in one sub-domain, and the account would still be able to log on and use services in another sub-domain for an extended period of time.
    What I'm trying to say is if you have a single forest, single site, single domain deployment and security sensitive operations take longer than a couple of seconds, you might have some AD replication issues.

    HTH!
    Rgds - Marcus.

     

    Thursday, February 3, 2011 12:52 AM
  • I see this issue still exists with WSP 1.2.1

    is there any reason not to simply create a different AD user for each server instead, would this cause any problems ?


    Snake

    Thursday, August 9, 2012 6:37 PM