1 person found this helpful
Do you allow contractors access also? We do, and we have the opposite problem -- sometimes contractors leave and come back and are then provided a different email address from the one they had the first time. This was not much of a problem until Jive, but now it means they are "two different people" and possibly can't even access the content they created the first time around. So we are taking pains to try to make sure returnees get the same email address they had before.
We also have a process for giving ownership of an gmail account and Google docs to an employee's manager for a month after the employee leaves, after which it gets deleted. But we decided we did not want to do this in Jive because it would look like the manager made comments that the employee actually said. We are learning that clear ownership forever, not just at a single point in time, is the way to go in Jive if you plan to keep content around after it's creator moves on.
Yes we do. And that same problem will arise for returning employees if they are given a different email address. Sigh. Thanks for mentioning, Dennis!
1 person found this helpful
We're currently in the process of integrating our own AD solution. We're using Oracle ID as the primary and email address as a secondary. I'm uncertain how you guys handle rehired employees. As Dennis mentioned recycling employees can often cause a headache. Since we were less likely to recycle an employee ID it worked a little easier than email address.
Our hurdle was the fact that we're in the process of condensing numerous domains and in the process we will have older employees that have a first name last name identifier in Oracle. So Joe Smith would eventually have two accounts if left unchecked. (joesmith versus oracle id #). We're remedying this through some preemptive scripting using the email address as one of the checks to look for duplicate accounts.
If you're AD is sourcing from another system, and that system remains intact in the event of an employee leaving. Deleting users in AD would be a non issue since any rehire could be relinked to their original employee ID. That's said with the assumption that a rehire isn't simply assigned a new id and email.
Aaron J. Perrotte
Hi Tracy - we have done this for customers through a couple of different methods but in general we don't use the Email as the ID. We will generally use the AD GUID as the primary identifier in Jive with the Email address as the user login. This allows us to maintain a guaranteed unique profile identifier on the Jive side while still linking back into AD if we need to find out information about security groups etc. Bonus points: most of the SSO packages will support passing through the GUID as an assertion on the login request so this can integrate fairly easily into whatever SSO they are using.
The users don't see it and don't care since they are using their Email address to login.
I can foresee a problem with the deletion of users on the AD side in the event of a re-hire situation. By definition you will get a new GUID when you create the "new" re-hired employee so this will mean that they can't get the same profile that they had before in Jive (because it still has their original GUID). I'm sure that something could be created that would patch this, but it sounds like an unnecessary hand-operation to me. I wonder what is driving the desire to delete the record at all...
We do this as well, the jive user externalID is objectSID from AD - however this sits in a separate table to the main user data.
I wonder if you will still run into issues with Jive default constraints around unique email and username fields in the jiveUser table?
Maybe part of the leavers process would have to be modifying the username and email in the Jive record when you deactivate them? Perhaps add a suffix/prefix?
The deactivation is an automatic nightly process, so I'm not sure how we would modify the username and email. And then there is the issue that if the same person DOES rejoin, and is assigned the same email address, we CAN'T connect them to their old account.
Gee, this is thorny....
My understanding is that they want to keep the database "clean". But since there is so little data in AD, I'm not sure why that is important.
I'm glad it's not just us that's finding user data and user life-cycle a nightmare.
The frustrating thing is it shouldn't really be a Jive project team who are responsible for sorting these various business process issues out. However because it's the most visible system from the user perspective we get lumbered with trying to resolve the conflicts and inconsistencies.
No one ever used to be bothered by the fact that somewhere deep in their Outlook contact card it still had their first job title "shelf stacker”, but now they have a lovely visible profile which highlights them on every piece of content they suddenly want it to be the correct "senior shelf coordinator” etc
I'm sure there's a book in it somewhere, "Managing global user data processes in the enterprise” ?
Hi (I work with Tracy),
We have to remember that Active Directory's design objectives and use scenarios are worlds apart from what Jive's are. Why are things deleted? Quite simply because it's good practice and human nature to a point. The only times we consider data or information persistent is when we're legally obliged to.
I think we should accept a degree of hand operation. The exceptions we're trying to address are exactly that, exceptional. No system is 100% autonomous (at least not yet) every system to date still need a degree of [hand] work even to automate it.
A number of your experiences above are things we're considering as technical solutions. We also have a strong desire to reduce username and password fatigue, make IT more personal and engaging. Achieving some of these aspirations has meant changing the way we've done things in the past and these changes don't always lend themselves to fluid system integration.
We have a number of initiatives running in parallel which could help us like a new HR system which could inject employee numbers into AD and also the options of using other properties in AD.
While I'm still trying to visualise a solution I have one additional question about the primary ID. Is the primary ID fixed when the account is created – can it be changed? We already have a non-integrated system so I assume a lot of users have this field populated with an arbitrary value. Would we be using the secondary ID (email) as the key pair? If that’s the case (and I believe the secondary ID can be changed) then we might have something to work with like deactivating the AD account and later stripping the email address from both sides. When the AD account is deleted the Jive account would remain but without a secondary ID. If the user later re-joined could we then re-populate the secondary ID Jive side to re-establish the sync pair, this could be any email address they re-join with. Of course, if a different person joins with the same email address we could allow the overnight provisioning to create a new Jive account as normal.
I agree with your comments about AD, and yes a global HR system would help us too, hopefully it’s in the pipeline!
Regarding your question:
There is a main jiveuser table, this has a fixed jive id like 2234 as well as the username and email address which can both be changed.
When you link to an AD or SSO system, an additional ‘external id’ is created which links to the jive user id. This can be removed, although I'm not sure how easy it is to manually add back in again
Pretty much what you said.
I'm not sure how the user sync works though, and also your auto provisioning may still fall over as the Jive system will check email and username in the main table to ensure there are no duplicates.
So in principle it should be easier to add the same person back in even with a different email address - if that's what you use as the external identifier.
However to keep that user deactivated and insert a new user with the same email address may still fail - our user import actually checks for existing username or email values to see if it should update rather than insert a new record.
Thanks Martin and Michael.
Michael, because AD is not going to maintain the ID, stripping the email address from Jive will only resolve the issue of people being matched against the wrong account. We'll be left with the issue of re-employed people being assigned a new account instead of associated with their previous account. And while I'm not opposed to (some) manual effort, I don't see how we would be able to get an exception report to alert us of this situation (since AD isn't aware of reuse of a "previous" ID). The other side to that is that Jive doesn't provide the ability to merge user accounts, or to reassign content. So if a person ends up with two accounts, we have no automated or manual ability to recombine them. Nor do we have the ability to manually separate one account into two (if we accepted people getting assigned to a previous user's account). So if the user should notice that there is an issue, there isn't a mechanism available to correct it.
Because I don't see a way around the situation here, at this point I'm hoping that HRIS will gallop to the rescue with some sort of personally unique, persistent ID that can be passed to AD and thus used to match against Jive accounts.
Great to get other perspectives to ensure we aren't missing anything obvious, and to see what methods others have used to address similar issues!
I pretty much agree with all of your points with perhaps one divergence. If you think about the concept of a GUID or an identity within any authentication/entitlement system (like AD or a SSO) a unique identifier should uniquely and accurately identify a "thing" (person, network resource, whatever). The challenge is that when you delete an asset (in this case a person) and then re-add them later you aren't able to "attach" to the original asset that was deleted. You create a second "unique" identifier for the same asset - which kinda defeats the whole purpose of the identifier (and leaves lots of issues behind in any other systems that were depending on the identifier).
So my reluctance to delete the user stems not from a philosophical difference with your desire to keep things clean and lean, but rather with the fact that previous environments I have worked in were very dynamic (lots of departures and returns) so we found that being able to re-establish a link outweighed the value of deleting them from AD.
Annnnnd your questions are getting sufficiently technical that I'm going to loop in Carlo Saggese who is much more deeply experienced in this than I am.
We too accept that people come and go, our internal procedures allow for people who come and go so we have a grace period of say 6-12 months before accounts get deleted, they can be recycled up to then. AD doesn't really give too may headaches if we can't re-link an individual's digital identity partly because individuality [that GUID] isn't as significant as the role they play in the business or teams and also we're not deleting any [digital] property. As long as we can establish their personal identity its not really a problem. I'd surmise that this is why AD in design and practice promotes role based structures or groupings and depreciates the significance of the individual – specifically the user GUID. I recognise that a "creator owner" security principle exists but its not a principle we often use – partly because it difficult to control and partly because we can always take ownership back.
I'm afraid I have to disagree on this statement "a unique identifier should uniquely and accurately identify a "thing" (person, network resource, whatever)". The GUID in AD represents a unique object within the directory itself and has no representation outside the directory, its used to bind the directory together enabling both persistence and agility or change. The persona of that GUID can be changed not entirely but significantly. As a person I can modify many attributes in the object so could Geoff become Jane, a network site in Denver becomes Chicago, and so on. They may have the same GUID but they are not the same person.
So I'm not suggesting either AD or Jive is wrong, this is technology and technology is used in different ways to achieve specific goals. What I am saying is that "Barry Bobbs" isn't defined by his AD GUID or Jive unique ID. Barry is a person and if he has a digital presence or identity somewhere and says "hey, that’s me!" I'd like to give him back that identity rather than say "well... your current digital fingerprint doesn’t match so that's not yours".
My ambition is a solution that works for humanity not humans that have to work for technology.
Sorry, I've droned on a bit.
Again I don't fundamentally disagree with any of your points philosophically with perhaps one exception - there is a value having something (A GUID, a unique login name, whatever) that uniquely and permanently identifies something. Stuff changes - I had a user who (over the course of 10 years) joined our company while married, got divorced (and kept her last name), remarried (and changed her name), divorced again and took her maiden name back. Her Email and login names changed but her GUID never did and we were able to handle that because her login name and email weren't the "unique" identifiers that tied together all her stuff in AD.
The beauty of something like a GUID (imo) is that it works (to your point) in service to the person - they don't have to know it is there but it quietly ties everything together in the background no matter how their other stuff changes (like last names). The model falls apart if whatever the unique thing is that labors in the background becomes mutable - a large part of the value is that it is "the" immutable thing that identifies the item. If more than one key can be used to identify something then the possibility of cases will arise where there can be more than one way to identify the same thing. Also the case will arise where the two identifiers will point to two different sets of stuff that actually should be part of the same thing (as is the case under discussion here). In order gather all of the content together you somehow need access to both keys to gather together the complete picture.
Jive is pretty flexible about this - but it does, at the core, depend on some unique identifier for the person (as does AD).
In my experience managing and participating in very large networks there is an enormous value to having some permanent unique identifier for a person that is never re-used and is never re-issued. Whether it is a login name, email address, GUID or something else really doesn't matter much. Just pick something and stick to it. Otherwise you spend a whole lotta time solving problems of re-connecting multiple sets of data that actually are part of one set.
Just my opinion!
When a user is employed, and active, there is a state of:
When a user departs, and becomes disabled in AD, that account changes to:
So this can match the Jive setup of disabling federated users. Here's a list of the codes for users. This is what is could look like in Jive:
Also, you can configure the Jive Group Mapping (Group Filter) to match up to a selected set of groups. That way you filter out the cruft. Here's a list of those groups. We've set our group filter to look at security groups:
and it simplifies everything.
Don't change a primary identifier in AD. If a person is already setup in a mixed environment (mac, pc, nix) then they risk blowing up their entire environment for everything, not just Jive.
Our AD team had decided to use email address as the unique ID for Active Directory. However, their plan is to delete accounts in AD as people leave the company, and thus potentially re-use email addresses for new employees. Their philosophy was that point-in-time uniqueness was acceptable.
That sounds like CRAZY TALK. I am no Active Directory expert but in addition to the downstream app ramifications (as you pointed out with Jive) even with email this seems like a horrible problem waiting to happen. What if someone opted in to mailing lists and now when I'm the new hire I get all his spam!
Unique usernames (or email addresses, if you prefer) seems like an obvious best practice. In our company we've broken the rule on a very very small number of occasions such as when a new CEO is hired and takes the "firstnameofceo" username even if there was a now-terminated user with this username.
As a former Active Directory and Exchange Messaging Architect (9 years), I would highly recommend using an Identity Management solution to proxy the authentication and mapping between Active Directory and any other systems such as JIVE. This provides much more flexibility in terms of managing IDs.
As for using email address or Proxy Address attribute as it is known for uniqueness in AD; I am against it. Even when deleting the AD accounts, reusing email addresses can cause problems for future employees.
AD can withstand massive amounts of accounts within the service, so I wouldn't recommend deletion as a method to "clean" things up. ("deletion for the purpose of reuse" a small disaster that results in a global catastrophe) In fact you can have completely federated multi organizational structures within the domain. This really means that you can contain users/ids/email addresses of departed employees. It's just a matter of moving them into a disabled users OU. That way returning employees can be reactivated without hiccups. There's always issues of returning employees and errors (like mistaken leave-of-absences or sequesters or corporate transfers) that can create havoc of user changes and modification within Jive. The database legwork alone on resolving a prior "expert" in Jive with massive amounts of content should ward anyone off of deleting user accounts in AD.
email as an identifier is really a veneer to hooking GUID or UID to an account. It's just an abstract layer.
AD-wise, the things that you'd probably desire is a flexible OU approach so sorting and managing personnel is achievable. You probably also want to map Jive to leverage AD groups (security groups or resource groups) so you don't have to configure Jive permissions too many times.
SSO is also extremely helpful as Richard Rashty suggests. That can trim some of the information and align users accordingly. It also allows you field matchup via SAML.
My philosophy is: go old school and stick with unique numbers for each person: GUID or UID. Numbers rock and are far easier for sequential managment. That's the AD / Unix side. Sure use email for logins, but it all needs to tie back to a unique per person one-time-use or you'll have collisions.
Doug MacKay your are 100% correct. These discussions show that while Social Platforms are linked and sold to clients based on Business Outcomes, there are numerous Technical dependencies and interrelationships that exist and need to be resolved in order to drive that wonderful experience we all talk about.
+1 to every comment made about not deleting accounts/reusing user IDs of any type. You have all said better than I ever could.