Showing posts with label RADIUS. Show all posts
Showing posts with label RADIUS. Show all posts

Mikrotik RouterOS 7.x Wireless Dynamic VLAN Assignment - Working Configuration

Overview

This document provides the complete working configuration for dynamic VLAN assignment on Mikrotik RouterOS 7.x wireless access points using RADIUS authentication with EAP-TLS (certificate-based authentication).

Must Have RADIUS Attribute: RouterOS 7.x requires the Mikrotik-Wireless-VLANID RADIUS attribute for wireless dynamic VLAN assignment to work properly.

Authentication Method: EAP-TLS using client certificates with UPN (User Principal Name) in the Subject Alternative Name field.

Network Architecture: Mikrotik acts as a wireless access point only. DHCP services are provided by a remote server, not by the Mikrotik router.

X.509 Certificate User Identification

In modern PKI (Public Key Infrastructure) setups, X.509v3 certificates identify users through specific certificate fields that contain user identity information. The most common methods are:

Important Note: Using the Common Name (CN) or other X.500 subject fields for user identification is considered outdated and deprecated in modern PKI deployments. RFC 5280 and subsequent standards recommend using Subject Alternative Name (SAN) extensions for identity information.

Why CN is Deprecated: - Limited scope: CN can only contain a single identity value - Ambiguity: CN doesn’t specify the type of identity (user, host, service) - Security concerns: CN validation is less strict than SAN validation - Modern standards: RFC 5280, RFC 6125, and RFC 8399 mandate SAN usage - Browser deprecation: Modern browsers no longer trust CN for hostname validation

User Principal Name (UPN)

The User Principal Name (UPN) is the primary method for user identification in enterprise environments. It follows the format username@domain.com and is stored in the certificate’s Subject Alternative Name (SAN) extension.

Certificate Field Location:

Subject Alternative Name:
    otherName: 1.3.6.1.4.1.311.20.2.3 (UPN)
    Email: user@domain.com

Example UPN in Certificate:

X509v3 Subject Alternative Name:
    otherName: 1.3.6.1.4.1.311.20.2.3, SEQUENCE:UTF8String:userA@company.com

Email Address in Subject Alternative Name

Alternatively, user identification can be based on the email address field in the Subject Alternative Name extension.

Certificate Field Location:

Subject Alternative Name:
    Email: user@domain.com  ← Used for user identification

How RADIUS Uses Certificate Identity

During EAP-TLS authentication:

  1. Client presents certificate to the RADIUS server
  2. RADIUS extracts user identity from either:
    • UPN in the SAN extension (preferred)
    • Email address in the SAN extension (fallback)
  3. RADIUS maps the identity to VLAN assignment rules
  4. RADIUS returns VLAN attributes based on the user identity

Example RADIUS Processing:

Certificate UPN: userA@company.com
↓
RADIUS looks up userA@company.com in user database
↓
RADIUS finds VLAN assignment: VLAN 1812
↓
RADIUS returns: Tunnel-Private-Group-Id = 1812

Certificate Requirements for Dynamic VLAN Assignment

For proper dynamic VLAN assignment, client certificates must contain:

  1. Valid UPN or email address in the Subject Alternative Name extension
  2. Proper certificate chain trusted by the RADIUS server
  3. Valid certificate dates (not expired, not future-dated)
  4. Appropriate key usage (digital signature, key encipherment)

Comparison: Old vs Modern Certificate Identity

Old Approach (Deprecated):

Subject: CN=userA, OU=IT, O=Company, C=US
  • Uses Common Name (CN) from subject field
  • Limited to single identity value
  • No type specification
  • Not recommended for modern deployments

Modern Approach (Recommended):

Subject: CN=userA, OU=IT, O=Company, C=US
X509v3 Subject Alternative Name:
    otherName: 1.3.6.1.4.1.311.20.2.3, SEQUENCE:UTF8String:userA@company.com
    Email: userA@company.com
  • Uses Subject Alternative Name (SAN) extension
  • Supports multiple identity types
  • Clear type specification (UPN, email)
  • Compliant with modern PKI standards

Network Architecture Diagram

┌─────────────────────────────────────────────────────────┐
│                    CLIENT A PATH (VLAN 1812)            │
└─────────────────────────────────────────────────────────┘

┌─────────────┐
│  Client A   │
│(EAP-TLS)    │
│userA@...    │
└─────┬───────┘
      │ 802.11
      ▼
