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: Karl E. Peterson on 16 Jun 2010 22:06 Tony Toews formulated on Wednesday : > On Wed, 16 Jun 2010 14:46:31 -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. > > Pokaing about in the registry for another problem I found an > interesting registry key which was named LOGONSERVER It was in a > hive? which stated Volatile Environment so dunno how useful that is. Yeah, I wonder, too. You can certainly determine this easily enough using NetWkstaUserGetInfo. I would guess that this key is being used to store what the last server was, for use with cached credentials. I just put away my laptop, or I'd test. But hey, it's time for dinner! <g> -- ..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 16 Jun 2010 22:07 Tony Toews was thinking very hard : > On Wed, 16 Jun 2010 14:46:31 -0700, Karl E. Peterson <karl(a)exmvps.org> > wrote: > >> I suppose the LOGONSERVER environment variable is a pretty good >> indication? > > I don't trust environment variables as someone could open up the > cmoment prompt, change an environment variable and then run the app > from the command prompt getting the changed environment variable. Yep, and I'm working on a console utility, to it's actually designed to be open to that sort of tinkering. -- ..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: GS on 16 Jun 2010 23:26 Karl E. Peterson pretended : > GS formulated on Wednesday : >>>> Well, I was particularly interested in the Workgroup part, feeling that >>>> this might be an issue with my WSH function not being able to determine a >>>> domain or workgroup. What say you? >>> >>> That was covered, I thought, in this last test? That machine, a VM >>> actually, isn't a member of the domain. So this is what I get from those >>> properties there: >>> >>> ?Wksta.LogonDomain, Wksta.Domain >>> VIRTUALXP-46963 WORKGROUP >>> >>> With the latter just being what Windows defaults to if you don't set it to >>> something else. >> >> Yeah, I see that your function does this. I was stating concern that my WSH >> function doesn't specify this info, and was asking your opinion as to its >> validity in that context. > > I'm not tracking. Are you asking how to differentiate between whether the > machine is a member of a domain or a workgroup? Yes, basically that's it. > If so, I think you need > heavier artilliary. Like NetGetDCName to look for a domain controller. > However, even that will fail if it's (for example) a notebook that's off the > network. I'd really have to putz around awhile to find out in that scenario. My concerns are having the ability to determine, for example, if a notebook is logged onto a domain OR as being part of a Workgroup connected to a domain. What's common for my users is to carry their notebooks around to their client sites and log onto the client's network via Workgroup rather than being part of the client's domain. This, of course, would give them whatever user-level access to the site's server they were allowed, via their normal notebook user account login. Clearly, the WSH approach (as written) doesn't provide that info. In contrast, your function would allow obtaining this info fairly easily via expanding it for reading various Wksta props. -Just thinking that using the class from the downloaded sample makes that easy since it exposes the necessary info. What adds to the complexity is when users are normally part of their network domain but (as you suggest) not connected to it when at client sites. This presents a problem when the notebook using my app requires license validation via the network it's normally connected to. What I would do in this case is bypass the normal license validation when the SiteID in the license profile is not their own network, thus needing a 'temp' off-site validation. I already offer a 'Roam' license profile where the app is installed to, and licensed for use on/from, a specific USB drive. This works very well on its own but doesn't address the cases where the laptop belongs to the company but is used off-site by the employee. Primarily, the company doesn't want their employees walking off with the company's licensed apps. This is why they use 'site licenses'. (The app won't run if not validated against the site license) I could set up an online validation service to handle this, but I really don't want to do that. Using something like this function to determine the 'location' status of the machine would work nicely<IMO>! I suspect the same holds true for a WSH function, given figuring all that out by examining its object model. Not sure why I'd need to know more than just this info, but you've demonstrated that others may possibly need it for whatever reasons. -- Garry Free usenet access at http://www.eternal-september.org ClassicVB Users Regroup! comp.lang.basic.visual.misc
From: Paul Clement on 17 Jun 2010 09:00 On Wed, 16 Jun 2010 14:46:31 -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 Paul ~~~~ Microsoft MVP (Visual Basic)
From: Karl E. Peterson on 17 Jun 2010 13:38
Paul Clement presented the following explanation : > On Wed, 16 Jun 2010 14:46:31 -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... -- ..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 |