ldap bind expired password issue

We are a managed services customer and have Lawson authentication bound to our local AD.


We use one intranet page for all password resets.


When a new emp is hired, an LDAP record is created for them with an initial password. (That's in our LDAP rather than Lawson's; it's used to authenticate them into email and other network resources.).


New employees are instructed to log in to the password reset page right away and change their password from the default to one of their choosing. Existing employees use the same page when they want to change their passwords.


The page runs a script that checks for the presence of a matching AD account, and creates it if not found.

At this point anyone using the page has an AD account, either just created by their first use of the page, or one they have had and been using.


Next, the page synchronizes the AD password with the LDAP password, i.e. it sets the AD password to the new password they entered on their page.


Now they can log into Lawson.

Hi DavidV,

We have a situation vary similar to yours. I like mikeP's approach, but we haven't been successful in making it happen to this point.

What we did was develop something called a "Deskless Worker" type of account in AD. These accounts are limited to Employee-Self-Service-Only users (no managers, super users, HR, etc). We have certain criteria that determine who gets these accounts - hourly non-exempt employees, etc. These folks basically have accounts that are only used for downloading check stubs, making benefit elections, and doing other similar tasks and they can only see their own information. We have these accounts set to "never expire" passwords. If the user forgets their password, they have to contact our IT Service Desk to have the password reset.

We also worked with Microsoft to set up these accounts to reduce the licensing cost impact - these Deskless Worker accounts are highly restricted as to the applications they can access via AD authentication - basically just Infor Self Service apps.

If a user requires more access or additional applications, then the account is converted to a "regular" AD account.

I hope this helps!

Kelly

Thanks Tim. We were looking for something that could possibly be used by all users. IE Possibly reduce the number of helpdesk calls. We'll definitely keep this in our back pocket. Hopefully the security administrator buys into it.

mikeP what did you use for the password reset page? PowerShell, vbscript, or some other app. I found one app via google search called ADSelfService plus, but it's kind of pricy and I'm not sure it's what we want. Hope to get a trial license to test it out.

I was talking with the guy who wrote it yesterday.  It's a PERL script that runs on a UNIX box.  He said it was a bit tricky getting the password value twiddled into the format Microsoft would accept for an AD password, but it boiled down to including the right PERL libraries and about four lines of code.

This is topical for us right now because as we move to Infor 10, managed services says they can't provide us the same password reset scripts as were provided to us for version 9 because the Infor user accounts (needed for LID access, IPD, etc) are now Infor AD accounts rather than local server accounts, and they don't have script that can change passwords in their AD.  I could go on, but I won't.