| Author | Messages | |
kurtbuff
Posts:200
 | | 06/23/2010 12:46 AM |
| ll,
Asked on another list, but I thought it perhaps appropriate here:
I have a developer who's designing an app with a web front end running
against a SQL database. This is in a Win2k3 AD forest, single domain.
For auth and auditing he's wanting to use the account GUID. I
suggested the AD SID, though I'm not married to it.
Any reason to prefer the SID to the GUID, or vice versa?
I would think that as long as he can derive the GUID or SID from the
account ID, and then determine the reverse as necessary, it shouldn't
matter too much.
Kurt
| | | |
| kurtbuff
Posts:200
| | 06/23/2010 1:10 AM |
| Works for me.
Thanks.
On Tue, Jun 22, 2010 at 16:57, Brian Desmond <brian@briandesmond.com> wrote:
> GUID will never change, SID can change e.g. if you do a cross domain move. Use the GUID.
>
> Thanks,
> Brian Desmond
> brian@briandesmond.com
>
> c - 312.731.3132
>
>
>
> -----Original Message-----
> From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Kurt Buff
> Sent: Tuesday, June 22, 2010 4:46 PM
> To: ActiveDir@mail.activedir.org
> Subject: [ActiveDir] OTish question: Designing a SQL App
>
> ll,
>
>
> Asked on another list, but I thought it perhaps appropriate here:
>
> I have a developer who's designing an app with a web front end running against a SQL database. This is in a Win2k3 AD forest, single domain.
>
> For auth and auditing he's wanting to use the account GUID. I suggested the AD SID, though I'm not married to it.
>
> Any reason to prefer the SID to the GUID, or vice versa?
>
> I would think that as long as he can derive the GUID or SID from the account ID, and then determine the reverse as necessary, it shouldn't matter too much.
>
> Kurt
>
>
>
| | | |
| skradel
Posts:177
| | 06/23/2010 1:10 AM |
| For the same reasons of mutability, I would prefer SID (searching on
objectSid + sIDHistory), because your application would then support a
domain migration. GUID is un-settable and more applicable to
replication.
--Steve
On Tue, Jun 22, 2010 at 7:57 PM, Brian Desmond <brian@briandesmond.com> wrote:
> GUID will never change, SID can change e.g. if you do a cross domain move. Use the GUID.
>
> Thanks,
> Brian Desmond
> brian@briandesmond.com
>
> c - 312.731.3132
>
>
>
> -----Original Message-----
> From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Kurt Buff
> Sent: Tuesday, June 22, 2010 4:46 PM
> To: ActiveDir@mail.activedir.org
> Subject: [ActiveDir] OTish question: Designing a SQL App
>
> ll,
>
>
> Asked on another list, but I thought it perhaps appropriate here:
>
> I have a developer who's designing an app with a web front end running against a SQL database. This is in a Win2k3 AD forest, single domain.
>
> For auth and auditing he's wanting to use the account GUID. I suggested the AD SID, though I'm not married to it.
>
> Any reason to prefer the SID to the GUID, or vice versa?
>
> I would think that as long as he can derive the GUID or SID from the account ID, and then determine the reverse as necessary, it shouldn't matter too much.
>
> Kurt
>
>
>
| | | |
| kurtbuff
Posts:200
| | 06/23/2010 1:18 AM |
| Uh, can you explain that a bit? I'm not sure I understanding what
you're getting at.
At least, my untutored train of thought is that if you've done a
domain migration, we can assume one of two things:
1) The app (and SQL server) have moved to the new domain
or
2) There's a trust between the existing domains that allows a query to
resolve the GUID to an ID and do the auth.
and that in either case the auth should be relatively transparent, not
that I see a domain migration as likely in this environment.
Or am I missing something?
Kurt
On Tue, Jun 22, 2010 at 17:10, Steve Kradel <skradel@zetetic.net> wrote:
> For the same reasons of mutability, I would prefer SID (searching on
> objectSid + sIDHistory), because your application would then support a
> domain migration. GUID is un-settable and more applicable to
> replication.
>
> --Steve
>
> On Tue, Jun 22, 2010 at 7:57 PM, Brian Desmond <brian@briandesmond.com> wrote:
>> GUID will never change, SID can change e.g. if you do a cross domain move. Use the GUID.
>>
>> Thanks,
>> Brian Desmond
>> brian@briandesmond.com
>>
>> c - 312.731.3132
>>
>>
>>
>> -----Original Message-----
>> From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Kurt Buff
>> Sent: Tuesday, June 22, 2010 4:46 PM
>> To: ActiveDir@mail.activedir.org
>> Subject: [ActiveDir] OTish question: Designing a SQL App
>>
>> ll,
>>
>>
>> Asked on another list, but I thought it perhaps appropriate here:
>>
>> I have a developer who's designing an app with a web front end running against a SQL database. This is in a Win2k3 AD forest, single domain.
>>
>> For auth and auditing he's wanting to use the account GUID. I suggested the AD SID, though I'm not married to it.
>>
>> Any reason to prefer the SID to the GUID, or vice versa?
>>
>> I would think that as long as he can derive the GUID or SID from the account ID, and then determine the reverse as necessary, it shouldn't matter too much.
>>
>> Kurt
>>
>>
>>
>
>
| | | |
| skradel
Posts:177
| | 06/23/2010 1:32 AM |
| Suppose the app stores that "S-1-5-12345-1" is the author of some
document. Using SID, an application can always search its configured
domains for "(|(objectsid=S-1-5-12345-1)(sidhistory=S-1-5-12345-1))"
or check the contents of the user's security token, if it's that kind
of app, and get a reasonable answer and proper security decision, even
if the original domain / forest is retired & replaced.
If you store GUID, then you will have to convert the data as part of a
domain collapse. If the intent is to keep a near-copy of AD in SQL,
then objectGuid is fine as a join key. As an indicator of identity or
security, however, I'd rather follow MSFT's lead where all ACL / ACE
trustees are SID based.
--Steve
On Tue, Jun 22, 2010 at 8:17 PM, Kurt Buff <kurt.buff@gmail.com> wrote:
> Uh, can you explain that a bit? I'm not sure I understanding what
> you're getting at.
>
> At least, my untutored train of thought is that if you've done a
> domain migration, we can assume one of two things:
>
> 1) The app (and SQL server) have moved to the new domain
>
> or
>
> 2) There's a trust between the existing domains that allows a query to
> resolve the GUID to an ID and do the auth.
>
> and that in either case the auth should be relatively transparent, not
> that I see a domain migration as likely in this environment.
>
> Or am I missing something?
>
> Kurt
>
> On Tue, Jun 22, 2010 at 17:10, Steve Kradel <skradel@zetetic.net> wrote:
>> For the same reasons of mutability, I would prefer SID (searching on
>> objectSid + sIDHistory), because your application would then support a
>> domain migration. GUID is un-settable and more applicable to
>> replication.
>>
>> --Steve
>>
>> On Tue, Jun 22, 2010 at 7:57 PM, Brian Desmond <brian@briandesmond.com> wrote:
>>> GUID will never change, SID can change e.g. if you do a cross domain move. Use the GUID.
>>>
>>> Thanks,
>>> Brian Desmond
>>> brian@briandesmond.com
>>>
>>> c - 312.731.3132
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Kurt Buff
>>> Sent: Tuesday, June 22, 2010 4:46 PM
>>> To: ActiveDir@mail.activedir.org
>>> Subject: [ActiveDir] OTish question: Designing a SQL App
>>>
>>> ll,
>>>
>>>
>>> Asked on another list, but I thought it perhaps appropriate here:
>>>
>>> I have a developer who's designing an app with a web front end running against a SQL database. This is in a Win2k3 AD forest, single domain.
>>>
>>> For auth and auditing he's wanting to use the account GUID. I suggested the AD SID, though I'm not married to it.
>>>
>>> Any reason to prefer the SID to the GUID, or vice versa?
>>>
>>> I would think that as long as he can derive the GUID or SID from the account ID, and then determine the reverse as necessary, it shouldn't matter too much.
>>>
>>> Kurt
>>>
>>>
>>>
>>
>>
>
| | | |
| kurtbuff
Posts:200
| | 06/23/2010 1:53 AM |
| Interesting. This is beyond my level of experience/knowledge. I'll
have to wait to hear what others say.
Just for background - the app (IIRC - he's working a couple of
different projects) is a manufacturing ticketing system, and history
needs to be kept for several years, when, for instance, users on the
floor will have a relatively high rate of turnover, and name
collisions will be somewhat likely if we start to delete/retire AD
accounts. It won't do for a 'bsmith' to be hired, do a bunch of
tickets, leave, and a new 'bsmith' to be hired, and then have folks
get confused about differentiating between the old and new 'bsmiths'.
Currently I only disable accounts, never delete them, and put the
disabled accounts in their own OU, just because of this reason, but at
some point we'll probably want to think about deleting old accounts.
Kurt
On Tue, Jun 22, 2010 at 17:31, Steve Kradel <skradel@zetetic.net> wrote:
> Suppose the app stores that "S-1-5-12345-1" is the author of some
> document. Using SID, an application can always search its configured
> domains for "(|(objectsid=S-1-5-12345-1)(sidhistory=S-1-5-12345-1))"
> or check the contents of the user's security token, if it's that kind
> of app, and get a reasonable answer and proper security decision, even
> if the original domain / forest is retired & replaced.
>
> If you store GUID, then you will have to convert the data as part of a
> domain collapse. If the intent is to keep a near-copy of AD in SQL,
> then objectGuid is fine as a join key. As an indicator of identity or
> security, however, I'd rather follow MSFT's lead where all ACL / ACE
> trustees are SID based.
>
> --Steve
>
> On Tue, Jun 22, 2010 at 8:17 PM, Kurt Buff <kurt.buff@gmail.com> wrote:
>> Uh, can you explain that a bit? I'm not sure I understanding what
>> you're getting at.
>>
>> At least, my untutored train of thought is that if you've done a
>> domain migration, we can assume one of two things:
>>
>> 1) The app (and SQL server) have moved to the new domain
>>
>> or
>>
>> 2) There's a trust between the existing domains that allows a query to
>> resolve the GUID to an ID and do the auth.
>>
>> and that in either case the auth should be relatively transparent, not
>> that I see a domain migration as likely in this environment.
>>
>> Or am I missing something?
>>
>> Kurt
>>
>> On Tue, Jun 22, 2010 at 17:10, Steve Kradel <skradel@zetetic.net> wrote:
>>> For the same reasons of mutability, I would prefer SID (searching on
>>> objectSid + sIDHistory), because your application would then support a
>>> domain migration. GUID is un-settable and more applicable to
>>> replication.
>>>
>>> --Steve
>>>
>>> On Tue, Jun 22, 2010 at 7:57 PM, Brian Desmond <brian@briandesmond.com> wrote:
>>>> GUID will never change, SID can change e.g. if you do a cross domain move. Use the GUID.
>>>>
>>>> Thanks,
>>>> Brian Desmond
>>>> brian@briandesmond.com
>>>>
>>>> c - 312.731.3132
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Kurt Buff
>>>> Sent: Tuesday, June 22, 2010 4:46 PM
>>>> To: ActiveDir@mail.activedir.org
>>>> Subject: [ActiveDir] OTish question: Designing a SQL App
>>>>
>>>> ll,
>>>>
>>>>
>>>> Asked on another list, but I thought it perhaps appropriate here:
>>>>
>>>> I have a developer who's designing an app with a web front end running against a SQL database. This is in a Win2k3 AD forest, single domain.
>>>>
>>>> For auth and auditing he's wanting to use the account GUID. I suggested the AD SID, though I'm not married to it.
>>>>
>>>> Any reason to prefer the SID to the GUID, or vice versa?
>>>>
>>>> I would think that as long as he can derive the GUID or SID from the account ID, and then determine the reverse as necessary, it shouldn't matter too much.
>>>>
>>>> Kurt
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
| | | |
| bdesmond
Posts:977
| | 06/23/2010 2:44 AM |
| Can you do a bind by a SID History SID (e.g. LDAP://<SID=foo> ? I generally agree with the recommendation here but I might actually cache both if you can't bind this way or something.
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
-----Original Message-----
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Steve Kradel
Sent: Tuesday, June 22, 2010 5:31 PM
To: activedir@mail.activedir.org
Subject: Re: [ActiveDir] OTish question: Designing a SQL App
Suppose the app stores that "S-1-5-12345-1" is the author of some document. Using SID, an application can always search its configured domains for "(|(objectsid=S-1-5-12345-1)(sidhistory=S-1-5-12345-1))"
or check the contents of the user's security token, if it's that kind of app, and get a reasonable answer and proper security decision, even if the original domain / forest is retired & replaced.
If you store GUID, then you will have to convert the data as part of a domain collapse. If the intent is to keep a near-copy of AD in SQL, then objectGuid is fine as a join key. As an indicator of identity or security, however, I'd rather follow MSFT's lead where all ACL / ACE trustees are SID based.
--Steve
On Tue, Jun 22, 2010 at 8:17 PM, Kurt Buff <kurt.buff@gmail.com> wrote:
> Uh, can you explain that a bit? I'm not sure I understanding what
> you're getting at.
>
> At least, my untutored train of thought is that if you've done a
> domain migration, we can assume one of two things:
>
> 1) The app (and SQL server) have moved to the new domain
>
> or
>
> 2) There's a trust between the existing domains that allows a query to
> resolve the GUID to an ID and do the auth.
>
> and that in either case the auth should be relatively transparent, not
> that I see a domain migration as likely in this environment.
>
> Or am I missing something?
>
> Kurt
>
> On Tue, Jun 22, 2010 at 17:10, Steve Kradel <skradel@zetetic.net> wrote:
>> For the same reasons of mutability, I would prefer SID (searching on
>> objectSid + sIDHistory), because your application would then support
>> a domain migration. GUID is un-settable and more applicable to
>> replication.
>>
>> --Steve
>>
>> On Tue, Jun 22, 2010 at 7:57 PM, Brian Desmond <brian@briandesmond.com> wrote:
>>> GUID will never change, SID can change e.g. if you do a cross domain move. Use the GUID.
>>>
>>> Thanks,
>>> Brian Desmond
>>> brian@briandesmond.com
>>>
>>> c - 312.731.3132
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: activedir-owner@mail.activedir.org
>>> [mailto:activedir-owner@mail.activedir.org] On Behalf Of Kurt Buff
>>> Sent: Tuesday, June 22, 2010 4:46 PM
>>> To: ActiveDir@mail.activedir.org
>>> Subject: [ActiveDir] OTish question: Designing a SQL App
>>>
>>> ll,
>>>
>>>
>>> Asked on another list, but I thought it perhaps appropriate here:
>>>
>>> I have a developer who's designing an app with a web front end running against a SQL database. This is in a Win2k3 AD forest, single domain.
>>>
>>> For auth and auditing he's wanting to use the account GUID. I suggested the AD SID, though I'm not married to it.
>>>
>>> Any reason to prefer the SID to the GUID, or vice versa?
>>>
>>> I would think that as long as he can derive the GUID or SID from the account ID, and then determine the reverse as necessary, it shouldn't matter too much.
>>>
>>> Kurt
>>>
>>>
>>>
>>
>>
>
| | | |
| Gil
Posts:311
| | 06/23/2010 11:25 AM |
| Most of the apps of this ilk that I've built store the GUID, the SID, and some displayable representation of the name, ala the extended DN LDAP control (LDAP_SERVER_EXTENDED_DN_OID). It's a useful denormalization.
-gil
-----Original Message-----
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Brian Desmond
Sent: Wednesday, 23 June 2010 11:44 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] OTish question: Designing a SQL App
Can you do a bind by a SID History SID (e.g. LDAP://<SID=foo>? I generally agree with the recommendation here but I might actually cache both if you can't bind this way or something.
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
-----Original Message-----
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Steve Kradel
Sent: Tuesday, June 22, 2010 5:31 PM
To: activedir@mail.activedir.org
Subject: Re: [ActiveDir] OTish question: Designing a SQL App
Suppose the app stores that "S-1-5-12345-1" is the author of some document. Using SID, an application can always search its configured domains for "(|(objectsid=S-1-5-12345-1)(sidhistory=S-1-5-12345-1))"
or check the contents of the user's security token, if it's that kind of app, and get a reasonable answer and proper security decision, even if the original domain / forest is retired & replaced.
If you store GUID, then you will have to convert the data as part of a domain collapse. If the intent is to keep a near-copy of AD in SQL, then objectGuid is fine as a join key. As an indicator of identity or security, however, I'd rather follow MSFT's lead where all ACL / ACE trustees are SID based.
--Steve
On Tue, Jun 22, 2010 at 8:17 PM, Kurt Buff <kurt.buff@gmail.com> wrote:
> Uh, can you explain that a bit? I'm not sure I understanding what
> you're getting at.
>
> At least, my untutored train of thought is that if you've done a
> domain migration, we can assume one of two things:
>
> 1) The app (and SQL server) have moved to the new domain
>
> or
>
> 2) There's a trust between the existing domains that allows a query to
> resolve the GUID to an ID and do the auth.
>
> and that in either case the auth should be relatively transparent, not
> that I see a domain migration as likely in this environment.
>
> Or am I missing something?
>
> Kurt
>
> On Tue, Jun 22, 2010 at 17:10, Steve Kradel <skradel@zetetic.net> wrote:
>> For the same reasons of mutability, I would prefer SID (searching on
>> objectSid + sIDHistory), because your application would then support
>> a domain migration. GUID is un-settable and more applicable to
>> replication.
>>
>> --Steve
>>
>> On Tue, Jun 22, 2010 at 7:57 PM, Brian Desmond <brian@briandesmond.com> wrote:
>>> GUID will never change, SID can change e.g. if you do a cross domain move. Use the GUID.
>>>
>>> Thanks,
>>> Brian Desmond
>>> brian@briandesmond.com
>>>
>>> c - 312.731.3132
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: activedir-owner@mail.activedir.org
>>> [mailto:activedir-owner@mail.activedir.org] On Behalf Of Kurt Buff
>>> Sent: Tuesday, June 22, 2010 4:46 PM
>>> To: ActiveDir@mail.activedir.org
>>> Subject: [ActiveDir] OTish question: Designing a SQL App
>>>
>>> ll,
>>>
>>>
>>> Asked on another list, but I thought it perhaps appropriate here:
>>>
>>> I have a developer who's designing an app with a web front end running against a SQL database. This is in a Win2k3 AD forest, single domain.
>>>
>>> For auth and auditing he's wanting to use the account GUID. I suggested the AD SID, though I'm not married to it.
>>>
>>> Any reason to prefer the SID to the GUID, or vice versa?
>>>
>>> I would think that as long as he can derive the GUID or SID from the account ID, and then determine the reverse as necessary, it shouldn't matter too much.
>>>
>>> Kurt
>>>
>>>
>>>
>>
>>
>
| | | |
| listmail
Posts:821
| | 06/23/2010 8:45 PM |
| Ah that is an interesting viewpoint.
I tend to think of user moves as an intraforest cross domain move and that
is what Brian was referencing in his post as well. This is applicable to
interforest (or cross forest if you prefer) cross domain moves and you are
absolutely right, in that context, a SID would be better as you would keep
the SID in SIDHistory (assuming you enabled that functionality and you used
an official cross forest move process versus new account with same name). Of
course the SIDHistory is something that should be cleaned up at some point
as well which means I would still recommend some kind of cleanup in SQL
Server as well after any kind of migration, however it could be delayed from
the actual migration itself where using GUID would require an immediate
remapping of some sort unless you pulled GUIDs along for the ride in your
own custom attribute in an interforest move.
I think I can argue this one back and forth with just myself...
Good one Steve. This making me think a little bit.
Joe
--
O'Reilly Active Directory Fourth Edition -
http://www.joeware.net/win/ad4e.htm
Blog: http://blog.joeware.net
-----Original Message-----
From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Steve Kradel
Sent: Tuesday, June 22, 2010 8:31 PM
To: activedir@mail.activedir.org
Subject: Re: [ActiveDir] OTish question: Designing a SQL App
Suppose the app stores that "S-1-5-12345-1" is the author of some
document. Using SID, an application can always search its configured
domains for "(|(objectsid=S-1-5-12345-1)(sidhistory=S-1-5-12345-1))"
or check the contents of the user's security token, if it's that kind
of app, and get a reasonable answer and proper security decision, even
if the original domain / forest is retired & replaced.
If you store GUID, then you will have to convert the data as part of a
domain collapse. If the intent is to keep a near-copy of AD in SQL,
then objectGuid is fine as a join key. As an indicator of identity or
security, however, I'd rather follow MSFT's lead where all ACL / ACE
trustees are SID based.
--Steve
On Tue, Jun 22, 2010 at 8:17 PM, Kurt Buff <kurt.buff@gmail.com> wrote:
> Uh, can you explain that a bit? I'm not sure I understanding what
> you're getting at.
>
> At least, my untutored train of thought is that if you've done a
> domain migration, we can assume one of two things:
>
> 1) The app (and SQL server) have moved to the new domain
>
> or
>
> 2) There's a trust between the existing domains that allows a query to
> resolve the GUID to an ID and do the auth.
>
> and that in either case the auth should be relatively transparent, not
> that I see a domain migration as likely in this environment.
>
> Or am I missing something?
>
> Kurt
>
> On Tue, Jun 22, 2010 at 17:10, Steve Kradel <skradel@zetetic.net> wrote:
>> For the same reasons of mutability, I would prefer SID (searching on
>> objectSid + sIDHistory), because your application would then support a
>> domain migration. GUID is un-settable and more applicable to
>> replication.
>>
>> --Steve
>>
>> On Tue, Jun 22, 2010 at 7:57 PM, Brian Desmond <brian@briandesmond.com>
wrote:
>>> GUID will never change, SID can change e.g. if you do a cross domain
move. Use the GUID.
>>>
>>> Thanks,
>>> Brian Desmond
>>> brian@briandesmond.com
>>>
>>> c - 312.731.3132
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Kurt Buff
>>> Sent: Tuesday, June 22, 2010 4:46 PM
>>> To: ActiveDir@mail.activedir.org
>>> Subject: [ActiveDir] OTish question: Designing a SQL App
>>>
>>> ll,
>>>
>>>
>>> Asked on another list, but I thought it perhaps appropriate here:
>>>
>>> I have a developer who's designing an app with a web front end running
against a SQL database. This is in a Win2k3 AD forest, single domain.
>>>
>>> For auth and auditing he's wanting to use the account GUID. I suggested
the AD SID, though I'm not married to it.
>>>
>>> Any reason to prefer the SID to the GUID, or vice versa?
>>>
>>> I would think that as long as he can derive the GUID or SID from the
account ID, and then determine the reverse as necessary, it shouldn't matter
too much.
>>>
>>> Kurt
>>>
>>>
>>>
>>
>>
>
| | | |
| barkills
Posts:200
| | 06/23/2010 10:21 PM |
| Seems like neither is ideal to me with the added complexity that has been added to the originally posed question. You need a layer of abstraction that isn't tied to where the account lives at any given moment. I'd also note that no one has added the other obvious additional complexity of federation. Of course, the original question didn't have any of this complexity, but the OP seems to be OK with the scope creep, so ... I'll go along.
I'd strongly consider looking at the System.Identity stuff that abstracts this stuff. And/Or consider putting a virtual directory into place. Then it doesn't matter if the account/identity moves around and the SIDs and GUIDs change on you.
I've got blog posts about topics that intersect here:
NextGen AD and System.Identity
https://sharepoint.washington.edu/windows/Lists/Posts/Post.aspx?ID=124
Virtual Directory Products and Use Cases
https://sharepoint.washington.edu/windows/Lists/Posts/Post.aspx?ID=121
Additionally, there's a pretty good Burton group paper out there about IdM approaches which talks about some of these issues. See http://www.gartner.com/technology/media-products/reprints/radiantlogic/burton3376.html.
> -----Original Message-----
> From: activedir-owner@mail.activedir.org [mailto:activedir-
> owner@mail.activedir.org] On Behalf Of joe
> Sent: Wednesday, June 23, 2010 12:43 PM
> To: activedir@mail.activedir.org
> Subject: RE: [ActiveDir] OTish question: Designing a SQL App
>
> Ah that is an interesting viewpoint.
>
> I tend to think of user moves as an intraforest cross domain move and
> that
> is what Brian was referencing in his post as well. This is applicable
> to
> interforest (or cross forest if you prefer) cross domain moves and you
> are
> absolutely right, in that context, a SID would be better as you would
> keep
> the SID in SIDHistory (assuming you enabled that functionality and you
> used
> an official cross forest move process versus new account with same
> name). Of
> course the SIDHistory is something that should be cleaned up at some
> point
> as well which means I would still recommend some kind of cleanup in SQL
> Server as well after any kind of migration, however it could be delayed
> from
> the actual migration itself where using GUID would require an immediate
> remapping of some sort unless you pulled GUIDs along for the ride in
> your
> own custom attribute in an interforest move.
>
> I think I can argue this one back and forth with just myself...
>
> Good one Steve. This making me think a little bit.
>
> Joe
>
>
> --
> O'Reilly Active Directory Fourth Edition -
> http://www.joeware.net/win/ad4e.htm
> Blog: http://blog.joeware.net
>
>
>
>
> -----Original Message-----
> From: activedir-owner@mail.activedir.org
> [mailto:activedir-owner@mail.activedir.org] On Behalf Of Steve Kradel
> Sent: Tuesday, June 22, 2010 8:31 PM
> To: activedir@mail.activedir.org
> Subject: Re: [ActiveDir] OTish question: Designing a SQL App
>
> Suppose the app stores that "S-1-5-12345-1" is the author of some
> document. Using SID, an application can always search its configured
> domains for "(|(objectsid=S-1-5-12345-1)(sidhistory=S-1-5-12345-1))"
> or check the contents of the user's security token, if it's that kind
> of app, and get a reasonable answer and proper security decision, even
> if the original domain / forest is retired & replaced.
>
> If you store GUID, then you will have to convert the data as part of a
> domain collapse. If the intent is to keep a near-copy of AD in SQL,
> then objectGuid is fine as a join key. As an indicator of identity or
> security, however, I'd rather follow MSFT's lead where all ACL / ACE
> trustees are SID based.
>
> --Steve
>
> On Tue, Jun 22, 2010 at 8:17 PM, Kurt Buff <kurt.buff@gmail.com> wrote:
> > Uh, can you explain that a bit? I'm not sure I understanding what
> > you're getting at.
> >
> > At least, my untutored train of thought is that if you've done a
> > domain migration, we can assume one of two things:
> >
> > 1) The app (and SQL server) have moved to the new domain
> >
> > or
> >
> > 2) There's a trust between the existing domains that allows a query
> to
> > resolve the GUID to an ID and do the auth.
> >
> > and that in either case the auth should be relatively transparent,
> not
> > that I see a domain migration as likely in this environment.
> >
> > Or am I missing something?
> >
> > Kurt
> >
> > On Tue, Jun 22, 2010 at 17:10, Steve Kradel <skradel@zetetic.net>
> wrote:
> >> For the same reasons of mutability, I would prefer SID (searching on
> >> objectSid + sIDHistory), because your application would then support
> a
> >> domain migration. GUID is un-settable and more applicable to
> >> replication.
> >>
> >> --Steve
> >>
> >> On Tue, Jun 22, 2010 at 7:57 PM, Brian Desmond
> <brian@briandesmond.com>
> wrote:
> >>> GUID will never change, SID can change e.g. if you do a cross
> domain
> move. Use the GUID.
> >>>
> >>> Thanks,
> >>> Brian Desmond
> >>> brian@briandesmond.com
> >>>
> >>> c - 312.731.3132
> >>>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: activedir-owner@mail.activedir.org
> [mailto:activedir-owner@mail.activedir.org] On Behalf Of Kurt Buff
> >>> Sent: Tuesday, June 22, 2010 4:46 PM
> >>> To: ActiveDir@mail.activedir.org
> >>> Subject: [ActiveDir] OTish question: Designing a SQL App
> >>>
> >>> ll,
> >>>
> >>>
> >>> Asked on another list, but I thought it perhaps appropriate here:
> >>>
> >>> I have a developer who's designing an app with a web front end
> running
> against a SQL database. This is in a Win2k3 AD forest, single domain.
> >>>
> >>> For auth and auditing he's wanting to use the account GUID. I
> suggested
> the AD SID, though I'm not married to it.
> >>>
> >>> Any reason to prefer the SID to the GUID, or vice versa?
> >>>
> >>> I would think that as long as he can derive the GUID or SID from
> the
> account ID, and then determine the reverse as necessary, it shouldn't
> matter
> too much.
> >>>
> >>> Kurt
> >>>
> >>>
> >>>
> >>
> >>
> >
>
| | | |
| bdesmond
Posts:977
| | 06/24/2010 12:54 AM |
| Yeah I think there may also be a communal level of overthinking here. If the app uses the GUID and it's documented, and the relationships to user records are setup right in the database you could always just issue an update command to the GUID in the table if the user is moved cross forest...
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
-----Original Message-----
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Brian Arkills
Sent: Wednesday, June 23, 2010 2:19 PM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] OTish question: Designing a SQL App
Seems like neither is ideal to me with the added complexity that has been added to the originally posed question. You need a layer of abstraction that isn't tied to where the account lives at any given moment. I'd also note that no one has added the other obvious additional complexity of federation. Of course, the original question didn't have any of this complexity, but the OP seems to be OK with the scope creep, so ... I'll go along.
I'd strongly consider looking at the System.Identity stuff that abstracts this stuff. And/Or consider putting a virtual directory into place. Then it doesn't matter if the account/identity moves around and the SIDs and GUIDs change on you.
I've got blog posts about topics that intersect here:
NextGen AD and System.Identity
https://sharepoint.washington.edu/windows/Lists/Posts/Post.aspx?ID=124
Virtual Directory Products and Use Cases
https://sharepoint.washington.edu/windows/Lists/Posts/Post.aspx?ID=121
Additionally, there's a pretty good Burton group paper out there about IdM approaches which talks about some of these issues. See http://www.gartner.com/technology/media-products/reprints/radiantlogic/burton3376.html.
> -----Original Message-----
> From: activedir-owner@mail.activedir.org [mailto:activedir-
> owner@mail.activedir.org] On Behalf Of joe
> Sent: Wednesday, June 23, 2010 12:43 PM
> To: activedir@mail.activedir.org
> Subject: RE: [ActiveDir] OTish question: Designing a SQL App
>
> Ah that is an interesting viewpoint.
>
> I tend to think of user moves as an intraforest cross domain move and
> that is what Brian was referencing in his post as well. This is
> applicable to interforest (or cross forest if you prefer) cross domain
> moves and you are absolutely right, in that context, a SID would be
> better as you would keep the SID in SIDHistory (assuming you enabled
> that functionality and you used an official cross forest move process
> versus new account with same name). Of course the SIDHistory is
> something that should be cleaned up at some point as well which means
> I would still recommend some kind of cleanup in SQL Server as well
> after any kind of migration, however it could be delayed from the
> actual migration itself where using GUID would require an immediate
> remapping of some sort unless you pulled GUIDs along for the ride in
> your own custom attribute in an interforest move.
>
> I think I can argue this one back and forth with just myself...
>
> Good one Steve. This making me think a little bit.
>
> Joe
>
>
> --
> O'Reilly Active Directory Fourth Edition -
> http://www.joeware.net/win/ad4e.htm
> Blog: http://blog.joeware.net
>
>
>
>
> -----Original Message-----
> From: activedir-owner@mail.activedir.org
> [mailto:activedir-owner@mail.activedir.org] On Behalf Of Steve Kradel
> Sent: Tuesday, June 22, 2010 8:31 PM
> To: activedir@mail.activedir.org
> Subject: Re: [ActiveDir] OTish question: Designing a SQL App
>
> Suppose the app stores that "S-1-5-12345-1" is the author of some
> document. Using SID, an application can always search its configured
> domains for "(|(objectsid=S-1-5-12345-1)(sidhistory=S-1-5-12345-1))"
> or check the contents of the user's security token, if it's that kind
> of app, and get a reasonable answer and proper security decision, even
> if the original domain / forest is retired & replaced.
>
> If you store GUID, then you will have to convert the data as part of a
> domain collapse. If the intent is to keep a near-copy of AD in SQL,
> then objectGuid is fine as a join key. As an indicator of identity or
> security, however, I'd rather follow MSFT's lead where all ACL / ACE
> trustees are SID based.
>
> --Steve
>
> On Tue, Jun 22, 2010 at 8:17 PM, Kurt Buff <kurt.buff@gmail.com> wrote:
> > Uh, can you explain that a bit? I'm not sure I understanding what
> > you're getting at.
> >
> > At least, my untutored train of thought is that if you've done a
> > domain migration, we can assume one of two things:
> >
> > 1) The app (and SQL server) have moved to the new domain
> >
> > or
> >
> > 2) There's a trust between the existing domains that allows a query
> to
> > resolve the GUID to an ID and do the auth.
> >
> > and that in either case the auth should be relatively transparent,
> not
> > that I see a domain migration as likely in this environment.
> >
> > Or am I missing something?
> >
> > Kurt
> >
> > On Tue, Jun 22, 2010 at 17:10, Steve Kradel <skradel@zetetic.net>
> wrote:
> >> For the same reasons of mutability, I would prefer SID (searching
> >> on objectSid + sIDHistory), because your application would then
> >> support
> a
> >> domain migration. GUID is un-settable and more applicable to
> >> replication.
> >>
> >> --Steve
> >>
> >> On Tue, Jun 22, 2010 at 7:57 PM, Brian Desmond
> <brian@briandesmond.com>
> wrote:
> >>> GUID will never change, SID can change e.g. if you do a cross
> domain
> move. Use the GUID.
> >>>
> >>> Thanks,
> >>> Brian Desmond
> >>> brian@briandesmond.com
> >>>
> >>> c - 312.731.3132
> >>>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: activedir-owner@mail.activedir.org
> [mailto:activedir-owner@mail.activedir.org] On Behalf Of Kurt Buff
> >>> Sent: Tuesday, June 22, 2010 4:46 PM
> >>> To: ActiveDir@mail.activedir.org
> >>> Subject: [ActiveDir] OTish question: Designing a SQL App
> >>>
> >>> ll,
> >>>
> >>>
> >>> Asked on another list, but I thought it perhaps appropriate here:
> >>>
> >>> I have a developer who's designing an app with a web front end
> running
> against a SQL database. This is in a Win2k3 AD forest, single domain.
> >>>
> >>> For auth and auditing he's wanting to use the account GUID. I
> suggested
> the AD SID, though I'm not married to it.
> >>>
> >>> Any reason to prefer the SID to the GUID, or vice versa?
> >>>
> >>> I would think that as long as he can derive the GUID or SID from
> the
> account ID, and then determine the reverse as necessary, it shouldn't
> matter too much.
> >>>
> >>> Kurt
> >>>
> >>>
> >>>
> >>
> >>
> >
>
| | | |
| kurtbuff
Posts:200
| | 06/24/2010 1:08 AM |
| Well, as OP, I actually stopped (seriously) considering after
considering Mr. Kradel's explanation, and taking discussion with the
dev we decided that the GUID was the right spot for us to be at this
point. We're a small company, wholly owned by a larger company who
seemed to have decided we can be left alone for now.
If, in something more than 5 years, we have to revisit this issue,
I'll bet there are some things we can do to remedy the situation.
However, I really appreciate the further discussion, as, while I got a
bit lost at a couple of points, I did see some of the further issues
in a larger and/or more dynamic environment than we have.
Many thanks to all!
Kurt
On Wed, Jun 23, 2010 at 14:19, Brian Arkills <barkills@washington.edu> wrote:
> Seems like neither is ideal to me with the added complexity that has been added to the originally posed question. You need a layer of abstraction that isn't tied to where the account lives at any given moment. I'd also note that no one has added the other obvious additional complexity of federation. Of course, the original question didn't have any of this complexity, but the OP seems to be OK with the scope creep, so ... I'll go along.
>
> I'd strongly consider looking at the System.Identity stuff that abstracts this stuff. And/Or consider putting a virtual directory into place. Then it doesn't matter if the account/identity moves around and the SIDs and GUIDs change on you.
>
> I've got blog posts about topics that intersect here:
> NextGen AD and System.Identity
> https://sharepoint.washington.edu/windows/Lists/Posts/Post.aspx?ID=124
> Virtual Directory Products and Use Cases
> https://sharepoint.washington.edu/windows/Lists/Posts/Post.aspx?ID=121
>
> Additionally, there's a pretty good Burton group paper out there about IdM approaches which talks about some of these issues. See http://www.gartner.com/technology/media-products/reprints/radiantlogic/burton3376.html.
>
>> -----Original Message-----
>> From: activedir-owner@mail.activedir.org [mailto:activedir-
>> owner@mail.activedir.org] On Behalf Of joe
>> Sent: Wednesday, June 23, 2010 12:43 PM
>> To: activedir@mail.activedir.org
>> Subject: RE: [ActiveDir] OTish question: Designing a SQL App
>>
>> Ah that is an interesting viewpoint.
>>
>> I tend to think of user moves as an intraforest cross domain move and
>> that
>> is what Brian was referencing in his post as well. This is applicable
>> to
>> interforest (or cross forest if you prefer) cross domain moves and you
>> are
>> absolutely right, in that context, a SID would be better as you would
>> keep
>> the SID in SIDHistory (assuming you enabled that functionality and you
>> used
>> an official cross forest move process versus new account with same
>> name). Of
>> course the SIDHistory is something that should be cleaned up at some
>> point
>> as well which means I would still recommend some kind of cleanup in SQL
>> Server as well after any kind of migration, however it could be delayed
>> from
>> the actual migration itself where using GUID would require an immediate
>> remapping of some sort unless you pulled GUIDs along for the ride in
>> your
>> own custom attribute in an interforest move.
>>
>> I think I can argue this one back and forth with just myself...
>>
>> Good one Steve. This making me think a little bit.
>>
>> Joe
>>
>>
>> --
>> O'Reilly Active Directory Fourth Edition -
>> http://www.joeware.net/win/ad4e.htm
>> Blog: http://blog.joeware.net
>>
>>
>>
>>
>> -----Original Message-----
>> From: activedir-owner@mail.activedir.org
>> [mailto:activedir-owner@mail.activedir.org] On Behalf Of Steve Kradel
>> Sent: Tuesday, June 22, 2010 8:31 PM
>> To: activedir@mail.activedir.org
>> Subject: Re: [ActiveDir] OTish question: Designing a SQL App
>>
>> Suppose the app stores that "S-1-5-12345-1" is the author of some
>> document. Using SID, an application can always search its configured
>> domains for "(|(objectsid=S-1-5-12345-1)(sidhistory=S-1-5-12345-1))"
>> or check the contents of the user's security token, if it's that kind
>> of app, and get a reasonable answer and proper security decision, even
>> if the original domain / forest is retired & replaced.
>>
>> If you store GUID, then you will have to convert the data as part of a
>> domain collapse. If the intent is to keep a near-copy of AD in SQL,
>> then objectGuid is fine as a join key. As an indicator of identity or
>> security, however, I'd rather follow MSFT's lead where all ACL / ACE
>> trustees are SID based.
>>
>> --Steve
>>
>> On Tue, Jun 22, 2010 at 8:17 PM, Kurt Buff <kurt.buff@gmail.com> wrote:
>> > Uh, can you explain that a bit? I'm not sure I understanding what
>> > you're getting at.
>> >
>> > At least, my untutored train of thought is that if you've done a
>> > domain migration, we can assume one of two things:
>> >
>> > 1) The app (and SQL server) have moved to the new domain
>> >
>> > or
>> >
>> > 2) There's a trust between the existing domains that allows a query
>> to
>> > resolve the GUID to an ID and do the auth.
>> >
>> > and that in either case the auth should be relatively transparent,
>> not
>> > that I see a domain migration as likely in this environment.
>> >
>> > Or am I missing something?
>> >
>> > Kurt
>> >
>> > On Tue, Jun 22, 2010 at 17:10, Steve Kradel <skradel@zetetic.net>
>> wrote:
>> >> For the same reasons of mutability, I would prefer SID (searching on
>> >> objectSid + sIDHistory), because your application would then support
>> a
>> >> domain migration. GUID is un-settable and more applicable to
>> >> replication.
>> >>
>> >> --Steve
>> >>
>> >> On Tue, Jun 22, 2010 at 7:57 PM, Brian Desmond
>> <brian@briandesmond.com>
>> wrote:
>> >>> GUID will never change, SID can change e.g. if you do a cross
>> domain
>> move. Use the GUID.
>> >>>
>> >>> Thanks,
>> >>> Brian Desmond
>> >>> brian@briandesmond.com
>> >>>
>> >>> c - 312.731.3132
>> >>>
>> >>>
>> >>>
>> >>> -----Original Message-----
>> >>> From: activedir-owner@mail.activedir.org
>> [mailto:activedir-owner@mail.activedir.org] On Behalf Of Kurt Buff
>> >>> Sent: Tuesday, June 22, 2010 4:46 PM
>> >>> To: ActiveDir@mail.activedir.org
>> >>> Subject: [ActiveDir] OTish question: Designing a SQL App
>> >>>
>> >>> ll,
>> >>>
>> >>>
>> >>> Asked on another list, but I thought it perhaps appropriate here:
>> >>>
>> >>> I have a developer who's designing an app with a web front end
>> running
>> against a SQL database. This is in a Win2k3 AD forest, single domain.
>> >>>
>> >>> For auth and auditing he's wanting to use the account GUID. I
>> suggested
>> the AD SID, though I'm not married to it.
>> >>>
>> >>> Any reason to prefer the SID to the GUID, or vice versa?
>> >>>
>> >>> I would think that as long as he can derive the GUID or SID from
>> the
>> account ID, and then determine the reverse as necessary, it shouldn't
>> matter
>> too much.
>> >>>
>> >>> Kurt
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>>
>
>
>
| | | |
|
|