Loading...

Knowledge Center


Firewall Enterprise: How to set up external group authentication using FreeRADIUS as a RADIUS server
Technical Articles ID:  KB67454
Last Modified:  09/25/2013

Summary

This article provides an example of how to configure authentication based on group membership that is determined by a RADIUS authentication server that is external to the firewall. We will use the FreeRADIUS server running on a Suse Linux system.

Example network:

In this example, we will require authentication of users from the 192.168.9.0/24 network trying to Telnet to two servers:
  • serverA at 192.168.4.24
  • serverB at 192.168.4.16

Server access is restricted as follows:
  • Members of the "testers" group are allowed to access serverA. 
  • Members of the "auditors" or "developers" group are allowed to access serverB.

The RADIUS server is "radius" at 10.140.168.28. The RADIUS server provides group membership information to the firewall.


                                            Telnet clients
                                        192.168.9.0/24 network
                                              |
                                              |
        radius                                |
     RADIUS server------------------------Firewall Enterprise
     10.140.168.28                           192.168.9.65
                                              |
                                              |
                                       +------+---------+
                                       |                |
                                    serverA           serverB
                                 192.168.4.24       192.168.4.16
                                 Telnet server      Telnet server

Solution

NOTE: These procedures use the values from the example network. Enter appropriate values for your network.

Configure the FreeRADIUS Server

In this example, we use the FreeRADIUS server in the freeradius-0.9.3-106.9 RPM on a Suse 9 server.
  1. Modify the /etc/raddb/clients.conf configuration file to add the hosts and networks that are allowed to query the FreeRADIUS server and the passwords that they must use.

    In this example, we add the following:
    • client network - 192.168.9.0/24
    • password for the network - mcafee
    • network name - lab-9

    Here is the entry we add: 

    client 192.168.9.0/24 {
          secret          = mcafee
          shortname       = lab-9
    }


    NOTE: Ensure proper insertion of white space, for example a Tab character - not spaces - comes before the line that starts with secret. 
     
  2. Modify the /etc/raddb/dictionary configuration file to specify a vendor ID, attribute name, and attribute number to indicate group membership.

    Since the RADIUS standard doesn't specify a particular attribute to indicate group membership, we will configure the server with a vendor-specific attribute.

    You can use any vendor ID, but in this example, we will use the ID reserved by IANA for McAfee: 1573.

    We make an arbitrary decision that attribute number 2 will be of type string and will have the name Sw-Groups.

    Adding Sw-Groups to the dictionary will allow us to configure users in the users configuration file with a Sw-Groups attribute. Sw-Groups is an arbitrary name, only visible within the FreeRADIUS configuration files. The FreeRADIUS server has no concept of groups, and just sees it as a string.

    We will configure both the firewall and the FreeRADIUS server to use vendor 1573 type 2 as a list of groups of which the user is a member. 

    Here is the line we add to /etc/raddb/dictionary:

    $INCLUDE        /etc/raddb/dictionary.mcafee

    Here are the contents of the /etc/raddb/dictionary.mcafee file:

    VENDOR          McAfee                  1573
    ATTRIBUTE       Sw-Groups               2       string  McAfee

     
    NOTE: Ensure proper insertion of white space, for example a Tab character - not spaces - comes between VENDOR and McAfee. 
     
  3. Modify the /etc/raddb/users.lab configuration file to configure some users.

    In this example, we give each user an Sw-Groups attribute, plus an example RADIUS attribute, "Framed-IP-Address," which is completely arbitrary and may be omitted. The significant thing is that we can configure each user with group membership using the Sw-Groups attribute.

    NOTE: Users can be a member of more than one group by separating the group names with a comma. Using a comma is also an arbitrary decision. The firewall must be told that the group names are delimited by a comma. We'll demonstrate this later. In the example below, user "mark" is a member of two groups.

    We choose to put the users in a separate file. Here is the line we add to the /etc/raddb/users file:

    $INCLUDE /etc/raddb/users.lab

    Here are the contents of the /etc/raddb/users.lab file:

    steve   Auth-Type := Local, User-Password == "fido89"
            Framed-IP-Address = 172.16.3.31,
            Sw-Groups := "testers"

    jack    Auth-Type := Local, User-Password == "spot77"
            Framed-IP-Address = 172.16.3.32,
            Sw-Groups := "auditors"

    don     Auth-Type := Local, User-Password == "king33"
            Framed-IP-Address = 172.16.3.33,
            Sw-Groups := "developers"

    mark    Auth-Type := Local, User-Password == "rufus41"
            Framed-IP-Address = 172.16.3.34,
            Sw-Groups := "testers,auditors"


    NOTE: Ensure proper insertion of white space, for example a Tab character - not spaces - comes before Framed in the second line. 
     
  4. Start (or restart) the RADIUS server with this command:

    /etc/init.d/radiusd restart

    Now you should have a /usr/sbin/radiusd running in your system. You can check for it with:

    ps -ewf|grep radius

    You should also check /var/log/radius/radius.log for errors.

