ldap bind expired password issue

Sort:
You are not authorized to post a reply.
Author
Messages
DavidV
Veteran Member
Posts: 101
Veteran Member
    We have many employees who don't have PCs available to connect directly to our network.  We have kiosks available for them, but they cannot login to Lawson when their password is expired.  The LDAP Bind doesn't account for the extra calls to handle expired AD passwords.  Is there an app or script that would allow them to authenticate to the network and allow them to reset their password before connecting to Lawson?  How have others addressed this issue?  We have about 1,500 employees that fall into this category.  They have initial AD accounts created for them with unique default passwords that are expired.  One solution was to communicate this to the managers and have them assist them but we're looking for a better alternative.
    mikeP
    Veteran Member
    Posts: 151
    Veteran Member
      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.
      Woozy
      Veteran Member
      Posts: 709
      Veteran Member
        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
        Kelly Meade
        J. R. Simplot Company
        Boise, ID
        DavidV
        Veteran Member
        Posts: 101
        Veteran Member
          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.
          mikeP
          Veteran Member
          Posts: 151
          Veteran Member

            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.

            You are not authorized to post a reply.