TACACS+ and ISE:2.x Recommended Configuration :-

on Sunday, October 21 21 October , in , 1 Comment

TACACS+ and ISE:2.x Recommended Configuration :-
Layer-3 and Layer-2 switches: -
Define TACACS SERVER: -
aaa group server tacacs+ ISE-GROUP

 server-private <primary ISE server> key <plain key>
 server-private <secondary ISE Server> key <plain key>


AAA Login Commands: -
aaa new-model
aaa authentication login ISEauth group ISE-GROUP local

aaa authorization exec ISEauth group ISE-GROUP local if-authenticated

line vty 0 15
 login authentication ISEauth
 authorization exec ISEauth


AAA Command Authorization Config: -
you can monitor and restrict the commands that have been issued in the Switch.
aaa authorization commands 1 default group ISE-GROUP local if-authenticated
aaa authorization commands 15 default group ISE-GROUP local if-authenticated
aaa authorization config-commands
Login Accounting Logs sent to ISE server: -
"Exec accounting” will capture details about user accessing the shell prompt where you run all the commands & “command accounting” keep track of what commands users execute on a Cisco device.
aaa accounting exec default start-stop group ISE-GROUP
aaa accounting commands 1 default start-stop group ISE-GROUP
aaa accounting commands 15 default start-stop group ISE-GROUP





ASA Firewall Configuration: -
Define TACACS SERVER: -
·        max-failed-attempts: - To specify the maximum number of failures that will be allowed for any server in the group before that server is deactivated. The default value is three.
·        reactivation-mode: -There are two different AAA server reactivation modes in ASA:
timed mode and depletion mode. The command below is the timed mode.
1.      With the timed mode, it reactivates a failed server after 30 seconds of downtime. In my limited testing, it continuously tried to reactivate the server after 30 seconds when I bring the TACACS+ server down.
2.      With the depletion mode shown below, the failed TACACS+ server will stay down until all servers in the group are in the failed state. The default deadtime is 10 minutes.
                                                           
aaa-server TACACS protocol tacacs+
 aaa-server TACACS+ max-failed-attempts 3
 reactivation-mode timed
aaa-server TACACS (inside) host <primary ISE server>
 timeout 5
 key *****
aaa-server TACACS (inside) host <secondary ISE server>
 timeout 5
 key *****
AAA Login Commands: -
aaa authentication http console TACACS LOCAL
aaa authentication ssh console TACACS LOCAL
aaa authentication enable console TACACS LOCAL
aaa authentication telnet console TACACS LOCAL
aaa authentication serial console TACACS LOCAL
aaa authorization exec authentication-server




AAA Command Authorization Config: -
 you can monitor and restrict the commands that have been issued in the ASA.
aaa authorization command TACACS LOCAL
Login Accounting Logs sent to ISE server: -
aaa accounting telnet console TACACS
aaa accounting ssh console TACACS
aaa accounting command privilege 15 TACACS




ISE 2.x configuration:-

NOTE:- you need device admin License to configure tacacs+ in ISE2.x version and above.

Step1:- configure Shell profiles  having privilege 15 access


Step2:-
Configure READ WRITE command authorization or Command Sets



Step3:- 
Configure READ-ONLY access, by unchecking permit any commands and configure only specific commands, you can either permit or deny these specific commands as shown below



If you have any queries please comment below

Transparent Proxy vs Explicit mode Proxy

21 October , in , 7 Comments


Transparent Proxy vs Explicit mode Proxy 

 Explicit Mode Proxy :-
• Client requests a website
• Browser connects first to WSA
• WSA connects to website
• Firewall usually only allows web traffic for WSA
• DNS Resolution is done by WSA



Disadvantages of explicit proxy deployment includes Following: -
• A user's ability to alter an individual client configuration and bypass the proxy. To counter this, you can configure the firewall to allow client traffic to proceed only through the proxy. Note that this type of firewall blocking may result in some applications not working properly.
     (Example: - IKEAHOME etc...)
• To bypass any URL, every time you need to use a Group Policy object (GPO) setting to push the proxy exceptions as well as prevent users from changing proxy settings. This type of configuration can be difficult to maintain for a large user base because of the lack of centralized management.
• Few Non-browser client applications that cannot specify a proxy server may not work with explicit proxy deployment.
• Very important is HTTPS scanning is not enabled in this mode. This is a big security impact as WSA is not scanning/inspecting HTTPS traffic. User can easily download a Malicious or a Virus file on port 443 without being inspected by WSA.


Transparent Mode Proxy :-

Transparent Proxy works via WCCP (Web Cache Coordination
Protocol) on Cisco ASA. Wherein WCCP is a method by which the ASA
can redirect traffic to a WCCP caching engine through a generic
routing encapsulation (GRE) tunnel.

The flow of work for redirection has these steps:

