RADIUS authentication of trusted domain users

Why and why is it?

So there were circumstances that I had to administer the already configured RADIUS user authentication of one trusted domain on the Mikrotik site, which either allowed users to the Internet or not. Previously, this did not have to be configured, just a ready-made customized “black box” was available. The task was to add another domain user to this authentication scheme.
So that I remember this story forever, here and describe the process.

How does it work?

So, I started to look at how this all works in the current scheme. At first (and not the first one too), everything is in the textbook:

• On a certain computer domain AUTHSRV.DOM1.LOCAL (win2003), raised "service authentication on the Internet."
• The client is registered in it - Mikrotik, with the general secret.
• Domain DOM1.LOCAL (win2008) has bilateral trust with DOM2.LOCAL (win2003).
• In DOM2.LOCAL , the global group allow_internet is created , to which users who must successfully authenticate to Mikrotik are added.
• The local group allow_internet has been created on the computer AUTHSRV.DOM1.LOCAL , which includes the global group of the trusted domain DOM2.LOCAL \ allow_internet .
• Accordingly, a remote access policy has been created in the authentication service settings that allows access if the user is a member of the AUTHSRV \ allow_internet group .

Everything looks logical and really works as expected.

How to make it work?

I see a purpose, but I do not see obstacles. I create a bilateral trust DOM1.LOCAL with DOM3.LOCAL (win2003). I create an allow_internet global group in DOM3.LOCAL , including users there. I add this global group to AUTHSRV \ allow_internet and happily try to log in.
')
Of course, nothing worked. Here is the answer:

Cause = Unable to establish connection due to denial of remote access permission for user account. To allow remote access, enable such permission for the user account or, if it indicates that access control is exercised using the appropriate remote access policy, enable the remote access permission for this policy.

And since the lack of my knowledge did not allow me to understand that actually the answer lies here, the research began. There were no traces in the logs on the domain controllers DOM3.LOCAL or DOM1.LOCAL from this event. Google by this error gives in general something irrelevant to the case (continuous RDP). Search in group policies on the "working" DOM2.LOCAL did not give anything.
I even tried proxying RADIUS requests, raising also the authentication service on the Internet to DC.DOM3.LOCAL and broadcasting there requests with the user name of the form “DOM3 *”. However, in the proxy-RADIUS server log there was exactly the same error and access denied.

The cause of all troubles

And the reason is always the same - gracelessness. It turns out that because DOM3.LOCAL worked in the mixed-mode, then on all users by default on the tab “Incoming calls” / “Dial-in” the attribute “Remote access permission (VPN or modem)” is set to “Deny access” , unlike DOM2.LOCAL .
Changed the domain operation mode DOM3.LOCAL to “native” and changed the attribute “Remote access permission (VPN or modem)” attribute for all users to the value “Management based on remote access policy” (which was not available until the domain operation mode was changed) as follows script:

Set objOU = GetObject("LDAP://dc=DOM3,dc=local") objOU.Filter = Array("user") For Each objUser In objOU objUser.PutEx 1,"msNPAllowDialin", vbnull objUser.SetInfo Next 

After that, everything worked as it should.