Happy New Year 2021

Today is the day of Holy Innocents. It seems a lie. We are living a pandemic where lots of people have died from March till today. The world has changed! We wear masks. There are even masks with logos, different colors and designs. Lots of people are working from home and most of us don’t want to meet up with others because we are afraid of getting the virus. Companies have also changed. They have had to install SSL VPN appliances to allow users working from home. Therefore, companies have had to deploy technology, security tools and new procedures to go ahead!!

I think, this 2020 has been the year of F5 BIG-IP APM because I’ve deployed and configured many services on this access management proxy solution. I’ve started the year configuring SSL VPN with Network Access, Configuring Host Checking, OTP Authentication and SSL VPN with Edge Client because of the pandemic. Finally, I’ve finished the year configuring SSO via Kerberos and configuring an In-Line SAML SSO Architecture. I’ve written more than 10 weeks about F5 BIG-IP APM.

I’ve also been working with F5 BIG-IP ASM. I’ve compared F5 Advanced WAF and BIG-IP ASM, and later on, I’ve written about Good Protection, Elevated Protection, High Protection and Maximum Protection using F5 WAF. I ended up as a F5 ASM ReCertified Technology Specialist. Companies have more services on Internet as a result of the pandemic and they have to take care of them. I’ve also written more than 10 weeks about F5 BIG-IP ASM.

As you have realised, I’ve written a lot about F5 BIG-IP. It’s true. I’ve written a lot about F5 because I’m working for a big project where there are lots of F5 BIG-IP appliances. In addition, I’ve been working in many other projects with F5 appliances. As a result, I’ve written about automating F5 configuration with Ansible, BIG-IP AFM, F5 AVR, SSL Orchestrator (SSLO) and even what’s new in BIG-IP version 15.0 and what’s new in BIG-IP version 16.0.

I haven’t been working only with F5 appliances but I’ve also been working with many other tech things. I’ve been working with IoC and MISP, and I’ve written about Cyber Threat Intelligence. I’ve also analysed alarms about Lazarus and MuddyWater, and I’ve written about the Lazarus Group and the MuddyWater Threat Actor. In addition, I’ve been reading Buyology and Destrucción Masiva as well as studying French at Official School of Languages.

To sum up, this has been a year weird and uncommon. We don’t know if this is the new world but we have to going forward. I’ll try to keep learning new things. I’ll try to keep reading books. I’ll try to be my best. I would like keep working with technology and I would like keep meeting with all of you. Have a nice day and ...

Merry Christmas and Happy New Year.

F5 VE - Hardware Acceleration with SmartNIC

Organizations are moving to the software-defined architectures whether it’s for agility, efficiency, reducing total cost of ownership, time to market, etc. BIG-IP VE provides that advanced functionality but in a virtualized form that can be run using commercial hypervisors on Common Off-The-Shelf (COTS) servers. The COTS trades-off in flexibility which comes primarily at the cost of performance. However, there are examples which are more efficiently in hardware such as DDoS mitigation, SYN Cookies, whitelisting, QinQ Tunneling, cryptographic processing, etc. All of these things put significant strain on CPU resources.

F5 and Intel - Accelerating Applications Anywhere

What can we do about that if we don’t have the BIG-IP hardware? What’s the solution? One of the things that we can do it’s using a hardware accelerator. There are two solutions. The Intel FPGA PAC N3000 SmartNIC and the Intel QuickAssist Technology (QAT). For the first solution, we need VE + AFM on 15.1.0.4 or higher and, for the second solution, we need VE on 14.1.0.3 or higher.

F5 VE SmartNIC

The SmartNIC from Intel has a FPGA and it can be programmed to perform specific tasks similar to the TurboFlex FPGA profiles that we have in BIG-IP iSeries appliances. For instance, when we have a COTS server with an hypervisor, a BIG-IP VE and a SmartNIC installed, we can boost BIG-IP VE performance easily for DDoS Mitigation. Clients will send good traffic in through the SmartNIC, which goes up through the hypervisor, and VE will deliver the application. However, when we have a bad actor sending some DDoS traffic into the system, AFM has a threshold defined for the amount of identified traffic and it handles the threshold inquiry through the SmarNIC FPGA to detect and ultimately mitigate the DDoS attack via dropping or rate limiting. Therefore, the SmartNIC is going to cut off the DDoS attack. The SmartNIC is able to mitigate a DDoS attack at 70 times greater in magnitude than with a AFM alone.

DDoS Attack Mitigation

The QuickAssist Technology (QAT) is also a hardware accelerator. When we have a COTS server with an hypervisor, a BIG-IP VE and a QuickAssist Technology card installed, we can offload the crypto on the QAT card and, instead of VE doing the decryption, the QAT card is going to do it. We are not only get significant improvement in SSL TPS but also for bulk encryption because it allows about 35% CPU reduction, which allow BIG-IP VE compute resources to handle other things.

Intel QuickAssist  Adapter

Probably, you didn’t know anything about hardware accelerator like these. Me neither. I’ve been speaking with customers who wanted hardware appliances instead of Virtual Edition because hardware were better for encryption and decryption but we can see it’s no longer like this. Thanks to Intel SmartNIC and Intel QuickAssist Technology, we can boost BIG-IP VE performance significantly. As a result, we now can take advantage of flexibility, as well as speed, with BIG-IP VE and SmartNIC.

Thanks my friends!! Would you like to deploy a BIG-IP VE with SmartNIC. I would like it!!

F5 APM – In-Line SAML SSO Architecture

Federation services along with Single Sign-On (SSO) is increasingly configured by many companies. I think SAML is the most used standard which can be configured in many cloud service providers. For instance, we can configure Application Access with Azure AD easily with F5 APM thanks to the SAML standard. However, we can also configure a little bit more complex architecture such as the In-Line SAML SSO architecture where there are two SAML flows: one from F5 APM to the application with the aim of providing in-line SSO for service providers (SP) not directly reachable by the client, and another flow from clients to F5 APM, which is configured as a service provider (SP), against an external Identity Provider (IdP).

Traffic Flow

The traffic flow for an In-Line SAML SSO architecture has mainly 3 steps. Firstly, the user is redirect to the external SAML IdP and once the user is authenticated at the IdP, the user is redirected back to the F5 APM. Secondly, session variables are assigned and an iRule Event is triggered to establish a sideband connection to another virtual server. Finally, this virtual server gets variable values through execution of another iRule to allow SAML SSO access for clients.

BIG-IP as SAML IdP and SAML SP

The SAML configuration for the In-Line SAML SSO architecture is easy to configure. On one hand, we have to configure the SAML SP Service and the SAML IdP Connector. Binding the SAML SP Service to the IdP Connector. On the other hand, we have to configure the SAML IdP Service and the SAML SP Connector. Binding the SAML IdP Service to the SP Connector. In addition, the SAML IdP Service configuration will be used as SSO configuration for the second SAML traffic flow.

IdP Service

The iRule event triggered is mandatory to establish the TCP based sideband connection to the second virtual server. This iRule converts the APM session variable to a TCL variable and sends a HTTP request over the sideband with the username in a query string. What’s more, this iRule is really important because it is useful to start the second SAML traffic flow from the F5 APM to the internal service provider.

send-sideband iRule

There is another iRule attached to the second virtual server which parses the query string and splits the first parameter name from the value. This value is next stored as the username variable. Finally, the TCL username variable is saved as a session variable which is used in the SSO configuration. For instance, it can be used for Kerberos SSO, NTLM SSO, Form based SSO, etc. This iRule is always triggered when there are requests to the second virtual server.

receive-sideband iRule

To sum up, the In-Line SAML SSO architecture with two SAML traffic flows is a little bit more complex configuration than those configurations which only have one SAML traffic flow. However, this architecture is useful for lots of companies and it is also supported by F5 APM.

Thanks my friends!! Have you ever configured an architecture like this?

What’s new in BIG-IP version 16.0

BIG-IP version 16 is still far away for production environments from my point of view. Today, I usually install version 14 in new deployments and, I think, version 15 will be ready for production next year. However, I like to know new features and enhancements in new version. I wrote about What’s new in BIG-IP version 14.0 and What’s new in BIG-IP version 15 to know new features and enhancements which are used today and it will be used next year. Therefore, I’ve been reading this week about the new BIG-IP version that it will be installed probably in two years.

I’ve already written about HTTP/2 and Moving the Web from TCP to UDP. I’ve also written about Mutipath TCP and MPTCP Security, and I’ve even recorded a POC Multipath TCP. BIG-IP supports HTTP/2 but what’s amazing is BIG-IP version 16 also supports HTTP/3. I’ll write about it deeply next week but I would like to highlight HTTP/3 fixes the performance issues of HTTP/2 and it supports 0-RTT connection resumption. Therefore, BIG-IP version 16 provides a turnkey solution by converting HTTP/3 requests from clients to HTTP/1 and HTTP/2 requests to backend servers.

HTTP/2 vs HTTP/3

BIG-IP version 16 has lots of new features for BIG-IP APM. For instance, the Advanced Guide Configuration has been improved to Simplified Guided Access where we can deploy mission critical apps with Microsoft Azure AD easily. Another interesting feature is Identity Aware Proxy (IAP) Webtop which simplifies application access to end users with a single catalog of their applications. F5 Edge Client has also been improved. The F5 Edge Client supports DTLS 1.2 and it also supports SSO across remote access (SSL VPN) and web applications. There are many improvements in BIG-IP APM.

Identity Aware Proxy Webtop

The BIG-IP version 16 has also been improved a lot the BIG-IP AWAF. The new version supports Web Socket Compression traffic in real time to analyze the payload and recompress without increasing network traffic. This version of Advanced WAF enables HTTP Desync mitigation, which enables customers to protect against Desync or similar attacks. In addition, there is a new role to restrict WAF Log Access. This is an interesting feature to reduce exposure of potentially sensitive WAF log data. There are many more new features for BIG-IP WAF in this new version.

Web Guided Configuration for Micro Services

You can see there are lots of new features and enhancements in the BIG-IP version 16 for APM and WAF but there are also many new features for SSL Orchestrator (SSLO) and BIG-IP AFM. For example, Secure Web Gateway (SWG) as an SSL Orchestrator service can be configured in SSLO and Datagroup is also supported in SSLO. On the other hand, BIG-IP AFM VE with SmartNICs can improve DDoS mitigation capacity by up to 300x compared to High Performance AFM VE on its own. To sum up, BIG-IP version 16 has lots of new improvements which can be already tested but we’ll have to wait at least one year to be ready for production environments.

F5 VE SmartNIC

Thanks my friends!! Would you like to test this new version? I do!

F5 APM - Application access with Azure AD

I would like to write about simplify and centralize access to web applications. Most organizations have lots of different web applications. Some of them are classic applications or custom apps. There are also mission-critical applications such as SAP, ERP or Oracle apps. These types of applications tend to live on premise or in a private cloud. When users access to these applications, they use Kerberos, NTLM or maybe header-based authentication. Administrator has to have different identity stores and different access policies for each of these apps. Administrators have that burden of keeping up with all these apps.

An organisation in addition have modern applications such as SaaS apps in a public cloud. All of these SaaS apps tend to use standards such as SAML or OpenID Connect (OIDC) – OAuth. These standards allow SaaS apps authentication with Identity as a Service providers (IDaaS) such as Azure Active Directory (AAD).

As a result, there are mainly two kind of apps. The applications on-premise and the applications in the cloud. This generate a lot of frustration for users and administrators. Therefore, we need some thing in the middle to simplify and centralize all of these applications. F5 BIG-IP APM can take the simplification and centralization of all these access to all these different applications. Rather than having indentity stores with access policies in the cloud and identity store with access policies on premise, BIG-IP APM can centralize all that and it can even have context aware policies based on a lot of different parameters like time of the day, location, endpoint security checks, etc. Consequently, users can work through APM to gain access directly to both kind of apps.

Secure hybrid application access

There is a capability in APM version 15 called AGC (Advanced Guided Configuration) which allow to set up and integrate the Microsoft Azure Active Directory easily in the APM. We can onboard the custom and classic applications in the console of APM and we can also onboard Azure Active Directory for cloud-based identity services in the APM. Therefore, users can gain access to classic applications who may not otherwise be able to transition to a public cloud environment. However, BIG-IP APM version 16 has also a new feature called Simplified Guided Configuration which provides step-by-step guidance to onboard easily apps like SAP, ERP, Oracle, PeopleSoft, etc. As a result, we can just step right through this simplified guide to get classic and custom applications onboarded into Azure Active Directory and APM. It just really simplifies things for the administrator and then suddenly the user by using the step-by-step simplified guided configuration.

F5 APM - Simplified Guided Configuration

To sum up, if a user need to access to classic or custom applications with, for instance, Kerberos or header-based authentication, they are still going to use the more modern technology of SAML and they have the capability and the benefit of Single Sign-On (SSO) because they interact with APM which will take the SAML assertion, that’s generated through the whole SAML process, and it will translate the data out of the SAML assertion to Kerberos or header based or whatever authentication.