• The host uses the default gateway of the ASA to open the HTTP connection.
• The ASA redirects the packet (encapsulated in GRE) to the WSA.
• The WSA verifies or updates the cache for the requested site.
• The WSA replies directly to the host.
• All outbound packets from the host are redirected from the ASA to the WSA.
• All inbound packets from the server to the host are directed from the WSA to the host.



• Client requests a website
• Browser tries to connect to Website
• ASA-Firewall redirects traffic to WSA using WCCP
• WSA proxies the request
• DNS Resolution is done by the Client


Advantages of Transparent proxy deployment includes Following: -
• All Internet traffic from a client goes through the proxy (not just traffic from Web browsers), including: HTTP and HTTPS applications, instant messaging clients, software updaters for Windows, Custom applications, etc.…

• Because traffic management is centralized, users cannot easily bypass the proxy.

• Can Bypass Proxy for any traffic based on Destination subnet or IP address on Firewall itself. If there are any URL's this can be bypassed on WSA.

• Enabling transparent proxy will also enable HTTPS scanning which inspects HTTPS port 443 traffic and will Block any Malicious or virus file if being accessed by User.


Configuration:-

• ASA allows only “redirect in “
  (a)Client’s and WSA must be on Inside interface of ASA
  (b)No DMZ Deployment possible.
• Inside ACL is checked before WCCP redirection
  (a)Destination Server must be allowed in ACL
• Redirection Method is GRE based
• Redirect ACL allows permit and deny


WCCP Config in ASA Firewall: -

(Service=90-97 is user configurable that support up to eight ports for each WCCP service.)

#wccp 90 redirect-list wccp_traffic group-list wccp-server
#wccp interface inside 90 redirect in


#access-list wccp_traffic extended permit tcp <LAN subnets> any eq www
#access-list wccp_traffic extended permit tcp <LAN subnets> any eq https
#access-list wccp_traffic extended deny ip any any

#access-list wccp-server extended permit ip host <WSA DATA PORT IP> any

#access-list acl-in extended permit tcp <LAN subnets> any eq www
#access-list acl-in extended permit tcp <LAN subnets> any eq https


WSA Config:-
Step1: -
 Configure Transparent Redirection in WSA on port 80 and 443



Step2: -
 Configure Web Proxy on port 80 for Transparent Proxy Mode.


Step3:-
 Configure HTTPS Proxy on port 443 for Transparent Proxy Mode.
Generate a CSR and sign it with Internal Root CA. Make sure this Root CA is pushed to all Client PC's through GPO etc..

If you need transparent proxym HTTPS proxy needs to be enabled. and make sure there is Decryption policy enabled for the same.

Verification:-

Router identifier is always selects Highest IP address. here my DMZ has 192.168.243.14 which is selected as router id.

ASA/pri/act# sh wccp 90

 Global WCCP information:
    Router information:
        Router Identifier:                   192.168.243.14
        Protocol Version:                    2.0

     Service Identifier: 90
        Number of Cache Engines:             1
        Number of routers:                   1
        Total Packets Redirected:            687937782
        Redirect access-list:                wccp_traffic
        Total Connections Denied Redirect:   4544924
        Total Packets Unassigned:            24
        Group access-list:                   wccp-server
        Total Messages Denied to Group:      0
        Total Authentication failures:       0
        Total Bypassed Packets Received:     0

 Web Cache ID is always Firewall Inteface IP where the WSA is connected to.
ASA/pri/act# sh wccp 90 detail

 WCCP Cache-Engine information:
        Web Cache ID:          10.101.21.194
        Protocol Version:      2.0
        State:                 Usable
        Initial Hash Info:     00000000000000000000000000000000
                               00000000000000000000000000000000
        Assigned Hash Info:    FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
                               FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
        Hash Allotment:        256 (100.00%)
        Packets Redirected:    687937833
        Connect Time:          15w3d



Authentication server type: - 
Currently we are using NTLMSSP or Basic Authentication
NTLMSSP: - enables the functionality for the client to send the credentials securely and transparently(SSO) to the web proxy.

NTLM Basic: - allows the client to send the username and password in plain text when prompted for the credentials.

NTLMSSP or Basic Authentication: - The client chooses the best available method when the Use Basic or NTLMSSP option is selected (recommended). If the client supports NTLMSSP, it will use this method, and all other browsers will use Basic. This allows for maximum compatibility.

If the client does not trust the WSA, it will not send its credentials transparently(SSO).

PC----- > ASA ------- >WSA

Step1: When PC tries to access any URL’s, or send any 80 or 443 traffic, then this packet is sent to ASA.
Step2: ASA redirects the same traffic to WSA using WCCP config.
Step3: NOW WSA directly sends GET request to client (HTTP 401 Authorization required) Where Source= WSA_IP, destination: PC_IP asking for credentials
Step4: Client sends its credentials automatically (SSO - Single Sign On), or prompts the end user to manually enter their credentials.
    (Below is the packet capture asking for Authorization)



