• Search Forums
    Advanced Search Topics Posts
Prev
Next
Forums Infor / Lawson Platforms S3 Systems Administration

9006 to 9008 SSO failure

 5 Replies
 0 Subscribed to this topic
 27 Subscribed to this forum
Sort:
Author
Messages
DavidV
Veteran Member Send Private Message
Posts: 101
Veteran Member
3/1/2010 7:33 PM

We are trying to upgrade from 9006 to 9008.  We originally installed LSF 9006 on 10/26/2008.  On 06/03/2009 we ran ldapbind so that we could authenticate our Lawson logins to AD.  Everything worked great.  We been installed LSF patches and everything works fine.  Now we are trying to install 9008 and the install fails: @@ h2 note: security server started.
@@ h2 note: importing sso credential set.
Fatal: [install-sec.pl] sso config failed
Error: Fatal: [install-sec.pl] sso config failed

This is not a valid password.
Run this utility again with valid password. Exiting...


Error:
Error: Activating Lawson Security, RM, and SSO failed.
**** 2010.02.20 10.19.39 UPDATE Failed.
I tried with and without installing the lawsec_inst.ldif changes.  There were minor changes.  The biggest one being:################################################################################
#       RM metadata to be placed in containers defined in rootnodes.ldif
################################################################################

dn: lwsnrmbootName=People,lwsnrmbootName=RMOBJECTS,lwsnrmbootName=lwsnActiveMeta
Data,dc=mjh,dc=org
changetype: modify
replace: lwsnrmbootStructuralClass
lwsnrmbootStructuralClass: lwsnrmbootRMTopStruct

Lawson support will not help because I did the LSF 900 upgrade myself.

My question is, there are a couple parts. 
1-The point it is failing is when executing install-sec.pl  Which reads the install.cfg file.  And they said the install.cfg file doesn't matter, we'll it does.  Trust me.  So since I did an ldapbind do I need to change the LADP_CONSUME_USERS=FALSE to TRUE?
2-Should I restore using the backup from ldapbind, basically doing unbind; install 9008; and then run ladbind after the upgrade?

 

Any help would be appreciated

DavidV
Veteran Member Send Private Message
Posts: 101
Veteran Member
3/1/2010 7:42 PM
Note I verified the user and password in the install.cfg
MattM
Veteran Member Send Private Message
Posts: 82
Veteran Member
3/5/2010 4:34 PM
You should not have to change anything in the install.cfg file as a result of running the bind.

If you restore from the xml file the bind creates, you will have issues if the LDAP was modified as resources will be missing/modified etc...

The user in the install.cfg is not always correct, if you modify the user subsequent to the install, the install.cfg will not be modified.
MattM
Veteran Member Send Private Message
Posts: 82
Veteran Member
3/5/2010 4:36 PM
Also, have you updated your web applications and imported the LDIF files generated by ESPs and often times CTPs? If not, that can cause quite a bit of issue....
DavidV
Veteran Member Send Private Message
Posts: 101
Veteran Member
3/5/2010 5:10 PM
Thanks Matt,

I ran the bind in June of last year. Tons of ESPs and CTPs have been applied since and not once did the lawsec_inst.ldif get updated with schema changes. I always check for changes in this file even when the installer doesn't tell me to. I was shocked this time when it asked to apply ldif changes. After reviewing the changes I wasn't too concerned except for the People structural class attribute. The lwsnrmbootStructuralClass had inetOrgPerson and it wanted to change it to lwsnrmbootRMTopStruct. Here is the full lawsec_inst.ldif. I applied the changes before continuing with the initial install. I tried again w/o applying the changes. Both times the same error was reported. Everything is back to 9006 again and everything is working fine. I'm digging through the install-sec.pl and install-sso.pl perl scripts trying to figure out why it wanted to make these changes before making another attempt.
################################################################################
# object classes and attributes to hold objects defined in RM
################################################################################

DN:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-


dn: cn=zzlwsnobjPeople,CN=Schema,CN=Configuration,CN={EF101DC3-8B24-43BD-8100-A2E0F74002ED}
changetype: modify
add: mayContain
mayContain:zzlwsnattrEmail
-

