glassfish
  1. glassfish
  2. GLASSFISH-15061

[BLOCKING] OAM 11G with LINUX for Basic authentication in the client got failed

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 3.1_b27
    • Fix Version/s: 3.1_ms08
    • Component/s: security
    • Labels:
      None
    • Environment:

      Linux / Windows

      Description

      Configure GlassFish v3.1 with OAM 11G as it is given in the document.

      To check the OAM server connection provide the URL as http://localhost:8080/BasicAuthen/SecureServlet
      in the browser.

      Authentication at OAM failed for user : GlassFish

      Failure happens in both Windows and Linux platform.

        Activity

        Hide
        rameshthiyaga added a comment -

        I have gone through the steps as it is given here,
        http://appserver.sfbay.sun.com/Wiki.jsp?page=3.1OAM

        ejp-172x-138.india.sun.com
        Appserver is installed under :
        /space/gf31/b2711G/
        AppserverSDK install Loc : /opt/netpoint/AppserverSDK/

        Show
        rameshthiyaga added a comment - I have gone through the steps as it is given here, http://appserver.sfbay.sun.com/Wiki.jsp?page=3.1OAM ejp-172x-138.india.sun.com Appserver is installed under : /space/gf31/b2711G/ AppserverSDK install Loc : /opt/netpoint/AppserverSDK/
        Hide
        kumarjayanti added a comment -

        Edited the bug summary since the problem now is only on LINUX and not on WINDOWS, but the summary indicates both Linux and Windows

        Show
        kumarjayanti added a comment - Edited the bug summary since the problem now is only on LINUX and not on WINDOWS, but the summary indicates both Linux and Windows
        Hide
        kumarjayanti added a comment -

        VNCed to ejp-172x-138.india.sun.com

        When i enter username/password as glassfish/glassfish i get to see the following :

        ---------------
        Servlet SecureServlet at /BasicAuthen
        Principal cn=Glassfish,o=company,c=us
        ---------------

        Since the user glassfish/glassfish was created by me on the OAM-10g Backend, i started suspecting that somehow the ASDK is not configured with the 11g AccessGate.

        So i tried running the command :

        [root@ejp-172x-138 lib]# ./configureAccessGate -i /opt/netpoint/AccessServerSDK -t AccessGate -w GlassfishAG -m open -h cieqalnx01.us.oracle.com -p 5575 -a oam_server1

        This was successful however when i observe the file :

        /opt/netpoint/AccessServerSDK/oblix/lib/ObAccessClient.xml

        which is the main file which the AccessGate client tries to use, i still see that it is pointing to the 10g instance :

        <ValNameList
        xmlns="http://www.oblix.com"
        ListName="primaryServer1">
        <NameValPair
        ParamName="host"
        Value="staqh24-5.us.oracle.com"></NameValPair>
        <NameValPair
        ParamName="port"
        Value="6021"></NameValPair>
        <NameValPair
        ParamName="numOfConnections"
        Value="1"></NameValPair>
        </ValNameList>

        And this explains why the username/password glassfish/glassfish works whereas GlassFish/GlassFish gives the following error

        ---------
        Authentication at OAM failed for user :GlassFish
        ---------

        1. I tried to manually update the ObAccessClient.xml (stored the old one as ObAccessClient.xml.bak) file to point to the 11g Instance (and restarted GlassFish) :

        Now authentication fails for both username/password pairs : glassfish/glassfish as well as GlassFish/GlassFish

        2. If i restore it back

        -----------
        [root@ejp-172x-138 lib]# mv ObAccessClient.xml ObAccessClient.xml.11g
        [root@ejp-172x-138 lib]# mv ObAccessClient.xml.bak ObAccessClient.xml
        -----------

        Again try then username/password pair glassfish/glassfish works successfully but GlassFish/GlassFish does not work again.

        So i suspect this has something to do with the fact that the QE is using the same ASDK installation for both 10g and 11g testing and this is somehow causing interference

        I would suggest the QE use a Fresh Linux Machine where the ASDK was never configured to work with 10g. Then configure it to work with 11g. This should solve the problem.

        Show
        kumarjayanti added a comment - VNCed to ejp-172x-138.india.sun.com When i enter username/password as glassfish/glassfish i get to see the following : --------------- Servlet SecureServlet at /BasicAuthen Principal cn=Glassfish,o=company,c=us --------------- Since the user glassfish/glassfish was created by me on the OAM-10g Backend, i started suspecting that somehow the ASDK is not configured with the 11g AccessGate. So i tried running the command : [root@ejp-172x-138 lib] # ./configureAccessGate -i /opt/netpoint/AccessServerSDK -t AccessGate -w GlassfishAG -m open -h cieqalnx01.us.oracle.com -p 5575 -a oam_server1 This was successful however when i observe the file : /opt/netpoint/AccessServerSDK/oblix/lib/ObAccessClient.xml which is the main file which the AccessGate client tries to use, i still see that it is pointing to the 10g instance : <ValNameList xmlns="http://www.oblix.com" ListName="primaryServer1"> <NameValPair ParamName="host" Value="staqh24-5.us.oracle.com"></NameValPair> <NameValPair ParamName="port" Value="6021"></NameValPair> <NameValPair ParamName="numOfConnections" Value="1"></NameValPair> </ValNameList> And this explains why the username/password glassfish/glassfish works whereas GlassFish/GlassFish gives the following error --------- Authentication at OAM failed for user :GlassFish --------- 1. I tried to manually update the ObAccessClient.xml (stored the old one as ObAccessClient.xml.bak) file to point to the 11g Instance (and restarted GlassFish) : Now authentication fails for both username/password pairs : glassfish/glassfish as well as GlassFish/GlassFish 2. If i restore it back ----------- [root@ejp-172x-138 lib] # mv ObAccessClient.xml ObAccessClient.xml.11g [root@ejp-172x-138 lib] # mv ObAccessClient.xml.bak ObAccessClient.xml ----------- Again try then username/password pair glassfish/glassfish works successfully but GlassFish/GlassFish does not work again. So i suspect this has something to do with the fact that the QE is using the same ASDK installation for both 10g and 11g testing and this is somehow causing interference I would suggest the QE use a Fresh Linux Machine where the ASDK was never configured to work with 10g. Then configure it to work with 11g. This should solve the problem.
        Hide
        kumarjayanti added a comment -

        Just shutting down the linux system and restarting it and then executing the following steps before starting glassfish might also help :

        cd /opt/netpoint/AccessServerSDK/oblix/lib
        mv ObAccessClient.xml ObAccessClient.xml.bak
        mv ObAccessClient.xml.11g to ObAccessClient.xml

        cd <gf.home>bin
        asadmin start-domain

        then try to access : http://localhost:8080/BasicAuthen/SecureServlet

        Show
        kumarjayanti added a comment - Just shutting down the linux system and restarting it and then executing the following steps before starting glassfish might also help : cd /opt/netpoint/AccessServerSDK/oblix/lib mv ObAccessClient.xml ObAccessClient.xml.bak mv ObAccessClient.xml.11g to ObAccessClient.xml cd <gf.home>bin asadmin start-domain then try to access : http://localhost:8080/BasicAuthen/SecureServlet
        Hide
        kumarjayanti added a comment -

        1. There seems to be a problem with configureaccessgate command when executed on linux systems as root.

        ---------
        [root@ejp-172x-138 configureAccessGate]# ./configureAccessGate -i /opt/netpoint/AccessServerSDK -t AccessGate -w GlassfishAG -m open -h cieqalnx01.us.oracle.com -p 5575 -a oam_server1

        Please enter the Password for this AccessGate :

        Preparing to connect to Access Server. Please wait.

        Error: Permission denied

        ---------

        2. Also as observed above when i looked into the Linux systems they seemed to have the 10G OAM address in their ObAccessClient.xml and since the 11g username is GlassFish/GlassFish it will fail on the 10G OAM Server.
        3. By manually copying ObAccessClient.xml onto both the systems :ejp-172x-138.india.sun.com, ejp-172x-53.india.sun.com i was able to get the scenario working.

        4. From time to time someone sets the default LDAP Server on OAM Server instance to point to an External LDAP instead of the Embedded LDAP on which we have initially created the users for the Dev-Test. So we have to make sure we reset the default to Embedded LDAP before testing these scenarios.

        Show
        kumarjayanti added a comment - 1. There seems to be a problem with configureaccessgate command when executed on linux systems as root. --------- [root@ejp-172x-138 configureAccessGate] # ./configureAccessGate -i /opt/netpoint/AccessServerSDK -t AccessGate -w GlassfishAG -m open -h cieqalnx01.us.oracle.com -p 5575 -a oam_server1 Please enter the Password for this AccessGate : Preparing to connect to Access Server. Please wait. Error: Permission denied --------- 2. Also as observed above when i looked into the Linux systems they seemed to have the 10G OAM address in their ObAccessClient.xml and since the 11g username is GlassFish/GlassFish it will fail on the 10G OAM Server. 3. By manually copying ObAccessClient.xml onto both the systems :ejp-172x-138.india.sun.com, ejp-172x-53.india.sun.com i was able to get the scenario working. 4. From time to time someone sets the default LDAP Server on OAM Server instance to point to an External LDAP instead of the Embedded LDAP on which we have initially created the users for the Dev-Test. So we have to make sure we reset the default to Embedded LDAP before testing these scenarios.

          People

          • Assignee:
            kumarjayanti
            Reporter:
            rameshthiyaga
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: