>>>The approach suggested by Tamar is nice. But the customer won't want my VFP application to SQL Select all records from the AD. Instead they want the application to "know" - or determine - the AD username currently logged into the PC.
>>>
>>>That is, suppose when a user logs into his/her PC, they enter the AD username "j_smith" (as an open text) and enter the password (of course, covered with asterisks). Then, they want my VFP application to determine (how is a big question) that the current AD username (logged into the PC) is j_smith.
>>>
>>>Is the above possible?
>>
>>When a user signs in to on-premises AD, several environment variables are set:
>>USERDNSDOMAIN
>>USERDOMAIN
>>USERNAME
>>
>>You could retrieve these with GETENV(). Bear in mind these can be modified by the user so they're not reliable in an adversarial situation.
>>There are also the old ID( ) and SYS( 0 ) functions. I'm not sure if these return the correct username if the user modifies the environment variables.
>>
>>I haven't tested any of the above for a user sign in to Azure Active Directory (AAD), if that applies in your case. I suspect not, since those usernames are of the format someuser@somedomain.com .
>
>Thank you for your message.
>Now - just this morning (since the customer is in Europe) - I received a new requirement. Now the customer wants a user to enter both the AD username and AD password into my VFP application. And my VFP application to check if this is a valid user. Initially I thought that they would not want a user to enter his/her password into the VFP application.
>So, I am back to Tamar's link where the VFP application should create a query to the AD and validate a user.
>I will need to find the name of the AD/SQL Server DB to do that.

I question the need for this. If the user has already signed in to a domain-joined computer. their session is already authenticated. Why should they need to authenticate again from within your app, with the same credentials?

If access privileges within your app depend on the AD username, you already have that, and you know they've already successfully authenticated against AD using that username.