SSO for Intranet sites: - 
By default, the client does not trust the authentication redirection URL's (transparent deployments only)
If client access ADFS URL which require authentication, then the client may not trust the redirected location i.e; (*.domain.com) 
The Workaround to make Internet Explorer trust is by adding the end URL in IE>Local Intranet Zone.


If you have any queries please comment!

Guest Implementation:Self Registration using Cisco ISE-2.2

21 October , in , 3 Comments

Guest Implementation:Self Registration using Cisco ISE-2.2  

 This Document explains the Design plan of Guest Wireless Implementation using automatic self-registration Portal.

This Guest SSID can be used for Both Guests and Internal Employees.
If the user is a Guest they will create self registration account, If the user is a internal Employee he/she can Enter their Active Directory Username/password to login.


Working: -
a) When a user connects to SSID: GUEST, User gets a Login Prompt,
1)If User is Internal employee, they can sign in with their username and password.
2) If User is a guest, they will create an account using the link provided in the same page.
All these traffic is sent to Anchor WLC through Mobility Tunnel.
b) In anchor WLC, default gateway is pointed to Local Firewall DMZ interface.
c)Now all Guest authentications are performed by Cisco ISE server. Once the user is authenticated then they will be accessed to internet.
d) Return traffic from Anchor WLC is send to Firewall, here we will give Access rules Blocking all RFC-1918 IP address (private IP access) and allowing remaining access.


Step1:- Create a HTML Self-registration portal which contains following
a)Login page
b)Self Registration Page
c)Registration Success Page
d)support Information.
You can use ISE2.2 pre-defined image or you can customize the HTML page.

Below are some sample which are created for same..

a)Login Page :-



b)Self-Registration Page:-


All the above fields are mandatory.
Email Address: it should be Guest email Address rajiv@gmail.com, rajiv@outlook.com etc..
Person Being Visited:- This is very Important Field, Here they have to enter any Employees Email id.
so that the approval/deny email will be sent to this person.



I'm using following Java script to make sure only email id ends with @rajcompany.com works. and all other email ids will be blocked as shown below.

<script>
     setTimeout(function(){
          $.validator.addMethod("customemailvalidator", function(value, element) {
       return (/@rajivcompany.com/).test( value );
     }, 'Invalid Email address format');
     jQuery("[name='guestUser.fieldValues.ui_person_visited']").rules("add",{customemailvalidator:true});
     }, 50);
</script>

Working:- when you enter your company email id to whom they are responsible for Approving/Denying Guest users.


No-working:-





Once the user clicks on REGISTER then a Automatic email will be sent to "Person Being visited" so that they can Appove or Deny the Guest user account.

It uses Following code in ISE2.2 to send automatic email which has Approval/Deny links:

$ui_self_reg_email_approve_link_start$ Approve $ui_self_reg_email_approve_link_end$
$ui_self_reg_email_deny_link_start$ Deny $ui_self_reg_email_deny_link_end$
Please approve (or deny) this self-registering guest by clicking in the link above.

The guest provided the following information:
Username: $ui_user_name$
First Name: $ui_first_name$
Last Name: $ui_last_name$
Password: $ui_password$
Phone Number:$ui_phone_number$
Valid From: $ui_start_date_time$
Valid To: $ui_end_date_time$
Person being visited: $ui_person_visited$





--------------------------------------------------------------------------------------------------------------------
This is an Automated Message: Please DO NOT Reply Directly to this email.
For support Please contact the help desk sriramoju@outlook.com 

Sample email:-


c)Guest Self Registration success Page:-




Once the Guest user is approved. they will get an automatic email to Guest email along with username and password as shown below.

Firewall Configuration:-

a)Create a sub-Interface and a separate vlan for Guest in Firewall.
b)Create Firewall Rules in such a way that it Blocks RFC-1918 and allows all other IP communication.
Source:Guest subnets, Destination: RFC-1918, protocol:IP==>action:  Block
Source:Guest subnets, Destination: any, protocol:IP==> action: Permit

 WLC configuration:-

1)Both Foreign and anchor WLC should have similar WLAN configuration. where Interface config and DHCP server will configured in Anchor WLC. There is a mobility tunnel between Anchor and Foreign WLC.
2)Under AAA config configure ISE servers and enable ISE-NAC redirection under WLAN settings.
3)Configure Pre-Auth ACL or REDIRCT ACL in Anchor WLC, this ACL is used to redirect the guest user to ISE selfregistration portal.
ACL:- Permit DNS , Permit ISE servers, Deny all other traffic.
Now all traffic will be redirected from AP to Foreign WLC to Anchor WLC.


If you have any queries then please feel free to comment below.



Subscribe to: Posts (Atom)
Powered by Blogger