Older versionVersion 2.2SolutionsHow to add support for different MS login formats on RADIUS authentication

How to add support for different MS login formats on RADIUS authentication

This article describes how to add support for different MS login formats in PhenixID Server.

The reader should have some basic knowledge about PhenixID Server.

System requirements

  • PhenixID Server installed.
  • A RADIUS login scenario configured

Overview

The instructions in this document will help you how to add support for different MS login formats in PhenixID Server.

In the example we will configure PhenixID Server to accept three different methods for login, sAMAccountName, UPN and DOMAIN\UserName.

Configuration

Please make sure that you have a recent copy of <PhenixID Server installationdirectory>/config/phenix-store.json before proceeding.

Login to the administration configuration interface via a web browser at https://<hostname_or_ip>:8443/config/ and then choose the tab Advanced.

Go to the section Pipes and find your uid_pwd_pipe. This pipe can be found on your RADIUS_AUTHENTICATOR under Authentication - Radius.

We will start by adding a few valves before the LDAPSearchValve:

{
      "name" : "ItemCreateValve",
      "config" : {
        "dest_id" : "ID2"
      }
    }, {
      "name" : "PropertyAddValve",
      "config" : {
        "name" : "usr",
        "value" : "{{request.User-Name}}"
      }
    }, {
      "name" : "PropertyReplaceRegexValve",
      "config" : {
        "source" : "usr",
        "regex" : "^(.*?\\\\)",
        "replacement" : ""
      }
    }

Now we need to set the LDAPSearchValves. We need two of them for this configuration. One will execute if we see an @ sign in the request. The other one is for sAMAccountName and DOMAIN\UserName.

    {
      "name" : "LDAPSearchValve",
      "config" : {
        "connection_ref" : "b402f4b4-fa93-4e58-82d1-a24a2a48a89c",
        "base_dn" : "DC=org,DC=local",
        "scope" : "SUB",
        "size_limit" : "0",
        "filter_template" : "userPrincipalName={{request.User-Name}}",
        "attributes" : "mobile",
        "exec_if_expr" : "request['User-Name'].contains('@')"
      }
    }, {
      "name" : "LDAPSearchValve",
      "config" : {
        "connection_ref" : "b402f4b4-fa93-4e58-82d1-a24a2a48a89c",
        "base_dn" : "DC=org,DC=local",
        "scope" : "SUB",
        "size_limit" : "0",
        "filter_template" : "samAccountName={{item.usr}}",
        "attributes" : "mobile",
        "skip_if_expr" : "request['username'].contains('@')"
      }
    }

A new ItemRemoveValve is added after the LDAPSearchValve.

    {
      "name" : "ItemRemoveValve",
      "config" : {
        "item_include_expr" : "item.id===('ID2')"
      }
    }

The rest of the uid_pwd_pipe should remain as is.

If SMS/SMTP/SMPP is used, nothing needs to be done on the validate_otp_pipe.

But if software or hardware tokens are used, please continue and add the configuration below for the validate_otp_pipe in question.

So this next part is ONLY required if software or hardware tokens are used.

And this part will have the same valves added, so before the LDAPSearchValve, add:

{
      "name" : "ItemCreateValve",
      "config" : {
        "dest_id" : "ID2"
      }
    }, {
      "name" : "PropertyAddValve",
      "config" : {
        "name" : "usr",
        "value" : "{{request.User-Name}}"
      }
    }, {
      "name" : "PropertyReplaceRegexValve",
      "config" : {
        "source" : "usr",
        "regex" : "^(.*?\\\\)",
        "replacement" : ""
      }
    }

And then the LDAPSearchValves:

{
      "name" : "LDAPSearchValve",
      "config" : {
        "connection_ref" : "b402f4b4-fa93-4e58-82d1-a24a2a48a89c",
        "base_dn" : "DC=org,DC=local",
        "scope" : "SUB",
        "size_limit" : "0",
        "filter_template" : "userPrincipalName={{request.User-Name}}",
        "attributes" : "sAMAccountName",
        "exec_if_expr" : "request['User-Name'].contains('@')"
      }
    }, {
      "name" : "LDAPSearchValve",
      "config" : {
        "connection_ref" : "b402f4b4-fa93-4e58-82d1-a24a2a48a89c",
        "base_dn" : "DC=org,DC=local",
        "scope" : "SUB",
        "size_limit" : "0",
        "filter_template" : "samAccountName={{item.usr}}",
        "attributes" : "sAMAccountName",
        "skip_if_expr" : "request['username'].contains('@')"
      }
    }

But now we retrive the value for sAMAccountName ("attributes" : "sAMAccountName").

The ItemRemoveValve is added after the LDAPSearchValve.

{
      "name" : "ItemRemoveValve",
      "config" : {
        "item_include_expr" : "item.id===('ID2')"
      }
    }

Last step is to change the TokenValidationValve according to this example:

{
      "name" : "TokenValidationValve",
      "config" : {
        "provided_otp_param_name" : "{{request.User-Password}}",
        "otp_length" : "6",
        "hotp_lookahead" : "20",
        "userid_param_name" : "{{item.sAMAccountName}}"
      }
    }

The configuration is now in place.

So test login using , sAMAccountName, UPN and DOMAIN/UserName.