Introduction
Beginning with Lotus Domino 8.5.1, the Domino Web server can be configured to use Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) and the underlying Kerberos network authentication security that is provided by Active Directory to negotiate authentication with a browser client. Also known as "Windows single sign-on for Web clients" or "Integrated Windows Authentication", this mechanism allows Web users who are actively logged on to the Active Directory domain to open applications on the Domino server from a browser, without being prompted for a password.
This article attempts to address some of the most common questions related to deployment of Windows single sign-on for Web clients (SPNEGO) in an existing Domino environment. It is assumed that the reader is already familiar with the basic steps to prepare the Domino server, set up the Windows service, configure user name mapping and configure Web client browsers. If you have not already, it is suggested that you examine the comprehensive online documentation available on this subject by following the
Links to the Notes/Domino InfoCenter at the bottom of this article.
Conceptual Overview
Before addressing questions about deployment of SPNEGO in your Domino environment, it is helpful to visualize how this type of authentication mechanism works. The flow diagram below shows how these various components interact:
Frequently Asked Questions
Following, are some of the most common questions related to deployment of SPNEGO in your current Domino environment and some general troubleshooting steps for investigating specific issues that may occur while testing this implementation. If additional questions arise, it is suggested that you search the
Knowledge Base
and
Lotus Notes/Domino 8.5 Forum, or contact IBM Lotus Support to
open a service request for further assistance.
Configuring SPNEGO in a mixed server environment
Several Domino servers in my environment are running on UNIX (Red Hat, Solaris, AIX, etc.) or an iSeries platform. Is it possible to use Windows single sign-on for Web clients (SPNEGO) so that users can access these servers without being prompted to provide credentials?
Due to the nature of Kerberos authentication via the SPNEGO protocol in Domino, Windows single sign-on can be only be achieved when a user initially accesses a Domino 8.5.1 server running on a Windows platform that is part of the Active Directory domain. However, even though non-Windows servers cannot automatically authenticate users via SPENGO, they can participate in a Web SSO configuration that has been created for a Windows Domino server. In other words, if you create Web SSO configuration document and enable it for "Windows single sign-on integration", other non-Windows Domino servers can still use this same SSO configuration document and there will be no conflicts if the user needs to directly authenticate to a non-Windows Domino server via form-based login.
For automatic authentication via Windows single sign-on to work across a mixed server domain, users would need to
always access the Windows Domino server
first. Then, after they have been issued a valid LTPAToken from the SPNEGO-enabled Windows Domino server, they could be redirected to a non-Windows Domino server. When the sever they are redirected to shares the same SSO configuration, the LTPAToken they have been issued will allow them access without prompting for credentials. If the user attempts to access a non-Windows Domino server first, they will not automatically be authenticated via Windows single sign-on for Web clients, but they will still be presented the standard Domino login form where they can enter valid credentials for authentication.
One alternative solution you may want to investigate is to build a custom DSAPI filter and deploy on non-Windows Domino servers that cannot initiate Kerberos authentication. DSAPI (Domino web server application programming interface) is a C API you can use to write your own extensions to the Domino Web server, whereby these extensions (i.e. filters) allow you to customize the behavior of the Web server. In this scenario, a DSAPI filter would intercept the initial HTTP request for authentication to a non-Windows Domino server and redirect the user to another server capable of providing Windows single sign-on. If the Windows Domino server shares the same SSO configuration as your non-Windows Domino server, the user subsequently can achieve single sign-on via LTPA technology. For illustration, the expected flow with this type of DSAPI filter would be as follows:
- At the browser, the user enters the URL of your non-Windows Domino server.
- Your Domino server determines that the user is not authenticated, and the DSAPI filter is called.
- This DSAPI filter redirects to a database URL on a Windows single sign-on server.
- When accessing the database URL on the Windows single sign-on server, the server authenticates the user by Windows single sign-on, and sends an LTPA token back to the user's browser.
- The database URL on the Windows single sign-on server redirects back to the user's originally requested URL. Since the user has already acquired an LTPA token in previous step, the user is not challenged to supply a username and password.
A sample DSAPI filter (including source code) is available on OpenNTF.org and can be customized to meet your needs, allowing you to achieve the above implementation:
http://www.openntf.org/projects/pmt.nsf/ProjectLookup/SSO%20for%20Web%20for%20non%20Windows%20Servers
IMPORTANT NOTE: The above offering is supplied for illustrative purposes only. It is provided AS IS, without warranty of any kind, express or implied and Lotus Support cannot provide any assistance with customization or troubleshooting issues that may arise from its use.
I have several Domino servers that cannot currently be upgraded to 8.5.1. Is it possible to use Windows single sign-on for Web clients (SPNEGO) on a Domino 7.x, 8.0.x or 8.5.0 server?
Windows single sign-on for Web clients is a feature that is new to Domino 8.5.1 and is only available starting in this release. Previous Domino server releases will need to be upgraded to take advantage of the automatic SPNEGO authentication mechanism.
Although we strongly recommend upgrading any servers that will be participating in the same SSO configuration as a SPNEGO-enabled Windows server, it is possible for pre-8.5.1 Domino servers to use a SSO configuration document that has been created in a 8.5.1 Domino Directory and enabled for "Windows single sign-on integration". As with the scenario described above for non-Windows servers, if a user attempts to access a pre-8.5.1 Domino server first, they will not automatically be authenticated via Windows single sign-on for Web clients and will be, instead, presented with the standard Domino login form where they can enter valid credentials for authentication.
Configuring SPNEGO on a server that accepts Web traffic from mixed sources
I have internal users and external customers that will be accessing the same Domino server. Is it possible to configure Domino to use Windows single sign-on for Web clients (SPNEGO) in this scenario?
Windows single sign-on is not available to Web clients that connect over the Internet (rather than the intranet) or those that are not set up to use the feature. Client machines and browsers must be properly configured to enable SPNEGO authentication, have network access to the Active Directory server, and be actively logged on to the Active Directory domain. Since this will usually not be the case for external Internet users, when these clients attempt connecting to a Lotus Domino server through a URL participating in Windows single sign-on, they will either be blocked from accessing the server (Firefox users) or will be inconvenienced by extra login prompts (Internet Explorer users).
If one Domino server will be servicing both types of users, you can work around this restriction by setting up separate "Internet Sites" to map requests from different sources, one for participating intranet Web clients to use and another for non-participating external Web clients to use. Each Internet Site document should use a different host name in the "Host names or addresses mapped to this site" field. Then, you would give users the appropriate URL to use for accessing the server, depending on whether they participate in Windows single sign-on. For more information concerning how to configure your Domino server for Internet Sites, please see the following documentation in the IBM Lotus Domino and Notes Information Center:
Enabling Internet sites on a server
Creating an Internet site document
Hosting Web sites
Configuring SPNEGO for non-Windows workstations
Some of my users will be accessing Domino over the web from a non-Windows workstation (Ubuntu, Mac OS, etc). Is it possible for these users to utilize Windows single sign-on for Web clients (SPNEGO) to access Domino resources without being prompted for credentials?
Windows single sign-on for Web clients is only possible with browsers and platforms that support the SPNEGO protocol. Client machines and browsers must be properly configured to enable SPNEGO authentication, have network access to the Active Directory server, and be actively logged on to the Active Directory domain.
While some third-party products are available to facilitate authentication to Active Directory for non-Windows workstations, these solutions are usually implemented through the LDAP protocol and usually cannot support SPNEGO because they do not request Kerberos service tickets from the Kerberos Key Distribution Center (KDC). If a SPNEGO token cannot be provided by the browser when accessing the Domino server, Windows single sign-on for Web clients will not work on these workstations. These users will need to be provided with an alternate URL for accessing the server, such as the one used by your external Internet users (see previous question for related information concerning this type of configuration).
Ultimately, Windows single sign-on for Web clients is only supported on the following browsers which have been tested and are known to function successfully with Domino SPNEGO:
- Microsoft Internet Explorer Version 6.0 (Windows)
- Microsoft Internet Explorer Version 7.0 (Windows)
- Microsoft Internet Explorer Version 8.0 (Windows)
- Mozilla Firefox Version 3.0.x (Windows)
- Mozilla Firefox Version 3.5.x (Windows)
For more information on how to configure these browsers for authentication to the Lotus Domino server using SPNEGO, please see
Configuring Web client browsers for Windows single sign-on in the Notes/Domino InfoCenter or contact the support organization for the browser software.
Session expiration on a SPNEGO-enabled Domino server
When I enable "Windows single sign-on integration" in the Web SSO document, I am no longer able to configure an "Idle Timeout" for Web users. Why is this field hidden when I enable SPNEGO authentication?
The Idle Session Timeout option is only available for a Domino-only Web SSO configuration. However, you can still configure an expiration for the session cookie (LTPAToken) generated by Domino using the "Token Expiration" field in the Domino Web SSO document. This setting defines how long a session cookie generated by Domino is valid, regardless of user activity.
Normally, if a user is accessing the server at the time the LTPAToken expires, the user is prompted to re-authenticate. However, if the user is still accessing a Windows Domino server with SPNEGO enabled, this expiration will be transparent, because the Domino server will automatically request a new Kerberos token from the browser, validate with the Key Distribution Center and issue a new LTPAToken. The user should not be prompted to re-authenticate upon expiration and will continue with uninterrupted access to the Domino server, unless they fail to provide a new Kerberos ticket or the ticket is no longer valid (i.e. they are no longer logged into the Active Directory domain). Therefore, the timeout period from the perspective of a user is effectively defined by the Kerberos ticket issued from the KDC. Active Directory administrators can configure the maximum lifetime of a Kerberos ticket by defining a Kerberos policy for the domain. For more information, please refer to the Microsoft documentation on this topic:
http://technet.microsoft.com/en-us/library/cc961966.aspx
How to deploy necessary browser changes across the organization
Now that I know what configuration steps are necessary on the users' workstations, is there any way to distribute these settings across the organization without requiring user intervention?
You can deploy specific security settings for Internet Explorer across the organization using a Group Policy in an Active Directory–based domain. There is no native mechanism in Active Directory for accomplishing this for the Mozilla Firefox browser, however, there are several third-party solutions available which might meet your needs. While specific configuration instructions for distributing software in your domain is beyond the scope of this article, you may find the following links useful when investigating this type of deployment:
http://support.microsoft.com/kb/274846
http://www.frontmotion.com/FMFirefoxCE/index.htm
http://sourceforge.net/projects/firefoxadm/
Configuring Domino when multiple Kerberos realms are used
How do I configure Domino for name mapping when multiple Kerberos realms are used?
Before addressing this question, it is important to understand how name mapping works with Windows Single Sign-on. When a user is authenticated via SPNEGO, Domino will attempt to map the Kerberos name that was returned by Active Directory to a username that Domino can resolve for authorization (i.e. the username present in your database ACLs). Depending on where directory information is stored in your environment and how you have configured name mapping in Domino, this typically occurs in one of two ways:
(A) Users are managed through the Domino Directory:
The Kerberos username is compared against a special field -- "Active Directory (Kerberos) logon name" -- in person documents stored in the Domino directory. If a match is found, Domino name mapping occurs and this user is resolved to their Notes distinguished name (first entry listed in the User Name field of the person document).
(B) Users are managed through Active Directory:
Assuming that Directory Assistance has been configured appropriately to query Active Directory via LDAP for authentication lookups, a LDAP query occurs to Active Directory for the Kerberos username that was returned during authentication. If a match is returned by the LDAP query, Domino will either use the distinguished name (DN) returned, or -- if an "Attribute to be used as Notes distinguished name" has been configured in the DA document -- the value of the NotesDN attribute returned.
If name mapping occurs via the Domino Directory (Scenario A), it does not matter what Kerberos realm the user belongs to, because we will simply resolve the matching Kerberos name from the user's person document. However, if name mapping occurs via Directory Assistance (Scenario B), Domino will only search the first LDAP server listed in your Directory Assistance database. If the Kerberos realm specified in this document does not match the Kerberos realm that the user belongs to, name mapping of this user will not occur and authorization could fail. To work around this issue, it will be necessary to either consider using Scenario A above, or configure SPNEGO on a separate Domino server for each Kerberos realm. On each server, you would use a separate Directory Assistance databases, each listing a unique Kerberos realm. Then, users would access the appropriate Domino server based on the Kerberos realm that they are a member of.
Troubleshooting common issues
Below is a checklist of components that can be examined when you just need to isolate a SPNEGO issue to a specific step in the authentication process. For more in depth analysis, the technote below should be used as a comprehensive guide for troubleshooting Windows single sign-on issues. It includes more information on some of the steps described below and should reviewed before opening a service request with IBM Lotus Support.
Troubleshooting Windows single sign-on for Web clients (SPNEGO) (
http://www-01.ibm.com/support/docview.wss?rs=899&uid=swg21394592 )
It is important to note that the most common failure when implementing SPNEGO is configuration of the browser client. This is because, by default, most browsers will reject a SPNEGO Negotiate challenge unless the site is in the "Local Intranet zone" (Internet Explorer), has been defined as a "Trusted Site" (Internet Explorer) or is listed in the "network.negotiate-auth.trusted-uris" key of about:config (Mozilla Firefox). This is to protect the user from potential man-in-the-middle exploits by preventing Kerberos token exchange with non-trusted DNS hostnames. If you are still unable to successfully implement Windows single sign-on for Web clients, and are confident that your browser client has been configured properly, you should continue with the steps below and review the technote previously mentioned.
☑ First, does the HTTP task load successfully? If you encounter any SSO errors when loading HTTP, you should examine your SSO configuration document. You might try to create a new SSO document and list only the individual Domino server, for which you are trying to load HTTP, in the "Participating Servers" field.
☑ If the HTTP task and SSO document load correctly, try to access a resource that allows anonymous access from a supported browser on the Domino server itself (for example: www.mydominoserver.com/homepage.nsf)
NOTE: During each of these steps, it is required that you use the fully qualified domain name of the Domino server, not localhost or 127.0.0.1. This should be the same FQDN that you used when setting the service principal name (SPN) in your Active Directory domain.
☑ If the above step does not succeed, disable session authentication in the server document, restart the HTTP task, and try to access the server again. If you still are not able to access the server after disabling SSO, then your problem with HTTP is not specific to SPNEGO. Please investigate other standard troubleshooting techniques or contact IBM Lotus Support to open a service request.
☑ If you are successful to this point, then (using the same browser on the local server), attempt to access a resource that allows "Default" access in the database ACL (for example: www.mydominoserver.com/names.nsf). If you are still prompted for credentials or receive a 401 Unauthorized and you are confident that the browser on the local server is configured correctly, then the service principal name (SPN) for the server may not have been assigned correctly. Please review the step
Setting up the Windows service for Domino in the Notes/Domino InfoCenter. If you are authenticated automatically (not prompted to provide credentials on a login form), then SPNEGO has been configured correctly between Domino and the Active Directory domain. At this point, your problem accessing secure resources from another workstation is either related to browser configuration on that workstation, or an issue mapping your Kerberos name to a Domino username.
☑ To confirm whether this is a browser configuration issue or name mapping issue, please create a test discussion database on the Domino server using the "Discussion - Notes & Web" template (discsw7.ntf). Set the "Default" access in the ACL of this database to at least "Author". Then, attempt to access this database on the Domino Web server from your workstation. If you are still prompted for credentials or you get a "Error 401: You are not authorized to perform this operation", then the client browser is not configured correctly. Please review the step
Configuring Web client browsers for Windows single sign-on in the Notes/Domino InfoCenter.
☑ If you are able to access a test discussion database over the Web, without being prompted for credentials, create a new "Main Topic". In the upper-left side of the new document, you will see the @Username field which displays your current Domino identity. If this username does not correspond to the distinguished name you expect, then you may have a problem with name mapping. Please review the step
Configuring user name mapping in a Windows single sign-on for Web clients environment in the Notes/Domino InfoCenter.
If none of the above steps are helpful in your attempt to isolate the issue, please review the technote previously mentioned or
open a service request with IBM Lotus Support. As stated in the technote, while troubleshooting issues with SPNEGO, you may find it useful to enable the following debug to assist in the investigation:
| CONSOLE_LOG_ENABLED=1 | Enables logging of all console output to <Domino Program Directory>\\<Data Directory>\\IBM_Technical_Support\\console.log |
| Debug_SSO_Trace_Level=2 | Enables SSO configuration and token debug - will take effect after restarting the HTTP task ("restart task http") |
| DEBUG_HTTP_SERVER_SPNEGO=5 | Enables detailed SPNEGO debug - will take effect after restarting the HTTP task ("restart task http") |
| webauth_verbose_trace=1 | Enables web authentication debug for troubleshooting name mapping & DA to external LDAP - effective immediately |
Below is an example of the console output from a Domino 8.5.1 server with this debug enabled, when a successful automatic authentication via SPNEGO has occurred. In this scenario, users are managed through Domino Directory and the Kerberos username is stored in the "Active Directory (Kerberos) logon name" field of the user's Domino person document. Name mapping to this field occurs because WIDE_SEARCH_FOR_KERBEROS_NAMES=1 is enabled in the notes.ini for the Domino server.
Please note: this is just one of the few possible methods for configuring name mapping. How you configure user name mapping in your organization depends on whether you manage users primarily through Active Directory or the Domino Directory. For more information, please review the step
Configuring user name mapping in a Windows single sign-on for Web clients environment in the Notes/Domino InfoCenter.
/* SSO configuration document is read as the HTTP task is loaded */
[150C:0002-10F0] 05/16/2010 11:45:41.48 PM SSO API> Parsing fields from configuration [SPNEGOLtpaToken]
[150C:0002-10F0] 05/16/2010 11:45:41.48 PM SSO API> -SSO configuration name = SPNEGOLtpaToken
[150C:0002-10F0] 05/16/2010 11:45:41.48 PM SSO API> -Token Domain = .austin.ibm.com
[150C:0002-10F0] 05/16/2010 11:45:41.48 PM SSO API> -Name mapping = Off
[150C:0002-10F0] 05/16/2010 11:45:41.48 PM SSO API> -SPNEGO = On
[150C:0002-10F0] 05/16/2010 11:45:41.48 PM SSO API> -Require SSL for token = Off
[150C:0002-10F0] 05/16/2010 11:45:41.48 PM SSO API> -Restrict token to to HTTP/HTTPS = Off
[150C:0002-10F0] 05/16/2010 11:45:41.48 PM SSO API> -Expiration = 180 Minutes
[150C:0002-10F0] 05/16/2010 11:45:41.48 PM SSO API> -Config Type = CONFIGTYPE_DOMINO
[150C:0002-10F0] 05/16/2010 11:45:41.48 PM SSO API> Setting token domain parameter [.austin.ibm.com]
[150C:0002-10F0] 05/16/2010 11:45:41.48 PM SSO API> Creation time not specified, using current time [05/16/2010 11:45:41 PM].
[150C:0002-10F0] 05/16/2010 11:45:41.48 PM SSO API> Expiration time not specified, using current time plus config expiration [05/17/2010 02:45:41 AM].
[150C:0002-10F0] 05/16/2010 11:45:41.48 PM SSO API> Setting token name parameter [LtpaToken]
[...]
[150C:0002-10F0] 05/16/2010 11:45:43 PM HTTP Server: Started
/* Web browser sends HTTP request for a secure resource and Domino server returns HTTP 401 WWW-Authenticate: Negotiate */
[150C:000A-1170] 05/16/2010 11:46:38.22 PM SPNEGO> Starting SPNEGO Negotiate - a properly configured HTTP client should send an Authorization: Negotiate header containing SPNEGO token when repeating the request /names.nsf
/* Properly configured browser returns SPNEGO authorization token and Domino verifies the token format received is SPNEGO */
[150C:000A-1170] 05/16/2010 11:46:38.33 PM SPNEGO> Success calling native routine AcquireCredentialsHandleW
[150C:000A-1170] 05/16/2010 11:46:38.33 PM SPNEGO> Security token format received is SPNEGO NegTokenInit
/* Domino validates ticket against Kerberos KDC to authenticate the user */
[150C:000A-1170] 05/16/2010 11:46:38.33 PM SPNEGO> Success calling native routine AcceptSecurityContext
[150C:000A-1170] 05/16/2010 11:46:38.33 PM SPNEGO> SSPI security attributes received 0x20802, but requested 0x20014
[150C:000A-1170] 05/16/2010 11:46:38.33 PM SPNEGO> Success calling native routine QueryContextAttributesW
[150C:000A-1170] 05/16/2010 11:46:38.33 PM SPNEGO> Success calling native routine QueryContextAttributesW
[150C:000A-1170] 05/16/2010 11:46:38.33 PM SPNEGO> Success calling native routine QueryContextAttributesW
/* User is authenticated by Kerberos service */
[150C:000A-1170] 05/16/2010 11:46:38.33 PM SPNEGO> User Administrator@ADLAB.AUSTIN.IBM.COM authenticated by Kerberos service HTTP/adlab.austin.ibm.com@ADLAB.AUSTIN.IBM.COM
[150C:000A-1170] 05/16/2010 11:46:38.33 PM SPNEGO> Success calling native routine QueryContextAttributesW
/* Kerberos name is returned and mapped to a Domino distinquished name */
[150C:000A-1170] 05/16/2010 11:46:38.33 PM SPNEGO> Authenticated user is Administrator@ADLAB.AUSTIN.IBM.COM via MSIE 7.0
[150C:000A-1170] 05/16/2010 11:46:38.33 PM WebAuth> Attempt to map name Administrator@ADLAB.AUSTIN.IBM.COM for Kerberos user.
[150C:000A-1170] 05/16/2010 11:46:38.33 PM WebAuth> LOOKUP Kerberos name (user='Administrator@ADLAB.AUSTIN.IBM.COM' org='')
[1330:000A-1484] 05/16/2010 11:46:38.33 PM WebAuth> LOOKUP in view $KrbUsers (user='Administrator@ADLAB.AUSTIN.IBM.COM' org='')
[1330:000A-1484] 05/16/2010 11:46:38.33 PM WebAuth> Warning: 0 matches for pre-authenticated user (user='Administrator@ADLAB.AUSTIN.IBM.COM' org='').
[1330:000A-1484] 05/16/2010 11:46:38.33 PM WebAuth> No unambiguous match for pre-authenticated user='Administrator@ADLAB.AUSTIN.IBM.COM' org=''
[...Internal function calls removed for clarity...]
[1330:0004-1484] 05/16/2010 11:46:38.44 PM LDAP> Type of search: FT Search
[1330:0004-1484] 05/16/2010 11:46:38.44 PM LDAP> ... FT Query: (([$$OBJECTCLASS] Contains ("inetOrgPerson") OR [$objectclass] Contains
("inetOrgPerson")) AND (([fullname] Contains ("Administrator@ADLAB.AUSTIN.IBM.COM")) OR ([ShortName] Contains ("Administrator@ADLAB.AUSTIN.IBM.COM"))
[1330:0004-1484] 05/16/2010 11:46:38.46 PM LDAP> FTSearch candidate matches: 1
[1330:0004-1484] 05/16/2010 11:46:38.46 PM LDAP> Type of search: Modified Since FT Search (05/15/2010 02:46:50 PM - 05/17/2010 11:57:02 PM)
[1330:0004-1484] 05/16/2010 11:46:38.46 PM LDAP> Found matching entry, Note ID: 6230
[1330:0004-1484] 05/16/2010 11:46:38.46 PM LDAP> Entry:
[1330:0004-1484] 05/16/2010 11:46:38.46 PM LDAP> dn: CN=Lotus Admin,O=LTSwebserver
[1330:0004-1484] 05/16/2010 11:46:38.46 PM LDAP> cn: Lotus Admin
[1330:0004-1484] 05/16/2010 11:46:38.46 PM LDAP> fullname: CN=Lotus Admin,O=LTSwebserver
[1330:0004-1484] 05/16/2010 11:46:38.46 PM LDAP> fullname: CN=Lotus Admin
[1330:0004-1484] 05/16/2010 11:46:38.46 PM LDAP> fullname: CN=Administrator,CN=Users,DC=adlab,DC=austin,DC=ibm,DC=com
[...Additional directory entry attributes removed for clarity...]
[1330:0004-1484] 05/16/2010 11:46:38.47 PM SEARCH returned '1' match(es).
[1330:0004-1484] 05/16/2010 11:46:38.47 PM ldap_search returned matched DN='CN=Lotus Admin/O=LTSwebserver'
[1330:0004-1484] 05/16/2010 11:46:38.47 PM Return buffer was added ok.
[1330:000A-1484] 05/16/2010 11:46:38.47 PM WebAuth> DirCtxSearchPersons found 1 entries for Kerberos user Administrator@ADLAB.AUSTIN.IBM.COM
[1330:000A-1484] 05/16/2010 11:46:38.47 PM WebAuth> Kerberos user 'Administrator@ADLAB.AUSTIN.IBM.COM' (org='') is mapped to CN=Lotus Admin/O=LTSwebserver
[...Internal function calls removed for clarity...]
/* Domino generates a LTPAToken and verifies access in ACL of requested resource */
[150C:000A-1170] 05/16/2010 11:46:38.62 PM SSO API> *** Getting Single Sign-On Config Data (SECGetSSOConfigData) ***
[150C:000A-1170] 05/16/2010 11:46:38.62 PM SSO API> ConfigName specified [SPNEGOLtpaToken].
[150C:000A-1170] 05/16/2010 11:46:38.62 PM SSO API> Retrieved global static cache memory for config [SPNEGOLtpaToken].
[150C:000A-1170] 05/16/2010 11:46:38.62 PM SSO API> *** Generating Single Sign-On Token List and retrieving token info (SECTokenListGenerateAndGetTokenInfo) ***
[150C:000A-1170] 05/16/2010 11:46:38.62 PM SSO API> ConfigName specified [SPNEGOLtpaToken].
[150C:000A-1170] 05/16/2010 11:46:38.62 PM SSO API> Retrieved global static cache memory for config [SPNEGOLtpaToken].
[150C:000A-1170] 05/16/2010 11:46:38.62 PM SSO API> Setting token domain parameter [.austin.ibm.com]
[150C:000A-1170] 05/16/2010 11:46:38.62 PM SSO API> Creation time not specified, using current time [05/16/2010 11:46:38 PM].
[150C:000A-1170] 05/16/2010 11:46:38.62 PM SSO API> Expiration time not specified, using current time plus config expiration [05/17/2010 02:46:38 AM].
[150C:000A-1170] 05/16/2010 11:46:38.62 PM SSO API> Setting token name parameter [LtpaToken]
[150C:000A-1170] 05/16/2010 11:46:38.62 PM SSO API> Encoding Domino style Single Sign-On token.
[150C:000A-1170] 05/16/2010 11:46:38.62 PM SSO API> -Creation Ticks = 4BF0CA2E [05/16/2010 11:46:38 PM].
[150C:000A-1170] 05/16/2010 11:46:38.62 PM SSO API> -Expiration Ticks = 4BF0F45E [05/17/2010 02:46:38 AM].
[150C:000A-1170] 05/16/2010 11:46:38.62 PM SSO API> -Username = CN=Lotus Admin/O=LTSwebserver
[150C:000A-1170] 05/16/2010 11:46:38.62 PM SSO API> Dumping memory of constructed token [69 bytes].
[...]
/* Domino returns a LTPAToken and the content originally requested */
|
IBM, Lotus Domino, AIX, and IBM System i (iSeries) are trademarks of International Business Machines Corporation in the United States, other countries, or both.
Microsoft Windows and Microsoft Active Directory are trademarks of Microsoft Corporation in the United States, other countries, or both.
Red Hat Enterprise Linux is a trademark of Red Hat, Inc.in the United States, other countries, or both.
Sun Solaris is a trademark of Sun Microsystems & Oracle Corporation in the United States, other countries, or both.
Mozilla Firefox is a trademark of Mozilla Corporation in the United States, other countries, or both.