LDAP Authentication for apps - where and what to use for user data store

[WannaFly]

So, I've been developing plenty of small apps for our department, they all use .NET and LDAP authentication - it works great, but looking back the design leads to some flaws. It's quite easy to "orphan" a user or their data.

A few examples:
1) An app uses a users login name to associate them with records, but they get married and their login name changes. Now they can no longer see their past records
2) An app uses the SID (unique identifier in AD), but our admin routinely renames the person when people leave and a new person takes their job role - now the new person see's all the old persons records.
3) Copy the username and SID to the database, sync them on every login. This works, but again in the above two scenarios - you never know what to do.

So, how do enterprise apps, or even other programmers/apps handle it? I know some places use custom developed user-management software that goes out and updates all appliciable places when a user is change/deleted, but that doesnt really seem feasible in my case.

 

[Tarrant64]

Originally posted by: WannaFly
So, I've been developing plenty of small apps for our department, they all use .NET and LDAP authentication - it works great, but looking back the design leads to some flaws. It's quite easy to "orphan" a user or their data.

A few examples:
1) An app uses a users login name to associate them with records, but they get married and their login name changes. Now they can no longer see their past records
2) An app uses the SID (unique identifier in AD), but our admin routinely renames the person when people leave and a new person takes their job role - now the new person see's all the old persons records.3) Copy the username and SID to the database, sync them on every login. This works, but again in the above two scenarios - you never know what to do.

So, how do enterprise apps, or even other programmers/apps handle it? I know some places use custom developed user-management software that goes out and updates all appliciable places when a user is change/deleted, but that doesnt really seem feasible in my case.

So you're saying the person's name in AD gets renamed everytime? I don't understand, WHY you would do this.

Also, I thought the SID didn't actually change for the user when you make changes to the "attributes" or whatever.

Edit: Nevermind, I see. GUIDs are what doesn't change.

I tend to manage AD with groups, not users when it comes to applications, access, etc. It is easier to manage groups for say your "job roles" than it is specific users. It is 'best practice' to do it this way. If AD wasn't setup this way originally it can be troublesome later on down the road to manage. You, as the programmer, are left to deal with the issue.

Let me think on it some more, as I too use VB.NET/LDAP for creating applications and have had no problems so far. I've had to dig deeper into an understanding of AD but I've come a long way since.

 

[WannaFly]

Originally posted by: Tarrant64
So you're saying the person's name in AD gets renamed everytime? I don't understand, WHY you would do this.

Also, I thought the SID didn't actually change for the user when you make changes to the "attributes" or whatever.

Well, our sysadmin says he does this - we have some very picky applications that are trickey to install/setup - and there are specific computers that specific users use them on. If that person leaves, he renames the profile so that the user is already configured for the software, has all the documents, etc.

 

[Tarrant64]

Originally posted by: WannaFly

Originally posted by: Tarrant64
So you're saying the person's name in AD gets renamed everytime? I don't understand, WHY you would do this.

Also, I thought the SID didn't actually change for the user when you make changes to the "attributes" or whatever.

Well, our sysadmin says he does this - we have some very picky applications that are trickey to install/setup - and there are specific computers that specific users use them on. If that person leaves, he renames the profile so that the user is already configured for the software, has all the documents, etc.

Maybe I'm wrong, but to me, that's just WRONG. :shocked:

 

[Nothinman]

2) An app uses the SID (unique identifier in AD), but our admin routinely renames the person when people leave and a new person takes their job role - now the new person see's all the old persons records.

This is your best option and that behaviour would be expected if you did account mangement like that. Tell him to stop doing that, it's retarded. If he doesn't have groups and rights setup properly to make it easy to add a new user with all of the same rights as another then that's his fault.

So, how do enterprise apps, or even other programmers/apps handle it? I know some places use custom developed user-management software that goes out and updates all appliciable places when a user is change/deleted, but that doesnt really seem feasible in my case.

Just use the SID, that's what it's there for. It's supposed to be a unique number representing an account. If your admin is renaming accounts for new users instead of creating new then he's circumventing that system and that's not your problem.

 

[Tarrant64]

Originally posted by: WannaFly


A few examples:
1) An app uses a users login name to associate them with records, but they get married and their login name changes. Now they can no longer see their past records

