This file is indexed.

/etc/freeradius/3.0/sites-available/check-eap-tls is in freeradius-config 3.0.16+dfsg-1ubuntu3.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
# This virtual server allows EAP-TLS to reject access requests
# based on some attributes of the certificates involved.
#
# To use this virtual server, you must enable it in the tls
# section of mods-enabled/eap as well as adding a link to this
# file in sites-enabled/.
#
#
# Value-pairs that are available for checking include:
#
#   TLS-Client-Cert-Subject
#   TLS-Client-Cert-Issuer
#   TLS-Client-Cert-Common-Name
#   TLS-Client-Cert-Subject-Alt-Name-Email
#
# To see a full list of attributes, run the server in debug mode
# with this virtual server configured, and look at the attributes
# passed in to this virtual server.
#
#
# This virtual server is also useful when using EAP-TLS as it is
# only called once, just before the final Accept is about to be
# returned from eap, whereas the outer authorize section is called
# multiple times for each challenge / response. For this reason,
# here may be a good location to put authentication logging, and
# modules that check for further authorization, especially if they
# hit external services such as sql or ldap.


server check-eap-tls {


# Authorize - this is the only section required.
#
# To accept the access request, set Auth-Type = Accept, otherwise
# set it to Reject.

authorize {

	#
	# By default, we just accept the request:
	#
	update config {
		&Auth-Type := Accept
	}


	#
	# Check the client certificate matches a string, and reject otherwise
	#

#	if ("%{TLS-Client-Cert-Common-Name}" == 'client.example.com') {
#		update config {
#			&Auth-Type := Accept
#		}
#	}
#	else {
#		update config {
#			&Auth-Type := Reject
#		}
#		update reply {
#			&Reply-Message := "Your certificate is not valid."
#		}
#	}


	#
	# Check the client certificate common name against the supplied User-Name
	#
#	if (&User-Name == "host/%{TLS-Client-Cert-Common-Name}") {
#		update config {
#			&Auth-Type := Accept
#		}
#	}
#	else {
#		update config {
#			&Auth-Type := Reject
#		}
#	}


	#
	# This is a convenient place to call LDAP, for example, when using
	# EAP-TLS, as it will only be called once, after all certificates as
	# part of the EAP-TLS challenge process have been verified.
	#
	# An example could be to use LDAP to check that the connecting host, as
	# well as presenting a valid certificate, is also in a group based on
	# the User-Name (assuming this contains the service principal name).
	# Settings such as the following could be used in the ldap module
	# configuration:
	#
	# basedn = "dc=example, dc=com"
	# filter = "(servicePrincipalName=%{User-Name})"
	# base_filter = "(objectClass=computer)"
	# groupname_attribute = cn
	# groupmembership_filter = "(&(objectClass=group)(member=%{control:Ldap-UserDn}))"

#	ldap

	# Now let's test membership of an LDAP group (the ldap bind user will
	# need permission to read this group membership):

#	if (!(Ldap-Group == "Permitted-Laptops")) {
#		update config {
#			&Auth-Type := Reject
#		}
#	}

	# or, to be more specific, you could use the group's full DN:
	# if (!(Ldap-Group == "CN=Permitted-Laptops,OU=Groups,DC=example,DC=org")) {


	#
	# This may be a better place to call the files modules when using
	# EAP-TLS, as it will only be called once, after the challenge-response
	# iteration has completed.
	#

#	files


	#
	# Log all request attributes, plus TLS certificate details, to the
	# auth_log file. Again, this is just once per connection request, so
	# may be preferable than in the outer authorize section. It is
	# suggested that 'auth_log' also be in the outer post-auth and
	# Post-Auth REJECT sections to log reply packet details, too.
	#

	auth_log

}
}