Thanks my friends!! Are you ready for simplifying application access with Microsoft AAD and F5 APM?

MuddyWater Threat Actor

I wrote about the Lazarus Group and Lazarus targeting banks because we analysed alarms about this threat actor last month in the Ariolo SIEM. However, we have also analysed another threat actor last weeks. MuddyWater is one of the most active Iranian APTs, that has been active since 2017, targeting Middle Eastern and Asian countries but also United States and some European countries. We have also seen alarms about this threat actor in the Ariolo SIEM. The attacks detected were not successful, therefore, they were not dangerous. However, reading about MuddyWater is worth while.

MuddyWater Alarm

The initial wave of attacks was the PowerStats era where MuddyWater used Office documents which activated malicious macros that communicate with hacked C&C. The second wave used the DNS tunneling technique and they used the same Office documents, but instead of connecting to a hacked server, the group performed DNS queries to self-owned server. Finally, the third wave is a new attack campaign, characterized by generating executables that unload two main files to the machine: a legitimate PDF and a malicious DLL. It is thought that the purpose of the campaign is intelligence gathering, destruction, or a combination of both.

An Excel file containing a malicious macro

I think it’s interesting to know the post-exploitation tools used by MuddyWater. I knew some of them such as Meterpreter or Mimikatz, but there are post-exploitation tools I didn’t know. For instance, I didn’t know the LaZagne project which can be used to retrieve lots of passwords stored on a local computer such as passwords stored on browsers, chats, databases, etc. Another post-exploitation tool I didn’t know is Koadic, which is similar to Meterpreter and Powershell Empire, but the major difference is that Koadic does most of its operations using Windows Script Host. All post-exploitation tools used by MuddyWater are worth having a look.

Tools used by MuddyWater campaigns over the years

MuddyWater campaigns also uses false flags, which are messages that threat actors add into their programs to misattribute the campaign to a specific country. For instance, Chinese and Russian strings have been found in some PowerShell samples. User names such as poopak, leo, Turk and Vendetta have also been found inside weaponized word documents. All of these false flags are distraction techniques used by MuddyWater.

Several older backdoors contained simplified Chinese texts

MuddyWater victims used to communicating directly to IP addresses as C&C servers. They compromised WordPress websites as proxies to send commands that were forwarder to the final C&C servers. In addition, these C&C servers were usually set up to listen to an uncommon port, and were shut down a few hours later. The next time the servers were up, they usually listened on a different port. However, they now use DNS tunneling, as a result, instead of communicating directly to compromised WordPress, they communicate to self-owned server.

Communication flow between the operator and the victim

Thanks my friends!! Have you ever heard about MuddyWater? Neither do I.

F5 BIG-IQ

When we have lots of BIG-IP devices and there are lots of applications, it’s really difficult to remember where applications, IP addresses, SSL certificates, etc have been configured. It’s also really difficult to look for nodes, pools, iRules, etc when we have lots of applications and BIG-IP devices. In addition, when we are going to manage lots of devices and the deployment velocity of all application services should be quick, as well as, we need visibility of device health, services health and network traffic, F5 BIG-IQ deployment is mandatory.

BIG-IQ is an useful device which help us to look for applications, IP addresses, iRules, etc. It’s really useful to look for any object when you have a large deyployment and you don’t know where that object has been configured. I think it’s also really useful for visibility because we can know how much transactions per second (TPS) or throughput has the applications. What’s more, BIG-IQ can be used for many other things such as a centralized certificate management or centralized backup repository. Therefore, from my point of view, we should deploy a BIG-IQ when we have a large deployment of applications.

BIG-IQ Analytics and Visibility

The BIG-IQ architecture has mainly two components. The BIG-IQ Central Manager (CM) and the BIG-IQ Data Collector Device (DCD). The first one is a web console where we are going to manage all BIG-IP devices from. It delivers analytics, visibility and reporting. In addition, the Central Manager automates BIG-IP deployments and configurations. However, the second one collects alerts, events and statistical data from managed BIG-IPs using Elasticsearch. Therefore, the BIG-IP devices send alerts, events and statistical data to the DCD, and this information is displayed in the BIG-IQ Console.

BIG-IQ Components and System Architecture

