Section 3.51. <AuthBy ADSI>

3.51. <AuthBy ADSI>

<AuthBy ADSI> authenticates from Windows Active Directory, which is the user information database on Windows 2000 and later servers. It uses ADSI (Active Directory Service Interface) to get user information from any Active Directory service provider available to your Windows server. It is only available on Windows 2000 and later server platforms. It is implemented in AuthADSI.pm.

ADSI is a unified interface to Windows user information that was introduced in Windows 2000. Active Directory can access user information from a range of provider types:

NT Primary or Secondary domain controller (WinNT:)
Active Directory LDAP database (LDAP:)
Novell Directory Services (NDS:)

You can configure AuthBy ADSI to use any of these service providers.

For more information, see Active Directory Service Interfaces website

During authentication, <AuthBy ADSI> check and honours AccountDisabled, IsAccount-Locked and LoginHours for the user being authenticated. It also checks the users password (by attempting to change it). Because Active Directory does not make the plaintext password available, <AuthBy ADSI> only supports PAP, not CHAP or MSCHAP authentication.

<AuthBy ADSI> understands also the same parameters as <AuthBy xxxxxx>. For more information, see Section 3.32. <AuthBy xxxxxx>.

3.51.1. BindString

BindString is the string that defines what ADSI object will be bound in order to get user details. You can bind to any Active Directory provider supported on your Radiator host, but WinNT or LDAP will be the usual choices. BindString must specify which provider to use and how to match the user. Use %0 to specify the user name to match.

WinNT means to use an NT 4.0 primary or backup domain controller, e.g. WinNT:MyDomain/%0,User means to match Users in the Windows NT domain called MyDomain. If the domain is omitted, the “best” domain controller in the default domain will be used.

Other acceptable variants are:

BindString WinNT://%0,User
BindString WinNT://domain/%0,User
BindString WinNT://domain/controller/%0,User

LDAP means to use an LDAP server, including Microsoft Exchange and Windows 2000 Active Directory e.g. LDAP://ldapsvr/cn=%n,cn=Users,dc=yourdomain, dc=com means to match a user with the given common name (cn), in the AD domain yourdomain.com. If ldapsvr is omitted, the default AD server will be used.

Other acceptable variants are:

BindString LDAP://cn=%0.......
BindString LDAP://controller/cn=%0.......
BindString LDAP://msexchangeserver.bigco.com/cn=%0.......
BindString LDAP://msexchangeserver:390/cn=%0.......

NDS means use Novell Directory Services. e.g. NDS://MarsTree/O=MARS/OU=MARTIANS/CN=%0

The default is WinNT://%0,User which means a user with the given user name in the default domain

# Get users from the OSC domain in NT
BindString WinNT://OSC/%0,User
# Get user details from the Users folder in Active Directory
# for the AD domain open.com.au
BindString LDAP://cn=%0,cn=Users,dc=open,dc=com,dc=au

3.51.2. AuthUser

This parameter defines how to construct the Active Directory user name to be authenticated by Active Directory. You can choose whether to use standard NTLM user names or AD Distinguished Names. This is a different concept to BindString, which specifies what AD object to get account details from.

The default is %0, which will try to authenticate the user name sent by the NAS (after RewriteUsernames have been applied).

This example will authenticate the user from an AD user record in the ‘csx users’ Organizational Unit, and get account details from the same AD record. Unlike NTLM user names, it will even work for user names with spaces in them. Note that you need to specify AuthFlags of 0 in order to use an Active Directory DN in AuthUser.

BindString LDAP://cn=%0,ou=csx users,dc=open,dc=com,dc=au
AuthUser cn=%0,ou=csx users,dc=open,dc=com,dc=au
AuthFlags 0

3.51.3. AuthFlags

This optional parameter specifies flags to be passed to OpenDSObject. The default is 1, which means NTLM secure authentication. For more information, see AuthFlags website

. You need to specify 0 to use an Active Directory DN in AuthUser.

3.51.4. AuthAttrDef

