Help Desk password reset tool?

Are you using SSOP passwords stored within Lawson LDAP, or are you using ldapbind and storing SSOP passwords elsewhere?

BTW, if you're storing the SSOP passwords within Lawson LDAP, users can change their own passwords via portal or /sso/useratts.htm

We are not binding just yet.  I need a good Help Desk tool to establish a new password but then direct the user to set it to something they want.

What about ssoconfig? 

DO NOT GIVE A HELP DESK SSOCONFIG!! Once they have it, you have no control over which options are accessible. This means ability to do ANYTHING in the system. Including destroy it.

What you want to do will require some custom coding. I have written this for others, so if you want more information, contact me.

The reason /sso/useratts.htm will NOT work in this case, is it makes two assumptions. One it assumes you are changing your own data. Two, it assumes you are already logged in.

Kwane
954.547.7210

Also, just in case you think you could wrap a sudo script around ssoconfig, don't think about it, unless you have EXACTLY ONE helpdesk person at ONE time making resets. The reason is race conditions in the ssoconfig code. I might be ok, but you will get 'lase' locks when more then 4 people do it, and may get 'lase' locks anytime more then one person does it simultaneously.

Kwane
954.547.7210

Kwane, I was suggesting that--since they're not using binding--their users could use /sso/useratts.htm to change their *own* passwords. Not that their helpdesk users could use it for managing passwords for OTHER users. One drawback of using /sso/useratts.htm is that it also allows access/changing of the user's environment password in addition to the SSOP password.

The best solution IMHO is to use binding and to use the password change facility associated with your native LDAP provider.

I agree with you on using the native external LDAP's facilities. Also, you can control which services are available to be controlled with useratts.htm

Kwane

Thanks for the discussion. I never intended to give help desk ssoconfig command line. I was hoping to script something. I could script the creation and load of an xml file to change the password. This script could also confirm that no other instance was running. (This is me dreaming).

I agree, the best solution is to bind. We won't be getting there this year because we're pressed for time just to get LSF9 running. We don't have time to redesign security.

What about a custom web app (built in PHP or something) to directly talk to the LDAP? I have access to the ldap and have LDAP functions. If I could understand where the password value is, I could definately do that.

ldapbind is not redesigning security. All it does is point the portal (SSOP) password lookup/validation away from Lawson LDAP to your primary network's LDAP, which is often Active Directory, which makes your user's Portal password the same as their network password.

By "redesign security" I mean implement Lawson role-based-security in order to be in the position to bind. Right now we have many people with multiple logins. I love the bind idea, we just have to implement Lawson security first.

ldapbind has nothing to do with role-based-security. It's simply a way to redirect the password lookups. Do the users who have multiple logins have those logins created explicitly/only on your Lawson server, or does those logins exist on your network as well?

I guess I'm not being clear.

We have many users with multiple logins. For simplicity, these logins are the same as their normal Novell network login with -rss, -mss, -app on the end. The 8.0.3 Apache password file is easily maniuplated to make these passwords all the same during initial set up or reset. All the user has to remember is what they're doing (RSS, MSS, Application) and append the end. The login that matches their normal network login is used for ESS. The logins different from their regular network logins are not in Novell and aliasing does not work. If we did a bind, only the login without an extension would work (ESS). In order to do the rest we have to implement Lawson security and combine these logins first.

Is that making sense?

Ok, I see what you mean by redesign security. The only way to manage security in this fashion, would be to write a webapp, since a script hitting ssoconfig would have some race issues (though it would work, if thought out properly). Unfortunately, you can't just directly update the LDAP, since you don't have a way to encrypt the passwords yourself. There is a way to do it, but it is a crazy mess to do, and isn't worth the effort.

As I posted before, I have written code to do this. I will not post details on any forum, though.
Feel free to contact me.

Kwane
954.547.7210

What if I did have a way to encrypt passwords? Do we know the method LDAP uses?

I'll look to call you this week. Thank you.

<!-- Converted from text/plain format -->

I was thinking the same thing. One option might be to use the Bouncy Castle routines that Lawson uses and create an .ldif ldapmodify file.
John Henley

Now we're on to something. I'm going to investigate Bouncy Castle to see what I can learn. All I know now is that it's required and our consultant is installing it.

I'm going to do some research. Thanks for the lead. Let me know if you have any knowledge of Bouncy Castle.

New idea:

What about processflow? Do you know if the RM Resource Update module can write a password? If so, I think I could rig something

ProcessFlow Integrator's ResourceUpdate can update passwords, but /ResourceQuery nodes can't see change passwords.

I can't win. Lawson has made it so if you're not using bind, the Security Administrator is the only way to reset passwords. They're really pushing towards the bind.

It seems that my last option is to attempt to script an xml upload via ssoconfig. I might use that for scripting new employee additions to ESS but I'd better stick with the Security Administrator for Help Desk.

I've had luck with ssoconfig -l filename.xml.

What about scripting that? That would leave ssoconfig out of the wrong hands by only providing enough to get the job done.

I've gotten pflow to change a password.  It works fine.  I'm creating a separate security structure to set up temp passwords, then the user establishes a new password that is then picked up by a custom program that creates a work unit for my flow.

The only problem I have is that the sync to/from LDAP is only every 15 minutes.  If a user resets a password it can take 15 minutes to take effect.

Two options: 

1. Decrease the sync time (don't want to do this)
2. Manually sync.  I don't know how to do this.  I see that when a user sets their own password in portal that it take effect immediately.  I imagine that it calls a refresh applet of some kind.  I'd like to call it in my flow.

Any ideas?

I'm in the same boat.

Do you know the password attribute in ldap that needs to be updated? I'm in a process or creating a webapp that will reset the SSOP password - the only password attribute I found is 'lwsnssoAllAttrValueList' - which has both the PASSWORD:'encrypted' and USER:user1  - as an array attibute. My webapp can successfully update this attribute, but it doesn't take the change. I've emailed John to ask if he's got any other ideas.

Using processflow integrator, it's a simple resource update to the SSOP service. Since we're not binding yet, it works great. I'm not trying to talk to LDAP myself, just making a web site that can feed some info for processflow to take over.

now I just need to force the sync for the best possible user experience.