I am getting SID right from the AD. I learned how to do it. All I need is the domain name and username. Then I connect and find the user from the AD. Then I can get the SID (which a property of the AD object) and many other values.
As far as what to store in the table, to uniquely identify a user. I prefer SID because if the username changes, I don't want to create another record in my app user table.
Does it make sense?

UPDATE: After thinking about this a bit more, I may decide to store both the user ID (username) and the SID in my user table. Since the table is not very large. Most organizations I deal with have no more than a couple of thousand employees; say 10,000. For a SQL Server table, this is a fairly small table. Then, I can use the SID to validate the user and, if necessary, use the username (ID) as a value that a human can understand.

>>I am pretty sure that the SID value I get - because I get it from actual ACD with the actual username - is a valid unique identifier of a user.
>
>Where are you running the code that gives you the SID? If it's on IIS you can only get a valid one by using valid information passed into your ASP.NET app as a result of a successful Windows Auth. If Windows Auth is working you can get a valid AD logon name "SomeADDomain\SomeUser". That's guaranteed to be unique at any given point in time, and I can't ever recall an instance managing various clients' AD where an AD logon name was eventually recycled to another account with a different SID.
>
>If you actually do get valid SIDs it's up to you if you store them or not. If it were me I'd definitely store AD logon names as they're easy to interpret and are more meaningful in case of staff turnover and account reassignment.
>
>>Here is what I am trying to do:
>>First, a user - say John Smith - loads the app, the app gets his username automatically or prompts his to enter it. Then the code - my C# code - get the SID of the user, email address and the name (e.g. John Smith).
>>The code checks - using the SID - if this user already entered the app before and there is an entry of this user in my app user table.
>>If yes, then nothing needs to be done. The user is allowed to submit a work order. And the work order is "tagged" with this user name.
>>If there is no record of this user in the user table (in my app), a record is entered. And still the user can submit a work order.
>>So, the SID is simply a way to check if the user already in the user table or not.
>>
>>>A couple of comments:
>>>
>>>- Are you certain the SID values you're getting are correct? They may have the same context issues we discussed earlier, and it would be very hard to tell that you're getting the wrong ones
>>>
>>>- I don't see why you're going down this rabbit hole. If you get Windows Auth working that will give you a valid AD user name. If you store SIDs (assuming the ones you're getting are valid) you would still have to dereference them against AD to get human-meaningful values. And doing that would always return Jane, even if was previously John who accessed your app
>>>
>>>>Yes, just ran a test and the SID is a very long string. I need to create a field corresponding to this entry in my SQL DB. But I don't know how long is the max length of the string. At least, I know not to rely on the username but instead use the SID.
>>>>
>>>>>Things like AD user names and display names are fluid and can be changed. One example is staff turnover - John Smith leaves and Jane Doe replaces him. Jane assumes John's account so she has all his access privileges, see all Exchange mail, calendars etc. This provides continuity. Some attributes such as logon name (and password), email address(es) and display name will be updated to reflect Jane. Yes, during changes some things are required to be unique org-wide such as AD logon names, SMTP email addresses etc.
>>>>>
>>>>>There must be some sort of unique identifier for every AD account (probably a GUID or similar) but I've never needed to access or use them. For logging or forensic purposes my guess is one would typically want to know if it was actually John or Jane who accessed the web app; for both of them the underlying account ID would be the same.
>>>>>
>>>>>>I understand (correct me if I am wrong) that the username with which someone logs into the PC (and when the organization uses AD) is unique. So, for example, when someone logs with username 'smithben12' and then enters his/her password, the username ('smithben12') is unique. But usually the username is entered in the Windows without masking the entry.
>>>>>>
>>>>>>My question is, do organization often or sometimes change the usernames of the staff (in AD)? If so, that is, if username is changed sometimes, what would be the unique ID in the AD that is not changed?
>>>>>>
>>>>>>TIA