┌─────────────┐
│ Mikrotik AP │
│RouterOS 7.x │
│ ┌─────────┐ │ ← RADIUS assigns VLAN 1812
│ │ wlan1/2 │ │   based on userA@domain.com
│ └───┬─────┘ │
│ ┌───▼─────┐ │ ← VLAN filtering enabled
│ │ bridge  │ │   ingress-filtering=no
│ └───┬─────┘ │
└─────┼───────┘
      │ 802.1Q VLAN 1812
      ▼
┌─────────────┐
│  Upstream   │
│Switch/Router│
│(Trunk Port) │
└─────┬───────┘
      │ VLAN 1812
      ▼
┌─────────────┐
│ Remote DHCP │
│Server VLAN  │
│192.168.44.x │
└─────────────┘

┌─────────────────────────────────────────────────────────┐
│                    CLIENT B PATH (VLAN 2000)            │
└─────────────────────────────────────────────────────────┘

┌─────────────┐
│  Client B   │
│(EAP-TLS)    │
│userB@...    │
└─────┬───────┘
      │ 802.11
      ▼
┌─────────────┐
│ Mikrotik AP │
│RouterOS 7.x │
│ ┌─────────┐ │ ← RADIUS assigns VLAN 2000
│ │ wlan1/2 │ │   based on userB@domain.com
│ └───┬─────┘ │
│ ┌───▼─────┐ │ ← VLAN filtering enabled
│ │ bridge  │ │   ingress-filtering=no
│ └───┬─────┘ │
└─────┼───────┘
      │ 802.1Q VLAN 2000
      ▼
┌─────────────┐
│  Upstream   │
│Switch/Router│
│(Trunk Port) │
└─────┬───────┘
      │ VLAN 2000
      ▼
┌─────────────┐
│ Remote DHCP │
│Server VLAN  │
│192.168.55.x │
└─────────────┘

┌─────────────────────────────────────────────────────────┐
│                  SHARED INFRASTRUCTURE                  │
└─────────────────────────────────────────────────────────┘

                ┌─────────────┐
                │ FreeRADIUS  │
                │   Server    │
                │ ┌─────────┐ │ ← Processes certificate UPN
                │ │ EAP-TLS │ │   Returns VLAN attributes
                │ └─────────┘ │
                │ ┌─────────┐ │ ← Adds Mikrotik-Wireless-VLANID
                │ │Post-Auth│ │   attribute for RouterOS 7.x
                │ └─────────┘ │
                └─────────────┘

VLAN Assignment Flow

Client A (userA@domain.com):
1. Client A connects with EAP-TLS certificate
   └── Certificate contains UPN: userA@domain.com

2. Mikrotik sends RADIUS request to FreeRADIUS
   └── Includes certificate UPN: userA@domain.com

3. FreeRADIUS processes UPN and returns:
   └── Tunnel-Type = VLAN
   └── Tunnel-Medium-Type = IEEE-802  
   └── Tunnel-Private-Group-Id = 1812
   └── Mikrotik-Wireless-VLANID = 1812  ← REQUIRED for RouterOS 7.x

4. Mikrotik assigns Client A to VLAN 1812
   └── Client A traffic is tagged with VLAN 1812
   └── Sent to upstream switch via trunk port

5. Upstream switch routes VLAN 1812 traffic
   └── To remote DHCP server for VLAN 1812
   └── Client A gets IP from 192.168.44.x subnet

Client B (userB@domain.com):
1. Client B connects with EAP-TLS certificate
   └── Certificate contains UPN: userB@domain.com

2. Mikrotik sends RADIUS request to FreeRADIUS
   └── Includes certificate UPN: userB@domain.com

3. FreeRADIUS processes UPN and returns:
   └── Tunnel-Type = VLAN
   └── Tunnel-Medium-Type = IEEE-802  
   └── Tunnel-Private-Group-Id = 2000
   └── Mikrotik-Wireless-VLANID = 2000  ← REQUIRED for RouterOS 7.x

4. Mikrotik assigns Client B to VLAN 2000
   └── Client B traffic is tagged with VLAN 2000
   └── Sent to upstream switch via trunk port

5. Upstream switch routes VLAN 2000 traffic
   └── To remote DHCP server for VLAN 2000
   └── Client B gets IP from 192.168.55.x subnet

Prerequisites

  • RouterOS 7.x with classic wireless package (not wifiwave2)
  • FreeRADIUS server configured for EAP-TLS authentication
  • Client certificates properly configured and trusted by RADIUS server
  • RADIUS server must send Mikrotik-Wireless-VLANID attribute
  • Upstream switch/router with VLAN trunking configured
  • Remote DHCP server (not local to Mikrotik) configured for each VLAN subnet

