ASA. Configuring Intercept Authentication via AD and LDAP
According to the advice of respected harakchiteli I change the format of my publications on ASA. I will write here the most interesting, not tiring detailed description. Complete article “ASA. Interception Authentication "read our newly baked blog
And here I will tell how using ASA, directly authenticate to AD
ITU often has the task of verifying the user before giving him access to certain resources. On the ASA, this check is called “intercept authentication” (cut-through proxy).
')
This service uses the AAA infrastructure (Authentication, Authorization, Accounting).
Note: in the English word authentication there is no syllable “phi”, which appeared in Russian “authentication” most likely because of the consonance with the word “identification”. Moreover, in our mighty language there is also “authenticity”. Without any "fi" :) Do not get caught!
Authentication.
Answers the question "is there such a user." The search for this user can be performed both in the local (LOCAL) database and in the external (TACACS +, RADIUS, AD via LDAP).
Setting up an LDAP server implies specifying a user account from AD with which the ASA will log in to LDAP, server type, search root, etc.
Example:
Once the servers are configured, it's time to determine what kind of traffic is interesting for us to check and not to pass without authentication. The ASA is responsible for this ... of course, the access list, where lines of permit indicate such traffic. The access list itself for authentication is used by the command
This will check packets arriving at the input of the specified interface.
For example, we want to check all traffic from the local network 10.1.1.0/24 (behind the inside interface) going to all networks except 172.16.1.0/24:
But how to ask the user his username / password? After all, can not any ping initiate a request?
Intercept the session and ask the username and password of the ASA can http / https, ftp, telnet. If you need to authenticate other traffic, then you need to make 2 movements: go somewhere behind the ASA using one of the specified protocols, enter your login / password either in the browser or in telnet or in the ftp window. It should be borne in mind that such traffic must be indicated in the access list for interesting traffic.
For example, we want the user to be able to go via telnet or http to host 1.1.1.1 and be asked for a username and password. Then this traffic must be included in the access list. This is not suitable, because via telnet will not work:
If the data is correct, the ASA will pass your traffic. But only for the specified time. By default, timeouts, let's say, strange: 5 minutes of absolute time, inactivity timeout is not monitored. Change them not only possible, but necessary:
Example:
Thus, with authentication, everything is simple: if you do not specify anything else, then the user, or rather, the ip-address of his computer, everything will be possible.
A much more interesting point is authorization , that is, restriction of user rights.
For LDAP authorization, we need a “crutch” - a special construct that matches the LDAP attribute with the RADIUS attribute that the ASA understands. This design is called
Example. Let us match the attribute IETF-Radius-Filter-Id (access list) to the base ipPhone AD attribute. And we describe that if in the specified attribute we get the word "BUHG", then the user will use the access list BUH, which is already written on the ASA:
Important: if in the specified attribute we received nothing, we ignore it, and if we receive a word that is not described in the values ​​for this attribute, then access will be denied. Thus, an AD administrator can affect access rights. For example, it can block the Internet for an undesirable user without touching the ASA :)
It remains only to apply this attribute list to a specific LDAP server.
Example:
Enjoy your authorization, dear hawreaders, ciscolab :)
Threat I myself: "On normal OS, this is done by half of the team" :) So we will help the admins of the "abnormal" :)
And here I will tell how using ASA, directly authenticate to AD
ITU often has the task of verifying the user before giving him access to certain resources. On the ASA, this check is called “intercept authentication” (cut-through proxy).
')
This service uses the AAA infrastructure (Authentication, Authorization, Accounting).
Note: in the English word authentication there is no syllable “phi”, which appeared in Russian “authentication” most likely because of the consonance with the word “identification”. Moreover, in our mighty language there is also “authenticity”. Without any "fi" :) Do not get caught!
Authentication.
Answers the question "is there such a user." The search for this user can be performed both in the local (LOCAL) database and in the external (TACACS +, RADIUS, AD via LDAP).
Setting up an LDAP server implies specifying a user account from AD with which the ASA will log in to LDAP, server type, search root, etc.
aaa-server {SERVERNAME} protocol ldap
aaa-server {SERVERNAME} ({interface}) host {IP_SERVER}
ldap-base-dn { }
ldap-scope {subtree|onelevel}
ldap-naming-attribute { }
ldap-login-dn { ASA}
ldap-login-password { ASA}
server-type {Microsoft|Novell|OpenLDAP|sun|auto}
Example:
aaa-server AD (dmz) host 172.16.1.100
ldap-base-dn ou=Employers, dc=anticisco, dc=ru
ldap-scope subtree
ldap-naming-attribute sAMAccountName
ldap-login-dn cn=ASA, cn=users, dc=anticisco, dc=ru
ldap-login-password ASALDAPPASS
server-type microsoft
Once the servers are configured, it's time to determine what kind of traffic is interesting for us to check and not to pass without authentication. The ASA is responsible for this ... of course, the access list, where lines of permit indicate such traffic. The access list itself for authentication is used by the command
aaa authentication match {AUTHACL} {interface} {SERVERNAME}This will check packets arriving at the input of the specified interface.
For example, we want to check all traffic from the local network 10.1.1.0/24 (behind the inside interface) going to all networks except 172.16.1.0/24:
access-list AUTH deny ip 10.1.1.0 255.255.255.0 172.16.1.0 255.255.255.0
access-list AUTH permit ip 10.1.1.0 255.255.255.0 any
aaa authentication match AUTH inside RAD
But how to ask the user his username / password? After all, can not any ping initiate a request?
Intercept the session and ask the username and password of the ASA can http / https, ftp, telnet. If you need to authenticate other traffic, then you need to make 2 movements: go somewhere behind the ASA using one of the specified protocols, enter your login / password either in the browser or in telnet or in the ftp window. It should be borne in mind that such traffic must be indicated in the access list for interesting traffic.
For example, we want the user to be able to go via telnet or http to host 1.1.1.1 and be asked for a username and password. Then this traffic must be included in the access list. This is not suitable, because via telnet will not work:
access-list AUTH permit tcp any any eq 80
access-list AUTH permit udp any any
If the data is correct, the ASA will pass your traffic. But only for the specified time. By default, timeouts, let's say, strange: 5 minutes of absolute time, inactivity timeout is not monitored. Change them not only possible, but necessary:
timeout uauth {HH:MM:SS} {absolute|inactivity}
Example:
timeout uauth 0:15:0 inactivity
timeout uauth 20:00:00 absolute
Thus, with authentication, everything is simple: if you do not specify anything else, then the user, or rather, the ip-address of his computer, everything will be possible.
A much more interesting point is authorization , that is, restriction of user rights.
For LDAP authorization, we need a “crutch” - a special construct that matches the LDAP attribute with the RADIUS attribute that the ASA understands. This design is called
ldap attribute-map {MAPNAME}
map-name {LDAPATTRIBUTE} {RADUISATTRIBUTE}
map-value {LDAPATTRIBUTE} {SENDNAME} {TRANSLATENAME}
Example. Let us match the attribute IETF-Radius-Filter-Id (access list) to the base ipPhone AD attribute. And we describe that if in the specified attribute we get the word "BUHG", then the user will use the access list BUH, which is already written on the ASA:
ldap attribute-map AD
map-name ipPhone IETF-Radius-Filter-Id
map-value ipPhone BUHG BUH
Important: if in the specified attribute we received nothing, we ignore it, and if we receive a word that is not described in the values ​​for this attribute, then access will be denied. Thus, an AD administrator can affect access rights. For example, it can block the Internet for an undesirable user without touching the ASA :)
It remains only to apply this attribute list to a specific LDAP server.
aaa-server {SERVERNAME} ({interface}) host {IP_SERVER}
ldap-attribute-map {MAPNAME}
Example:
aaa-server AD (dmz) host 172.16.1.100
ldap-attribute-map AD
Enjoy your authorization, dear hawreaders, ciscolab :)
Threat I myself: "On normal OS, this is done by half of the team" :) So we will help the admins of the "abnormal" :)
Source: https://habr.com/ru/post/85104/
All Articles