This optional parameter allows you to use additional ADSI user information as RADIUS check or reply items. This is most useful when you define new user attributes in your Active Directory schema. It is beyond the scope of this document to describe how to add new attributes to an Active Directory schema.

The general format is

AuthAttrDef adsiname,radiusattr,type

adsiname is the name of an attribute in your Active Directory User schema. The value of that attribute will be fetched using ADSI during authentication.
radiusattr is the name of the RADIUS attribute that the adsiname will be converted to. check or reply item. The special radiusattr ‘GENERIC’ indicates that it is a list of comma separated attribute=value pairs, similar to ReplyAttr or CheckAttr.
type specifies whether to use the value as a check or reply item. type may be check, reply or request. If type is “request” the value is saved in the current request, from where it can be later collected with a special formatting macro like: %{attributename}.

For example,

AuthAttrDef address,Framed-IP-Address,reply

would get an attribute called ’address’ from the ADSI user record, and put it into Framed-IP-Address attribute in the RADIUS reply. If address was not defined in your schema, or there was no value defined for the user being authenticated, then Framed-IPAddress would not be set in the reply.

Multi-valued AD attributes can be used as check items, which results in Radiator passing the authentication if one of the multiple items matches. For example if you have this in your AuthBy ADSI:

AuthAttrDef otherHomePhone,Calling-Station-Id,check

and multiple entries in Home, ‘Other....’ tab of the Telephones tab. Then Radiator will let the user log in if they call from any one of the Other Home Phone numbers.

3.51.5. GroupBindString

This optional parameter is used to generate an ADSI group identifier when checking group membership through a Group= check item. Defaults to ‘WinNT://%0,Group’ (i.e. the named group in the default domain). Special characters can be used, and %0 is replaced with the name of the group being checked, and %1 with the name of the user whose group membership is being checked.

3.51.6. GroupUserBindString

This optional parameter is used to generate an ADSI user name identifier when checking group membership through a Group= check item. Defaults to ‘WinNT://%1’ (i.e. the named user). Special characters can be used, and %0 is replaced with the name of the group being checked, and %1 with the name of the user whose group membership is being checked.

This example checks whether an NT user in the OSC domain is in an NT Group in the OSC domain:

GroupBindString WinNT://OSC/%0,Group
GroupUserBindString WinNT://OSC/%1

This example checks whether the active directory user identified by GroupUserBindString is in the group defined by GroupBindString.

GroupBindString LDAP://cn=%0,dc=open,dc=com,dc=au
GroupUserBindString LDAP://cn=%1,cn=Users,dc=open,dc=com,dc=au

Tip

With AD, do not confuse Organizational Unit with group membership. They are different ideas. A user can be in one OU, but be a member of multiple groups. Use GroupBindString, GroupUserBindString and the Group= check item to check for AD group members.

3.51.7. CheckGroupServer

This optional parameter, in conjunction with CheckGroup, allows you to set a Class reply attribute that depends on which NT group the user is a member of. CheckGroupServer is the name of an NT domain controller that contains group information.

<AuthBy ADSI>
      CheckGroupServer brbaaa01
      CheckGroup USVPN,ou=tcgic
      CheckGroup UKVPN,ou=tcgic
      ....
</AuthBy>

3.51.8. CheckGroup

This optional parameter, in conjunction with CheckGroupServer, allows you to set a Class reply attribute that depends on which NT group the user is a member of. Recall that if you set the Class in an access reply, then subsequent accounting requests sent by the NAS for that session will contain exactly the same Class attribute. This is useful for remembering which accounting group or rate to charge the user.

CheckGroup is a comma-separated pair of names. The first is an NT group name, the second is an arbitrary string. During authentication, if the user is a member of the NT group, then the Class attribute in the reply will be set to the arbitrary string. The first match found will be used.

For example:

<AuthBy ADSI>
      CheckGroupServer romeo
      CheckGroup USVPN,premium
      CheckGroup UKVPN,standard
      ....
</AuthBy>

In this example, if a user is a member of the NT group USVPN, then the reply will contain Class=premium. If they are in UKVPN group, then the reply will contain Class=standard. If they are in neither group, then no Class will be set in the reply.