Hi Greg. it's an interesting idea and I'd keep thinking about it. For temps, they are either set up in HR with employee numbers, or get separate "temp.last.first" or similar IDs.

In addition, I'm actually a big fan of using employee number for AD account naming as well Not only does it solve the renaming of accounts when names change, it allows AD accounts to all be set up with similar (lower) privileges and forces IT users to use separate higher-privileged accounts only when needed, i.e. they have to logout of their "employee" user, and login as a separate admin-enabled AD account to do a specific task (yes, they have to have two accounts, but look at the security benefit).

Just don't do what one client I worked with did, and use SSN as employee number and then use employee number as their login

Thanks for the reply, John. We have (and have had for years) the ability to log in to Lawson with our employee ID.
We store it in a separate field on our AD record. For instance, say I log into AD with SmithSam. I could also log into Lawson with 10003733. We would like to continue this practice but with new hardware, we are starting to find it challenging.
New Win 2019 ADFS server specifically. Apparently there is some claim rule modification(s). and who knows what else was put in place by the consultant that got it all working 3-4 years ago when we moved to new hardware then. The biggest issue may be Smart Office. (and not knowing what was done by the consultant that originally got it working).

We don't relish the thought of re-doing all of our LBI reporting, that is all based on that Lawson employee number as well.

(If we have to move to authenticating against samAcctName)

Greg,
Connect with me. Perhaps I can help you document the changes, since one of my strong suites is reverse engineering solutions.

This probably doesn't help, but our organization decided to start using employee numbers as login in 2017. That is, our sAMAccountName became the employee number. users log on using their UPN. Unfortunately, this doesn't apply to contractors, volunteers and vendors, aka "non-employees", so we still have some other username formats. Our HR departments have not been keen on taking on maintaining the "non-employees".

So @Roy are you creating aliases for your email accounts then, or just going with the employee_number@company.com?

Hi Genssis,

We are using the same method you are using since the start of our implementation and we didn't find any issue with that.
What is the challenge you have to reconfigure it again for you after you install the new hardware?

Thank you