The BIG-IQ Central Manager has improved a lot with the latest version. We can deploy applications easily from BIG-IQ to BIG-IP devices in a private cloud or on-premise. It’s also really interesting how we can manage Let’s Encrypt SSL Certificate from BIG-IQ, which is really useful for the DevOps crowd because these certificates are free and the interface is programmatic. As a result, BIG-IQ can handle certificate creation and renewal. In addition, BIG-IQ Automation can be used as a self service application portal with application templates and autoscale policies. Therefore, lots of new features and lots of new improvements.

Analytics for BIG-IQ Applications

From my point of view, one of the most interesting feature is analytics. We can configure TCP Analytics profiles and HTTP Analytics profiles in the BIG-IP, which are attached to Virtual Servers. These profiles can collect metrics such as TPS and throughput, page load times, HTTP methods, etc. These metrics are really useful for troubleshooting when applications are slow and it’s also useful to know how much traffic is using each application. However, F5 AVR (Application Visibility and Reporting) must be deployed in BIG-IP devices. It’s mandatory. The AVR module send statistical data to the DCD device and this analytics is displayed in the BIG-IQ console.

TCP Analytics

Thanks my friends!! Have you ever deployed and configured BIG-IQ in your infrastructure?

F5 APM – SSO and Multi-Domain Auth

I’ve written about SSO via Kerberos and SSO via NTLM recently but I also wrote about SSO Authentication such as SSO for Terminal Services, AutoLaunch SAML Resources and OAuth with Facebook last year. I think Single Sign-On (SSO) is really useful for organization which have lots of applications. Users log in once and they have access to all the applications. However, there are companies which have several domains because they have still old domains in the company or they need several domains. Anyway, most of them would like to configure SSO for multi-domain authentication.

There are two mainly Multiple Domain Authentication methods which can be used along with Single Sign-On (SSO). On one hand, we can configure a drop down menu where we can choose what domain we are going to use for autentication. In addition, we can enable multi-domain support for SSO. This is a best configuration when there are several virtual servers and each of them in one domain.

Single Sign-On and Multi-Domain

The Visual Policy Editor (VPE) will have a Logon Page, which will be the Primary Auth Service, where there will be a drop down menu wich all domains. We will also add a Check Domain box to check what domain the user has choosen. Finally, there will be two AD Auth box to authenticate the user in the right domain. I think this is a really simple and powerful configuration which allow SSO for multi-domain authentication.

Domain drop down menu on the logon page - VPE

On the other hand, we can configure home realm discovery or where are you from for Multiple Domain Authentication which can also be used along with Single Sign-On (SSO). This second method prompt the user for their UPN, then their password and authenticate the user against the desired domain. We can also enable muti-domain support for SSO and we can associate the access profile with each of the virtual servers participating in the domain group.

Home realm discovery - where are you from

The Visual Policy Editor (VPE) will have a Logon Page like the first method but it only prompts the UPN. Since APM’s AD Auth action by default authenticates users by username and not the UPN we’ll need to extract the username from the UPN with a variable assign. Next we’ll need to examine the UPN and determine which domain to use for authentication. We’ll also need to create domain specific logon pages to request credentials. Finally, we can add an AD Auth action to each branch and configure the Server to the corresponding AAA object for the selected domain.

Home realm discovery - where are you from - VPE

Actually, there are a third method for Multiple Domain Authentication. This third method uses end-point inspection with Window Registry check or machine certificate authentication. However, this third method requires BIG-IP Edge Client installation in the user’s PC. Therefore, this third method is much difficult to configure and manage.

Thanks my friends!! Do you know any other method for Multi-Domain Authentication with SSO?

F5 BIG-IP APM – SSO via NTLM

The Single Sign-On (SSO) feature is really interesting for most companies because it allows to sign-on once to access to all applications. For instance, you access to your computer once in the morning when you arrive to your office and you no longer have to sign-on again to your applications that day. However, when there are lots of applications, each one different from the other, new applications and old applications, the SSO configuration can be really tough. I’m going to write about how to configure SSO via NTLM with F5 BIG-IP APM which is useful for Windows networks.

First of all, APM can perform three types of 401-based challenge authentication: Basic, NTLM, and Kerberos. I wrote about Basic and Kerberos authentication last week. Basic authentication requires always user’s intervention. However, Kerberos and NTLM can enable users to seamlessly authenticate to the APM virtual server and allow it to either securely proxy connection to the backend application, leveraging Kerberos Constrained Delegation as the SSO mechanism, or acting as SAML IDP and issuing assertions to the SAML Service Providers based upon user identity extracted during NTLM authentication or Kerberos ticket.