Complete RouterOS Configuration

1. Bridge Configuration

/interface bridge
add admin-mac=AA:BB:CC:DD:EE:FF auto-mac=no comment=defconf name=bridge vlan-filtering=yes ingress-filtering=no

Critical Settings: - vlan-filtering=yes - Enables VLAN filtering - ingress-filtering=no - REQUIRED for dynamic VLAN assignment in RouterOS 7.x - frame-types=admit-all - Allows all frame types

2. VLAN Interfaces

/interface vlan
add interface=bridge name=vlan1812 vlan-id=1812
add interface=bridge name=vlan2000 vlan-id=2000

3. Wireless Security Profile

/interface wireless security-profiles
add authentication-types=wpa2-eap,wpa3-eap comment=EAP-RADIUS-SECURITY disabled=no encryption=tkip,gcmp,gcmp-256 name=EAP-RADIUS-SECURITY

4. Wireless Interfaces

/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-XX comment=wpa-enterprise-2GHz country=bulgaria disabled=no distance=indoors frequency=auto installation=outdoor mode=ap-bridge security-profile=EAP-RADIUS-SECURITY ssid=wpa-enterprise vlan-mode=use-tag wireless-protocol=802.11 wps-mode=disabled

set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=20/40/80mhz-XXXX comment=wpa-enterprise-5GHz country=bulgaria disabled=no distance=indoors frequency=auto installation=outdoor mode=ap-bridge security-profile=EAP-RADIUS-SECURITY ssid=wpa-enterprise vlan-mode=use-tag wireless-protocol=802.11 wps-mode=disabled

Critical Settings: - vlan-mode=use-tag - Enables dynamic VLAN assignment - security-profile=EAP-RADIUS-SECURITY - Uses EAP-RADIUS authentication

5. Bridge Ports

/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=wpa-enterprise-2GHz interface=wlan1
add bridge=bridge comment=wpa-enterprise-5GHz interface=wlan2
add bridge=bridge comment=ether1/upstream interface=ether1

6. Bridge VLAN Table

/interface bridge vlan
add bridge=bridge tagged=ether1,bridge,wlan1,wlan2 vlan-ids=1812
add bridge=bridge tagged=ether1,bridge,wlan1,wlan2 vlan-ids=2000

Critical Settings: - Wireless interfaces (wlan1, wlan2) must be tagged (not untagged) - All interfaces that need dynamic VLAN assignment must be in the tagged list

7. RADIUS Configuration

/radius
add address=192.168.0.254 comment=192.168.0.254 service=wireless

Critical Settings: - service=wireless - Required for wireless VLAN assignment - Ensure RADIUS secret matches on both sides

8. Bridge Port Settings (Automatic)

The bridge ports will automatically have these settings: - pvid=1 - Default VLAN ID - frame-types=admit-all - Allows all frame types - ingress-filtering=yes - Per-port ingress filtering

Verification Commands

1. Check Bridge Configuration

/interface bridge print detail

Expected Output:

name="bridge" vlan-filtering=yes ingress-filtering=no frame-types=admit-all

2. Check Bridge VLAN Table

/interface bridge vlan print

Expected Output:

#   BRIDGE  VLAN-IDS  CURRENT-TAGGED         CURRENT-UNTAGGED
1   bridge  1812      bridge,ether1,wlan1,wlan2
2   bridge  2000      bridge,ether1,wlan1,wlan2

3. Check Wireless Registration Table

/interface wireless registration-table print

Expected Output:

Columns: INTERFACE, MAC-ADDRESS, AP, SIGNAL-STRENGTH, TX-RATE, UPTIME
#  INTERFACE  MAC-ADDRESS        AP  SIGNAL-STRENGTH  TX-RATE  UPTIME
0  wlan1      9C:EF:D5:FB:DB:62  no  -27dBm@HT20-0    1Mbps    7s

Important: This command shows connected clients but does NOT display VLAN assignment information. The VLAN assignment happens transparently in the background. Do not expect to see a VLAN-ID column or VLAN information in this output - this is normal behavior for RouterOS 7.x.

4. Check RADIUS Configuration

/radius print

Expected Output:

# SERVICE   ADDRESS        SECRET
0 wireless  192.168.0.254  test123

5. Verify Dynamic VLAN Assignment

Important: The /interface wireless registration-table print command does NOT show VLAN information in RouterOS 7.x. This is normal behavior - do not expect to see VLAN-ID columns or VLAN assignment details in this output.

