IBM Support

LO47872: BROWSER USERS FAILED TO LOGIN SERVER WHEN THE 2 DOMINO SERVERS H AVE SAME DNS SUFFIX NAMES.

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as fixed if next.

Error description

  • Browser users failed to login server when the 2 domino servers
    have same DNS
    suffix names.
    
    Background:
    
    1. there are 2 domino servers.
    
    2. the 2 domino servers are locating in 2 different domains.
    
    3. there is no any relationship between the 2 servers.
    
    4. sso is configured separately in both the 2 different domains.
    
    --------------------
    
    Domino servers' informations:
    
    1. the first domino server name is:  802e/802dom
    FQDN is: 802e.st.qq.com
    user name: admin/802dom
    
    
    2. the second domino server name is: server-802/802Org
    FQDN is: 802.qq.com
    user name: admin/802Org
    
    Note: the 1st server's DNS suffix (st.qq.com) is subset of the
    2nd server's DNS suffix (qq.com).
    
    --------------------
    
    Steps to reproduce:
    
    1. Open IE, access the first server :
    http://802e.st.qq.com/names.nsf,
    enter the user name (admin of the first server) and password in
    login form. The
    login is successful.
    
    2. In the same IE, change URL to the second server:
    http://802.qq.com/names.nsf, the login form appears. After
    entering the
    user name (admin of second server) and password, the login is
    successful.
    
    IE think qq.com is a different DNS from st.qq.com, so login is
    successful.
    
    ----------------
    
    3. Open a new IE, access the second server :
    http://802.qq.com/names.nsf,
    enter the user name (admin of the second server) and password.
    The login is
    successful.
    
    4. In the same IE, change URL to the first server:
    http://802e.st.qq.com/names.nsf, the login form appears.
    After entering the
    user name (admin of the first server) and password, fail to
    login.
    
    IE think st.qq.com is same DNS as qq.com.
    
    5. enable below debug notes.ini parameters on the first server:
    
    webauth_verbose_trace=1
    debug_sso_trace_level=3
    
    
    Below log is on console of the first server:
    [16F4:0011-1298] 2010-01-14 14:17:38.88 SSO API> Digest
    verification failed
    [Single Sign-On token is invalid].
    [16F4:0011-1298] 2010-01-14 14:17:38.88 SSO API> ERROR: when
    decoding Domino
    LaToken [Single Sign-On token is invalid].
    
    
    6. using javascript:alert(document.cookie) for printing the
    cookie.
    
    For the above step 3, below is the print result:
    ---------------------------
    Microsoft Internet Explorer
    ---------------------------
    LtpaToken=AAECAzRCNEVCMkExNEI0RUI5QTlDTj1kd2EgdXNlci9PPTgwMk9yZz
    fF4Pve5Yxg+aKcfk
    qrX3H4EDbr
    ---------------------------
    
    
    
    For the above step 4, below is the print result:
    ---------------------------
    Microsoft Internet Explorer
    ---------------------------
    LtpaToken=AAECAzRCNEVCMkExNEI0RUI5QTlDTj1kd2EgdXNlci9PPTgwMk9yZz
    fF4Pve5Yxg+aKcfk
    qrX3H4EDbr;
    LtpaToken=AAECAzRCNEVCMkQzNEI0RUI5REJDTj1hZG1pbi9PPTgwMmRvbYPRFa
    VeBDc6KslH0YPpg+
    TFuAbk
    ---------------------------
    
    
    
    So we can see that the first session cookie is still existing in
    the second
    session, and the second new cookie is appended after it.
    
    
    --------------------------------
    
    7. I tried the following also:
    
    1) using internet site document for specifying the domain name.
    2) change the Token name in WEB SSO document to other name (such
    as LtpaABC)
    instead of the original name (LtpaToken).
    
    But the above could not fix it.
    
    
    Note:
    1. Customer is using Domino R7.0.2.
    2. The above test is done on Domino R8.0.2.
    

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

  • This APAR is associated with SPR# MZHA7ZP9F5.
    This issue was raised against V6x or V70x.  There are no more
     planned maintenance releases.  If issue continues to occur in
     a later 8.5x release, it can be re-raised for consideration
     against that release.
    

APAR Information

  • APAR number

    LO47872

  • Reported component name

    DOMINO SERVER

  • Reported component ID

    5724E6200

  • Reported release

    702

  • Status

    CLOSED FIN

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2010-01-14

  • Closed date

    2010-02-19

  • Last modified date

    2010-02-19

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Modules/Macros

  • NA
    

Fix information

Applicable component levels

  • R702 PSN

       UP

[{"Business Unit":{"code":"BU055","label":"Cognitive Applications"},"Product":{"code":"SSKTMJ","label":"Lotus Domino"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0.2","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
19 February 2010