>>>>>>>Hello,
>>>>>>>
>>>>>>>Does anyone know what information VFP 9 can query from the Windows environment with regards to the user logged into the PC (I assume they log using their AD credentials). For example,
>>>>>>>SYS(0) - User Name
>>>>>>>Are there other SYS settings in VFP 9 that can get the user email and/or ID? Other information?
>>>>>>>
>>>>>>>TIA
>>>>>>
>>>>>>This is a method in my domainuserinfo class, GetDomainuserInfo(). it returns an object ADUser which is a class with the necessary properties that you want to use.
>>>>>>
>>>>>>

>>>>>>LPARAMETERS tcUserName, tcUserDomain
>>>>>>*
>>>>>>#DEFINE ADS_NAME_INITTYPE_GC  3
>>>>>>#DEFINE ADS_NAME_TYPE_NT4 	3
>>>>>>#DEFINE ADS_NAME_TYPE_1779 	1
>>>>>>*
>>>>>>LOCAL lcCurrentUserName, lcCurrentUserDomain
>>>>>>lcCurrentUserName = GETENV("UserName")
>>>>>>lcCurrentUserDomain = GETENV("UserDomain")
>>>>>>*
>>>>>>*-- If parameters are not supplied, use current user login info
>>>>>>LOCAL lcUserName, lcUserDomain
>>>>>>lcUserName = EVL(tcUserName, lcCurrentUserName)
>>>>>>lcUserDomain = EVL(tcUserDomain, lcCurrentUserDomain)
>>>>>>*
>>>>>>LOCAL loNameTrans, lcDN
>>>>>>LOCAL loActiveDomainUser
>>>>>>*
>>>>>>LOCAL loADUser AS Aduser OF security_activedirectory.vcx
>>>>>>loADUser = MakeObject("Aduser","security_activedirectory.vcx")
>>>>>>*
>>>>>>TRY
>>>>>>
>>>>>>	*-- Use NameTranslate object to get DN based on Windows Login Name
>>>>>>	loNameTrans = CREATEOBJECT("NameTranslate")					
>>>>>>	loNameTrans.Init( ADS_NAME_INITTYPE_GC, "")
>>>>>>	loNameTrans.Set(ADS_NAME_TYPE_NT4, lcUserDomain + "\" + lcUserName)
>>>>>>	lcDN = loNameTrans.Get(ADS_NAME_TYPE_1779)
>>>>>>	loActiveDomainUser = GETOBJECT("LDAP://" + lcDN)
>>>>>>	loADUser.Exists = .T.
>>>>>>	loADUser.DomainName = lcDN
>>>>>>	loADUser.FullName = loActiveDomainUser.cn
>>>>>>	loADUser.Department = loActiveDomainUser.Department
>>>>>>	loADUser.PrincipalName = loActiveDomainUser.UserPrincipalName
>>>>>>	loADUser.DistinguishedName = loActiveDomainUser.DistinguishedName
>>>>>>	loADUser.CurrentUserDomain = lcUserDomain
>>>>>>CATCH TO oExp WHEN oExp.Errorno = 1426
>>>>>>	loActiveDomainUser = Null
>>>>>>	loADUser.Exists = .F.
>>>>>>ENDTRY	
>>>>>>*
>>>>>>RETURN loADUser
>>>>>>

>>>>>
>>>>>Thank you very much for the sample code. Although I can see that since I don't have the "security_activedirectory.vcx", I will have to create it, somehow.
>>>>>Another question, very newbie. Since the GETENV("UserName") gives you (if I understand correctly) the AD user name of the current user, what is the purpose of getting the loActiveDomainUser?
>>>>
>>>>That is because if you are not in the domain, you also get a username. So the process gets the username, and by getting the domain user I verify if we are at all connected to the AD. Also I query the other properties that are helpful.
>>>>
>>>>One thing I had problems with at one time was that there can be more than one domain. Not sure how that was setup, but they had a separate for Exchange I believe.
>>>
>>>Again, thank you for your reply. And another newbie question (since I am trying to see how I can make my code work without the activedirectory class.
>>>
>>>So, if - by convention (that is, if the customer assures) all users are on domain and connected to the AD, then I can relay on the GETENV("UserName") to give the VFP app the AD username, correct?
>>
>>Hi, sorry for the late reply. It does give you the AD username, but I think under the hood it is actually the other way around: When you log into the AD on the machine, it takes over the user account from AD, even if you have a local user account with that same name.
>
>Not quite. The key thing to remember is that an AD account and a local account are two completely separate accounts. On a domain-joined computer you can log on as either; you get separate user profiles (desktops etc).
>
>Suppose your computer name (local domain) is MyPC, your local AD domain is MyADDomain, and the account name you use on both domains is MyName. You can log on to:
>
>Local account: log on with user name MyPC\MyName, with the local account password. User profile will be something like C:\Users\MyName
>
>AD account: log on with user name MyADDomain\MyName, with the domain account password. User profile will be something like C:\Users\MyName.MyADDomain
>
>The AD account does not "take over" the local account in any way, they remain completely separate and both are accessible.
>
>There is one special case where these accounts interact. If you log on with the local account, and then try to access network resources, you need to authenticate on the remote machine (server, or another workstation if peer-to-peer). If there happens to be an account on the remote machine (AD or local account) that has the same user name and password as the local account you're using on your local computer, then Windows computers will automatically authenticate you and your attempt to access the resource will "just work". However, if there is no matching account name on the remote machine, or there is an account but the password is different, then you'll get a dialog asking to authenticate:
>
>- if AD joined, you can use user name MyADDomain\MyName with your AD password
>- if peer to peer, you can use OtherPC\SomeOtherAccount with its password
>
>IMO the automatic authentication on matching account names and passwords, despite different domains, is a security risk. But it's been a convenience feature in Windows for decades, there would be plenty of users screaming if they took it away.
>
>For domain-joined computers it's often a good idea to retain a local account that has admin privileges. That way if there's ever an issue with the domain controller, or the machine has to be removed from the domain with the DC not present (disposal of computers etc) then the machine can still be accessed.

Thanks for the clarification, that is helpful information.