This scenario occurs in mixed deployments of workgroup users and Active Directory users in which you do not want workgroup users who are not part of the AD domain to be prompted for authentication. You can achieve this by having the same username and password of your workgroup users in AD. In this case, installing BCAAA on the DC works fine without prompting users for authentication. However, when you install BCAAA on a member server, the workgroup users will be prompted for authentication.
On the BCAAA agent debug logs when the BCAAA agent running on a member server:
On the Netlogon logs when the BCAAA agent running on a DC:
10/26 22:23:17 [LOGON] ZDOMAIN: SamLogon: Network logon of ZULTEST12345678\zul2 from ZULTEST12345678 Returns 0x0
The BCAAA debug logs and the Netlogon logs above show that the response from Active Directory have no issues. However, AD assumes that the workgroup user was authenticating in the local domain of the DC, which is the AD domain and not the workgroup domain. This is not the case when the BCAAA agent is running on the member server.
This is expected behavior from AD when a user authenticates from the member server: the workgroup or the domain that the user is coming from will be checked. So in this case, the workgroup name is not the domain name, thus AD responds correclty by giving the user an error because the user does not belong to the AD domain.Therefore, it is expected behavior for a workgroup user who is not an AD domain user to receive an authentication pop-up when the BCAAA agent runs on a member server.
Imported Document ID: 000016775
Subscribing will provide email updates when this Article is updated. Login is required.
Thanks for your feedback. Let us know if you have additional comments below. (requires login)
Subscribed to the Article.
Unable to subscribe
Thanks for your additional feedback !!!
Enterprise Support Virtual Agent
Rate Me :
Tell us more:
Welcome! My name is Sami, the Enterprise Support Virtual Agent answering technical support questions.