|
Installing DSML Services for Windows |
|
Subject: Installing DSML Services for Windows
Author: SteveHB
In response to: Installing and Configuring DSML Services for Windows
Posted on: 07/19/2006 02:45:14 PM
Download the DSML Services for Windows files to a temporary directory on the IIS server system. Run the DSfW.msi installer. This starts the DSML Services for Windows Setup Wizard. On the first page of the wizard, click Next. Read the license agreement, click I Agree, and then click Next. The default install folder is C:\DSFW\. You can install DSML Services for Windows for the current user, but it is recommended that you install it for all users on the computer. To do this, select Everyone, and then click Next. Click Next on the Confirm Installation page to begin installing the DSML Services for Windows files. Read the Congratulations! page, and then click Next. The Installation Complete page will display when the setup is complete. Click Close to exit the Setup Wizard.
>
> On 07/19/2006 02:39:14 PM SteveHB wrote:
System Requirements
DSML Services for Windows uses a three-tiered architecture that requires the following components:
Client --> IIS --> LDAP Server
Client: Client computers running applications that use DSML V2 These clients must be able to send HTTP requests and accept HTTP responses. Computers running Windows 95, Windows 98, Windows Millennium Edition, Windows 2000, Windows XP, and Windows Server 2003 can act as a client for applications using DSML V2.
IIS: DSML Services for Windows, running on Microsoft Internet Information Services (IIS) 5.0 or later MSXML 4.0 Service Pack 1 or later must be installed on the IIS server.
LDAP Server: Active Directory or Active Directory Application Mode (AD/AM) running on Windows 2000 Server or Windows Server 2003
Both DSML Services for Windows and Active Directory must be in the same Active Directory forest.
If using DSML Services for Windows with Active Directory Application Mode (AD/AM) instead of Active Directory, DSML Services for Windows and AD/AM do not have to be in the same forest, or even be joined to a domain. However, if they are not in the same forest, then both DSML Services for Windows and AD/AM should be run on the same computer, because IIS will use local accounts for authentication and would not be able to authenticate to AD/AM using those local accounts if AD/AM were on a separate computer.
All of these components can be installed on a single computer if the computer satisfies the system requirements for each of the components.
Note: All those constraints are due to the authentication between IIS and LDAP. There are two models can be chosen from: trusted or delegation. Trusted Model: A trustee or agent with predifined name IUSR_<Computer NetBIOS name> is used to SASL bind against LDAP via Kerberos Authentication Protocol; Delegation Model: Client's credentials estabished between Client --> IIS will be used to SASL bind against LDAP via Kerberos Authentication Protocol;
As we can see, no matter what models is selected and what authentication methods for client to be authenticated to IIS, the Kerberos Authentication Protocol will be tried first for IIS --> LDAP binding. If Kerberos failed, NTLM will be used as the default back-up authentication protocol.
In that sense, for Microsoft DSML services to work on IIS, the third tier LDAP Server must support Kerberos or/and NTLM. Definitely, AD/AM is the best candidate.
Another Note: For NTLM to work, IIS and LDAP must be in the same domain; For Kerberos to work, IIS and LDAP must be in forests which have trusted relationship.
References:
|
|
|
|