That's also something that is probably more palatable if you phase it in.
Start with new accounts being created that way, then any accounts which require
changes get migrated, then later (if ever) migrate the remaining accounts.
Since many of those may go away due to attrition depending on your environment
a lot of the pain can be spread out over time or even eliminated.
--
There are 10 kinds of people in the world...
those who understand binary and those who don't.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Maglinger, Paul
Sent: Thursday, May 22, 2014 9:40 AM
To: '[email protected]'
Subject: [NTSysADM] RE: Adding employeeNumber field in ADUC user property window
It's cool.
I know that putting in a change like this, although probably better in the long
run on so many levels, is going to be difficult to be accepted by the users.
I'll have to put together a pretty damn good case and presentation to make it
happen.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Michael B. Smith
Sent: Thursday, May 22, 2014 8:06 AM
To: [email protected]
Subject: [NTSysADM] RE: Adding employeeNumber field in ADUC user property window
Hahahaha
I was being facetious, actually. I hope you didn't take it personally. It
wasn't intended to be personal.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Maglinger, Paul
Sent: Thursday, May 22, 2014 1:59 AM
To: '[email protected]'
Subject: [NTSysADM] RE: Adding employeeNumber field in ADUC user property window
Yep - didn't see this coming 18 years ago...
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Michael B. Smith
Sent: Wednesday, May 21, 2014 7:38 PM
To: [email protected]
Subject: [NTSysADM] RE: Adding employeeNumber field in ADUC user property window
+1
Insufficient planning ahead of time.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Ken Schaefer
Sent: Wednesday, May 21, 2014 8:33 AM
To: [email protected]
Subject: [NTSysADM] RE: Adding employeeNumber field in ADUC user property window
Can you elaborate?
The way I see it:
Your identity is ABC123 - totally abstracted from your name. This is the lowest
common denominator that works across all your systems Your display name in AD
is infinitely flexible (governed only by policy - you can't call yourself
F*ckGWBush or F*ckObama) You can use a provisioning tool across all your major
systems to keep any identity changes, and display name changes "in sync"
(subject to whatever audit trail requirements there are to marry any new
identity to old identity)
Why can't you change either the identity or the display name?
Cheers
Ken
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Maglinger, Paul
Sent: Wednesday, 21 May 2014 10:19 PM
To: '[email protected]'
Subject: [NTSysADM] RE: Adding employeeNumber field in ADUC user property window
The trouble would be now is that I can't change it without breaking things.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Free, Bob
Sent: Tuesday, May 20, 2014 6:37 PM
To: [email protected]
Subject: [NTSysADM] RE: Adding employeeNumber field in ADUC user property window
Nope, I wouldn't. I understand completely. We get that all the time. We have a
self-service web page where they can update a lot of that stuff.
Lots of reasons to be flexible with names, the name they are provisioned with
sourced from HR is often not the one they want to use. Some people get really
passionate about being called Betsy vs Elisabeth
They often need to deal with ambiguity in display names as well. Douglas
Johnson(IT) vs Douglas Johnson(HR), people want things like Robert(Bud) Smith Jr
That's why systems like I mentioned use some construct other than actual name
and leave that cosmetic stuff to Display Name and other attributes that can be
changed at any time without downstream impact.
Ours just used the 3 initials + 1 number. e,g ABC1. Ironically one of the guys
who came up with it had the initials ABC :-)
That becomes challenging after a while when more than 10 people have the same
initials. I've seen universities that use 3 initials + 3 numbers. ABC001 etc
Lot of ways to skin that cat
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Maglinger, Paul
Sent: Tuesday, May 20, 2014 2:33 PM
To: '[email protected]'
Subject: [NTSysADM] RE: Adding employeeNumber field in ADUC user property window
>From a strict IS perspective I see that.
>From a user perspective - if you were a woman who went through a particularly
>nasty divorce, would you really want to be reminded of that every time you
>logged in?
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Free, Bob
Sent: Tuesday, May 20, 2014 4:20 PM
To: [email protected]
Subject: [NTSysADM] RE: Adding employeeNumber field in ADUC user property window
I think many (most?) folks' approach is , just don't change samaccountname...
If they want a cosmetic name change, there are plenty of name attributes to
make them look nice in the GAL and other systems.
Personnel numbers have changed here depending on which HR system was in place.
Names change...Solutions and systems change... You need a single source of
truth across everything...IMHO.
We have an NRC requirement for such a single immutable identifier so a scheme
was established long ago that establishes their CorpID and UID at account
provisioning time. Neither is ever changed or reused. In hindsight, that made
it easy for us.
We established samaccountname as the attribute mapped to CorpID in AD in the
beginning, UPN is also a construct of it, mail, Lync, Unity and on and on..
Before that it was used in NT, Banyan, UNIX , mainframe, email gateways etc etc.
My CorpID (samaccountname) shows up in >15 other AD attributes. Heaven knows
how many other systems use it. Even if you don't have regulatory requirements
for such (yet), it's a good way to go.
I guess if you only log into one or 2 systems with your identity it is cool but
it sure won't scale in an environment where you have many, many systems
consuming the identity.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Maglinger, Paul
Sent: Monday, May 19, 2014 3:03 PM
To: '[email protected]'
Subject: [NTSysADM] RE: Adding employeeNumber field in ADUC user property window
That doesn't make me any happier.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Michael B. Smith
Sent: Monday, May 19, 2014 4:55 PM
To: [email protected]
Subject: [NTSysADM] RE: Adding employeeNumber field in ADUC user property window
That isn't new :)
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Maglinger, Paul
Sent: Monday, May 19, 2014 5:37 PM
To: '[email protected]'
Subject: [NTSysADM] RE: Adding employeeNumber field in ADUC user property window
I'm glad to hear from someone that used it.
This is spurred by the discovery that Cisco Unity Connections 10 uses LDAP
sync. Funny thing, users get married and divorced and require account name
changes. If the association between Unity and AD is based on the
samAccountName the association breaks - and you apparently can't just associate
the old voicemail account with the new account name. You have to delete and
recreate the Unity account.
Something else that the sales rep and engineers didn't mention when we were
considering this solution.
Now looking into using an attribute that won't change and employeeNumber is an
option.
Powershell is a definite for initially populating the attribute for existing
users. I'd still like to have something available that's already familiar with
everyone else for new users.
-Paul
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Melvin Backus
Sent: Monday, May 19, 2014 4:13 PM
To: [email protected]
Subject: [NTSysADM] RE: Adding employeeNumber field in ADUC user property window
I'm guessing you probably found the same one I did. I've been running if for
about 5 years now with no "known" ill effects, in case that makes you feel
better. We also handle employee type that way too. I agree, a separate tab or
being able to expose it on one of the existing tabs would be preferable, but
lately I've started using powershell for that sort of thing.
--
There are 10 kinds of people in the world...
those who understand binary and those who don't.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Maglinger, Paul
Sent: Monday, May 19, 2014 5:02 PM
To: New NT System Admin List ([email protected])
Subject: [NTSysADM] Adding employeeNumber field in ADUC user property window
Is there a way to add a place under say, the General or Organization tab of the
user properties to enter the employeeNumber value without having to go into the
Attribute Editor and modifying it there?
I found an article which would have me put a vb script on the server, and then
right-click on the account to set the value. I'm not real crazy about putting
a vb script on my domain controller, much less one I downloaded from the net.
And I'd like the option to be available on all the DCs.
Anyone have any other options? Ideally I'd like to see a place on user's
property page in ADUC.
-Paul
PG&E is committed to protecting our customers' privacy.
To learn more, please visit http://www.pge.com/about/company/privacy/customer/
PG&E is committed to protecting our customers' privacy.
To learn more, please visit http://www.pge.com/about/company/privacy/customer/