dn: cn=zzlwsnobjPeople,CN=Schema,CN=Configuration,CN={EF101DC3-8B24-43BD-8100-A2E0F74002ED}
changetype: modify
add: mayContain
mayContain:zzlwsnattrFirstName
-

dn: cn=zzlwsnobjPeople,CN=Schema,CN=Configuration,CN={EF101DC3-8B24-43BD-8100-A2E0F74002ED}
changetype: modify
add: mayContain
mayContain:zzlwsnattrLastName
-

dn: cn=zzlwsnobjPeople,CN=Schema,CN=Configuration,CN={EF101DC3-8B24-43BD-8100-A2E0F74002ED}
changetype: modify
add: mayContain
mayContain:zzlwsnattrName
-

dn: cn=zzlwsnobjPeople,CN=Schema,CN=Configuration,CN={EF101DC3-8B24-43BD-8100-A2E0F74002ED}
changetype: modify
delete: mayContain
mayContain:displayName
-


dn: cn=zzlwsnobjPeople,CN=Schema,CN=Configuration,CN={EF101DC3-8B24-43BD-8100-A2E0F74002ED}
changetype: modify
delete: mayContain
mayContain:givenName
-


dn: cn=zzlwsnobjPeople,CN=Schema,CN=Configuration,CN={EF101DC3-8B24-43BD-8100-A2E0F74002ED}
changetype: modify
delete: mayContain
mayContain:mail
-


dn: cn=zzlwsnobjPeople,CN=Schema,CN=Configuration,CN={EF101DC3-8B24-43BD-8100-A2E0F74002ED}
changetype: modify
delete: mayContain
mayContain:sn
-


DN:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-


################################################################################
# RM metadata to be placed in containers defined in rootnodes.ldif
################################################################################

dn: lwsnrmbootName=People,lwsnrmbootName=RMOBJECTS,lwsnrmbootName=lwsnActiveMetaData,dc=mjh,dc=org
changetype: modify
replace: lwsnrmbootStructuralClass
lwsnrmbootStructuralClass: lwsnrmbootRMTopStruct
-

dn: lwsnrmbootName=Email,lwsnrmbootName=People,lwsnrmbootName=RMOBJECTS,lwsnrmbootName=lwsnActiveMetaData,dc=mjh,dc=org
changetype: modify
replace: lwsnrmbootMapping
lwsnrmbootMapping: zzlwsnattrEmail
-

dn: lwsnrmbootName=FirstName,lwsnrmbootName=People,lwsnrmbootName=RMOBJECTS,lwsnrmbootName=lwsnActiveMetaData,dc=mjh,dc=org
changetype: modify
replace: lwsnrmbootMapping
lwsnrmbootMapping: zzlwsnattrFirstName
-

dn: lwsnrmbootName=Name,lwsnrmbootName=People,lwsnrmbootName=RMOBJECTS,lwsnrmbootName=lwsnActiveMetaData,dc=mjh,dc=org
changetype: modify
replace: lwsnrmbootMapping
lwsnrmbootMapping: zzlwsnattrName
-

dn: lwsnrmbootName=LastName,lwsnrmbootName=People,lwsnrmbootName=RMOBJECTS,lwsnrmbootName=lwsnActiveMetaData,dc=mjh,dc=org
changetype: modify
replace: lwsnrmbootMapping
lwsnrmbootMapping: zzlwsnattrLastName
-

DavidV
Veteran Member Send Private Message
Posts: 101
Veteran Member
3/16/2010 5:54 PM
Issue resolved. 3 things
1)LAWDIR/system/RmMeta_Default.xml was wrong. Using Lawson RM schema editor click file and refresh meta data file. Make sure you have a backup of the file first. This rebuilds the RmMeta_Default.xml file using the existing schema definition in the LDAP.
2)LAWDIR/system/install.cfg - change LDAP_CONSUME_USERS=FALSE to TRUE
3)LAWDIR/system/install.cfg The SSO_CONF_PASSWORD and SSO_CONF_PASSWORD_CONFIRM were in correct. They were right in one environment, but not the one I was working on.

These three things corrected the issues I was having with the install of 9008.

Thanks for the help