Configure Firewall Enterprise

  1. Create the new authenticator.
    1. Navigate to Policy, Rules Elements, Authenticators.
    2. Click New (+) and select RADIUS.
    3. Name it radius-auth.
    4. On the General tab:
      1. Under RADIUS servers, click New.
      2. In the resulting Server Configuration window, set:
        IP Address: The IP address for your server, 10.140.168.28 in this example.
        Shared Secret: The password for your server, mcafee in this example.
      3. Click Add.
      4. Under Group source, select external.
    5. Click the Groups tab.
      1. Under External Group, click New. In the Groups: New Group window, enter all the external groups you will need to configure rules for, one per line. In this example: 
        testers
        auditors
        developers
      2. Click OK.
      3. Under RADIUS group options, set these values:
        Group type: 26 (the default for a vendor-specific attribute)
        Vendor ID: 1573
        Vendor type: 2
        Group delimiters: ,
    6. Click Add then Save to create the new authenticator.


    The cf equivalent of this step is:

    cf auth add name=radius-auth description='RADIUS authenticator' \
    external_groups=developers,auditors,testers warder=radius \
    vendor_id=1573 host=10.140.168.28 port=1812 password='mcafee' \
    group_type=26 invalid_message='Login incorrect' \
    group_source=external vendor_type=2 pass_prompt='Password: ' \
    user_prompt='Username: ' group_delimiters=,
      
     
  2. Create host endpoints for the Telnet servers.
    1. Create the serverA host endpoint.
      1. Navigate to Policy, Rules Elements, Network Objects.
      2. Click New (+) and select Host.
      3. In the Network Objects: Host dialog, enter the following values:
        Name: serverA
        Host: serverA.mfelab.net
      4. Click New and enter the following value:
        IP Address: IP address of your server, 192.168.4.24 in this example.
      5. Click Add.
      6. Click Add.
    2. Create the serverB host endpoint.
      1. Click New (+) and select Host.
      2. In the Network Objects: Host dialog, enter the following values:
        Name: serverB
        Host: serverB.mfelab.net
      3. Click New and enter the following value:
        IP Address: IP address of your server, 192.168.4.16 in this example.
      4. Click Add.
      5. Click Add.
    3. Click Save.

    The cf equivalent of the this step is:

    cf host add name=serverA dns_mode=dns host=serverA.mfelab.net ipaddrs=192.168.4.24 ttl=0
    cf host add name=serverB dns_mode=dns host=serverB.mfelab.net ipaddrs=192.168.4.16 ttl=0

     
  3. Create the firewall rules.
    1. Create a rule to allow only the users in the group "testers" to have access to serverA.
      1. Navigate to Policy, Rules.
      2. Click New (+).
      3. Enter the following values:
        Name: telnet-serverA
        Action: Allow
        Service: telnet
        Source Burb: internal
        Source Endpoint: <Any>
        Destination Burb: dmz
        Destination Endpoint: serverA (Host)
        NAT: <None>
        Redirect: <None>
        Authenticator: radius-auth
        Allow users in the following groups: testers
      4. Click OK.
    2. Create a rule to allow only the users in the groups "developers" and "auditors" to have access to serverB.
      1. Click New (+).
      2. Enter the following values:
        Name: telnet-serverB
        Action: Allow
        Service: telnet
        Source Burb: internal
        Source Endpoint: <Any>
        Destination Burb: dmz
        Destination Endpoint: serverB (Host)
        NAT: <None>
        Redirect: <None>
        Authenticator: radius-auth
        Allow users in the following groups: Click ... , and in the resulting New Rule: Authentication window, select Allow only users in the selected groups under Authorization and select the "developers" and "auditors" checkboxes
      3. Click OK.
      4. Click OK.
    3. Click Save.

    The cf equivalent of this step is:

    cf policy add table=rule name=telnet-serverA rulegroup='' pos=2 \
    action=allow appdefense= audit=standard authenticator=radius-auth \
    authgroups=testers dest=host:serverA dest_burbs=burb:dmz \
    disable=no inspection_level=comprehensive ipsresponse= \
    nat_addr= nat_mode=none redir= redir_port= \
    service=service:telnet sign_category_grp= source='*' \
    source_burbs=burb:internal timeperiod='*' ts_enable=no \
    ts_reputation=suspicious_unverified_threshold \
    description='Allow users in testers group access to serverA'

    cf policy add table=rule name='telnet serverB' rulegroup='' pos=3 \
    action=allow appdefense= audit=standard authenticator=radius-auth \
    authgroups=auditors,developers dest=host:serverB \
    dest_burbs=burb:dmz disable=no inspection_level=comprehensive \
    ipsresponse= nat_addr= nat_mode=none redir= redir_port= \
    service=service:telnet sign_category_grp= source='*' \
    source_burbs=burb:internal timeperiod='*' ts_enable=no \
    ts_reputation=suspicious_unverified_threshold \
    description='Allow users in developer or auditors access to serverB'
