Remote Access Authentication Policies/Permissions

jwlazarjwlazar Member Posts: 21 ■□□□□□□□□□
I was watching a CBTNugget on the overlap of RRAS Remote Access Policies/Profiles and permissions as defined in user settings. There was a flowchart in regards to how the settings are processed, either granting or denying permission.

I'm confused as to how the presence (of absence) of policies in the RRAS profile interacts with user settings. Say for example that the user was granted access (as opposed to "set access through remote policy") in the remote tab of his/her profile under ADU&G. Would the absence of policies in RRAS universally dictate that above user wouldn't be able to use remote access despite having access explicity defined in the profile?

Comments

  • royalroyal Member Posts: 3,353
    Basically it's like this.

    If Dial-up is granted in ADUC. then the user is granted access. If denied in ADUC, then the user is denied access. If Domain Functional Level is moved up to at least Windows 2000 Native, Remote Access Policies are defaulted. If there are no remote access policies (you deleted them), user is automatically denied access. By default, the first 2 remote access policies are deny access.

    Remote access policies are applied in a certain order. For instance, let's say you have a user named Joe. Joe is a part of Sales and Research and Development. You have another user named Marry that is only a part of Sales. Sales are allowed 24/7 access to VPN. Research and Development is locked down so you do not want any VPN access granted to any user in that group regardless if they are in other groups that are allowed access. You want your deny policies first. I will show you why.

    Custom Remote Access Policy #1 - Deny if user is in Research and Development Group
    Custom Remote Access Policy #2 - Grant if user is in Sales Group

    Joe VPNs in. VPN server checks AD to see if access is allowed, denied, or to use its Remote Access Policy. The VPN server sees to use Remote Access Policy. VPN server now looks at the 1st Remote Access Policy. It sees Joe is a part of the Research and Development Group. The 1st policy applies to him and is set to Deny access. Joe is now denied access.

    Mary VPNs in. VPN server checks AD to see if access is allowed, denied, or to use its Remote Access Policy. The VPN server sees to use Remote Access Policy. VPN server now looks at 1st Remote Access Policy. Is Mary a part of Research and Development group. She is not so now the VPN server checks the 2nd Remote Access Policy. She is a part of the Sales Group which is set to grant access. Mary now has VPN access.

    As you can see, it checks the top-most Remote Access Policy, and if it applies to a user, that user is granted or denied access depending on what you set that Remote Access Policy to. If that Remote Access Policy does not apply, it tries the next Policy in the list.

    Hope this helps.
    “For success, attitude is equally as important as ability.” - Harry F. Banks
  • jwlazarjwlazar Member Posts: 21 ■□□□□□□□□□
    icroyal,

    I understand how RRAS parses the individual policies as defined in remote authentication. Your first paragraph however, is what summarizes my point of contention:
    If Dial-up is granted in ADUC. then the user is granted access. If denied in ADUC, then the user is denied access. If Domain Functional Level is moved up to at least Windows 2000 Native, Remote Access Policies are defaulted. If there are no remote access policies (you deleted them), user is automatically denied access. By default, the first 2 remote access policies are deny access.

    So hypothetically, if Sam was specified "grant access" in his user profile but no policies were defined in remote access policies, he would still have access? The reason I ask this is because the CBTNugget seems to dispute this. It implies that regardless of user settings in ADUC, the presence of policies is what dictates access. Is this correct?

    Thanks for the reply.
    [/quote]
  • royalroyal Member Posts: 3,353
    The reason there might be some confusion is because when you bump up the DFL and RAPs are now defaulted, if you delete the RAPs, all users lose access by default. I think I remember testing this and I granted a user access manually in ADUC and they were granted access even with no RAPs. This was quite a while ago so I could be wrong.

    Do you have a lab to test this out? I would hope so. If anything, I am curious myself because I am not 100% sure, only 99% sure the user is still granted access if you explicitly grant them access in ADUC even if you have no RAPs. I won't be in the office till Monday, so I wouldn't be able to test this until then.
    “For success, attitude is equally as important as ability.” - Harry F. Banks
  • royalroyal Member Posts: 3,353
    Btw, I just tested this out for you. I had Dial-In set to Grant Access and I removed all the Remote Access Policies. I was still granted access. So it is only when a user is set to use Remote Access Policy that they will be denied if there are no Remote Access Policies.
    “For success, attitude is equally as important as ability.” - Harry F. Banks
  • TregTreg Member Posts: 79 ■■□□□□□□□□
    Im certain you are denied if you delete all the default RAP's regardless what you set the user dialin option to. Maybe you didnt leave enough gap between deleting them and trying the connection?
  • royalroyal Member Posts: 3,353
    Yep, you are correct. I just tested this some more. In mixed mode and have grant access. I re-tried with the RAP removed and was denied access. I then created a RAP with grant to Domain Users and waited a few minutes and then was granted access. When I was denied access, it said it was a policy issue on the RAP server. Weird how RAP changes take effect immediately and sometimes it takes several minutes.
    “For success, attitude is equally as important as ability.” - Harry F. Banks
  • jwlazarjwlazar Member Posts: 21 ■□□□□□□□□□
    icroyal, thanks mucho for your replies; when I have a chance to toy around, I'll replicate the scenario here to get a firm understanding of policies in general

    at least for now, any doubt about access permissions has been answered :)

    Thank again!
Sign In or Register to comment.