To verify dynamic VLAN assignment is working:

  1. Check client IP address - Client should get IP from the assigned VLAN subnet (provided by remote DHCP server)
  2. Check upstream switch/router - Verify traffic is tagged with correct VLAN
  3. Monitor FreeRADIUS logs - Confirm Mikrotik-Wireless-VLANID is being sent
  4. Test connectivity - Client should only reach resources in assigned VLAN

Troubleshooting

Issue: Client Gets IP from Wrong VLAN

Symptoms: Client connects successfully but gets IP from default VLAN instead of assigned VLAN.

Solution: Ensure RADIUS is sending Mikrotik-Wireless-VLANID attribute and check upstream switch port trunking configuration.

Issue: DHCP Server Not Responding

Symptoms: Client connects but cannot get an IP address.

Solution: Check upstream switch port trunking and remote DHCP server configuration for the assigned VLAN. Verify the remote DHCP server is listening on the correct VLAN and has available IP addresses.

Issue: Authentication Fails

Symptoms: Client cannot authenticate at all.

Solution: Check RADIUS server connectivity and EAP-TLS certificate configuration. Verify client certificates are valid and trusted by the RADIUS server.

Common Mistakes

  1. Missing ingress-filtering=no on bridge - Required for dynamic VLANs
  2. Wireless interfaces as untagged in bridge VLAN table - Must be tagged
  3. Missing Mikrotik-Wireless-VLANID in RADIUS reply - Required for RouterOS 7.x
  4. Wrong RADIUS service - Must be service=wireless
  5. Wrong vlan-mode - Must be vlan-mode=use-tag

RouterOS Version Compatibility

  • RouterOS 6.x: Works with standard RADIUS attributes only
  • RouterOS 7.x: Requires Mikrotik-Wireless-VLANID attribute
  • wifiwave2 package: Does not support dynamic VLAN assignment

Summary

The key to making wireless dynamic VLAN assignment work in RouterOS 7.x is:

  1. Correct bridge configuration with ingress-filtering=no
  2. Wireless interfaces as tagged in bridge VLAN table
  3. RADIUS sending Mikrotik-Wireless-VLANID attribute
  4. Proper wireless interface configuration with vlan-mode=use-tag

This configuration has been tested and verified to work with RouterOS 7.19.2 and FreeRADIUS with EAP-TLS authentication.

IMAP connector for FreeRADIUS to support EAP-TTLS authentication in Eduroam

Content:

  1. Introduction
  2. The code of the IMAP connector
  3. Configuring FreeRADIUS to use the IMAP connector
  4. SELinux issues
  5. Notes on the productivity

1. Introduction

In spite its amazing collection of drivers supporting a variety of authentication protocols, FreeRADIUS does not support (yet) verification of the user names and passwords against IMAP/IMAPS servers, especially when using EAP-TTLS method for authenticating the users. It is also true that in average the IMAP servers are slow authenticators, compared to those based on LDAP or Active Directory, which might explain the lack of interest among the developers to create an intrinsic IMAP authentication module and include it into the FreeRADIUS source code. Nevertheless, there are cases when one simply cannot obtain direct access to the authentication data base, and in that case the only possibility available is to authenticate the users of the RADIUS server against publicly available service, like IMAP.

But why the IMAP authentication is considered slow? The goal of the IMAP servers is to provide access to the user's e-mail storage. In that aspect they are more closer to the file serversm then to the dedicated authentication servers (like 389 Directory Server). In other words, the major aim of developing IMAP server code is not to handle fast authentication of intensive stream of authentication requests. But if the intensity of incoming authentication requests is not huge, and the IMAP server is not engaged into intensive operations for managing the mail box content, it might be possible to relay on that server to handle a moderate stream of authentication request, sent by one or more FreeRADIUS servers.

One might find on Internet some solutions connecting the FreeRADIUS authentication process to IMAP server indirectly, through Linux Pluggable Authentication Modules (PAM). That way the FreeRADIUS server deals with local (to the Linux system hosting the server) users. Once sent to the PAM, the authentication request is passed to a specific PAM library, configured to connect to the IMAP server. In turn, the library passes the user name and password combination to the IMAP server for a verification. That kind of authentication process seems clear and simple, but it turns the remote users into local to the Linux system running the RADIUS server. In certain cases that might open an exploitable hole in the system security.

