Chetan Gaonker | 7f4bf74 | 2016-05-04 15:56:08 -0700 | [diff] [blame] | 1 | # This virtual server allows EAP-TLS to reject access requests |
| 2 | # based on some certificate attributes. |
| 3 | # |
| 4 | # Value-pairs that are available for checking include: |
| 5 | # |
| 6 | # TLS-Client-Cert-Subject |
| 7 | # TLS-Client-Cert-Issuer |
| 8 | # TLS-Client-Cert-Common-Name |
| 9 | # TLS-Client-Cert-Subject-Alt-Name-Email |
| 10 | # |
| 11 | # To see a full list of attributes, run the server in debug mode |
| 12 | # with this virtual server configured, and look at the attributes |
| 13 | # passed in to this virtual server. |
| 14 | # |
| 15 | # |
| 16 | # This virtual server is also useful when using EAP-TLS as it is only called |
| 17 | # once, just before the final Accept is about to be returned from eap, whereas |
| 18 | # the outer authorize section is called multiple times for each challenge / |
| 19 | # response. For this reason, here may be a good location to put authentication |
| 20 | # logging, and modules that check for further authorization, especially if they |
| 21 | # hit external services such as sql or ldap. |
| 22 | |
| 23 | server check-eap-tls { |
| 24 | |
| 25 | |
| 26 | # Authorize - this is the only section required. |
| 27 | # |
| 28 | # To accept the access request, set Auth-Type = Accept, otherwise |
| 29 | # set it to Reject. |
| 30 | |
| 31 | authorize { |
| 32 | |
| 33 | # |
| 34 | # By default, we just accept the request: |
| 35 | # |
| 36 | update config { |
| 37 | Auth-Type := Accept |
| 38 | } |
| 39 | |
| 40 | |
| 41 | # |
| 42 | # Check the client certificate matches a string, and reject otherwise |
| 43 | # |
| 44 | |
| 45 | # if ("%{TLS-Client-Cert-Common-Name}" == "client.example.com") { |
| 46 | # update config { |
| 47 | # Auth-Type := Accept |
| 48 | # } |
| 49 | # } |
| 50 | # else { |
| 51 | # update config { |
| 52 | # Auth-Type := Reject |
| 53 | # } |
| 54 | # update reply { |
| 55 | # Reply-Message := "Your certificate is not valid." |
| 56 | # } |
| 57 | # } |
| 58 | |
| 59 | |
| 60 | # |
| 61 | # Check the client certificate common name against the supplied User-Name |
| 62 | # |
| 63 | # if ("host/%{TLS-Client-Cert-Common-Name}" == "%{User-Name}") { |
| 64 | # update config { |
| 65 | # Auth-Type := Accept |
| 66 | # } |
| 67 | # } |
| 68 | # else { |
| 69 | # update config { |
| 70 | # Auth-Type := Reject |
| 71 | # } |
| 72 | # } |
| 73 | |
| 74 | |
| 75 | # |
| 76 | # This is a convenient place to call LDAP, for example, when using |
| 77 | # EAP-TLS, as it will only be called once, after all certificates as |
| 78 | # part of the EAP-TLS challenge process have been verified. |
| 79 | # |
| 80 | # An example could be to use LDAP to check that the connecting host, as |
| 81 | # well as presenting a valid certificate, is also in a group based on |
| 82 | # the User-Name (assuming this contains the service principal name). |
| 83 | # Settings such as the following could be used in the ldap module |
| 84 | # configuration: |
| 85 | # |
| 86 | # basedn = "dc=example, dc=com" |
| 87 | # filter = "(servicePrincipalName=%{User-Name})" |
| 88 | # base_filter = "(objectClass=computer)" |
| 89 | # groupname_attribute = cn |
| 90 | # groupmembership_filter = "(&(objectClass=group)(member=%{control:Ldap-UserDn}))" |
| 91 | |
| 92 | # ldap |
| 93 | |
| 94 | # Now let's test membership of an LDAP group (the ldap bind user will |
| 95 | # need permission to read this group membership): |
| 96 | |
| 97 | # if (!(Ldap-Group == "Permitted-Laptops")) { |
| 98 | # update config { |
| 99 | # Auth-Type := Reject |
| 100 | # } |
| 101 | # } |
| 102 | |
| 103 | # or, to be more specific, you could use the group's full DN: |
| 104 | # if (!(Ldap-Group == "CN=Permitted-Laptops,OU=Groups,DC=example,DC=org")) { |
| 105 | |
| 106 | |
| 107 | # |
| 108 | # This may be a better place to call the files modules when using |
| 109 | # EAP-TLS, as it will only be called once, after the challenge-response |
| 110 | # iteration has completed. |
| 111 | # |
| 112 | |
| 113 | # files |
| 114 | |
| 115 | |
| 116 | # |
| 117 | # Log all request attributes, plus TLS certificate details, to the |
| 118 | # detail auth_log. Again, this is just once per connection request, so |
| 119 | # may be preferable than in the outer authorize section. It is |
| 120 | # suggested that 'auth_log' also be in the outer post-auth and |
| 121 | # Post-Auth REJECT sections to log reply packet details, too. |
| 122 | # |
| 123 | |
| 124 | auth_log |
| 125 | |
| 126 | } |
| 127 | |
| 128 | |
| 129 | |
| 130 | } |
| 131 | |