SharePoint 3.0 / MOSS 2007 Configuration Guide

Transcription

1 SharePoint 3.0 / MOSS 2007 Configuration Guide Summary: This is the configuration guide to set up Windows SharePoint Services 3.0 with SecureAuth. It is divided into 3 sections: Section I go over the procedure on changing Windows SharePoint Services to work with SecureAuth. Section II outlines further changes in SecureAuth in addition to its basic setup. And Section III contains steps to add users to access the User Portal. Section I) Configuring Windows SharePoint Services 1. Within your WSS server, open up web.config in the Central Administration site folder (i.e. C:\Inetpub\wwwroot\wss\VirtualDirectories\4061) a. Add (or Modify if already exists) the <connectionstrings> element it should go right after the </SharePoint> tag <connectionstrings> <add name="adconnectionstring" connectionstring="ldap://your_ldap_server/cn=users,dc=your_server,dc=com" /> </connectionstrings> b. Add (or Modify if already exists) the <membership> element it should go right after the </machinekey> tag <membership defaultprovider="aspnetactivedirectorymembershipprovider"> <providers> <add connectionstringname="adconnectionstring" name="aspnetactivedirectorymembershipprovider" type="system.web.security.activedirectorymembershipprovider, System.Web, Version= , Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionusername="your_user_name" connectionpassword="your_password" connectionprotection="none" /> </providers> </membership> c. Review the <identity> element to make sure it is denying unauthenticated users it should go after the </authentication> tag <identity impersonate="true" /> <authorization> <deny users="?" /> </authorization> d. While you are inside the web.config file, make a note of the Machine Key for later use in the SecureAuth site. <machinekey validationkey="5b505c6ca7e878c56c998ed78e4b f8904abcdabcd" decryptionkey="dd18d8b8d0d e13f4156a6cb2c349c " validation="sha1" />

2 2. Within your WSS server, open up web.config in the User Portal site (the site that is being protected by SecureAuth) folder (i.e. C:\Inetpub\wwwroot\wss\VirtualDirectories\80) a. Add (or Modify if already exists) the <connectionstrings> element it should go right after the </SharePoint> tag <connectionstrings> <add name="adconnectionstring" connectionstring="ldap://your_ldap_server/cn=users,dc=your_server,dc=com" /> </connectionstrings> b. Add (or Modify if already exists) the <membership> element it should go right after the </machinekey> tag <membership defaultprovider="aspnetactivedirectorymembershipprovider"> <providers> <add connectionstringname="adconnectionstring" name="aspnetactivedirectorymembershipprovider" type="system.web.security.activedirectorymembershipprovider, System.Web, Version= , Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionusername="your_user_name" connectionpassword="your_password" connectionprotection="none" /> </providers> </membership> c. Change <authentication> element (you will need to provide the SecureAuth website URL to complete this task, but it does not need to physically exist yet) <authentication mode="forms"> <forms loginurl=" name=".aspxformsauth" protection="all" path="/" timeout="30" domain="your-domain.com"/> </authentication> d. Change <identity> and <authorization> elements <identity impersonate="false" /> <authorization> <deny users="?" /> </authorization>

3 3. Open up your browser and launch the Central Administration site (i.e. a. Click on Application Management tab on top, and then click Authentication providers link towards the bottom

4 b. Click Default

5 c. In Authentication Type radio group, change to Forms, and then put AspNetActiveDirectoryMembershipProvider under Membership provider name, finally hit Save button to apply changes

6 d. Click Application Management tab on top to go back, then click on Site collection administrators link

7 e. Type under Primary site collection administrator, and then click the check icon next to it. If such user exists in your Active Directory, it will resolve the name properly. Click OK button to apply changes

8 Section II) Configuring SecureAuth site 1. Open up the Web Administration Console a. Click on the SecureAuth policy that is being used for SharePoint (i.e. SecureAuth1) b. Click on Post Authentication tab on the left c. Drop down Authenticated User Redirect and change to Use Custom Redirect d. Enter the URL of the SharePoint page in the Redirect To text box (i.e. FQDN.com) e. Click Save at the bottom 2. Configure the Encryption/Decryption key properties a. Change Domain to your domain name (i.e. ezmultifactor.com) a. Make sure Validation Key and Decryption Key match with the ones entered inside SharePoint s web.config file b. Click Save at the bottom 3. Refer to the SecureAuth Configuration Guide for initial set up and other details a. For example, User ID needs to set to userprincipalname so it contains the entire domain in the field. This is needed for SharePoint to recognize and grant proper permission.

9 Section III) Granting user permissions 1. Log on to the User Portal site using an Administrator account (i.e. the same account that you put in the Site Collection Administrators section at 3e above) 2. Click Site Actions, then Site Settings

10 3. Click People and groups, then New, Add Users

11 4. Type in the user name in the same format that you typed in the Site Collection Administrators above. Click the Check icon to verify the login. 5. Once the user name is verified, it will be changed to a short form with underline. Next, grant proper rights by choosing the permission level at the Give Permission section. Finally, click OK button at the end to apply changes There is a known issue with SharePoint that with Forms-based Authentication, it will only grant permission at user level, it cannot grant permission at the group level 6. User is now ready to login

12 Other Configuration items to be aware: 1) In both SharePoint and SecureAuth web.config, the <forms> tag should have an attribute of domain= yourdomain.com. This is especially required in the dev environment where the FQDN s are not resolvable. Refer to Part II, item 2 above on how to configure this in Web Administration console 2) Both SecureAuth and SharePoint should have a FQDN. If in dev environment, modify the host files (2 servers + any test client) to give it the same name within the domain. 3) It works best if both SecureAuth and SharePoint are on HTTPS, but SharePoint is not required to be on HTTPS.