Prev
Next
Forums S3 Systems Administration

Creating user profiles for employees from more than one domain?

Sort:
You are not authorized to post a reply.
Author
Messages
TBonney
Veteran Member
Posts: 277
Veteran Member
6/20/2018 1:17 PM
    We have entered into an affiliation with another, "non-Lawson" local hospital a few years ago. Since then, we have integrated the HR & Payroll functionality from their legacy HR/PR system into our Lawson system, so that we now utilize a single HR/PR system & process.

    The only piece we've yet to allow is ESS access for their employees. As such, they do not have access to their paychecks which are being processed out of Lawson. We'd like to address this and create Lawson Security accounts for them so they too may access their employee information as "our" employees do, through ESS. However, all of their users still reside in a separate domain.

    Has anyone ever built user profiles for groups of employees form different domains? Is that possible within the confines of Lawson Security? How complex is it to do? And, would anyone who has attempted this process/approach be willing to discuss it with us?

    Thank you in advance for any feedback provided.

    (p.s. - In order to get maximum views & increased potential for feedback/responses, I am posting this to both the Security forum and the Administration forum.)
    Kwane McNeal
    Veteran Member
    Posts: 479
    Veteran Member
    6/20/2018 1:34 PM
      There are a few ways, but it depends on a few factors:

      First, if there is no common top-level forest, AND you can ensure there are NO TWO OR MORE accounts that have the same identifier (such as sAMAccountName), then your only option is to use the multi-domain bind feature.

      ...Now if there is no common top-level forest, AND there is the possibility of TWO OR MORE accounts with the same identifier, then you'll have to use EITHER multi-domain bind AND prepend it with the domain name OR some sort of two way trust AND a combination of universal and domain local AD groups. This is your worst case, because you'll likely have to convert your existing SSOP and I'm not sure for batch job purposes that the AD group enumeration functions work correctly on domain local or universal groups.

      If there IS a common top-level forest, then you can just craft a LDAP search pattern that finds the users, assuming there are no DUPLICATES. if there are, then you'd likely have to use the prepend domain with the multi-domain bind
      You are not authorized to post a reply.