NTLM is no longer used by new applications because NTLM passwords are weak and they can be brute-forced very easily with modern hardware. As a result, new applications use Kerberos instead of NTLM. However, companies may have still old applications which use NTLM. Therefore, companies which want SSO for all applications will have to configure all kind of authentication methods such as forms, Kerberos, SAML or even NTLM. 

NTLM Authentication messages

Configuring SSO via NTLM with F5 BIG-IP APM is really easy. First, and foremost, we have to create an NTLM Machine Account object to join the APM to the domain and create an unique computer object in Active Directory. Secondly, we need to create a “NTLM Auth Configuration” using the machine account name created previously. 

NTLM Machine Account

Unlike the other APM client side authentication methods, there’s no GUI option to enable APM client side NTLM. Consequently, we have to apply the External Client Authentication (ECA) profile to the APM virtual server via de TM shell. In addition, we have to create an iRule to enable ECA. I would also point out here that client side NTLM authentication is a bit different from Kerberos in that ECA is generally going to issue a 401 Unauthorized NTLM challenge on every new request. If this proves to add too much overhead, the iRule will allow NTLM to be processed once at the beginning of the session. The APM session cookie is used thereafter to maintain the session.

iRule to enable client side NTLM

Finally, we have to add a SSO Credential Mapping assigment in the access policy, which should be after the NTLM Auth, and add a NTLM SSO configuration object on the access profile (SSO / Auth Domains tab).

Visual Policy Editor configuration

That’s it my friends! Drop me a line with the first thing you are thinking.

F5 BIG-IP APM - SSO via Kerberos

I’m working lately, and again, a lot with F5 APM. I think, this product has lots of interesting features. For instance, we can use F5 APM for SSL VPN remote access. We can configure a Custom Login Page, we can configure Host Checking, we can configure OTP Authentication. We can configure SSL VPN tunnel with Edge Client or SSL VPN with Portal Access Webtop. In addition, we can use F5 APM for Identity Federation and SSO. For example, we can enable SSO via SAML to applications such as SAP, AWS, Salesforce, etc or even third-party applications. We can also enable SSO via forms based authentication, HTTP authentication, NTLM, Kerberos and OAuth. F5 APM can also work as Citrix ICA Proxy allowing F5 APM to publish Citrix apps. Actually, F5 APM is a full proxy appliance which can be used as a secure access proxy.

These weeks, I’m working on a project to migrate an Apache server to F5 LTM+APM. The aim is to migrate all the configuration from Apache to F5. There are virtual hosts easy to migrate with iRules, Pools and Virtual Servers. However, there are also authentication configurations a little bit more complex to configure and migrate. For instance, SSO is configured via Kerberos in the Apache server. Therefore, users authenticated in the Active Directory can use apps without sign in again.

Apache configuration for Kerberos Authentication

On one hand, I have to configure Basic Authentication for users who haven’t been authenticated yet by the Active Directory. Therefore, F5 APM has to retrieve user credentials (username and password) from a browser. It’s a form-based authentication with an standard login screen. Thereafter, F5 APM populates the username and password session variables in Active Directory. Once users have been authenticated successfully, they can access to apps.

On the other hand, I have to configure Kerberos Authentication for users who have already been authenticated by the Active Directory. With the Kerberos method, the client system must first join a domain and a Kerberos action must follow. Therefore, the client firstly becomes a member and connects to the domain. Secondly, the clients connects to a virtual server on the BIG-IP system. Thirdly, the access policy runs and issues a 401 HTTP request action. Fourthly, if Kerberos is present, the browser forwards the Kerberos ticket along with the request when it receives the 401 HTTP request. Finally, F5 APM validates the Kerberos ticket after the request is received and determines whether or not to permit the request.

How Kerberos end-user logon works

The access policy for Kerberos Authentication with End-User Logons is really easy to configure. We have to add three boxes in the Visual Policy Editor. The first one is an HTTP 401 Response box to request clients credentials. The second one is an AD Auth box for basic authentication. The third one is a Kerberos Auth box for clients who have already been authenticated by Active Directory. Therefore, this last box enables SSO via Kerberos.

Example access policy for end-user login

Thanks my friends!! Are you ready to configure SSO via Kerberos?