Implementing F5 NGINX STIGs: A Practical Guide to DoD Security Compliance
Introduction In today’s security-conscious environment, particularly within federal and DoD contexts, Security Technical Implementation Guides (STIGs) have become the gold standard for hardening systems and applications. For organizations deploying NGINX—whether as a web server, reverse proxy, or load balancer—understanding and implementing NGINX STIGs is critical for maintaining compliance and securing your infrastructure. This guide walks through the essential aspects of NGINX STIG implementation, providing practical insights for security engineers and system administrators tasked with meeting these stringent requirements. Understanding STIGs and Their Importance STIGs are configuration standards created by the Defense Information Systems Agency (DISA) to enhance the security posture of DoD information systems. These guides provide detailed technical requirements for securing software, hardware, and networks against known vulnerabilities and attack vectors. For NGINX deployments, STIG compliance ensures: Protection against common web server vulnerabilities Proper access controls and authentication mechanisms Secure configuration of cryptographic protocols Comprehensive logging and auditing capabilities Defense-in-depth security posture Key NGINX STIG Categories Access Control and Authentication Critical Controls: The STIG mandates strict access controls for NGINX configuration files and directories. All NGINX configuration files should be owned by root (or the designated administrative user) with permissions set to 600 or more restrictive. # Verify permissions sudo chmod 600 /etc/nginx/nginx.conf Client Certificate Authentication: For environments requiring mutual TLS authentication, NGINX must be configured to validate client certificates: # Include the following lines in the server {} block of nginx.conf: ssl_certificate /etc/nginx/ssl/server_cert.pem; ssl_certificate_key /etc/nginx/ssl/server_key.pem; # Enable client certificate verification ssl_client_certificate /etc/nginx/ca_cert.pem; ssl_verify_client on; # Optional: Set verification depth for client certificates ssl_verify_depth 2; location / { proxy_pass http://backend_service; # Restrict access to valid PIV credentials if ($ssl_client_verify != SUCCESS) { return 403; } } Certificate Management: All certificates must be signed by a DoD-approved Certificate Authority Private keys must be protected with appropriate file permissions (400) Certificate expiration dates must be monitored and renewed before expiry Cryptographic Protocols and Ciphers One of the most critical STIG requirements involves configuring approved cryptographic protocols and cipher suites. Approved TLS Versions: STIGs typically require TLS 1.2 as a minimum, with TLS 1.3 preferred: ssl_protocols TLSv1.2 TLSv1.3; FIPS-Compliant Cipher Suites: When operating in FIPS mode, NGINX must use only FIPS 140-2 validated cipher suites: ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256'; ssl_prefer_server_ciphers on; Logging and Auditing Comprehensive logging is mandatory for STIG compliance, enabling security monitoring and incident response. Required Log Formats: log_format security_log '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' '$request_time $upstream_response_time ' '$ssl_protocol/$ssl_cipher'; access_log /var/log/nginx/access.log security_log; error_log /var/log/nginx/error.log info; Key Logging Requirements: Log all access attempts (successful and failed) Capture client IP addresses and authentication details Record timestamps in UTC or local time consistently Ensure logs are protected from unauthorized modification (600 permissions) Implement log rotation and retention policies Pass Security Attributes via a Proxy STIGs require implementation of security attributes to implement security policy for access control and flow control for users, data, and traffic: # Include the "proxy_pass" service as well as the "proxy_set_header" values as required: proxy_pass http://backend_service; proxy_set_header X-Security-Classification "Confidential"; proxy_set_header X-Data-Origin "Internal-System"; proxy_set_header X-Access-Permissions "Read,Write"; Request Filtering and Validation Protecting against malicious requests is a core STIG requirement: # Limit request methods if ($request_method !~ ^(GET|POST|PUT|DELETE|HEAD)$) { return 405; } # Request size limits client_max_body_size 10m; client_body_buffer_size 128k; # Timeouts to prevent slowloris attacks client_body_timeout 10s; client_header_timeout 10s; keepalive_timeout 5s 5s; send_timeout 10s; # Rate limiting limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s; limit_req zone=req_limit burst=20 nodelay; SIEM Integration Forward NGINX logs to SIEM platforms for centralized monitoring: # Syslog integration error_log syslog:server=siem.example.com:514,facility=local7,tag=nginx,severity=info; access_log syslog:server=siem.example.com:514,facility=local7,tag=nginx NGINX Plus Specific STIG Considerations Organizations using NGINX Plus have additional capabilities to meet STIG requirements: Active Health Checks upstream backend { zone backend 64k; server backend1.example.com; server backend2.example.com; } match server_ok { status 200-399; header Content-Type ~ "text/html"; body ~ "Expected Content"; } server { location / { proxy_pass http://backend; health_check match=server_ok; } } JWT Authentication For API security, NGINX Plus can validate JSON Web Tokens: location /api { auth_jwt "API Authentication"; auth_jwt_key_file /etc/nginx/keys/jwt_public_key.pem; auth_jwt_require exp iat; } Dynamic Configuration API The NGINX Plus API must be secured and access-controlled: location /api { api write=on; allow 10.0.0.0/8; # Management network only deny all; # Require client certificate ssl_verify_client on; } Best Practices for STIG Implementation Start with Baseline Configuration: Use DISA's STIG checklist as your starting point and customize for your environment. Implement Defense in Depth: STIGs are minimum requirements; layer additional security controls where appropriate. Automate Validation: Use configuration management and automated scanning to maintain continuous compliance. Document Deviations: When technical controls aren't feasible, document risk acceptances and compensating controls. Regular Updates: STIGs are updated periodically; establish a process to review and implement new requirements. Testing Before Production: Validate STIG configurations in development/staging before deploying to production. Monitor and Audit: Implement continuous monitoring to detect configuration drift and security events. Conclusion Achieving and maintaining NGINX STIG compliance requires a comprehensive approach combining technical controls, process discipline, and ongoing vigilance. While the requirements can seem daunting initially, properly implemented STIGs significantly enhance your security posture and reduce risk exposure. By treating STIG compliance as an opportunity to improve security rather than merely a checkbox exercise, organizations can build robust, defensible NGINX deployments that meet the most stringent security requirements while maintaining operational efficiency. Remember: security is not a destination but a journey. Regular reviews, updates, and continuous improvement are essential to maintaining compliance and protecting your infrastructure in an ever-evolving threat landscape. Additional Resources DISA STIG Library: https://public.cyber.mil/stigs/ NGINX Security Controls: https://docs.nginx.com/nginx/admin-guide/security-controls/ NIST Cybersecurity Framework: https://www.nist.gov/cyberframework Have questions about implementing NGINX STIGs in your environment? Share your challenges and experiences in the comments below.Zero Trust Application Access for Federal Agencies
Introduction Zero Trust Network Access (ZTNA) and Zero Trust Application Access (ZTAA) represent two distinct architectural approaches to implementing zero trust application access. ZTAA is emerging as the superior choice for enterprises seeking high-performance, application-centric protection. While both operate under the "never trust, always verify" principle, ZTAA can deliver better performance, lower costs, and provide greater granular control at the application layer, where business-critical assets reside. As a leader in application access, F5 provides strong authentication and authorization through its mature BIG-IP Access Policy Manager platform. Access Policy Manager, or APM, is a tool that helps organizations with zero trust. It does this by following many of the zero trust principles that organizations like the DoD, CISA, and NIST document. Capabilities like strong encryption, user interrogation, conditional and contextual access, device posture, risk scoring, and API integration with third-party security vendors all contribute to a modern zero-trust access solution. It can be said that F5 and APM were the original zero-trust access solutions long before Forrester coined the term "zero trust" back in 2010. Understanding the Architectural Divide ZTNA operates as a network-centric model, creating secure tunnels from users to applications through centralized trust brokers and gateways. This approach can necessitate substantial modifications to the network infrastructure, client software deployment, and, in some cases, re-routing all traffic through tunnel concentration points. ZTNA is well-established and has well-established vendor ecosystems. However, ZTNA can cause performance problems, increase latency, and require big changes to the network architecture. Zero Trust Application Access is different because it focuses on individual applications. It protects these applications directly by using reverse proxies that are already in place in the business environments where these applications are located or at cloud gateways for cloud-based workloads. This architecture lets users connect directly to applications without tunneling. This means no extra work, keeps existing network investments, and gives you control at the application layer. ZTAA operates agentless in many scenarios and integrates seamlessly with cloud-native, containerized, and microservices architectures. F5 Zero Trust Direct Application Access The technical differences create distinct performance profiles. ZTNA's tunnel concentration can create bottlenecks for high-volume applications and add latency from traffic backhauling. At the same time, ZTAA eliminates these performance issues through direct application access and a distributed proxy architecture. Organizations with large application portfolios, cloud-native environments, or performance-sensitive applications find that ZTAA delivers superior user experience and operational efficiency. It is worth noting that ZTNA solutions are, at their core, just a proxy and use encryption for transport, such as TLS or IPsec. ZTAA or ZTNA? Application portfolio size serves as a strong decision criterion. Cost and complexity are also strong considerations. Organizations with fewer than 20 applications, primarily legacy systems, and uniform user bases typically find ZTNA's network-centric approach adequate. However, enterprises with 20+ applications, cloud-native architectures, and diverse user requirements achieve better outcomes with ZTAA's application-specific controls. Performance requirements strongly favor ZTAA for high-volume, real-time, or latency-sensitive applications. Cost considerations also help ZTAA adoption. It can be implemented for a smaller amount of ZTNA costs (depending on how the vendor is doing it) while keeping current network infrastructure investments. Organizations prioritizing rapid deployment, application-by-application rollout, or cloud-first strategies find ZTAA's minimal infrastructure impact and flexible deployment models advantageous. Infrastructure strategy alignment matters significantly. ZTNA is best for big network changes and unified SASE plans. ZTAA is best for applications-first approaches, DevOps cultures, and cloud-native changes. The regulatory environment influences decisions, with some compliance frameworks requiring network-level controls that favor ZTNA, while others benefit from ZTAA's granular application-level security audit trails. F5's ZTAA Leadership Position for Federal Agencies F5 has a strong security position in both federal and commercial landscapes—nearly all the Fortune 50 trust F5 to protect their most mission-critical applications. In addition, federal organizations like the DoD and civilian agencies trust F5 to preserve our nation's most critical infrastructure. The federal sector was an early adopter of zero trust principles. NIST and CISA were instrumental in designing zero-trust reference architectures. The NIST 800-207 document was a landmark, describing how organizations can approach the implementation of a zero-trust architecture in their environments. The DoD Zero Trust Strategy document builds off this architecture and gets specific by calling out controls under each zero trust pillar. The DoD Zero Trust Strategy document outlines 152 targets and requirements for achieving a mature zero trust implementation. F5 today meets or partially meets 57 of those targets. In addition, recent work was published by the NCOEE/NIST describing a completely independent, tested solution utilizing F5 as a Zero Trust Application Access. CISA 5 Pillar Maturity Model – Optimal Level F5 Key Capabilities for Zero Trust Application Access F5 BIG-IP APM Identity Aware Proxy (ZTAA) uses access control per request that checks each application access attempt individually. This moves from session-based authentication to transaction-level verification. The platform provides context-aware authentication, evaluating user identity, device posture, location, and application sensitivity for each request. Continuous device posture checking maintains real-time, ongoing assessments throughout user sessions with adaptive multi-factor authentication and risk-based step-up authentication. F5's Privileged User Access (PUA) solution complements ZTAA with DoD-approved capabilities for both privileged and unprivileged user authentication to government systems. The agent-free deployment adds strong authentication, including CAC/PKI and MFA, to old systems that don’t have native support. It also manages temporary passwords and has many audit trails to make sure the system is compliant and secure. The solution is truly zero trust, with neither the end user nor the endpoint knowing the ephemeral password used during the session. Passwords are never stored on disk and are destroyed when the session terminates, creating a strong access solution. Full proxy architecture brings visibility into your network data plane. Protocols like TLS 1.3 and Post-Quantum look to strengthen your network security posture, but they also bring potential blind spots. TLS 1.3 key structure is ephemeral by design. This protocol feature is excellent for application security, but it creates potential blind spots for threat hunters. Traditionally, packet capture inspections happen out of band and potentially at a future date. With TLS 1.3, packet inspection out of band becomes increasingly tricky. Since TLS 1.3 is a perfect forward secret by default, the symmetric key used during sessions is ephemeral. This means you will need every ephemeral key generated during a session to decrypt out of band. This creates challenges with the SOC and your threat hunters. F5 can help with its SSL Orchestration solution. By orchestrating decrypted traffic to your security inspection stack and re-encrypting it to your applications, you can utilize all the strong security features of TLS 1.3 and PQC while still providing complete visibility into your data-plane traffic. Additional Distinctions F5's full-proxy architecture enables comprehensive traffic inspection and control that competitors cannot match. F5 provides a unified platform integrating ZTAA, application delivery, and enterprise-grade security capabilities. The platform also offers fast TLS decryption at large scale without slowing down performance. It also supports old applications and new web services. F5 adds advanced bot detection, fraud prevention, and API security capabilities that pure-play ZTNA vendors lack. F5's extensive identity provider partnerships include deep Microsoft Azure AD integration with Conditional Access policies, native Okta SAML/OIDC federation, and comprehensive custom LDAP/Active Directory support. Protocol support spans SAML, OAuth, OIDC, RADIUS, LDAP, and Active Directory with flexible deployment across on-premises, cloud, hybrid, and managed service models. Identity Aware Proxy - Key Capabilities APM's Identity Aware Proxy is F5's Zero Trust Application Access solution. We throw around a lot of acronyms in the IT industry, so I just wanted to get that out of the way and make it clear. As I mentioned earlier in this post, F5 can currently meet or partially meet 57 of the 152 targets listed in the DoD Zero Trust strategy guide. APM's IAP solution helps meet many of those 57 targets. Let’s look at some of these features in the access guided configuration. You can find it in the APM or Access Policy Manager’s GUI. If you would like to see a full walk-through sample config, check out this page for a great write-up and lab. Authentication and Authorization Authentication and authorization are at the forefront of any Zero Trust solution. APM provides for robust authentication and authorization integration out of the box. APM has deep integration with Active Directory and supports many of the identity SaaS providers, such as Okta, Ping, SailPoint, and Azure Entra ID. In the image above, MFA is a capability built into the GUI, which makes it very easy to implement a two-factor solution within your ZTAA solution. MFA should be a component of every Zero Trust solution, and F5 makes it easy to integrate with your favorite identity provider. Conditional and Contextual Access Another key component of any ZTAA solution is conditional and contextual access. The new perimeter in a zero-trust world doesn't really exist. We should prioritize protecting the data and application, rather than focusing on our network perimeter security. This is not completely true, as we will keep using network firewalls. But the main idea of zero trust is about data and strong identity, not gateways into our networks. Based on that last sentence, we must be able to interrogate both the user and the device they are accessing from. This involves checking a device's posture for an active firewall or determining its location and the time of day of access. Users should be required to provide a strong identity to include MFA and ABAC controls. In the image below, we show the contextual configuration options for Identity Aware Proxy. This capability makes it easy to configure complex if-then logic flows. Another strong capability sometimes overlooked is APM's ability to query third-party systems for additional context. The HTTP Connector, as shown below, allows the administrator to configure a third-party risk score provider or additional telemetry for access decisions. This is all done via API calls, and so it makes interoperability seamless with other ecosystem vendors. Conclusion ZTAA is the change from zero trust architecture to application-focused security. It offers better performance, strong identity, lower costs, and more flexibility than traditional ZTNA approaches. F5 leads this transformation through its authentication and authorization technology platform, comprehensive application security capabilities, and proven enterprise deployment success across federal and civilian agencies. Organizations evaluating zero trust solutions should prioritize ZTAA for their application portfolios, cloud-native environments, and performance-critical deployments. F5's unified platform approach, technical differentiators, and market-leading capabilities make it the clear choice for enterprises seeking comprehensive zero-trust application access solutions that scale with business growth and digital transformation initiatives.Action Items in OMB Memorandum M-22-09 “Moving the U.S. Government Toward Zero Trust...”
Purpose On January 26, 2022, OMB issued Memorandum M-22-09 for “Moving the U.S. Government Toward Zero Trust Cybersecurity Principles” listing a series of action items. This blog is to provide an overview of F5 capabilities and where they fit within those action items. Milestone Dates January 26, 2022 Issuance of M-22-09 “Moving the U.S. Government Toward Zero Trust Cybersecurity Principles” February 25, 2022 Agencies to designate and identify a zero trust strategy implementation lead for their organization March 27, 2022 Submit to OMB and CISA an implementation plan for FY22-FY24 May 27, 2022 Chief Data Officers to develop a set of initial categorizations for sensitive electronic documents within their enterprise January 26, 2023 Public-facing agency systems that support MFA must give users the option of using phishing-resistant authentication January 26, 2023 Each agency must select at least one FISMA Moderate system that requires authentication and make it Internet accessible August 27, 2022 Agencies must reach the first event logging maturity level (EL-1) as described in Memorandum M-21-31 End of FY2024 Agencies to achieve specific zero trust security goals Requirements to F5 Capability Mapping Page Requirements F5 Capabilities F5 Products 6 Section A.1 “Enterprise identity management must be compatible with common applications and platforms. As a general matter, users should be able to sign in once and then directly access other applications and platforms within their agency’s IT infrastructure. Beyond compatibility with common applications, an agency identity management program should facilitate integration among agencies and with externally operated cloud services; the use of modern, open standards often promotes such integration.” Proxies and transforms client side authentication method to adapt to application’s native authentication method. Modern authentication can now be applied to legacy web application without any changes. BIG-IP APM NGINX 7 Section A.2 Agencies must integrate and enforce MFA across applications involving authenticated access to Federal systems by agency staff, contractors, and partners. MFA, including PIV, can be applied to any applications, whether legacy or modern, without changes. BIG-IP APM 7 Section A.2 MFA should be integrated at the application layer MFA, including PIV, can be applied to any applications, whether legacy or modern, without changes. BIG-IP APM 7 Section A.2 guessing weak passwords or reusing passwords obtained from a data breach Finds compromised credentials in real-time, identifies botnets, and blocks simulation software. F5 Distributed Cloud Services 7 Section A.2 many approaches to multi-factor authentication will not protect against sophisticated phishing attacks, which can convincingly spoof official applications and involve dynamic interaction with users. Users can be fooled into providing a one-time code or responding to a security prompt that grants the attacker account access. These attacks can be fully automated and operate cheaply at significant scale. Finds compromised credentials in real-time, identifies botnets, and blocks simulation software. F5 Distributed Cloud Services 9 Section A.3 every request for access should be evaluated to determine whether it is appropriate, which requires the ability to continuously evaluate any active session After a session starts, a per-request policy runs each time the client makes an HTTP or HTTPS request. A per-request policy must provide the logic for determining how to process web-bound traffic. It must determine whether to allow or reject a URL request and control whether or not to bypass SSL traffic. BIG-IP APM NGINX 10 Section A.3 Agency authorization systems should work to incorporate at least one device-level signal alongside identity information about the authenticated user when regulating access to enterprise resources High-efficacy digital fingerprinting identifies returning web client patterns from new edge devices. F5 Distributed Cloud Services 12 Section C.1 Agencies should make heavy internal use of recent versions of standard encryption protocols, such as TLS 1.3 Regardless of your TLS version, you need to have visibility into encrypted threats to protect your business. SSL/TLS based-decryption devices that allow for packet inspection can intercept encrypted traffic, decrypt, inspect, and re-encrypt untrusted TLS traffic entering or leaving the network. BIG-IP LTM BIG-IP SSLO NGINX 13 Section C.1 agencies should plan for cryptographic agility in their network architectures, in anticipation of continuing to adopt newer versions of TLS Organizations don’t want to reconfigure hundreds of servers just to offer these new protocols. This is where transformational services become cipher agility. Cipher agility is the ability of an SSL device to offer multiple cryptographic protocols such as ECC, RSA2048, and DSA at the same time—even on the same virtual server. BIG-IP SSLO 13 Section C.2 agency DNS resolvers must support standard encrypted DNS protocols (DNS-over-HTTPS or DNS-over-TLS) NOTE: DNSSEC does not encrypt DNS data in transit. DNSSEC can be used to verify the integrity of a resolved DNS query, but does not provide confidentiality. DoH proxy—A passthrough proxy that proxies the client’s DoH request to a backend DoH server and the backend DoH server’s response back to the DoH client. DoH server—The server translates the client’s DoH request into a standard DNS request and forwards the DNS request using TCP or User Datagram Protocol (UDP) to the configured DNS server, such as the BIG-IP named process and the BIG-IP DNS cache feature. When the BIG-IP system receives a response from the configured DNS server, it translates the DNS response into a DoH response before sending it to the DoH client. BIG-IP DNS 14 Section C.3 Zero trust architectures—and this strategy— require agencies to encrypt all HTTP traffic, including within their environments. Handle SSL traffic in load balancing scenario and meet most of the security requirements effectively. The 3 common SSL configurations that can be set up on LTM device are: -SSL Offloading -SSL Passthrough -Full SSL Proxy / SSL Re-Encryption / SSL Bridging / SSL Terminations BIG-IP LTM BIG-IP SSLO NGINX 18 Section D.4 Making applications internet-accessible in a safe manner, without relying on a virtual private network (VPN) or other network tunnel Proxy-based access controls deliver a zero-trust platform for internal and external application access. That means applications are protected while extending trusted access to users, devices, and APIs. BIG-IP LTM BIG-IP APM 18 Section D.4 require agencies to put in place minimum viable monitoring infrastructure, denial of service protections, and an enforced access-control policy Integrate with SIEM for agency wide monitoring or use F5 management platform for greater visibility. On-prem DDOS works in conjunction with cloud service to protect from various attack strategies. BIG-IQ BIG-IP AFM BIG-IP ASM F5 Distributed Cloud DDOS 19 Section D.6 Automated, immutable deployments support agency zero trust goals Built-in support for automation and orchestration to work with technologies like Ansible, Terraform, Kubernetes and public clouds. BIG-IP NGINX 20 Section D.6 Agencies should work toward employing immutable workloads when deploying services, Built-in support for automation and orchestration to work with technologies like Ansible, Terraform, Kubernetes and public clouds. BIG-IP NGINX 24 Section F.1 Agencies are undergoing a transition to IPv6, as described in OMB Memorandum M-21- 07, while at the same time migrating to a zero trust architecture The BIG-IP device is situated between the clients and the servers to provide the applications the clients use. In this position—the strategic point of control—the BIG-IP device provides virtualization and high availability for all application services, making several physical servers look like a single entity behind the BIG-IP device. This virtualization capability provides an opportunity to start migrating either clients or servers—or both simultaneously—to IPv6 networks without having to change clients, application services, and both sides of the network all at once. BIG-IP LTM NGINX 24 Section F.2 OMB Memorandum M-19-1735 requires agencies to use PIV credentials as the “primary” means of authentication used for Federal information systems PIV authentication can be applied to any applications, whether legacy or modern, without changes. BIG-IP APM 25 Section F.3 Current OMB policies neither require nor prohibit inline decryption of enterprise network traffic SSL Orchestrator is designed and purpose-built to enhance SSL/TLS infrastructure, provide security solutions with visibility into SSL/TLS encrypted traffic, and optimize and maximize your existing security investments. BIG-IP SSLO 25 Section F.4 This memorandum expands the scope of M-15-13 to encompass these internal connections. NOTE: M-15-13 specifically exempts internal connections, stating, “[T]he use of HTTPS is encouraged on intranets, but not explicitly required.” SSL Orchestrator delivers dynamic service chaining and policy-based traffic steering, applying context-based intelligence to encrypted traffic handling to allow you to intelligently manage the flow of encrypted traffic across your entire security stack, ensuring optimal availability. BIG-IP LTM BIG-IP SSLO NGINX Your F5 Account Team Can Help Every US Federal agency has a dedicated F5 account team to support the mission. They are ready to discuss F5 capabilities and help provide further information for your Zero Trust implementation plan. Please contact your F5 account team directly or use this contact form.
F5 TIC3.0 Capability Mappings
About The information below lists how F5 products address TIC 3.0 capability requirements (Dec 2023/Version 3.1) from the context of how F5 can help the broader agency. Important Note: Prior to reading this please read each capability as defined in https://www.cisa.gov/sites/default/files/2023-12/CISA%20TIC%203.0%20Security%20Capabilities%20Catalog_508c.pdf If a capability is not explicitly listed it should be assumed the F5 product does not meet the requirement. At the core the security provided by TIC 3.0 is based on Zero Trust. If you would like to learn more about how F5 can help your agency meet its Zero Trust requirements, please contact your local account team for additional detail. F5 Products Background F5 BIG-IP is a reverse proxy with web application security and authentication capabilities. BIG-IP provides these capabilities for traditional applications. F5 BIG-IP delivers applications securely, efficiently and at scale. BIG-IP Web Application Firewall protects applications from the ever-evolving security threat landscape. Specific BIG-IP software modules are matched to certain capabilities below where applicable. F5 NGINX Plus is a reverse proxy with web application security and authentication capabilities in a containerized format. NGINX+ typical use cases is to provide these protections for modern containerized applications. F5 Distributed Cloud is a SaaS offering that provides Application Delivery, WAAP, DNS, DDOS to applications as an edge service. F5 Distributed Cloud also offers a “Customer Edge” CE that provides many of these same capabilities on-prem or in a Cloud Service Provider. F5 Distributed Cloud will be referred to as “F5 XC” below. TIC 3.0 Capabilities Universal Security Capabilities Central Log Management with Analysis BIG-IP BIG-IP provides application security and telemetry logging enterprise wide to a centralized log store. NGINX Plus NGINX Plus provides application security and telemetry logging enterprise wide to a centralized log store. F5 XC F5 XC provides application security and telemetry logging enterprise wide to a centralized log store. Configuration Management BIG-IP BIG-IP configuration and capabilities can be fully automated and orchestrated. NGINX Plus NGINX Plus configuration and capabilities can be fully automated and orchestrated. F5 XC F5 XC configuration and capabilities can be fully automated and orchestrated. Incident Response Planning and Incident Handling BIG-IP F5 BIG-IP provides the ability to detect, prevent and log application security events. NGINX Plus F5 NGINX Plus provides the ability to detect, prevent and log application security events in a containerized form factor. F5 XC F5 Distributed Cloud provides the ability to detect, prevent and log application security events. Strong Authentication BIG-IP F5 BIG-IP supports requiring SAML, OIDC, Active Directory, and mTLS authentication before a client can access an application NGINX Plus F5 BIG-IP NGINX Plus supports requiring OIDC, and mTLS authentication before a client can access an application containerized format. F5 XC N/A Enterprise Threat Intelligence BIG-IP F5 provides threat intelligence feeds that help organizations detect whether they are a target of a threat campaign. This service can be leveraged by BIG-IP. NGINX Plus F5 provides threat intelligence feeds that help organizations detect whether they are a target of a threat campaign. This service can be leveraged by NGINX Plus. F5 XC F5 provides threat intelligence feeds that help organizations detect whether they are a target of a threat campaign. This service can be leveraged by F5 XC. Dynamic Threat Discovery BIG-IP BIG-IP can learn HTTP traffic patterns and establish a baseline to protect applications. NGINX Plus N/A F5 XC N/A Continuous Monitoring Reporting BIG-IP BIG-IP provides application security and telemetry logging providing vital application access, performance, and threat data for analysis. NGINX Plus NGINX Plus provides application security and telemetry logging providing vital application access, performance, and threat data for analysis. F5 XC F5 XC provides application security and telemetry logging providing vital application access, performance, and threat data for analysis. Web PEP Capabilities Break and Inspect BIG-IP F5 BIG-IP provides the ability to decrypt TLS traffic and send the decrypted traffic to any number of security devices, allowing the security devices. NGINX Plus N/A F5 XC N/A Active Content Mitigation BIG-IP BIG-IP provides the ability to decrypt TLS traffic and send this traffic to a content filtering solution for further inspection. This allows the filtering solution to inspect previously encrypted traffic and remove any malicious content. NGINX Plus N/A F5 XC N/A Certificate Denylisting BIG-IP F5 BIG-IP can enforce certification revocation on clients (human or non-human) presenting certificates (mTLS/Smart Card/CAC/PIV) via OCSP or CRLs before granting access to the application. BIG-IP can also be configured to deny certificates based on a blacklist. NGINX Plus F5 BIG-IP can enforce certification revocation on clients (human or non-human) presenting certificates (mTLS/Smart Card/CAC/PIV) via OCSP or CRLs before granting access to the application. F5 XC N/A Content Filtering BIG-IP BIG-IP provides the ability to decrypt TLS traffic and send this traffic to a content filtering solution for further inspection. This allows the filtering solution to inspect previously encrypted traffic and remove any malicious content. NGINX Plus N/A F5 XC N/A Authenticated Proxy BIG-IP F5 BIG-IP is a reverse proxy that provides the ability to require SAML, OIDC, Active Directory and mTLS authentication before a client can access an application. NGINX Plus F5 BIG-IP NGINX Plus is a reverse proxy that provides the ability to require OIDC, and mTLS authentication before a client can access an application in a containerized format. F5 XC N/A Data Loss Prevention BIG-IP BIG-IP can detect and block sensitive data leaving an application. Data patterns that are deemed sensitive can be added. Additionally, BIG-IP provides the ability to decrypt TLS traffic and send this traffic to a DLP solution for further inspection preventing sensitive data leakage. NGINX Plus NGINX Plus can detect and block sensitive data leaving an application. Data patterns that are deemed sensitive can be added. F5 XC F5 XC can detect and block sensitive data leaving an application. Data patterns that are deemed sensitive can be added. Domain Resolution Filtering BIG-IP BIG-IP can report of block DNS over HTTPS originating from or destined for your agency. NGINX Plus N/A F5 XC N/A Protocol Compliance Enforcement BIG-IP BIG-IP provides protocol compliance for both HTTP and DNS with the ability to report or reject traffic that is out of compliance. NGINX Plus NGINX Plus provides protocol compliance for HTTP with the ability to report or reject traffic that is out of compliance. F5 XC F5 XC provides protocol compliance for HTTP with the ability to report or reject traffic that is out of compliance. Domain Category Filtering BIG-IP BIG-IP provides break and inspect capabilities for traffic egressing from the network. Categories may be configured to bypass break and inspect for domain categories (e.g., banking, medical, government). This is typically done so that PII data is not inspected. NGINX Plus N/A F5 XC F5 XC CEs provide forward proxy capabilities with the ability to restrict domain and URL access. https://docs.cloud.f5.com/docs/how-to/network-firewall/forward-proxy-policies Domain Reputation Filtering BIG-IP BIG-IP provides the ability to deny access to domains via a list or categories of domains enforced at the HTTP protocol layer. Domain filtering can also be provided via DNS using a list of domains or an integration with a RPZ provider such as Spamhaus or SUBRL. NGINX Plus N/A F5 XC N/A Bandwidth Control BIG-IP F5 BIG-IP provides the ability to limit bandwidth on a per application basis. https://techdocs.f5.com/en-us/BIG-IP-16-1-0/big-ip-policy-enforcement-manager-implementations/managing-traffic-with-bandwidth-controllers.html NGINX Plus F5 NGINX Plus provides the ability to rate limit on a per application basis in a containerized/Kubernetes environment. F5 XC F5 XC provides the ability to rate limit on a per application basis at a regional edge, on-prem or in the cloud. Malicious Content Filtering BIG-IP BIG-IP provides the ability to decrypt TLS traffic and send this traffic to a content filtering solution for further inspection. This allows the filtering solution to inspect previously encrypted traffic and remove any malicious content. NGINX Plus N/A F5 XC N/A Access Control BIG-IP F5 BIG-IP provides the ability to define policies to limit actions on protected web applications. This is achieved by limiting on a per user and per application basis the URLs and HTTP methods that a user is permitted to access. NGINX Plus F5 NGINX Plus provides the ability to define policies to limit actions on protected web applications. This is achieved by limiting on a per user and per application basis the URLs and HTTP methods that a user is permitted to access. F5 XC F5 XC provides the ability to define policies to limit actions on protected web applications. This is achieved by limiting on a per user and per application basis the URLs and HTTP methods that a user is permitted to access. Resiliency PEP Security Capabilities Distributed Denial of Service Protections BIG-IP BIG-IP provides protection against DOS attacks at layers 3-7 by providing the ability to learn traffic patterns and establish a baseline. BIG-IP Layer 3-4 capabilities provide protection against IP, UDP and TCP based attacks. Layer 7 capabilities provide protection against DNS, TLS and HTTP based DOS attacks. NGINX Plus NGINX Plus provides protection against HTTP based DOS attacks. F5 XC F5 XC provides protection against HTTP based DOS attacks. Elastic Expansion BIG-IP F5 BIG-IP provides the ability to scale out applications by distributed the application traffic across as many instances as needed. NGINX Plus F5 NGINX Plus provides the ability to scale out applications by distributed the application traffic across as many instances as needed in a containerized environment. F5 XC F5 XC provides the ability to scale out applications by distributed the application traffic across as many instances as needed. Regional Delivery BIG-IP N/A NGINX Plus N/A F5 XC F5 XC provides the ability through a Regional Edge to host containerized application and their associated services through a secure scalable fabric. Additionally, F5 XC’s Regional Edge provides the ability to scale, secure and deliver applications across a geographically dispersed set of environments. Domain Name System PEP Security Capabilities Domain Name Sinkholing BIG-IP Domain Name Sinkholing DNS using a list of domains or an integration with a RPZ provider such as Spamhaus or SUBRL. NGINX Plus N/A F5 XC N/A Domain Name Verification for Agency Clients BIG-IP F5 BIG-IP can enforce that queries from agency clients utilize DNSSEC NGINX Plus N/A F5 XC N/A Domain Name Validation for Agency Domains BIG-IP F5 BIG-IP can enforce DNSSEC chain of trust for all agency domains. NGINX Plus N/A F5 XC N/A Intrusion Detection PEP Security Capabilities Intrusion Detection and Prevention Systems BIG-IP F5 BIG-IP provides Intrusion Detection capabilities that allow for the reporting and blocking of threats over a wide range of protocols. NGINX Plus N/A F5 XC N/A Enterprise PEP Security Capabilities Virtual Private Network BIG-IP F5 BIG-IP provides site-to-site IPSEC capabilities along with end user remote access SSL VPN. NGINX Plus N/A F5 XC N/A Application Container BIG-IP N/A NGINX Plus F5 NGINX Plus provides load balancing, ingress services (for K8s), WAF, HTTP DOS protection and API Security for containerized services. F5 XC F5 XC provides the ability to host containerized services in F5 XC Regional Edge. Services PEP Security Capabilities Active Content Mitigation BIG-IP BIG-IP provides the ability to decrypt TLS traffic and send this traffic to a content filtering solution for further inspection. This allows the filtering solution to inspect previously encrypted traffic and remove any malicious content. NGINX Plus N/A F5 XC N/A Data Loss Prevention BIG-IP BIG-IP can detect and block sensitive data leaving an application. Data patterns that are deemed sensitive can be added. Additionally, BIG-IP provides the ability to decrypt TLS traffic and send this traffic to a DLP solution for further inspection preventing sensitive data leakage. NGINX Plus NGINX Plus can detect and block sensitive data leaving an application. Data patterns that are deemed sensitive can be added. F5 XC F5 XC can detect and block sensitive data leaving an application. Data patterns that are deemed sensitive can be added. Protocol Compliance Enforcement BIG-IP F5 BIG-IP provides the ability to enforce protocol compliance for HTTP and DNS protocols. NGINX Plus F5 NGINX Plus provides the ability to enforce protocol compliance for the HTTP protocol. F5 XC F5 XC provides the ability to enforce protocol compliance for the HTTP protocol. Malicious Content Filtering BIG-IP BIG-IP provides the ability to decrypt TLS traffic and send this traffic to a content filtering solution for further inspection. This allows the filtering solution to inspect previously encrypted traffic and remove any malicious content. NGINX Plus N/A F5 XC N/A Access Control BIG-IP F5 BIG-IP provides the ability to define policies to limit actions on protected web applications. This is achieved by limiting on a per user and per application basis the URLs and HTTP methods that a user is permitted to access. NGINX Plus F5 NGINX Plus provides the ability to define policies to limit actions on protected web applications. This is achieved by limiting on a per user and per application basis the URLs and HTTP methods that a user is permitted to access. F5 XC F5 XC provides the ability to define policies to limit actions on protected web applications. This is achieved by limiting on a per user and per application basis the URLs and HTTP methods that a user is permitted to access. Identity PEP Security Capabilities Behavioral Baselining BIG-IP BIG-IP can learn HTTP traffic patterns and establish a baseline to protect applications. NGINX Plus N/A F5 XC N/A Multi-factor Authentication BIG-IP F5 BIG-IP supports requiring SAML, OIDC, Active Directory, and mTLS authentication before a client can access an application NGINX Plus F5 BIG-IP NGINX Plus supports requiring OIDC, and mTLS authentication before a client can access an application containerized format. F5 XC N/A Continuous Authentication BIG-IP F5 BIG-IP provides the ability to authenticate users prior to accessing an application. After access to the application BIG-IP can enforce periodic requests for authentication to reverify the client’s identity in addition to their OS posture. NGINX Plus N/A F5 XC N/ABIG-IP iRulesLX FakeADFS - WS-Federation/SAML11
Details This was created as a solution to REPLACE the need for AD FS to tie APM into SharePoint. The goal was originally to demonstrate the flexibility of iRulesLX and also to find a way to add WS-Federation support very quickly. This solution is currently SP initiated, but wouldn't take much to handle IdP initiated as well. An example of the process flow is detailed in the following image. All that's needed for this solution is to create or import the iRulesLX workspace, configure SharePoint as if you are connecting to AD FS as a trusted Identity Provider, but point to a virtual server on the BIG-IP. Instructions First, ensure that you have a certificate / key for the IDP, as well as the CA Chain/Root CA. These do not have to be from the same domain CA that SharePoint lives on, if it exists. We are going to add these to SharePoint as trusted. On one of the SharePoint servers, open the SharePoint Management Powershell, issue the following. To import the Trusted Root CA, that issued the signing cert: $root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("") New-SPTrustedRootAuthority -Name "Token Signing Cert Parent" -Certificate $root To import the Trusted Certificate $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("") Next, create the Claim mappings for SharePoint: $emailClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress " -IncomingClaimTypeDisplayName "EmailAddress" –SameAsIncoming $upnClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn " -IncomingClaimTypeDisplayName "UPN" –SameAsIncoming $roleClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role " -IncomingClaimTypeDisplayName "Role" –SameAsIncoming $sidClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid " -IncomingClaimTypeDisplayName "SID" –SameAsIncoming Note: Additional claim options here. Next, create the Trusted Identity Provider. $realm = "urn:sharepoint:" $signInURL = "https:///adfs/ls" $ap = New-SPTrustedIdentityTokenIssuer -Name (ProviderName) -Description (ProviderDescription) -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $emailClaimMap,$upnClaimMap,$roleClaimMap,$sidClaimMap -SignInUrl $signInURL -IdentifierClaim $emailClaimmap.InputClaimType To Associate a SharePoint Web Application with the new Identity Provider. To configure an existing web application to use the FakeADFS identity provider Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group. In Central Administration, on the home page, click Application Management. On the Application Management page, in the Web Applications section, click Manage web applications. Click the appropriate web application. From the ribbon, click Authentication Providers. Under Zone, click the name of the zone. For example, Default. On the Edit Authentication page in the Claims Authentication Types section, select Trusted Identity provider, and then click the name of your SAML provider (<ProviderName> from the New-SPTrustedIdentityTokenIssuer command). Click OK. Next, you must enable SSL for this web application. You can do this by adding an alternate access mapping for the “https://” version of the web application’s URL and then configuring the web site in the Internet Information Services (IIS) Manager console for an HTTPS binding. APM Policy Flow The current workflow works as follows: 1. A user opens a link to SharePoint. 2. SharePoint presents Authentication options for the WebApp. 3. A user selects Authentication Source (FakeADFS), enters credentials, which then redirects the user to Virtual Server configured with FakeADFS iRulesLX solution. 4. FakeADFS Generates a SAML11 assertion, then wraps it in the WS-Federation elements. <t:RequestSecurityTokenResponse xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust"> <t:Lifetime> <wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2016-12-20T13:56:01.349Z</wsu:Created> <wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2016-12-20T14:56:01.349Z</wsu:Expires> </t:Lifetime> <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"> <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing"> <wsa:Address>urn:sharepoint:f5test</wsa:Address> </wsa:EndpointReference> </wsp:AppliesTo> <t:RequestedSecurityToken> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1" MinorVersion="1" AssertionID="_8Ed1lOeqLhnGTETTOn9BHJn72TZ8lE25" IssueInstant="2016-12-20T13:56:01.363Z" Issuer="http://fakeadfs.f5ttest.com/adfs/services/trust"> <saml:Conditions NotBefore="2016-12-20T13:56:01.363Z" NotOnOrAfter="2016-12-20T14:56:01.363Z"> <saml:AudienceRestrictionCondition> <saml:Audience>urn:sharepoint:f5test</saml:Audience> </saml:AudienceRestrictionCondition> </saml:Conditions> <saml:AttributeStatement> <saml:Subject> <saml:SubjectConfirmation> <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> <saml:Attribute AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims" AttributeName="emailaddress"> <saml:AttributeValue>flip@f5test.com</saml:AttributeValue> </saml:Attribute> <saml:Attribute AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims" AttributeName="upn"> <saml:AttributeValue>0867530901@f5test.com</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> <saml:AuthenticationStatement AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant="2016-12-20T14:56:01.363Z"> <saml:Subject> <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <Reference URI="#_8Ed1lOeqLhnGTETTOn9BHJn72TZ8lE25"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <DigestValue>fqLP9yVFDNveaOWwyEVl2Bc9M6bEzKb7KMZ2x33VgUc=</DigestValue> </Reference> </SignedInfo> <SignatureValue>tSLsHUu5m1Mc7qNmdfa5daEK2+noAgbuZ5faGaXQw7qCPEvNihXFUjGuwT4qgeIWFsiFcinin 6Q42DwjRZBL1jcYpAYxP3WQFc+JvRlOaaWecklLmlLGBp9qjyzNzNhgT374T1YkgWJLTm4Jky7bW6HAMWJzT2vCpbSWLbtU=</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>MIIGgjCCBGqgAwIBAgITFQAAAAVVlNqAr99awAAAAAAABTANBgkqhkiG9w0BAQsFADBJMRMwEQYKCZImiZ PyLGQBGRYDY29tMRUwEwYKCZImiZPyLGQBGRZjVsYWIxGzAZBgNVBAMTEkY1IExhYiBDQSAoMksxNlIyKTAeFw0xNjEyMTYxN TE1MjNaFw0xODEyMTYxNTE1MjNaMG8xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJQQTEUMBIGA1UEBxMLRG93bmluZ3Rvd24xDzAN BgNVBAoTBkY1IExhYjEPMA0GA1UECxMGRjUgTGFiMRswGQYDVQQDExJmYWtlYWRmcy5mNWxhYi5jb20wgZ8wDQYJKoZIhvcNAQE BBQADgY0AMIGJAoGBALgtr7ROiet3GPUg0yWa2dGPoirQ9dI8XiA7BsUwjTUG5yhAysKm0ZsCstKN92a2e8HxoHxiEZL39XzTxg 5+3fY4A8hWttlqkKoWutnUS3GpPhfoVdufr8bTcr/vhLPCkuy9GsiDqAMwuiX/B3r0EHqFk3utfL3KDxZ5V94ArwqJAgMBAAGjg gK/MIICuzAOBgNVHQ8BAf8EBAMCBaAwEwYDVR0AwwCgYIKwYBBQUHAwEweAYJKoZIhvcNAQkPBGswaTAOBggqhkiG9w0DAgIC AIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgU rDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUL8AJuPouaekEIK8JuQAthnBS8wHwYDVR0jBBgwFoAUeyV8LWPBfaUCaLG/UR cYpOrjK48wgeMGA1UdHwSB2zCB2DCB1aCB0qCBz4aBzGxkYXA6Ly8vQ049RjUlMjBMYWIlMjBDQSUyMCEwMDI4MksxNlIyITAwM jksQ049V0lOMksxMlIyREMwMDEsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZp Z3VyYXRpb24sREM9ZjVsYWrIsREM9Y29tP2NlcnRpZmljYXRl2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN 0cmlidXRpb25Qb2ludDCB0AYIKwYBBQUHAQEEgcMwgcAwgb0GCCsGAQxUFBzAChoGwbGRhcDovLy9DTj1GNSUyMExhYiUyMENBJT IwITAwMjgySzE2UjIhMDAyOSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlnd XJhdGlvbixEQz1mNWxhYixEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwIQYJKwYBBAGCNxQCBBQeEgBXAGUAYgBTAGUAcgB2AGUAcjANBgkqhkiG9w0BAQsFAAOCAgEAdom2Hvlw9MTKZbr6Ic3MLDR I10QGnflAq9w0/t6H8HN1jnEW8RTikIEpp2nOK7GknFq2161mJ4l5cRGroCyWsHN8to6VqhxqnESYHRyxwZDpS6a8JO4AYc111G fRWpB4nOIqs86aboUJDU+vRzrJHeuI1NzsI502i7fjlYqQVtE3FO2VIbekqx9zjHnliAX6l+VbDMFX8P8lP40U9rAIzHUPF+j3p 34i+4tPtv1/bwTco2EZE8hy2XvJ4xHXzpXYytchRhv+8glYNKK229vhML0micJfnCJQ3xaiJ2e08/GSVoBF9x4J+z4V+XS9aZSn P2+N3tZESVVBA8U4kk9u6syfmDc4+ryoIw5XGcBIyitaH7FbKbYyUHY0XuWPHx6FOWWnCe2kIA/Zfs9IDCP/z07egIJabLymLC vRhOMyd1s5lajnTFfoFaDd7LlL1ipz94OdhxJ5/Aga7sTEtFPbjnfcSZ8lFglQUOkaKuZt6D/LQ/TW6TyDqPC3RDCoaqkY4MXgnm P0dUk9ql1y2qFU2l692ZDZQPB4Tiaa3yXDKwDwCWITQ0YBvIiCcSWoMKXXea96Q2lB3R9n7v9Y6I7eSniZjGqlYYQ3Bdi3FMVz+ HGPeMOFq6HbzgnNtjFKwjqokUbwpwA7vZOQmFwEahEEaCPTpK25h4LSpLPtYa3fjfQ=</X509Certificate> </X509Data> </KeyInfo> </Signature> </saml:Assertion> </t:RequestedSecurityToken> <t:TokenType>urn:oasis:names:tc:SAML:1.0:assertion</t:TokenType> <t:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</t:RequestType> <t:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</t:KeyType> </t:RequestSecurityTokenResponse> 5. The results are injected into a form embedded in an HTTP::respond 200 content with javascript that will automatically POST the form data to SharePoint. SharePoint accepts the assertion from its Trusted Identity Provider. The current solution pulls attributed from LDAP, but this isn't required, you can basically enter anything as username and SharePoint accepts it without question. iRule/TCL Portion when HTTP_REQUEST { # Wctx: This is some session data that the application wants sent back to # it after the user authenticates. set wctx [URI::decode [URI::query [HTTP::uri] wctx]] # Wa=signin1.0: This tells the ADFS server to invoke a login for the user. set wa [URI::decode [URI::query [HTTP::uri] wa]] # Wtrealm: This tells ADFS what application I was trying to get to. # This has to match the identifier of one of the relying party trusts # listed in ADFS. wtrealm is used in the Node.JS side, but we dont need it # here. # Kept getting errors from APM, this fixed it. node 127.0.0.1 # Make sure that the user has authenticated and APM has created a session. if {[HTTP::cookie exists MRHSession]} { #log local0. "Generate POST form and Autopost " # tmpresponse is the WS-Fed Assertion data, unencoded, so straight XML set tmpresponse [ACCESS::session data get session.custom.idam.response] # This was the pain to figure out. The assertion has to be POSTed to # SharePoint, this was the easiest way to solve that issue. Set timeout # to half a second, but can be adjusted as needed. set htmltop "<html><script type='text/javascript'>window.onload=function(){ window.setTimeout(document.wsFedAuth.submit.bind(document.wsFedAuth), 500);};</script><body>" set htmlform "<form name='wsFedAuth' method=POST action='https://sharepoint.f5test.com/_trust/'><input type=hidden name=wa value=$wa><input type=hidden name=wresult value='$tmpresponse'><input type=hidden name=wctx value=$wctx><input type='submit' value='Continue'></form/>" set htmlbottom "</body></html>" set page "$htmltop $htmlform $htmlbottom" HTTP::respond 200 content $page } } when ACCESS_POLICY_AGENT_EVENT { # Create the ILX RPC Handler set fakeadfs_handle [ILX::init fakeadfs_extension] # Payload is just the incoming Querystring set payload [ACCESS::session data get session.server.landinguri] # Currently, the mapped attributes are Email & UPN. In some environments, # this may match, for my use case, they will not, so there is an LDAP AAA # which is queried based on the logon name (email), and the UPN is retrieved # from LDAP. set AttrUserName [ACCESS::session data get session.logon.last.username] set AttrUserPrin [ACCESS::session data get session.ldap.last.attr.userPrincipalName ] # Current solution uses Node.JS SAML module and can support SAML11, as well # as SAML20. The APM policy calls the irule even ADFS, with generates the token # based on the submitted QueryString and the logon attributed. switch [ACCESS::policy agent_id] { "ADFS" { log local0. "Received Process request for FakeADFS, $payload" set fakeadfs_response [ILX::call $fakeadfs_handle Generate-WSFedToken $payload $AttrUserName $AttrUserPrin] ACCESS::session data set session.custom.idam.response $fakeadfs_response } } } # This may or may not be needed, they arent populated with actual values, but # have not tested WITHOUT yet. # # MSISAuth and MSISAuth1 are the encrypted cookies used to validate the SAML # assertion produced for the client. These are what we call the "authentication # cookies", and you will see these cookies ONLY when AD FS 2.0 is the IDP. # Without these, the client will not experience SSO when AD FS 2.0 is the IDP. # # MSISAuthenticated contains a base64-encoded timestamp value for when the client # was authenticated. You will see this cookie set whether AD FS 2.0 is the IDP # or not. # # MSISSignout is used to keep track of the IDP and all RPs visited for the SSO # session. This cookie is utilized when a WS-Federation sign-out is invoked. # You can see the contents of this cookie using a base64 decoder. # MSISLoopDetectionCookie is used by the AD FS 2.0 infinite loop detection # mechanism to stop clients who have ended up in an infinite redirection loop # to the Federation Server. For example, if an RP is having an issue where it # cannot consume the SAML assertion from AD FS, the RP may continuously redirect # the client to the AD FS 2.0 server. When the redirect loop hits a certain # threshold, AD FS 2.0 uses this cookie to detect that threshold being met, # and will throw an exception which lands the user on the AD FS 2.0 error page # rather than leaving them in the loop. The cookie data is a timestamp that is # base64 encoded. when ACCESS_ACL_ALLOWED { HTTP::cookie insert name "MSISAuth" value "ABCD" path "/adfs" HTTP::cookie insert name "MSISSignOut" value "ABCD" path "/adfs" HTTP::cookie insert name "MSISAuthenticated" value "ABCD" path "/adfs" HTTP::cookie insert name "MSISLoopDetectionCookie" value "ABCD" path "/adfs" } iRulesLX / Node.JS Portion If you you are starting from scratch, the npm install xxx --save option below is required. If you are importing the workspace or the github solution, npm update will pull in the latest version of all the referenced modules. /* Import the f5-nodejs module. */ var f5 = require('f5-nodejs'); /* Import the additional Node.JS Modules npm install saml npm install querystring npm install fs npm install moment npm install https */ var saml11 = require('saml').Saml11; var queryString = require('querystring'); var fs = require('fs'); var moment = require('moment'); var https = require('https'); /* timeout is the length of time for the assertion validity wsfedIssuer is, believe it or not, the Issuer SigningCert, SigningKey are the required certificate and key pair for signing the assertion and specifically the DigestValue. */ var timeout = 3600; var wsfedIssuer = "http://fakeadfs.f5test.com/adfs/services/trust"; var SigningCert = "/fakeadfs.f5test.com.crt"; var SigningKey = "/fakeadfs.f5test.com.key"; /* Create a new rpc server for listening to TCL iRule calls. */ var ilx = new f5.ILXServer(); ilx.addMethod('Generate-WSFedToken', function(req,res) { /* Extract the ILX parameters to add to the Assertion data req.params()[0] is the first passed argument req.params()[1] is the second passed argument, and so on. */ var query = queryString.unescape(req.params()[0]); var queryOptions = queryString.parse(query); var AttrUserName = req.params()[1]; var AttrUserPrincipal = req.params()[2]; var wa = queryOptions.wa; var wtrealm = queryOptions.wtrealm; var wctx = queryOptions.wctx; /* This is where the WS-Fed gibberish is assembled. Moment is required to insert the properly formatted time stamps.*/ var now = moment.utc(); var wsfed_wrapper_head = "<t:RequestSecurityTokenResponse xmlns:t=\"http://schemas.xmlsoap.org/ws/2005/02/trust\">"; wsfed_wrapper_head += "<t:Lifetime><wsu:Created xmlns:wsu=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd\">" + now.format('YYYY-MM-DDTHH:mm:ss.SSS[Z]') +"</wsu:Created>"; wsfed_wrapper_head += "<wsu:Expires xmlns:wsu=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd\">" + now.add(timeout, 'seconds').format('YYYY-MM-DDTHH:mm:ss.SSS[Z]') + "</wsu:Expires>"; wsfed_wrapper_head += "</t:Lifetime><wsp:AppliesTo xmlns:wsp=\"http://schemas.xmlsoap.org/ws/2004/09/policy\"><wsa:EndpointReference xmlns:wsa=\"http://www.w3.org/2005/08/addressing\">"; wsfed_wrapper_head += "<wsa:Address>" + wtrealm + "</wsa:Address>"; wsfed_wrapper_head += "</wsa:EndpointReference></wsp:AppliesTo><t:RequestedSecurityToken>"; /* Generate and insert the SAML11 Assertion. These attributed are configured previously in the code. cert: this is the cert used for encryption key: this is the key used for the cert issuer: the assertion issuer lifetimeInSeconds: timeout audiences: this is the application ID for sharepoint, urn:sharepoint:webapp attributes: these should map to the mappings created for the IDP in SharePoint */ var saml11_options = { cert: fs.readFileSync(__dirname + SigningCert), key: fs.readFileSync(__dirname + SigningKey), issuer: wsfedIssuer, lifetimeInSeconds: timeout, audiences: wtrealm, attributes: { 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress': AttrUserName , 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn': AttrUserPrincipal } }; /* Sign the Assertion */ var signedAssertion = saml11.create(saml11_options); /* Add the WS-Fed footer */ var wsfed_wrapper_foot = "</t:RequestedSecurityToken><t:TokenType>urn:oasis:names:tc:SAML:1.0:assertion</t:TokenType><t:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</t:RequestType><t:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</t:KeyType></t:RequestSecurityTokenResponse>"; /* Put them all together */ var wresult = wsfed_wrapper_head + signedAssertion + wsfed_wrapper_foot; /* respond back to TCL with the complete assertion */ res.reply(wresult); }); /* Start listening for ILX::call and ILX::notify events. */ ilx.listen(); And thats it. You can now get away with WS-Fed and SAML1.1 assertions with a quick import to your BIG-IP.Powershell Script to automate base BIG-IP hardening, and STIG/SRG configuration.
Problem this snippet solves: Streamlines the Security Technical Implementations Guide & Security Requirements Guides for Federal Deployments of BIG-IP. Also, adds additional hardening configurations to BIG-IP. How to use this snippet: Before running this script, you will need set ScriptExecution policy level: Set-ExecutionPolicy RemoteSigned Then, run the script. The message boxes will guide you... Code : https://github.com/Mikej81/PowerSRG Tested this on version: 12.0US FEDERAL: DISA UCCO APL Certification
Great news! We have finally been posted to the Defense Information Systems Agency (DISA) Unified Capability (UC) Approved Product List (APL), as an IA Tool. The certification covers all F5 BIG-IP platforms (VE through Viprion) running a minimum of TMOS 11.6. The certification Memo can be found at the following link: DISA UC APL F5 Approval Memo Anyone that has been through the now defunct DoD Information Assurance Certification and Accreditation Process (DIACAP) or DoD Information Technology Security Certification and Accreditation Process (DITSCAP) in the past (1) knows it’s a party, and (2) may know that F5 BIG-IP used to be classified as a “Content Switch / Load Balancer with an OS of Other Network OS.” With the new APL certification, F5 is now classified as an IA tool. While the Certification and Accreditation process will look pretty much the same, things concerning the F5 are starting to change quite a bit. Change 1. F5 Military Unique Deployment Guide. This document helps identify and configure the BIG-IP base configuration required to pass IA scans. Change 2. There is much better clarification on which STIGS apply to F5 BIG-IP, and stronger guidance on how to configure your platform in adherence to STIG and Security Requirements Guidelines (SRG). Change 3. There is also the new National Institute of Standards and Technology (NIST) Risk Management Framework (RMF) process (DoD Instruction 8501.01). We didn’t have anything to do with this, but its new, and its important to know that we are in line with this process. Getting Started To start preparing the F5 BIG-IPs on your network, you should reach out to your account team to acquire a copy of the Military Unique Deployment Guide (MUDG), which details the proper base configuration. The MUDG can be acquired from any member of the F5 Federal team. However, due to sensitive information, a copy of the Information Assurance Assessment Package (IAAP) must be acquired directly from the Unified Capability Certification Office (UCCO), details on this information is located within the DISA UC APL Certification Memo. Next, Apply STIG/SRG. These are currently in process, but the MUDG is sufficient to lock the appliance down to pass initial IA scans. Draft STIG Release Guidance -Update: Final F5 STIG / SRG released, see below. There have been a lot of questions lately on the release of the Draft STIGS for BIG-IP. The important things to note are as follows: First and foremost, do not apply draft STIGS. These are drafts and not yet final. Do not start applying draft STIGS in production environments. Draft STIGS are subject to change. Finally, do not apply draft STIGS. To access and review the Draft STIGS, you can find them at the following location: http://iase.disa.mil/stigs/net_perimeter/network-infrastructure/Pages/network-overview.aspx Final STIG/SRG Release Guidance There have been a lot of questions lately on the release of the Final STIGS / SRGS for BIG-IP. The important things to note are as follows: It is important to first follow and apply the guidance provided in the Military Unique Deployment Guide v1.2 (MUDGv1.2). If you have any questions or concerns regarding the guidance or text in the F5 Final STIGS, do not hesitate to reach out to your account team. To access the Final F5 STIGS, you can find them at the following location: http://iase.disa.mil/stigs/net_perimeter/network-infrastructure/Pages/other.aspx Need Help? Contact Federal [at] F5.com.US FEDERAL: CCRI Season Lessons Learned
Tis the season for CCRI across the DoD landscape. It seems around this time every year, we start to get a lot of calls and emails concerning best practices for CCRI, STIG/SRG, and Federal Compliance. While we cant really help with things like IAT levels or application configurations, we can provide some lessons learned concerning any BIG-IP in your networks. So, first things first... What Is a CCRI? The CCRI is a thorough review of a Department of Defense entity’s cyber-readiness status conducted by DISA. The criteria for the review are based on several key industry standards, including DISA’s Security Technical Implementation Guides (STIGs), and various Chairman of the Joint Chiefs of Staffs Instruction (CJCSI) directives. Have (and configure) the right Hardware This comes up all the time. On DoD networks, if you are processing crypto on the BIG-IP, you need to have FIPS 140-2 Key Storage, not just cipher support; e.g. STIG ID SRG-APP-000179-NDM-000265. If you are on DREN, you may have some slack. If you are NOT processing crypto (layer 4 and below traffic only) then you might be ok. Also, it is not just a checkbox. The ciphers need to be configured in the SSL profiles, and the private keys need to be imported to the HSM. Baseline the BIG-IP There are several steps everyone should take to baseline your BIG-IP for security audits in the Federal space. First, the device needs to be on an approved (preferably maintenance) release, meaning 11.5.3 or higher. (Most of the SRGS were written with 12.0 in mind.) Second, run the NIST SP 800-53r4 iApp. A guide can be located at the following link. https://www.f5.com/pdf/deployment-guides/nist-sp-800-53-r4-dg.pdf Third, follow the Military Unique Deployment Guide, available from the F5 Federal Account team, or from the UCCO FSO with the Conditions of Fielding. This guide was originally written with 11.6 in mind, but most configurations still apply. Optional, there is an open source PowerShell script available on GITHUB, which covers many of the items in the MUDG, as well as several additional hardening configurations. This is provided as is, with no support. https://github.com/Mikej81/PowerSRG Remediate and/or POA&M Now that the BIG-IP is configured, there may still be some items that come up after or between the current guidance. There is a BIG-IP POA&M Document available from the F5 Federal Account Team, which details False Positives and remediations for findings. For any new CVE or findings not currently documented, it is possible to use Google to search for "official" guidance from F5 on support.f5.com. If a SOL does not currently exist for a finding, immediately open up a support case, and contact your F5 Account Team. Be Prepared The CCRI process can be long, and painful, if you are not properly prepared. Have your devices baselined ahead of time. Reach out to your account team for updated documents or any questions. A Couple of Notes The SRGS/STIGS are largely based on TMOS v12, while the MUDGv1.2 is largely based on TMOS 11.X (mostly 11.6). This happened due to timing issues, but we are working on resolving that as soon as we can. There is no magic wand, yet. The PowerShell script is a big help in most of the tests, but it does not account for everything. If you have an idea, send an email, or offer up some code on github. And finally, good luck!US FEDERAL: Enabling Kerberos for Smartcard Authentication to Apache.
The following provides guidance on the configuration of BIG-IP Local Traffic Manager and Access Policy Manager in support of Apache Web Server Smartcard / Kerberos access using Active Directory as the Key Distribution Center. This content is part of a series developed to address the configuration of non IIS webservers to support Kerberos Single Sign On and therefore smartcard access, but should be relevant anywhere SSO utilizing Kerberos is needed. Several assumptions are made concerning the implementation of Active Directory, PKI, and the Linux Distro(s) used. Base Software Requirements The following base requirements are assumed for this configuration. Microsoft Windows Server 2008 R2 (Active Directory) BIG-IP LTM 11.4 or higher (the configuration items will probably work with most versions of 11 but only 11.4 and 11.5 were tested in the scenario) Ubuntu Server 13.10 (This is a fairly simple and user friendly distro based on Debian, this was also tested in RHEL/CentOS.) This config will work in other distro’s of Linux, but posting all the difference configurations would just be redundant. If you need help, reach out to the US Federal Team. How it Works The configuration of this scenario is fairly simple. The majority of the configuration and testing will most likely reside on the Linux side. The client access and authenticates to APM via a smartcard. Depending on the method of choice, an attribute identifying the user is extracted from the certificate and validated against an AD/LDAP. In Federal, this step has two purposes; to extract the UPN to query AD for the User (EDIPI@MIL), and to retrieve the sAMAccountName to use for the Kerberos Principal. Once the user has been validated and the sAMAccountName retrieved, the session variables are assigned and the user is granted access. Base Linux Configuration Configure Static IP & DNS You can use the text editor of your own preference, but I like nano so that is what I will document. sudo nano /etc/network/interfaces You will want to change iface eth0 inet dhcp to static, and change the network settings to match your environment. Since this scenario uses Windows AD as the KDC, you will want to make sure your DNS points to a domain controller. auto eth0 iface eth0 inet static address 192.168.1.2 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 dns-nameservers 192.168.1.1 Note: Depending on your distro, you will use dns-nameservers or resolv.conf. I also removed the DHCP client entirely. (Not necessary, but I like to clean out things I wont ever use.) Restart networking sudo /etc/init.d/networking restart Or sudo service networking restart Install LAMP (Linux, Apache, MySQL, PHP) In Ubuntu, this is fairly simple, you can just do the following. sudo tasksel Then check the box for LAMP, and follow the on-screen instructions, set MySQL password, and then you are done. If you access the IP of your server from a browser, you will see the default Apache "It Works!" page. Install & Configure Kerberos sudo apt-get install krb5-user Some distros will ask for default REALM, KDC, and Admin server configs. In my case it is F5LAB.LOCAL, 192.168.1.5, 192.168.1.5. krb5.conf Depending on your distro, there will be a ton of extra settings in the krb5.conf file, some related to Heimdal and some for MIT Kerberos. The core settings that I needed for success are listed below. [libdefaults] Set your default realm, DNS lookups to true, and validate the encryption types. HMAC is good, Windows does not have DES enabled by default and you should not consider enabling it. default_realm = F5LAB.LOCAL dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = true default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc des3-hmac-sha1 default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc des3-hmac-sha1 [realms] KDC: Domain Controller admin_server: Not required, but can also point o Domain Controller default_domain: Kerberos Realm F5LAB.LOCAL = { kdc = 192.168.1.5:88 admin_server = 192.168.1.5 default_domain = F5LAB.LOCAL } Install Mod_Auth_Kerb This is required to make Apache support Kerberos. Some distros include this when you load apache, but here is how you make sure. sudo apt-get install libapache2-mod-auth-kerb Testing Lets make sure that we configured networking and Kerberos properly. Use KINIT to test a known user account. This should reach out to the KDC to get a ticket for the user. REALMS are case sensitive, so make sure its all upper case. The following will request a password for the user, and if everything is set up properly, there will be no response. kinit mcoleman@F5LAB.LOCAL You can run KLIST to see your ticket. klist An example of what happens when the REALM is entered incorrectly: KDC reply did no match expectations while getting initial credentials. Windows Configurations Configuring SPNs Since Linux is not the KDC or Admin server, this is done on the Active Directory side. Create a user account for each application, with the appropriate Service Principal Names. Be aware, when we run keytab, all SPNs will be overwritten, with the exception of the SPN used in the command. Crypto Pay attention to the encryption types that are / were enabled in the krb5.conf file. It is important to remember that both DES cipher suites (DES-CBC-MD5 & DES-CBC-CRC) are disabled by default in Windows 7.The following cipher suites are enabled by default in Windows 7 and Windows Server 2008 R2: AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96 RC4-HMAC For the purposes of this guide and the available settings in Windows use RC4-HMAC. DO NOT enable DES on Windows. Create a Keytab Keytabs can be created in windows by using ktpass. A keytab is a file that contains a Kerberos Principal, and encrypted keys. The purpose is to allow authentication via Kerberos, without using a password. ktpass –princ HTTP/lamp.f5lab.local@F5LAB.LOCAL -mapuser F5LAB\apache.svc -crypto RC4-HMAC-NT -pass pass@word1 -ptype KRB5_NT_PRINCIPAL -kvno 0 -out LAMP.keytab Copy the keytab to your linux server(s). For my use case I put the keytab at /etc/apach2/auth/apache2.keytab Lock it down - Linux The security of a keytab is pretty important. Malicious users with access to keytabs can impersonate network services. To avoid this, we can secure the keytab’s permissions. sudo chown www-data:www-data /etc/apache2/auth/apache2.keytab sudo chmod 400 /etc/apache2/auth/apache2.keytab Testing Now, we want to make sure everything is looking alright so far. So lets make sure the keytab looks right, and we can authenticate properly against the KDC. List the contents of the Keytab klist –ke /etc/apache2/auth/apache2.keytab Test Authentication with the S4U SPN The following commands can be used to initialize the credential cache for the S4U proxy account and then to test authentication with a user account. kinit –f http/lamp.f5lab.local@F5LAB.LOCAL kvno http/lamp.f5lab.local@F5LAB.LOCAL sudo klist –e –k –t /etc/apache2/auth/apache2.keytab kvno –C –U mcoleman http/lamp.f5lab.local Apache Configurations I was able to get authentication working by adding the following to the default site. In Ubuntu its /etc/apache2/sites-enabled/000-default.conf. <VirtualHost *:80> … <Location /> Options Indexes AllowOverride None Order allow,deny allow from all AuthType Kerberos #KrbServiceName HTTP/lamp.f5lab.local@F5LAB.LOCAL AuthName "Kerberos Logon" KrbMethodNegotiate on KrbMethodK5Passwd on KrbVerifyKDC off KrbAuthRealm F5LAB.LOCAL Krb5KeyTab /etc/apache2/auth/apache2.keytab require valid-user </Location> </VirtualHost> BIG-IP Configurations This portion is actually pretty straightforward. Configure a standard Virtual Server with a Pool pointing at the Apache Servers. Configuration Items • Kerberos SSO Profile – This is used to authenticate to Apache. • Access Profile – The Access profile binds all of the APM resources. • iRule – an iRule is used to extract the smartcard certificate User Principal Name (UPN). • ClientSSL Profile - This is used to establish a secure connection between the user and the APM VIP. Apply the server certificate, key, and a trusted certificate authority’s bundle file. All other settings can be left at default. • HTTP profile – This is required for APM to function. A generic HTTP profile will do. • SNAT profile – Depending on other network factors, a SNAT profile may or may not be necessary in a routed environment. If the backend servers can route directly back to the clients, bypassing the BIG-IP, then a SNAT is required. • Virtual server –The virtual server must use an IP address accessible to client traffic. Assign a listener (destination) IP address and port, the HTTP profile, the client SSL profile, a SNAT profile (as required), the access profile, and the iRule. Modify the krb5.conf [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes APM Kerberos SSO Profile Create an APM Kerberos SSO profile like the one shown below. Change the Username Source to “session.logon.last.username”, enter the Active Directory domain name (in all upper case), enter the full service principal name of the AD user service account previously created , and enter the account’s password. The only real change from IIS is the Send Authorization setting, which should be set to “On 401 Status Code.” Username Source: session.logon.last.username User REALM Source: session.logon.last.domain Kerberos REALM: F5LAB.COM KDC(optional): Account Name: HTTP/lamp.f5lab.com Account Password: password Confirm Account Password: password SPN Pattern (optional): Send Authorization: On 401 Status Note: The full service principal name includes the service type (ex. host/), the service name (ex. krbsrv.alpha.com), and the domain realm name (ex. @ALPHA.COM – in upper case). KDC can be specified, but is not needed unless you do not configure DNS lookup enabled in the krb5.conf on the F5. Basically, if you dont tell the F5 how to resolve the KDC, then you need to specify one. SPN Pattern can help resolve issues if you have issues with DNS/rDNS. You can specify which SPN you want to sent with either a designated, or dynamic option. VPE configuration The components of the VPE are as follows: • On-Demand Cert Auth – Set this to Require. • Rule event – Set the ID to “CERTPROC” to trigger the EDIPI extraction iRule code. • LDAP Query – Validates the UPN and retrieves sAMAccountName. Basic CAC iRule when ACCESS_ACL_ALLOWED { #Set Username to value of sAMAccountName extracted from LDAP Query. ACCESS::session data set session.logon.last.username [ACCESS::session data get "session.ldap.last.attr.sAMAccountName"] } when ACCESS_POLICY_AGENT_EVENT { switch [ACCESS::policy agent_id] { #Name of iRule event called from APM Policy "CERTPROC" { if { [ACCESS::session data get session.ssl.cert.x509extension] contains "othername:UPN<" } { #Set temporary session variable to value extracted from X.509 data. set tmpupn [findstr [ACCESS::session data get session.ssl.cert.x509extension] "othername:UPN<" 14 ">"] ACCESS::session data set session.custom.certupn $tmpupn #log local0. "Extracted OtherName Field: $tmpupn" } } } } Put it together. Now that all the functional parts are in place, you can test access to Apache. If you want to add some code to see what user is hitting your application, you can create a small PHP page containing the following code. $_SERVER['REMOTE_USER'] $_SERVER['KRB5CCNAME'] The server variables will echo the current authenticated user name. Troubleshooting Kerberos is fairly fault-tolerant, if the requisite services are in place. That being said, it can be a PITA to troubleshoot. If Kerberos authentication fails, check the following: The user has a valid ticket. Use klist, kinit, and kvno as explained previously. Validate basic network connectivity. DNS (Forward & Reverse), ensure no duplicate A or PTR records. This can be overwritten in the Keberos SSO profile SPN pattern settings. Verify the clocks of the KDC and local server are synced. Turn APM SSO logging up to debug and tail the APM logs (tail -f /var/log/apm). Questions? Contact the US Federal team, Federal [at] f5.com.
