Distinguish local versus domain user account?
in [Visual Basic]
|
Prev: I need to convert hex colors from Photoshop to something usable in GDI
Next: Determing the public IP address of an RDP client
From: Paul Clement on 17 Jun 2010 15:00 On Thu, 17 Jun 2010 10:38:52 -0700, Karl E. Peterson <karl(a)exmvps.org> wrote: � > � Is there a definitive test for whether the current user on a machine is � > � operating under a local account or a domain account? I can see � > � numerous ways to infer such a distinction, but nothing (in the API � > � realm) that directly tells you this unambiguously. � > � � > � I suppose the LOGONSERVER environment variable is a pretty good � > � indication? But I tend not to trust e-vars, in particular with console � > � utilities. And if I call NetUserGetInfo, the logon server always comes � > � back "\\*" as opposed to the DC that I actually validated against. � > � � > � For a number of other reasons, I really don't want to rely on e-vars at � > � all. Someone suggested if I compared LOGONSERVER with COMPUTERNAME, � > � that'd be "good enough." But imagine this scenario, and the results if � > � a console utility found itself there: � > � � > � C:\>set log � > � LOGONSERVER=\\NT12 � > � � > � C:\>set logonserver=\\BiteMe � > � � > � C:\>set log � > � LOGONSERVER=\\BiteMe � > � � > � C:\> � > � � > � I also see that if I call NetUserGetGroups on a local account, it � > � returns exactly 1 group, and it's name is "None" -- can that be � > � considered a *definitive* test for a local account? � > � � > � There's gotta be something very straight-forward here, that I'm simply � > � not seeing. Right? � > � � > � Thanks... Karl � > � > You can use ADSI to fetch the domain name the user has authenticated with: � > � > Set objRootDSE = GetObject("LDAP://RootDSE") � > Set objDomainObject = GetObject("LDAP://" & � > objRootDSE.Get("defaultNamingContext")) Debug.Print objDomainObject.Name � � That's an interesting one. It's not the flat name, and it's not the � dns name, either. Pretty much not usable in most contexts that I'm � aware of, but still interesting. IT'd be like... � � Left$(DnsName, Instr(DnsName, ".") - 1) � � Is that object documented somewhere? (I really hate those things, � because it seems so damned hard to find out wth they really offer.) � � Thanks... The domain name returned is actually part of the LDAP distinguished name path (e.g. . It will be returned as: DC=<domain name>. In any event, it will be different than the computer name. The other stuff (API, WScript) uses the older WinNT protocol. Remember this conversation? http://www.codenewsgroups.net/vb/t1620-querying-userdomain-currently-logged-user.aspx Paul ~~~~ Microsoft MVP (Visual Basic)
From: Karl E. Peterson on 17 Jun 2010 15:29 Paul Clement expressed precisely : > On Thu, 17 Jun 2010 10:38:52 -0700, Karl E. Peterson <karl(a)exmvps.org> wrote: > > � > � Is there a definitive test for whether the current user on a machine is > � > � operating under a local account or a domain account? I can see > � > � numerous ways to infer such a distinction, but nothing (in the API > � > � realm) that directly tells you this unambiguously. > � > � > � > � I suppose the LOGONSERVER environment variable is a pretty good > � > � indication? But I tend not to trust e-vars, in particular with console > � > � utilities. And if I call NetUserGetInfo, the logon server always comes > � > � back "\\*" as opposed to the DC that I actually validated against. > � > � > � > � For a number of other reasons, I really don't want to rely on e-vars at > � > � all. Someone suggested if I compared LOGONSERVER with COMPUTERNAME, > � > � that'd be "good enough." But imagine this scenario, and the results if > � > � a console utility found itself there: > � > � > � > � C:\>set log > � > � LOGONSERVER=\\NT12 > � > � > � > � C:\>set logonserver=\\BiteMe > � > � > � > � C:\>set log > � > � LOGONSERVER=\\BiteMe > � > � > � > � C:\> > � > � > � > � I also see that if I call NetUserGetGroups on a local account, it > � > � returns exactly 1 group, and it's name is "None" -- can that be > � > � considered a *definitive* test for a local account? > � > � > � > � There's gotta be something very straight-forward here, that I'm simply > � > � not seeing. Right? > � > � > � > � Thanks... Karl > � > > � > You can use ADSI to fetch the domain name the user has authenticated > with: � > > � > Set objRootDSE = GetObject("LDAP://RootDSE") > � > Set objDomainObject = GetObject("LDAP://" & > � > objRootDSE.Get("defaultNamingContext")) Debug.Print objDomainObject.Name > � > � That's an interesting one. It's not the flat name, and it's not the > � dns name, either. Pretty much not usable in most contexts that I'm > � aware of, but still interesting. IT'd be like... > � > � Left$(DnsName, Instr(DnsName, ".") - 1) > � > � Is that object documented somewhere? (I really hate those things, > � because it seems so damned hard to find out wth they really offer.) > > The domain name returned is actually part of the LDAP distinguished name path > (e.g. . It will be returned as: DC=<domain name>. In any event, it will be > different than the computer name. Of course. It's returning portions of the DNS name, not the "flat name". The latter is a remnant of NT4, but it lives on. The closest I've come to seeing it remotely documented is looking at the descriptions for the DS_RETURN_DNS_NAME and DS_RETURN_FLAG_NAME flags on this page: http://msdn.microsoft.com/en-us/library/ms675983%28VS.85%29.aspx > The other stuff (API, WScript) uses the older WinNT protocol. Remember this > conversation? > > http://www.codenewsgroups.net/vb/t1620-querying-userdomain-currently-logged-user.aspx HA! No, not even vaguely. Funny how this stuff just keeps circling the drain, huh? :-) -- ..NET: It's About Trust! http://vfred.mvps.org Customer Hatred Knows No Bounds at MSFT ClassicVB Users Regroup! comp.lang.basic.visual.misc Free usenet access at http://www.eternal-september.org
From: Karl E. Peterson on 17 Jun 2010 21:13
Karl E. Peterson presented the following explanation : > Is there a definitive test for whether the current user on a machine is > operating under a local account or a domain account? I can see numerous ways > to infer such a distinction, but nothing (in the API realm) that directly > tells you this unambiguously. It appears that calling GetUserNameEx also offers a pretty convincing case for ruling out a domain user. On an XP VM that doesn't belong to a domain, using a local account, this is what I see: GetUserName() = "XPMUser" GetUserNameEx(NameUnknown) = "" GetUserNameEx(NameFullyQualifiedDN) = "" GetUserNameEx(NameSamCompatible) = "VIRTUALXP-46963\XPMUser" GetUserNameEx(NameDisplay) = "" GetUserNameEx(NameUniqueId) = "" GetUserNameEx(NameCanonical) = "" GetUserNameEx(NameUserPrincipal) = "" GetUserNameEx(NameCanonicalEx) = "" GetUserNameEx(NameServicePrincipal) = "" GetUserNameEx(NameDnsDomain) = "" If I do that test on the main machine, logged into a domain account, every field (except Unknown) is full. -- ..NET: It's About Trust! http://vfred.mvps.org Customer Hatred Knows No Bounds at MSFT ClassicVB Users Regroup! comp.lang.basic.visual.misc Free usenet access at http://www.eternal-september.org |