Test the configuration
  1. Telnet through the firewall from the 192.168.9.0/24 network to serverA using the user steve. Steve should be allowed because he is a member of the testers group.

        24 [user@server:user] telnet 192.168.4.24
        Trying 192.168.4.24...
        Connected to 192.168.4.24.
        Escape character is '^]'.

                                 Welcome to Sidewinder 7.0

        Username: steve
        Password: 
        CentOS release 5.2 (Final)
        Kernel 2.6.18-92.el5 on an i686
        login: user
        Password:
        Last login: Tue Nov 17 15:33:03 from name-4
        =            Welcome to serverA!              ==

     

  2. Telnet through the firewall from the 192.168.9.0/24 network to serverA using the user jack. Jack should be denied because he is not a member of the testers group.

        25 [user@server:user] telnet 192.168.4.24
        Trying 192.168.4.24...
        Connected to 192.168.4.24.
        Escape character is '^]'.

                                 Welcome to Sidewinder 7.0

        Username: jack
        Password:
        Connection closed by foreign host.

     

  3. Telnet through the firewall from the 192.168.9.0/24 network to serverB using the user jack. Jack should be allowed because he is a member of the auditors group.

        29 [user@server:user] telnet 192.168.4.16
        Trying 192.168.4.16...
        Connected to 192.168.4.16.
        Escape character is '^]'.

                                 Welcome to Sidewinder 7.0

        Username: jack
        Password:
        Red Hat Linux release 9 (Shrike)
        Kernel 2.4.20-8 on an i686
        login: user
        Password:
        Last login: Tue Nov 17 15:33:40 from name-26
        [user@serverB user]$ 

     

  4. Telnet through the firewall from the 192.168.9.0/24 network to serverB using the user don. Don should be allowed because he is a member of the developers group.

        30 [user@server:user] telnet 192.168.4.16
        Trying 192.168.4.16...
        Connected to 192.168.4.16.
        Escape character is '^]'.

                                 Welcome to Sidewinder 7.0

        Username: don
        Password:
        Red Hat Linux release 9 (Shrike)
        Kernel 2.4.20-8 on an i686
        login: user
        Password:
        Last login: Tue Nov 17 16:52:35 from server-2
        [user@serverB user]$ 

     

  5. Telnet through the firewall from the 192.168.9.0/24 network to serverA using the user mark. Mark should be allowed because he is a member of the testers group (and also happens to be a member of the auditors group).

        31 [user@server:user] telnet 192.168.4.24
        Trying 192.168.4.24...
        Connected to 192.168.4.24.
        Escape character is '^]'.

                                 Welcome to Sidewinder 7.0

        Username: mark
        Password:
        CentOS release 5.2 (Final)
        Kernel 2.6.18-92.el5 on an i686
        login: user
        Password:
        Last login: Tue Nov 17 16:48:11 from server-2
        ==                Welcome to serverA!              ==


    The tcpdump of the authentication request from the firewall to the RADIUS server for mark looks as follows:

        Frame 1 (98 bytes on wire, 98 bytes captured)
        Ethernet II, Src: 00:b0:d0:76:49:34, Dst: 00:01:03:25:3d:68
        Internet Protocol, Src Addr: 192.168.9.65 (192.168.9.65),
                           Dst Addr: 10.140.168.28 (10.140.168.28)
        User Datagram Protocol, Src Port: 40098 (40098), Dst Port: radius (1812)
        Radius Protocol
            Code: Access Request (1)
            Packet identifier: 0xf8 (248)
            Length: 56
            Authenticator: 0x76552E762C282E6D4B563E704B425C64
            Attribute value pairs
                t:User Name(1) l:6, Value:"mark"
                t:User Password(2) l:18, Value:3FD40A8E57728008437AC067264B5634
                t:NAS IP Address(4) l:6, Value:192.168.2.65
                t:NAS Port(5) l:6, Value:1

        0000  00 01 03 25 3d 68 00 b0 d0 76 49 34 08 00 45 00   ...%=h...vI4..E.
        0010  00 54 32 b6 00 00 3f 11 62 96 c0 a8 09 41 ac 1a   .T2...?.b....A..
        0020  70 49 9c a2 07 14 00 40 f1 51 01 f8 00 38 76 55   pI.....@.Q...8vU
        0030  2e 76 2c 28 2e 6d 4b 56 3e 70 4b 42 5c 64 01 06   .v,(.mKV>pKB\d..
        0040  6d 61 72 6b 02 12 3f d4 0a 8e 57 72 80 08 43 7a   mark..?...Wr..Cz
        0050  c0 67 26 4b 56 34 04 06 c0 a8 02 41 05 06 00 00   .g&KV4.....A....
        0060  00 01  
                                             ..


    In the response from the RADIUS server back to the firewall, you can see the RADIUS server using vendor ID 1573 type 2 to provide a string of groups of which mark is a member: 

        Frame 2 (92 bytes on wire, 92 bytes captured)
        Ethernet II, Src: 00:01:03:25:3d:68, Dst: 00:b0:d0:76:49:34
        Internet Protocol, Src Addr: 10.140.168.28 (10.140.168.28), Dst Addr: 192.168.9.65 (192.168.9.65)
        User Datagram Protocol, Src Port: radius (1812), Dst Port: 40098 (40098)
        Radius Protocol
            Code: Access Accept (2)
            Packet identifier: 0xf8 (248)
            Length: 50
            Authenticator: 0x6CA776892E02AB6D10F7943F2AB7DE01
            Attribute value pairs
                t:Framed IP Address(8) l:6, Value:172.16.3.34
                t:Vendor Specific(26) l:24, Vendor:Undefined(1573)
                    t:Unknown Type(2) l:18, Value:Unknown Value Type

        0000  00 b0 d0 76 49 34 00 01 03 25 3d 68 08 00 45 00   ...vI4...%=h..E.
        0010  00 4e 00 06 40 00 40 11 54 4c ac 1a 70 49 c0 a8   .N..@.@.TL..pI..
        0020  09 41 07 14 9c a2 00 3a e6 98 02 f8 00 32 6c a7   .A.....:.....2l.
        0030  76 89 2e 02 ab 6d 10 f7 94 3f 2a b7 de 01 08 06   v....m...?*.....
        0040  ac 10 03 22 1a 18 00 00 06 25 02 12 74 65 73 74   ...".....%..test
                          ^^          ^^ ^^ ^^    ^^
                          ||          || || ||    ++-- the string begins here with 0x74
                          ||          || || ++-- 2 is the type (attribute ID)
                          ||          ++-++-- 0x625 is 1573, vendor ID
                          ++-- 0x1a = 26 = vendor specific
        0050  65 72 73 2c 61 75 64 69 74 6f 72 73               ers,auditors

Rate this document

Did this article resolve your issue?

Please provide any comments below

Glossary of Technical Terms


Highlight Glossary Terms

Please take a moment to browse our Glossary of Technical Terms.
United States - English
© 2003-2013 McAfee, Inc.