425 lines
17 KiB
HTML
425 lines
17 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<title>ProFTPD: RADIUS</title>
|
|
</head>
|
|
|
|
<body bgcolor=white>
|
|
|
|
<hr>
|
|
<center><h2><b>ProFTPD: RADIUS</b></h2></center>
|
|
<hr>
|
|
Some sites use the <a href="http://en.wikipedia.org/wiki/RADIUS">RADIUS</a>
|
|
protocol for authenticating users. For these sites, there is the
|
|
<a href="../contrib/mod_radius.html"><code>mod_radius</code></a> ProFTPD module.
|
|
|
|
<p>
|
|
<b>Common Configurations</b></br>
|
|
First, let's start with the most basic <code>mod_radius</code> configuration,
|
|
where we want to use the RADIUS server <b>only</b> for validating the user's
|
|
password:
|
|
<pre>
|
|
<IfModule mod_radius.c>
|
|
AuthOrder mod_radius.c mod_auth_unix.c mod_auth_file.c
|
|
|
|
RadiusEngine on
|
|
RadiusAuthServer localhost:1812 testing123 5
|
|
RadiusLog /etc/proftpd/radius.log
|
|
</IfModule>
|
|
</pre>
|
|
Here, we have told <code>mod_radius</code> the IP address of the RADIUS
|
|
server via the <a href="../contrib/mod_radius.html#RadiusAuthServer"><code>RadiusAuthServer</code></a> directive, which includes the port, shared secret,
|
|
and default timeout value (in seconds).
|
|
|
|
<p>
|
|
Since this configuration only uses the RADIUS server for validating the
|
|
password, we still need to get the user's UID, GID, home directory, group
|
|
membership, <i>etc</i> from somewhere. Thus we need the <code>AuthOrder</code>
|
|
directive to tell <code>proftpd</code> to use the
|
|
<a href="../modules/mod_auth_unix.html"><code>mod_auth_unix</code></a> and
|
|
<a href="../modules/mod_auth_file.html"><code>mod_auth_file</code></a> modules
|
|
as well.
|
|
|
|
<p>
|
|
Using the above configuration, when a client connects and sends the
|
|
<code>USER</code> and <code>PASS</code> FTP commands, the
|
|
<code>mod_radius</code> module will send an <code>Access-Request</code> RADIUS
|
|
packet to the RADIUS server, which will include the following attributes:
|
|
<pre>
|
|
<b>Service-Type 8</b> (<i>i.e.</i> Authenticate-Only)
|
|
User-Name <em>username</em>
|
|
User-Password <em>password</em>
|
|
NAS-Identifier "ftp"
|
|
NAS-IP-Address (<i>or</i> NAS-IPv6-Address) <em>server-ip-address</em>
|
|
NAS-Port <em>server-port</em>
|
|
NAS-Port-Type 5 (<i>i.e.</i> Virtual)
|
|
Calling-Station-Id <em>client-ip-address</em>
|
|
Acct-Session-Id <em>session-pid</em>
|
|
Message-Authenticator <em>mac</em>
|
|
</pre>
|
|
If the RADIUS server responds with an <code>Access-Accept</code> packet, then
|
|
the login succeeds, and the FTP session is establish. If, on the other hand,
|
|
the RADIUS server responds with <code>Access-Reject</code>, the login fails.
|
|
(The <code>mod_radius</code> module does not currently support the
|
|
<code>Access-Challenge</code> packet type.)
|
|
|
|
<p>
|
|
Now, let's examine a slightly more complex configuration, which enables the
|
|
use of RADIUS accounting:
|
|
<pre>
|
|
<IfModule mod_radius.c>
|
|
AuthOrder mod_radius.c mod_auth_unix.c mod_auth_file.c
|
|
|
|
RadiusEngine on
|
|
RadiusAuthServer localhost:1812 testing123 5
|
|
RadiusAcctServer localhost:1813 testing123 5
|
|
RadiusLog /etc/proftpd/radius.log
|
|
</IfModule>
|
|
</pre>
|
|
The additional directive here is the <a href="../contrib/mod_radius.html#RadiusAcctServer"><code>RadiusAcctSerer</code></a> directive, which is quite similar
|
|
to the <code>RadiusAuthServer</code> directive. The use of the
|
|
<code>RadiusAcctServer</code> directive instructs <code>mod_radius</code> to
|
|
use RADIUS accounting.
|
|
|
|
<p>
|
|
With this configuration, <code>mod_radius</code> will do the same as before.
|
|
In addition, once the login has succeeded, <code>mod_radius</code> will send
|
|
an <code>Accounting-Request</code> packet to the RADIUS accounting server
|
|
which includes:
|
|
<pre>
|
|
User-Name <em>username</em>
|
|
<b>Acct-Status-Type 1</b> (<i>i.e.</i> Start)
|
|
Acct-Session-Id <em>session-pid</em>
|
|
Acct-Authentic 1 (<i>i.e.</i> Local)
|
|
Event-Timestamp <em>timestamp</em>
|
|
</pre>
|
|
Then, when the client disconnects, <code>mod_radius</code> sends another
|
|
<code>Accounting-Request</code> packet, this time with a lot of information
|
|
about the just-ended session:
|
|
<pre>
|
|
User-Name <em>username</em>
|
|
<b>Acct-Status-Type 2</b> (<i>i.e.</i> Stop)
|
|
Acct-Session-Id <em>session-pid</em>
|
|
Acct-Authentic 1 (<i>i.e.</i> Local)
|
|
Acct-Session-Time <em>session-duration</em>
|
|
Acct-Input-Octets <em>bytes-in</em>
|
|
Acct-Output-Octets <em>bytes-out</em>
|
|
Acct-Terminate-Cause <em>cause</em>
|
|
Event-Timestamp <em>timestamp</em>
|
|
Class <em>class</em> (if provided in <code>Access-Accept</code>)
|
|
</pre>
|
|
|
|
<p>
|
|
The above configurations are the most common, as RADIUS is normally used
|
|
only as way of checking whether a client should be allowed to connect, based
|
|
on username/password.
|
|
|
|
<p>
|
|
<b>Sophisticated Configurations</b></br>
|
|
It is possible to use RADIUS as the sole means of user authentication, rather
|
|
than just validating passwords. The <code>mod_radius</code> configuration
|
|
to do so would look like:
|
|
<pre>
|
|
<IfModule mod_radius.c>
|
|
AuthOrder mod_radius.c
|
|
|
|
RadiusEngine on
|
|
RadiusAuthServer localhost:1812 testing123 5
|
|
RadiusAcctServer localhost:1813 testing123 5
|
|
RadiusLog /etc/proftpd/radius.log
|
|
|
|
# Use RADIUS Vendor-Specific Attributes (VSAs) for user details
|
|
RadiusVendor Unix 4
|
|
RadiusUserInfo $(10:1000) $(11:1000) $(12:/tmp) $(13:/bin/bash)
|
|
RadiusGroupInfo $(14:users,ftpd) $(15:500,501)
|
|
</IfModule>
|
|
</pre>
|
|
The key difference here is the use of the <a href="../contrib/mod_radius.html#RadiusUserInfo"><code>RadiusUserInfo</code></a> directive. Its appearance within
|
|
the configuration is what instructs <code>mod_radius</code> to do more than
|
|
just password validation. The <code>RadiusUserInfo</code> and <a href="../contrib/mod_radius.html#RadiusGroupInfo"><code>RadiusGroupInfo</code></a> directives
|
|
together tell <code>mod_radius</code> where to find the necessary information
|
|
about a user, such as the UID, GID, home directory, group membership,
|
|
<i>etc</i> in the response packets from the RADIUS server.
|
|
|
|
<p>
|
|
To let the RADIUS server know that we are expecting it do more than just
|
|
validate the password, the <code>Access-Request</code> packet will use a
|
|
different <code>Service-Type</code> attribute. Now the packet will look like:
|
|
<pre>
|
|
<b>Service-Type 1</b> (<i>i.e.</i> Login)
|
|
User-Name <em>username</em>
|
|
User-Password <em>password</em>
|
|
NAS-Identifier "ftp"
|
|
NAS-IP-Address (<i>or</i> NAS-IPv6-Address) <em>server-ip-address</em>
|
|
NAS-Port <em>server-port</em>
|
|
NAS-Port-Type 5 (<i>i.e.</i> Virtual)
|
|
Calling-Station-Id <em>client-ip-address</em>
|
|
Acct-Session-Id <em>session-pid</em>
|
|
Message-Authenticator <em>mac</em>
|
|
</pre>
|
|
|
|
<p>
|
|
Upon receiving the <code>Access-Accept</code> packet, <code>mod_radius</code>
|
|
will now look for specific <a href="http://en.wikipedia.org/wiki/RADIUS#Attribute_value_pairs">attributes</a>, bearing user details, within the packet.
|
|
What attributes does it look for? Answer: <a href="http://en.wikipedia.org/wiki/RADIUS#Vendor-specific_attributes">Vendor-Specific Attributes</a> (commonly
|
|
called "VSAs").
|
|
|
|
<p>
|
|
Every VSA is prefixed with a vendor ID, followed by an attribute ID/value which
|
|
are defined by that vendor. For example, Cisco has a vendor ID of 9,
|
|
Microsoft has a vendor ID of 311, and "Unix" has a vendor ID of 4. (For the
|
|
curious, these vendor IDs, per <a href="http://tools.ietf.org/search/rfc2865#section-5.26">RFC 2865, Section 5.26</a>, come from the <a href="http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers">IANA Enterprise Numbers</a> registry.)
|
|
|
|
<p>
|
|
With this background, we can explain the <code>RadiusUserInfo</code> and
|
|
<code>RadiusGroupInfo</code> directives in detail. Notice that we tell
|
|
<code>mod_radius</code> the vendor ID to look for, using the
|
|
<a href="../contrib/mod_radius.html#RadiusVendor"><code>RadiusVendor</code></a>
|
|
directive:
|
|
<pre>
|
|
RadiusVendor Unix 4
|
|
</pre>
|
|
The above is actually not necessary; <code>mod_radius</code> will look for
|
|
VSAs for vendor ID 4 (Unix) by default. It is useful, though, to make it
|
|
explicitly visible in the configuration.
|
|
|
|
<p>
|
|
Let's now see just what the <code>RadiusUserInfo</code> parameters are doing:
|
|
<pre>
|
|
RadiusUserInfo $(10:1000) $(11:1000) $(12:/tmp) $(13:/bin/bash)
|
|
</pre>
|
|
In order for <code>proftpd</code> to log a user in, it needs to know that
|
|
user's UID, GID, home directory, and shell. And the <code>RadiusUserInfo</code>
|
|
parameters say where to find those values, in that order.
|
|
|
|
<p>
|
|
For UIDs, "$(10:<em>1000</em>)" says to look for a vendor-specific
|
|
attribute ID of 10. If we find such an attribute, use the attribute value as
|
|
the UID. Otherwise, use <em>1000</em> as the UID for the user logging in.
|
|
|
|
<p>
|
|
For GIDs, "$(11:<em>1000</em>)" says to look for a vendor-specific
|
|
attribute ID of 11. If we find such an attribute, use the attribute value as
|
|
the GID. Otherwise, use <em>1000</em> as the GID for the user logging in.
|
|
|
|
<p>
|
|
For home directories, "$(12:<em>/tmp</em>)" says to look for a
|
|
vendor-specific attribute ID of 12. If we find such an attribute, use the
|
|
attribute value as the home directory. Otherwise, use <em>/tmp</em> as the
|
|
home directory for the user logging in.
|
|
|
|
<p>
|
|
And for the shell, "$(13:<em>/bin/bash</em>)" says to look for a
|
|
vendor-specific attribute ID of 13. If we find such an attribute, use the
|
|
attribute value as the shell. Otherwise, use <em>/bin/bash</em> as the shell
|
|
for the user logging in.
|
|
|
|
<p>
|
|
The <code>RadiusGroupInfo</code> directive is very similar: it tells
|
|
<code>mod_radius</code> which VSAs will contain the group membership, both
|
|
in terms of group IDs and group names, for the logging in user:
|
|
<pre>
|
|
RadiusGroupInfo $(14:users,ftpd) $(15:500,501)
|
|
</pre>
|
|
|
|
<p>
|
|
For group names, "$(14:<em>users,ftpd</em>)" says to look for a
|
|
vendor-specific attribute ID of 14. If we find such an attribute, use the
|
|
attribute value as the comma-separated list of supplemental group names.
|
|
Otherwise, use <em>users,ftpd</em> as the group names for the user logging in.
|
|
|
|
<p>
|
|
For group IDs, "$(15:<em>500,501</em>)" says to look for a
|
|
vendor-specific attribute ID of 15. If we find such an attribute, use the
|
|
attribute value as the comma-separated list of supplemental group IDs.
|
|
Otherwise, use <em>500,501</em> as the group IDs for the user logging in.
|
|
|
|
<p>
|
|
<b>FreeRADIUS Configuration</b><br>
|
|
To help demonstrate how you would configure and use VSAs, I will show the
|
|
<a href="http://freeradius.org/">FreeRADIUS</a> configuration that I used for
|
|
development and testing.
|
|
|
|
<p>
|
|
Here is the FreeRADIUS <code>dictionary.unix</code> file I used (slightly
|
|
modified from the stock <code>dictionary.unix</code> file distributed with
|
|
FreeRADIUS); this file defines the attributes supported for the "Unix"
|
|
vendor:
|
|
<pre>
|
|
VENDOR Unix 4
|
|
|
|
BEGIN-VENDOR Unix
|
|
|
|
ATTRIBUTE Unix-User-UID 10 integer
|
|
ATTRIBUTE Unix-User-GID 11 integer
|
|
ATTRIBUTE Unix-User-Home 12 string
|
|
ATTRIBUTE Unix-User-Shell 13 string
|
|
ATTRIBUTE Unix-User-Group-Names 14 string
|
|
ATTRIBUTE Unix-User-Group-Ids 15 string
|
|
|
|
END-VENDOR Unix
|
|
</pre>
|
|
You can see how:
|
|
<pre>
|
|
VENDOR Unix 4
|
|
</pre>
|
|
here corresponds to the <code>mod_radius</code> configuration line:
|
|
<pre>
|
|
RadiusVendor Unix 4
|
|
</pre>
|
|
|
|
<p>
|
|
The following attribute IDs are what we use in our <code>mod_radius</code>
|
|
directives:
|
|
<pre>
|
|
ATTRIBUTE Unix-User-UID <b><i>10</i></b> integer
|
|
ATTRIBUTE Unix-User-GID <b><i>11</i></b> integer
|
|
ATTRIBUTE Unix-User-Home <b><i>12</i></b> string
|
|
ATTRIBUTE Unix-User-Shell <b><i>13</i></b> string
|
|
</pre>
|
|
which match up with our <code>RadiusUserInfo</code> parameters:
|
|
<pre>
|
|
RadiusUserInfo $(<b><i>10</i></b>:1000) $(<b><i>11</i></b>:1000) $(<b><i>12</i></b>:/tmp) $(<b><i>13</i></b>:/bin/bash)
|
|
</pre>
|
|
|
|
<p>
|
|
Similarly for the group membership attributes, <code>dictionary.unix</code>
|
|
has:
|
|
<pre>
|
|
ATTRIBUTE Unix-User-Group-Names <b><i>14</i></b> string
|
|
ATTRIBUTE Unix-User-Group-Ids <b><i>15</i></b> string
|
|
</pre>
|
|
and our <code>RadiusGroupInfo</code> parameters are:
|
|
<pre>
|
|
RadiusGroupInfo $(<b><i>14</i></b>:users,ftpd) $(<b><i>15</i></b>:500,501)
|
|
</pre>
|
|
|
|
<p>
|
|
Note that only the IDs (numbers) for attributes are used in the RADIUS packets
|
|
sent between clients/servers. The attribute names are to make the configuration
|
|
and logging more human-readable.
|
|
|
|
<p>
|
|
Now, in order to tell FreeRADIUS that we want it to <i>include</i> those
|
|
VSAs in its <code>Access-Accept</code> packet back to <code>mod_radius</code>,
|
|
we have to modify the FreeRADIUS <code>users</code> file, like so:
|
|
<pre>
|
|
DEFAULT Auth-Type := System
|
|
Unix-User-UID := 500,
|
|
Unix-User-GID := 500,
|
|
Unix-User-Home := "/home/tj",
|
|
Unix-User-Shell := "/bin/bash",
|
|
Unix-User-Group-Names := "radius,ftpd",
|
|
Unix-User-Group-Ids := "200,501",
|
|
Fall-Through = 1
|
|
</pre>
|
|
See the FreeRADIUS documentation for the <code>users</code> file format in
|
|
order to learn how to configure different UID/GID/home/group values for each
|
|
user in that file.
|
|
|
|
<p>
|
|
<b>Obtaining Quota Information via RADIUS</b><br>
|
|
If you use the <a href="../contrib/mod_quotatab.html"><code>mod_quotatab</code></a> module for quota support in <code>proftpd</code>, <b>and</b> you use the
|
|
<code>mod_radius</code> module for authentication, then you might also be
|
|
interesting in getting your quota information from your RADIUS server, much
|
|
like you can get user details from the RADIUS server.
|
|
|
|
<p>
|
|
The mechanism is identical that used for user details, <i>i.e.</i>
|
|
vendor-specific attributes (VSAs). Assuming that you are using FreeRADIUS,
|
|
you would add the following to your FreeRADIUS <code>dictionary.unix</code>
|
|
file:
|
|
<pre>
|
|
ATTRIBUTE Unix-FTP-Quota-Per-Session <b><i>106</i></b> string
|
|
ATTRIBUTE Unix-FTP-Quota-Limit-Type <b><i>107</i></b> string
|
|
ATTRIBUTE Unix-FTP-Quota-Bytes-Upload <b><i>108</i></b> string
|
|
ATTRIBUTE Unix-FTP-Quota-Bytes-Download <b><i>109</i></b> string
|
|
ATTRIBUTE Unix-FTP-Quota-Bytes-Transfer <b><i>110</i></b> string
|
|
ATTRIBUTE Unix-FTP-Quota-Files-Upload <b><i>111</i></b> string
|
|
ATTRIBUTE Unix-FTP-Quota-Files-Download <b><i>112</i></b> string
|
|
ATTRIBUTE Unix-FTP-Quota-Files-Transfer <b><i>113</i></b> string
|
|
</pre>
|
|
and in the FreeRADIUS <code>users</code> file (assuming the above user-related
|
|
attributes as well):
|
|
<pre>
|
|
DEFAULT Auth-Type := System
|
|
Unix-User-UID := 500,
|
|
Unix-User-GID := 500,
|
|
Unix-User-Home := "/home/tj",
|
|
Unix-User-Shell := "/bin/bash",
|
|
Unix-User-Group-Names := "radius,ftpd",
|
|
Unix-User-Group-Ids := "200,501",
|
|
Unix-FTP-Quota-Per-Session := "false",
|
|
Unix-FTP-Quota-Limit-Type := "soft",
|
|
Unix-FTP-Quota-Bytes-Upload := "1.1",
|
|
Unix-FTP-Quota-Bytes-Download := "2.2",
|
|
Unix-FTP-Quota-Bytes-Transfer := "3.3",
|
|
Unix-FTP-Quota-Files-Upload := "4",
|
|
Unix-FTP-Quota-Files-Download := "5",
|
|
Unix-FTP-Quota-Files-Transfer := "6",
|
|
Fall-Through = 1
|
|
</pre>
|
|
and then, to tell <code>mod_radius</code> that it should look for quota-related
|
|
VSAs in the <code>Access-Accept</code> RADIUS packet, there is the aptly-named
|
|
<a href="../contrib/mod_radius.html#RadiusQuotaInfo"><code>RadiusQuotaInfo</code></a> directive:
|
|
<pre>
|
|
RadiusQuotaInfo $(<b><i>106</i></b>:false) $(<b><i>107</i></b>:hard) $(<b><i>108</i></b>:40.0) $(<b><i>109</i></b>:0.0) $(<b><i>110</i></b>:0.0) $(<b><i>111</i></b>:0) $(<b><i>112</i></b>:0) $(<b><i>113</i></b>:0)
|
|
</pre>
|
|
|
|
<p><a name="FAQ">
|
|
<b>Frequently Asked Questions</b><br>
|
|
<font color=red>Question</font>: Do I have to configure my RADIUS server to
|
|
return VSAs in order to use <code>mod_radius</code>?<br>
|
|
<font color=blue>Answer</font>: No. As shown above, <code>mod_radius</code>
|
|
is usually used just for validating user credentials.
|
|
|
|
<p>
|
|
It is also possible to use only <code>mod_radius</code> for user authentication,
|
|
without needing VSAs. For example, using a configuration like this will
|
|
do what you need:
|
|
<pre>
|
|
<IfModule mod_radius.c>
|
|
AuthOrder mod_radius.c
|
|
|
|
RadiusEngine on
|
|
RadiusAuthServer localhost:1812 testing123 5
|
|
RadiusAcctServer localhost:1813 testing123 5
|
|
RadiusLog /etc/proftpd/radius.log
|
|
|
|
RadiusUserInfo 1000 1000 /tmp /bin/bash
|
|
RadiusGroupInfo ftpd 1000
|
|
</IfModule>
|
|
</pre>
|
|
Notice how the <code>RadiusUserInfo</code> and <code>RadiusGroupInfo</code>
|
|
directives do not use the "$(<i>N</i>:<i>M</i>)" syntax? That means that
|
|
we are not telling <code>mod_radius</code> what vendor ID and attribute IDs
|
|
to look for. Instead, we are telling <code>mod_radius</code> to <b>always</b>
|
|
use the configured UID, GID, home directory, shell, group membership values.
|
|
|
|
<p>
|
|
<b>Note</b> that this means that all of your logged-in users will have the
|
|
exact same UID, GID, and home directory. For some sites, this is ideal. Other
|
|
sites need to have different UID/GID/homes for each users, and thus they will
|
|
use the VSA support.
|
|
|
|
<p><a name="RadiusAndSSH">
|
|
<font color=red>Question</font>: Can I use <code>mod_radius</code> for SFTP
|
|
connections?<br>
|
|
<font color=blue>Answer</font>: Yes. However, there are some caveats. The
|
|
main issue that clients which want to use SSH publickey authentication
|
|
<b>cannot</b> use RADIUS, since the RADIUS protocol does not define any means
|
|
of conveying the public key information from the connecting client to the
|
|
RADIUS server. So only password-based SSH authentication can be supported
|
|
using <code>mod_radius</code>.
|
|
|
|
<p>
|
|
<hr>
|
|
<font size=2><b><i>
|
|
© Copyright 2017 The ProFTPD Project<br>
|
|
All Rights Reserved<br>
|
|
</i></b></font>
|
|
<hr>
|
|
|
|
</body>
|
|
</html>
|