From: Karl E. Peterson on
GS wrote :
> Karl E. Peterson explained on 6/16/2010 :
>> on 6/16/2010, Karl E. Peterson supposed :
>>> GS used his keyboard to write :
>>>> Karl E. Peterson formulated on Wednesday :
>>>>> GS used his keyboard to write :
>>>>>>> Not exactly sure where it's going yet, but I'm working on a tool that
>>>>>>> will tell me what groups a user belongs to on various domains as well
>>>>>>> as locally. Wanted to be able to really identify who was using it due
>>>>>>> to the complex nature of the environment.
>>>>>>
>>>>>> Sounds like a good tool to have. I saw the link to the sample you
>>>>>> posted and it looks promising as the way to go. I'd be interested to
>>>>>> see what comes of this!
>>>>>
>>>>> I'll almost certainly post it, sure.
>>>>>
>>>>>> Did you look at Kevin's suggestion for using WScript.Network? Seems
>>>>>> simple enough but I don't know how it would behave in your case. Any
>>>>>> comments to that?
>>>>>
>>>>> I have a feeling that's just a wrapper around the NetWkstaGetInfo and
>>>>> NetWkstaUserGetInfo API calls, and they're giving me exactly the info
>>>>> needed, yep.
>>>>
>>>> Ok, Karl. Here's what I did with Kevin's example, to add to my arsenal of
>>>> DrivesFoldersFiles_Functions.bas:
>>>>
>>>> Function bUserIsLocalLogin() As Boolean
>>>> Dim oWS_Network
>>>> Set oWS_Network = CreateObject("WScript.Network")
>>>> bUserIsLocalLogin = (oWS_Network.UserDomain = oWS_Network.ComputerName)
>>>> End Function
>>>
>>> That seems to be valid. I'm leary of ever relying on WSH when there's an
>>> API that'll do the job, though. You can achieve those same results using
>>> the NetWksta sample I pointed to earlier.
>>
>> This works in all the scenarios I can envision:
>>
>> Public Function CurrentUserLocal() As Boolean
>> 'http://vb.mvps.org/samples/NetWksta/
>> Dim Wksta As CNetWksta
>> ' Determine currently logged on user.
>> Set Wksta = New CNetWksta
>> CurrentUserLocal = _
>> (StrComp(Wksta.LogonDomain, Wksta.Domain, vbTextCompare) <> 0)
>> End Function
>>
>> That includes:
>>
>> * Logged in as domain user on domain machine
>> * Logged in as local user on domain machine
>> * Logged in as local user on worgroup machine
>>
>> Did I miss anything? I used the case-insensitive StrComp on the
>> unlikely(?) possibility of that meaningless (in this context) difference
>> being the deciding factor.
>
> 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.

--
..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: Tony Toews on
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.

Tony
From: Tony Toews on
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.

Tony
From: GS on
>> 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.

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc


From: Karl E. Peterson on
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? 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.

--
..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