Hmm..maybe a solution here is to create a database that associates a user with another userID? Say Billy Bob -> 2535 (ID) and Mary Miller -> 2353 (ID). When Mary Miller becomes Mary Bob, just change the ID to Mary Bob.

Does that make sense?

The applications would then reference 2353, you just have to change who the ID associates with and call it good. The reason I say go this route is because trying to keep track of SIDs for users that go through constant changes, is like trying to keep track of USNs between different domain controllers(maybe some of you get it, maybe some of you don't)

 

[Tarrant64]

Originally posted by: Nothinman

2) An app uses the SID (unique identifier in AD), but our admin routinely renames the person when people leave and a new person takes their job role - now the new person see's all the old persons records.

This is your best option and that behaviour would be expected if you did account mangement like that. Tell him to stop doing that, it's retarded. If he doesn't have groups and rights setup properly to make it easy to add a new user with all of the same rights as another then that's his fault.

So, how do enterprise apps, or even other programmers/apps handle it? I know some places use custom developed user-management software that goes out and updates all appliciable places when a user is change/deleted, but that doesnt really seem feasible in my case.

Just use the SID, that's what it's there for. It's supposed to be a unique number representing an account. If your admin is renaming accounts for new users instead of creating new then he's circumventing that system and that's not your problem.

Nothinman is right here. My comment about keeping track of SIDs for users that go through changes, is if the SysAdmin insists on going that route.

Trying to get a SysAdmin to change his ways and coming from a programmer, good luck. Some people, just don't listen to advice.

 

[KB]

Because multiple people often serve the same role or people often change roles, I do what Tarrant64 does and thats manage access with AD groups. People then view the records their group created, not the ones they created themselves. In some situations I have stored the database ID of the group in the INFO/NOTES field of the AD group to link the database row with the AD group.

Doing this solution
Hmm..maybe a solution here is to create a database that associates a user with another userID? Say Billy Bob -> 2535 (ID) and Mary Miller -> 2353 (ID). When Mary Miller becomes Mary Bob, just change the ID to Mary Bob. "

is a good idea but often I am not the one renaming people in AD and I don't want to get involved in changing things everytime someone changes a name.

 

[Tarrant64]

Originally posted by: KB
Because multiple people often serve the same role or people often change roles, I do what Tarrant64 does and thats manage access with AD groups. People then view the records their group created, not the ones they created themselves. In some situations I have stored the database ID of the group in the INFO/NOTES field of the AD group to link the database row with the AD group.

Doing this solution
Hmm..maybe a solution here is to create a database that associates a user with another userID? Say Billy Bob -> 2535 (ID) and Mary Miller -> 2353 (ID). When Mary Miller becomes Mary Bob, just change the ID to Mary Bob. "

is a good idea but often I am not the one renaming people in AD and I don't want to get involved in changing things everytime someone changes a name.

Yeah, unfortunately somebody's gotta change it.

 

[WannaFly]

Originally posted by: KB
Because multiple people often serve the same role or people often change roles, I do what Tarrant64 does and thats manage access with AD groups. People then view the records their group created, not the ones they created themselves. In some situations I have stored the database ID of the group in the INFO/NOTES field of the AD group to link the database row with the AD group.

Yes- we use groups nad have plenty of them, but he described it as some (legacy) apps that store information in th users profile and are a PITA to setup/install - so he just renames the user so there is no need to reconfigure the software when the person leaves.

Doing this solution
Hmm..maybe a solution here is to create a database that associates a user with another userID? Say Billy Bob -> 2535 (ID) and Mary Miller -> 2353 (ID). When Mary Miller becomes Mary Bob, just change the ID to Mary Bob. "

is a good idea but often I am not the one renaming people in AD and I don't want to get involved in changing things everytime someone changes a name.

Yes - thats exactly it, I'm not involved in that process and don't want to be. Really, it sounds like there is no way to avoid orphaned users.

 

[kyzen]

Check out Microsoft Intentity Integration Services

 

[Tarrant64]

Originally posted by: kyzen
Check out Microsoft Identity Integration Services

That looks like it will take quite a bit of reading to understand how it works, and how it's going to help him.

Plus, this is probably out of his hands when it comes to implementing this.