Creating an external IMAP connector - an application or script that can be invoked by the FreeRADIUS server process on demand - seems a way more elegant and secure method for verifying the user name and password pairs against external IMAP servers. Especially, if the connector code is based on a set of software components, that can be installed and kept updated by using the Linux distribution package management system. One such set of software components is Python and its modules, because: (1) every modern Linux distribution have its own optimized and supported (via updates) Python packages, and (2) it is easy and simple to write a Python code that established and manages connections to IMAP servers, by means of intrinsic modules (like imaplib and ssl). The connector (regardless the programming language) need to receive at least the user name and password, as invoking parameters, and return back an exit status value (return value) on completion. If that value is zero, the FreeRADIUS sever process considers the user credentials verified.

Given bellow is a simple Python script, behaving as IMAP connector.

2. The code of the IMAP connector

Provided bellow is a Python 3 code, based on the modules imaplib, sys, and ssl, all intrinsic to the Python distribution included in CentOS distribution (check if the Python package in your distribution does not include imaplib, which is unlikely):

#!/usr/bin/env python3

import imaplib
import ssl
import sys

if len(sys.argv) == 3:

    hostname = 'imap.example.com'

    context = ssl.SSLContext(ssl.PROTOCOL_SSLv23)

    context.options |= ssl.OP_NO_SSLv2
    context.options |= ssl.OP_NO_SSLv3

    context.set_ciphers('EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:' + \
                        'EECDH+ECDSA+SHA512:EECDH+ECDSA+SHA384:' + \
                        'EECDH+ECDSA+SHA256:ECDH+AESGCM:ECDH+AES256:' + \
                        'DH+AESGCM:DH+AES256:RSA+AESGCM:!aNULL:' + \
                        '!eNULL:!LOW:!RC4:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS')

    context.verify_mode = ssl.CERT_REQUIRED
    context.check_hostname = True
    context.load_verify_locations("/etc/pki/tls/certs/ca-bundle.crt")

    try:
        imap_obj =  imaplib.IMAP4_SSL(hostname, 993, ssl_context = context)
    except:
        sys.exit(1)

    try:
        status = imap_obj.login(sys.argv[1], sys.argv[2])
    except:
        sys.exit(1)

The code establishes a SSL session (using TLSv1.2 protocol) to the IMAP server with host name imap.example.com (change it to that of your IMAP server), and thus checks the user credentials (the user name is assigned to sys.argv[1], the password is the value of sys.argv[2]). One might edit the list of ciphers in context.set_ciphers, if that is necessary, following the OpenSSL syntax for selecting ciphers.

If IP address is required instead of fully qualified host name (not recommended), the value of context.check_hostname have to be set False.

The file /etc/pki/tls/certs/ca-bundle.crt is the standard bundle file containing copies of the most used and trusted CA certificates (it is maintained by the vendor of the Linux distribution). That file is part of the package ca-certificates, installed by default in CentOS 7. That file might have different name and path in other distribution. Note, that if the X.509 certificate of the IMAP server is signed by some local certificate authority, whose CA certificate is not included in the list of CA certificates provided by the vendor of the Linux distribution, that particular CA certificate can be stored in a file alone. Then the file path and name should be declared an argument of context.load_verify_locations.

3. Configuring FreeRADIUS to use the IMAP connector

Before starting, do save the script given above as /var/lib/radiusd/login_imap.py.

To terminate the TLS tunnel, decrypt its content, and authenticate the users with realm (domain) "wifi.example.com" locally, the following configuration should be included to the file /etc/raddb/proxy.conf:

realm "wifi.example.com" {
   type = radius
   authhost = LOCAL
   accthost = LOCAL
}

To set PAP as default authentication protocol (after executing the EAP part of the authentication process), create the following entry inside the file /etc/raddb/users:

DEFAULT  Auth-Type = PAP

Then open the file /etc/raddb/modules/pap and add there the configuration section:

exec papauth {
     wait = yes
     program = "/var/lib/radiusd/login_imap.py '%{Stripped-User-Name}' '%{User-Password}'"
     input_pairs = request
     output_pairs = config
     }

If the IMAP server accepts e-mail addresses as user names, replace there %{Stripped-User-Name} with %{User-Name}.

Finally, open the file /etc/raddb/sites-available/inner-tunnel, go to the authenticate section there and change the declaration:

        Auth-Type PAP {
                pap
        }

into:

        Auth-Type PAP {
                papauth
        }

Why does the script check the number of elements in sys.argv list? It is because radiusd invokes the script twice for every single user authentication and therefore some polymorphic code is required to treat each call differently. The first time, the script is invoked, is right after the TLS tunnel is established. In this case the goal is to check the real user name and password against the specified IMAP server. If radiusd is running in debug mode (as radiusd -X), the following messages, related to the first call, will appear:

# Executing group from file /etc/raddb/sites-enabled/inner-tunnel
+group PAP {
[papauth]  expand: %{Stripped-User-Name} -> username
[papauth]  expand: %{User-Password} -> userpassword

Note that only two actual parameters are passed to the script by radiusd. Nevertheless, the result is the Python list sys.argv that contains three elements. The first element (sys.argv[0]) is the path to the script file, known to the radiusd (following the configuration above that should be /var/lib/radiusd/login_imap.py), and its value is assigned implicitly by the Python interpreter, the second one (sys.argv[1]) is the value of %{Stripped-User-Name}, and the third element (sys.argv[2]) is the password (that is the value of %{User-Password}). Therefore, sys.argv of this length will trigger the execution of the IMAP authentication section in the Python code. Otherwise, the script will return exit status 0 regardless the number of elements in sys.argv. The last is used to complete the authentication when radiusd is following the instructions found in the post-auth section located inside /etc/raddb/sites-enabled/default. In debug mode (radiusd) the following sequence of messages, related to the post-auth instructions, will be displayed on the screen:

# Executing section post-auth from file /etc/raddb/sites-enabled/default
+group post-auth {
[exec]  expand: %{Stripped-User-Name} -> anonymous
[exec]  expand: %{User-Password} ->
[exec]  expand: %{Calling-Station-Id} -> 02-00-00-00-00-01
[exec]  expand: %{NAS-IP-Address} -> 127.0.0.1
[exec]  expand: %{Framed-Protocol} ->

From those messages, it becomes clear that during that second execution of the script, the number of input parameters to the script is greater than two (unless there is some specific FreeRADIUS configuration, that reduces that number down to two). Therefore, the Python interpreter will not execute the IMAP authentication section in the script and will send back to radiusd an exit status 0.

4. SELinux issues

The radiusd expects the SELinux context of the IMAP connector script /var/lib/radiusd/login_imap.py to be the one of radiusd_t. That kind of context cannot be assigned by using chcon (at the present) and therefore radiusd cannot invoke the script. The only way to solve this issue is to create a specific SELinux module and install it. Srart radiusd and try to authenticate an user (if SELinux is enforced the authentication will fail). Then find the following type of entries in /var/log/audit/audit.log:

type=AVC msg=audit(1536040511.292:21627): avc:  denied  { execute } for  pid=29569 comm="radiusd" name="login_imap.py" dev=sda3 ino=132112 scontext=unconfined_u:system_r:radiusd_t:s0 tcontext=unconfined_u:object_r:radiusd_var_lib_t:s0 tclass=file
type=AVC msg=audit(1536040931.979:21649): avc:  denied  { execute_no_trans } for  pid=29739 comm="radiusd" path="/var/lib/radiusd/login_imap.py" dev=sda3 ino=132112 scontext=unconfined_u:system_r:radiusd_t:s0 tcontext=unconfined_u:object_r:radiusd_var_lib_t:s0 tclass=file
type=AVC msg=audit(1536041114.006:21653): avc:  denied  { name_connect } for  pid=29802 comm="python" dest=143 scontext=unconfined_u:system_r:radiusd_t:s0 tcontext=system_u:object_r:pop_port_t:s0 tclass=tcp_socket

and save them in a file (the file name myradius.avc is adopted in the example bellow). Finally, generate and then install the custom SELinux module:

# audit2allow -a -M myradius < myradius.avc
# semodule -i myradius.pp

5. Notes on the productivity

Establishing and supporting high number of simultaneous IMAP over SSL sessions, might bring a significant latency to the authentication process. One possible way to reduce the latency is to adopt an external SSL wrapper (like stunnel) to connect the radius server host to the IMAP server, and use a modification of the connector script, based on plain IMAP sessions to localhost:

#!/usr/bin/env python3

import imaplib
import sys

if len(sys.argv) == 3:

    hostname = 'localhost'

    try:
        imap_obj = imaplib.IMAP4(hostname)
    except:
        sys.exit(1)

    try:
        status = imap_obj.login(sys.argv[1], sys.argv[2])
    except:
        sys.exit(1)

Creative Commons - Attribution 2.5 Generic. Powered by Blogger.

Implementing LUKS Encryption on Software RAID Arrays with LVM2 Management

A comprehensive guide to partition-level encryption for maximum security ...

Search This Blog

Translate