i´m not shure if i understood your problem in detail. Therefore just a hint from my side. You can use an authentication chain like my attached screen shot. This also works, if you are using multiple Active Directory connections with one MWG. MWG will choose the right Domain Controller based on the Authentication Realm.
In my example, if MCP does not work the client does a NTLM authentication. There is only a popup shown if MCP and NTLM are not working. Feel free to add a third authentication method like Kerberos or LDAP.
Note: This does not work if you are configuring a wrong MCP Password for the endpoint. In this case you may add an event to the MCP authentication setting the authentication.failed property to false and Authentication.isAuthenticated to true.
"MCP not working" could mean a couple things to me, please let me know if we're on the same page. In my mind "MCP not working" means MCP is not standing up and not redirecting traffic.
From what your describing it sounds like MCP is standing up and redirecting traffic, but the user information isnt what you expect. Is that a correct characterization? If so, what shows as the username in this user's requests (look at rule tracing)?
The ruleset you've shown above will only apply if there was no groups sent by MCP. In which case we will ask the LDAP server for the user's groups. What does the rule trace show for the first rule "Only proceed if groups are empty"?
To your original question, you can prompt the user for credentials, but it wouldn't be done in the same way as you do it for proxy authentication (meaning you cant add a single rule to fix this). Instead you'd need to do a session based authentication (authentication server). This would require logic to identify the user logged in as local admin, then redirect them to the authentication server for auth. The MWG would them remember the user information based on IP rather than relying on MCP.
Troja, I dont think you're rules help with what kbolt is doing. Your rules simply check if the user has authenticated with MCP, if they have (authenticated with MCP) then there is no need to do NTLM.
jscholte, yes you are right. I was not aware whats really going on. so i decided to give the hint using an authentication chain. :-)
I do not know any configuration using a "prompt" if MCP authentication fails. If MCP fails, we need another type of authentication... could this be? So, if MCP does not deliver Groups, this Information is just missing, so we need another option. Hmmm, but how NTLM when no Proxy configures.... i have to rethink my solution.... *g*
This was my thought.
Troja & jscholte thank you very much for your replies! I've had a separate project pull me away from this for a while. Jon, you're correct. MCP is in fact redirecting traffic and it is correctly passing along user name and user group, however I've not put any rules on MWG to handle a local admin (i.e. admin) user. So if I depend solely on MCP, then admin gets pushed to the Default policy which isn't ideal when working on these machines. So based on what you've proposed, would it make sense to create a rule or ruleset that is triggered whenever the local admin user name is seen? This ruleset would include an NTLM authenticate option which I would hope would prompt for user credentials which would then be saved within MWG and used for further authentication.
Am I on the right track?
Please click on "Top Properties" in the same as in your screenshot. They you will see a response code which is usually 407 - Authentication Required. Technically the client is asked to send Authentication Details. Some Clients just ignore it. This isn't an issue on MWG, most likely week client behavior.