Cisco Unified MeetingPlace, Release 7.0 -- How to Configure Windows Integrated Authentication

From DocWiki

Jump to: navigation, search

Main page: Cisco Unified MeetingPlace, Release 7.0

Up one level: Configuration




Contents

Windows Integrated Authentication

Windows Integrated Authentication (WIA) uses an algorithm to generate a hash based on the credentials and computers that users are using. WIA then sends this hash to the server; user passwords are not sent to the server. If WIA fails for some reason, such as improper user credentials, the browser prompts users to enter their user IDs and passwords. The Windows logon credentials are encrypted before being passed from the client to the Web Server.


Tip: You can configure Internet Explorer version 4.0 or later to initially prompt for user information if needed. For more information, see the Internet Explorer documentation.


Windows Integrated Authentication (WIA) is secure, but has the following limitations:

  • Only Microsoft Internet Explorer version 4.0 or later supports this authentication method.
  • WIA does not work across proxy servers or other firewall applications.
  • WIA works only under the browser Intranet Zone connections and for any trusted sites you have configured.
  • WIA does not work on Web servers with SSL enabled


Therefore, WIA is best suited for an intranet environment where both users and the Web Server are in the same domain and where administrators can ensure that every user has Microsoft Internet Explorer. The Web Server must be in a Windows domain.


Refer to Microsoft online documentation to further ensure or verify that your network supports WIA.

Login Behavior with Windows Integrated Authentication

When WIA Works Properly:
  • Users log in to their workstations by using their Windows NT domain accounts.
  • If their NT account user IDs also exist in the Cisco Unified MeetingPlace profile database, users are automatically logged in to Cisco Unified MeetingPlace and granted access to the home page. Cisco Unified MeetingPlace user passwords are ignored and not used in the SSO operation.
The home page does not have Sign In links to the HTML-based login form because users are already logged in through the SSO process.
  • If their NT account user IDs do not match any user IDs in the Cisco Unified MeetingPlace directory, users see the Cisco Unified MeetingPlace home page, but with Sign In links to the HTML-based login form. Users must then enter valid Cisco Unified MeetingPlace user IDs and passwords.
  • (System administrators only) If a user clicks Sign Out from the Cisco Unified MeetingPlace Web Administration, then the user is logged out and returns to the home page. To log back in, the user may click Sign In and enter the valid Cisco Unified MeetingPlace user ID and password.


When WIA Does Not Work Properly:
  • Users see a popup window prompting them for their Cisco Unified MeetingPlace user IDs and passwords.
  • If their credentials are authenticated in the Cisco Unified MeetingPlace directory, users see the Cisco Unified MeetingPlace home page.
  • If authentication fails, users are prompted continually for their valid login credentials.


Note: Cisco Unified MeetingPlace user IDs are not case-sensitive.


Related Topics



Configuring Windows Integrated Authentication

Before You Begin

Read Restrictions: User Authentication and Load Balancing.


Restrictions
  • Each user must have an account (local or Active Directory) on the Windows NT server and must also have a Cisco Unified MeetingPlace profile user ID that matches the account name.
  • Users must be using Microsoft Internet Explorer version 4.0 or later.
  • WIA works only under the browser Intranet Zone connections. By default, only pages without any dots in the URL are considered to be in the Intranet Zone.


  • WIA does not work across proxy servers or other firewall applications.


Procedure
  1. Sign in to the end-user web interface.
  2. Click Admin.
  3. Click Web Server.
  4. Click the name of the Web Server that you want to configure in the "View" section of the page.
  5. Scroll down to the Web Authentication section.
  6. Select Windows Integrated Authentication for "Step 1: Directory."
    "Step 2: Login Method" is automatically set to HTTP Basic Authentication and cannot be changed.
  7. Select how you want user names transformed for "Username Conversion Function."
    Selecting None applies no transformation to the original user ID string.
  8. Click Submit and wait five minutes for the new configuration to take effect.


What to Do Next

(Optional) Proceed to Verifying the Windows Integrated Authentication Configuration.



Verifying the Windows Integrated Authentication Configuration

Use a Cisco Unified MeetingPlace end-user profile when completing this procedure.


Before You Begin

Complete Configuring Windows Integrated Authentication.


Procedure
  1. Open a web browser and navigate to Cisco Unified MeetingPlace.
  2. Verify the following end-user behaviors:
    • If you are on the same domain, you are immediately authenticated to the Web Server and see the Welcome page with your name displayed in firstname, lastname order. The Sign In link does not display.
    • If you are on a different domain, you see an Enter Network Password window that includes the Domain field.
    • If you are on a different domain, enter your Windows NT account user ID and password. You are then authenticated to the Cisco Unified MeetingPlace Web Server and see the Welcome page with your name displayed in firstname, lastname order. The Sign In link does not display.
    • Only users authenticated by the Web Server can log in.
    • In IIS, the MPWeb/Scripts folder is set to Integrated Windows Authentication.


Troubleshooting Tips

If you configured your Web Server Home Page hostname by using an IP address or FQDN, you will be prompted for your Windows login information even if you log in by using your domain Windows account.


See How to Resolve Authentication Problems for a workaround to this problem.


See Setting Your Web Server Options for information about configuring your Web Server Home Page hostname.




Configuring SiteMinder for Use With Cisco Unified MeetingPlace Web Conferencing

If your deployment includes the SiteMinder application for authentication and single-sign on support, you will need to make the following changes to the SiteMinder configuration so that it can interoperate properly with Cisco Unified MeetingPlace Web Conferencing Release 7.x.


String Blocking in URLs

SiteMinder looks for invalid strings in all URLs before processing. Web Conferencing uses internal URLs that include the "." character (period), which is blocked by the default SiteMinder configuration. The default block is:


badurlchars="./, /., /*, *., ~, \, %00-%1f,%7f-%ff"


In order for Web Conferencing to function properly, remove /. from the badurlchars string, for example:


badurlchars="./, /*, *., ~, \, %00-%1f,%7f-%ff"


Localhost Redirection and Hostname Blocking in URLs

Web Conferencing uses internal URLs that include connecting to the localhost/loopback on port 8002, for example, http://localhost:8002. When SiteMinder receives a localhost request, it resolves localhost to the actual host name of the server. SiteMinder then looks up the host name in its list of hosts and matches it to the name of an agent. In order for web conferencing to function properly, you must add this agent name to the exception list so that it is not blocked by SiteMinder.


The following example shows the SiteMinder logging for a localhost request on port 8002:

[5812/7912][Tue Apr 24 14:00:07 2007][..\..\..\CSmHttpPlugin.cpp:219][INFO:2] PLUGIN: Read HTTP_HOST value 'localhost:8002'.

[5812/7912][Tue Apr 24 14:00:07 2007][..\..\..\CSmHttpPlugin.cpp:270][INFO:2] PLUGIN: ProcessResource - Resolved Host 'YOURHOSTNAME:8002'.

[5812/7912][Tue Apr 24 14:00:40 2007][..\..\..\CSmHttpPlugin.cpp:290][INFO:1] PLUGIN: ProcessResource - Resolved Agentname 'yourhostname-unprotected' for HTTP_HOST 'YOURHOSTNAME:8002'.


In the first line, SiteMinder processes the request to localhost on port 8002. In the second line, localhost is resolved to the actual hostname of the computer (in this example, YOURHOSTNAME). In the third line, YOURHOSTNAME:8002 is resolved to the agent defined in your SiteMinder configuration as yourhostname-unprotected. It is this agent name that must be allowed (not blocked) by SiteMinder in order for the request to succeed.

Rating: 0.0/5 (0 votes cast)

Personal tools