NTLM Configuration error
Hi, I'm trying to configure NTLM, and for the machine account i face the following error, domain join for 'HAZA' failed: Operations error, base: CN=Computers,dc=LDAP-IBRAHIM,dc=TEST, scope: 0, filter: (objectClass=*) (1) I the below the last few packets before F5 (192.168.5.99) closes the connection with LDAP (192.168.5.155), I really don't know what i missed.....NTLM Machine Account Issues - APM
Good afternoon - I am hoping someone can point me in the right direction. I'm trying to use the iApp to deploy RDP Gateway using APM (using this template - ). Part of the config is to create a new NTLM Machine account. I had no issues creating the account - and the iApp deployment went swimmingly well. I also verified that the machine account showed up in AD as a computer account. However, I am seeing these errors in the APM logs: May 15 17:40:32 f5lab debug nlad[6379]: 01620000:7: <0x56900b70> nlclnt[2a8e2c794]: is now initializing. May 15 17:40:32 f5lab debug nlad[6379]: 01620000:7: <0x56900b70> NLAD_TRACE: cli_full_connection(output_cli = (nil), my_name = "F5LAB", dest_host = "domaincontroller.domain.local", port = 445, service = "IPC$", service_type = "IPC", user = "F5LAB$", domain = "DOMAIN") May 15 17:40:32 f5lab debug nlad[6379]: 01620000:7: <0x56900b70> NLAD_TRACE: cli_full_connection(output_cli = (nil)) = 0xC000006D May 15 17:40:32 f5lab err nlad[6379]: 01620000:3: <0x56900b70> nlclnt[2a8e2c794] init: Error [0xc000006d,NT_STATUS_LOGON_FAILURE] connecting to DC 10.11.12.13 I also cannot renew the NTLM account password from the GUI as I get this error: Could not connect to domain domain controller of realm 'domain.local' machine account update for 'f5lab' failed: Preauthentication failed, principal name: f5lab@domain.local. Invalid user credentials. (-1765328360) I'm running on 12.1.3.4 and have tried the following: Recreated the NTLM account, multiple times. I know I have permissions as the account does show up in AD, and I do have domain admin level permissions Restarted the eca service (bigstart restart eca) Restarted the nlad service (bigstart restart nlad) Restarted the F5 appliance itself. Verified that the DNS settings are configured properly. The F5 is able to resolve the domain controller IP from the alias. No firewall exists between this F5 and the domain controller. Has anyone seen this and if so - can anyone point me in the right direction? I thought I'd try here before opening a support ticket with F5.
Outlook Anywhere and NTLM authentication
Hello, I am trying to achieve Outlook Anywhere with basic-NTLM and Kerberos SSO. I followed the DG and am stucked at NTLM authentication. When I create the NTLM Machine Account the logs say that it joined the domain, then I create the NTLM Auth Configuration with my domain and DCs. After that I see this messages in the logs: nlad[11851]: 01620000:3: <0x2b3374f71700> nlclnt[12a02a8c0] init: Error [0xc000006d,NT_STATUS_LOGON_FAILURE] connecting to DC 192.168. I added some Exchange groups to the machine account and enabled delegation for http with Exchange servers. I then try to renew machine account password but I have this error: adutil[16625]: 01490274:5: (null):Common:00000000: New master key received. adutil[16625]: 01490200:3: ERROR: Could not connect to domain domain controller of realm 'EXAMPLE.AD' adutil[16625]: 01490200:3: WARNING: machine account update for 'f5apm' failed: Preauthentication failed, principal name: f5apm@EXAMPLE.AD. Invalid user credentials. (-1765328360) Then I took a look at Kerberos trafic and could see that the bigip can't get a Kerberos ticket: At this step I am not even talking about Kerberos SSO which I think has nothing to do with NTLM. I have found K33692321 but it doesn't help. I also took a look at K08915521. It says that it may be a domain name or NetBIOS name issue but I know that my domain is EXAMPLE.AD and NetBIOS EXAMPLE. Does someone already managed to make this work ? It is a standard configuration so am I missing something Windows side ? Best regards
ECA plugin documentation in the wiki
I'm running 11.4.1 and trying to figure out NTLM auth. I'm following a guide I found on devcentral but it's not working for me. I see there's a plugin ECA that enables NTLM authentication, however the documentation is...well, not present. The Wiki says that 11.3.0 introduced "ECA::metadata" however when I try using that in my iRule I get a syntax error: 01070151:3: Rule [/XXX/ntlm-auth-iRule] error: /XXX/ntlm-auth-iRule:44: error: [undefined procedure: ECA::metadata][ECA::metadata select_ntlm:$static::ntlm_config] So apparently ECA::select works - by which I mean that I get no errors when I save the iRule. However, the iRule is not working. I am having a hard time troubleshooting because ECA is such a black box.
NTLM Authentication issue
Hi, I'm setting up APM for authentication for Exchange 2013. In certain scenarios NTLM authentication is used to authenticate the client, and SSO via kerberos at the back end. This all works fine. The issue is that the NTLM machine account password sometime expires and is not automatically renewed, causing NTLM auth to fail. If I manually re-new the password all is fine again. So my main questions is: Does F5 not automatically renew its NTLM machine auth password? The policy in AD for the machine account is all default settings (30 days lifetime I think). Side question: How is NTLM machine auth password synced in a HA environment? At the moment we use manual sync, and based on the timestamps for the NTLM machine auth password a new password is synced to the standby device when you sync configuration. Assuming you have renewed the password and NOT synced the configuration, and then failover to to the other BIGIP, will NTLM auth fail? (Thus requiring automatic sync?) ThanksMixed APM authentication
Hi Folks, I'm tasked to create a unified APM Policy which is able to support the authentication methods below. Forms (For Browsers) Negotiate via Kerberos-Ticket (for Kerberos enabled clients) Negotiate via NTLM (Fallback if Kerberos-Ticket can not obtained) NTLM (Fallback for Negotiate unaware clients) Basic (Fallback of last resort) Performing selectively Forms, Negotiate via Kerberos, NTLM and Basic can be easily adopted reading available information. But "Negotiate via NTLMSSP" is somehow not supported by F5, or at least I cant find any information how to teach APM or ECA to consume negotiated NTLMSSP messages. Before I start to develop a solution by myself, I would like to ask if someone has already a working iRule to support "Negotiate via NTLM" authentication as a fallback in the case the client is unable to provide Kerberos-Tickets (e.g. client is not domain joined, local useraccount is used, DC is not reachable, SPN does not exist, etc.)? Cheers, Kai
Leveraging BIG-IP APM for seamless client NTLM Authentication
Many customers express interest to use F5 Access Policy Manager for transparent seamless authentication for their users. There are a couple of leading use cases that drive that desired behavior: Providing silent seamless authentication to Windows-based applications such as Exchange or Sharepoint from the domain-joined machines. The premise is is that if the user is logged in to their domain-joined machine, no matter where they are, they should be able to perform seamless NTLM authentication to their applications such as Sharepoint based on the Windows Integrated Authentication settings. Providing SAML Identity Provider services with APM. When users access SAML-enabled applications, they are asking for SAML assertions. Because APM can act as either native SAML 2.0 IDP or as a proxy to other SAML IDPs such as ADFS, for example, customer desire silent authentication to those IDP services from the domain-joined machines in order to seamlessly enable to SaaS applications such as Office 365, SalesForce.com, Google Apps, etc. APM can perform three types of 401-based challenge authentication: Basic, NTLM, and Kerberos. Basic always requires user’s intervention, but 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 such as Sharepoint, 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. Today, we are going to examine the second use case on how to configure APM to perform client NTLM authentication and use it in the context of sending a SAML assertion to the Office 365 service. It is assumed below that user knows how to configure APM for standard forms-based authentication and also has at least one existing policy(although you can create a new one from the scratch). One of the easiest ways to test this is to deploy the Office 365 configuration using the iApp and the modify configuration to enable NTLM authentication. The steps below assume that you either have a working Office 365 configuration based on the iApp, or you have an equivalent policy that you can modify. First, and foremost, we need to create an NTLM Machine Account object. Under Access Policy, go to Access Profiles->NTLM->Machine Account, and click on Create to join the BIG-IP to the domain and create unique computer object in Active Directory Keep in mind that you will need to create a unique account in Active Directory for your BIG-IP. In the example above, the account name is bigip1. Create a “NTLM Auth Configuration” using the above machine account name. Under Access Policy, go to Access Profiles->NTLM->NTLM Auth Configuration and click on Create. Give the configuration the name, select the Machine Account Name value based on the object you created in Step 1, and add as many FQDNs for the AD domain controllers in your infrastructure Now we need to create an iRule that will help us handle NTLM authentication to the BIG-IP properly. You need to modify the sec on cline of the RULE_INIT event to match the name of the NTLM Auth configuration you created in step 2. You will also need to replace all instances of appname with a unique identifier. Go to Local Traffic->iRules->iRules List and click on Create. Give the iRule name of “ntlm-auth-iRule” and paste the iRule into the BIG-IP: when RULE_INIT { set static::appname_ntlm_retries 2 set static::appname_ntlm_config "/Common/appname_ntlm_config" set static::appname_access_log_prefix "01490000:7:" set static::appname_ntlm_on_demand_prfx "$static::appname_access_log_prefix \[NTLM-ON-DEMAND\]" } when ACCESS_SESSION_STARTED { ACCESS::session data set "session.ntlm.last.retries" 0 } when HTTP_REQUEST { log -noname accesscontrol.local1.debug "$static::appname_ntlm_on_demand_prfx Request: [HTTP::uri]" switch -glob -- [string tolower [HTTP::uri]] { "/ntlm/auth" { set sid [ACCESS::session sid] log -noname accesscontrol.local1.debug "$static::appname_ntlm_on_demand_prfx sid: $sid" set referer [HTTP::header value Referer] log -noname accesscontrol.local1.debug "$static::appname_ntlm_on_demand_prfx Referer: $referer" set x_session_id [ HTTP::header value X-Session-Id ] if { [ string length $x_session_id ] != 0 } { set sid $x_session_id } set retries [ACCESS::session data get -sid $sid "session.ntlm.last.retries"] log -noname accesscontrol.local1.debug "$static::appname_ntlm_on_demand_prfx retries: $retries" set auth_result [ACCESS::session data get -sid $sid "session.ntlm.last.result"] log -noname accesscontrol.local1.debug "$static::appname_ntlm_on_demand_prfx auth result: $auth_result" if { ($auth_result == 1) || ($retries == $static::appname_ntlm_retries) && ($auth_result != 1) } { ECA::disable log -noname accesscontrol.local1.debug "$static::appname_ntlm_on_demand_prfx Redirect to: $referer" HTTP::redirect "$referer" } else { ECA::enable ECA::select select_ntlm:$static::appname_ntlm_config } unset x_session_id unset referer } default { ECA::disable } } } when CLIENT_ACCEPTED { set second_pass pass[IP::client_addr][TCP::client_port] # Check if this is the first or second time passing through this virtual if { [ table lookup $second_pass ] == "1" } { set wait_timeout 3000 set wait_delay 100 set wait_total 0 set disable_ssl disablessl[IP::client_addr][TCP::client_port] # Wait for SERVER_CONNECTED event to complete while { [ table lookup $disable_ssl ] != 0 && [ table lookup $disable_ssl ] != 1 && $wait_total < $wait_timeout } { set wait_total [ expr "$wait_total + $wait_delay" ] after $wait_delay } unset wait_delay wait_timeout # Check table value set by SERVER_CONNECTED to disable ssl set disable_ssl_value [ table lookup $disable_ssl ] if { $disable_ssl_value == "1" } { set command "SSL::disable" eval $command unset command } elseif { $disable_ssl_value != 0 } { log -noname accesscontrol.local1.notice "$static::appname_ntlm_on_demand_prfx Error: SERVER_CONNECTED event not completed after $wait_total ms" } table delete $disable_ssl table delete $second_pass unset disable_ssl wait_total } else { # This is the first time through this virtual. Set clientssl flag set client_ssl clientssl[IP::client_addr][TCP::client_port] if { [ catch { PROFILE::clientssl name } ] } { table add $client_ssl "0" } else { table add $client_ssl "1" } unset client_ssl } unset second_pass } when SERVER_CONNECTED { set client_ssl clientssl[IP::client_addr][TCP::client_port] set disable_ssl_value 0 # Check clientssl flag set from CLIENT_ACCEPTED. if { [ table lookup $client_ssl ] == "1" } { if { [ catch { PROFILE::serverssl name } ] } { # Clientssl is present but serverssl is not. Disable clientssl set disable_ssl_value 1 } table delete $client_ssl } set disable_ssl disablessl[IP::client_addr][TCP::client_port] table add $disable_ssl $disable_ssl_value unset disable_ssl unset client_ssl disable_ssl_value } when ECA_REQUEST_ALLOWED { log -noname accesscontrol.local1.debug "$static::appname_ntlm_on_demand_prfx NTLM Auth succeed" ACCESS::session data set session.ntlm.last.username "[ECA::username]" ACCESS::session data set session.ntlm.last.domainname "[ECA::domainname]" ACCESS::session data set session.ntlm.last.machinename "[ECA::client_machine_name]" ACCESS::session data set session.ntlm.last.status "[ECA::status]" ACCESS::session data set session.ntlm.last.result 1 ACCESS::disable HTTP::header insert X-Session-Id $sid log -noname accesscontrol.local1.debug "$static::appname_ntlm_on_demand_prfx use virtual: [ virtual name ]" # Set flag for next CLIENT_ACCEPTED telling it that it is the second pass through virtual set second_pass pass[IP::client_addr][TCP::client_port] table add $second_pass "1" unset second_pass # Connect to itself in order to generate HTTP response use virtual [ virtual name ] } when ECA_REQUEST_DENIED { log -noname accesscontrol.local1.debug "$static::appname_ntlm_on_demand_prfx NTLM Auth succeed" if { [ACCESS::session data get session.ntlm.last.retries] != $static::appname_ntlm_retries } { incr retries ACCESS::session data set session.ntlm.last.retries $retries } } After creating this iRule, assign it to the APM Virtual Server. Now you can create or modify your existing policy as below. Let’s examine how the policy depicted below is structured. The assumption is that the policy is going to be used to authenticate both internal and external users. If the users are coming in from the internal corporate network, we want to steer them straight to the NTLM authentication, if not, we want to use forms-based login for to authenticate them. I’ve started the policy with IP Subnet Match action to steer clients from certain networks to the NTLM authentication. One the desired source networks are matched, we move on to an External Login Page object that will send user back to the APM virtual and request NTLM authentication. Let’s examine how the policy depicted above is structured. The assumption is that the policy is going to be used to authenticate both internal and external users. If the users are coming in from the internal corporate network, we want to steer them straight to the NTLM authentication, if not, we want to use forms-based login for to authenticate them. I’ve started the policy with IP Subnet Match action to steer clients from certain networks to the NTLM authentication. Once the desired source networks are matched, we create an External Login Page object that will send user back to the APM virtual and request NTLM authentication. After sending the user to the “external login page”, which in fact is just a request to the same virtual server that is handled by the iRule that enables NTLM authentication between the client and BIG-IP, we need to check the status of the NTLM authentication, so we add the “NTLM Auth Result Check” action to see if the NTLM authentication was successful. If so, we need to populate the username session variable to enable APM to use it in session reporting/tracking, SAML assertion, SSO, etc. Now you can assign necessary resources to the user session. In this example, we are assigning APM to act as the IDP to Office 365. After you finished creating or modifying the Access Policy, make sure it is assigned to the APM virtual. Now we need to associate a ECA profile with the Virtual Server in order to enable NTLM functionality. This assignment needs to be performed via the command line. Establish an SSH connection in the box and enter TMSH and type the following commands, substituting the name of your virtual server for the highlighted portion /sys modify /ltm virtual NTLM-AUTH-vs profiles add { eca } save config list /ltm virtual NTLM-AUTH-vs Note the ‘eca’ profile associated with the virtual server 6. Next, we need to modify how the virtual server handles preservation of the original source port of the connection. This can be done either from the BIG-IP Administrative interface, or from the command line. Both examples are shown below. Command Line Interface Using the same SSH session as established in Step 5, type the following commands substituting the name of your virtual server for the highlighted portion: modify /ltm virtual NTLM-AUTH-vs source-port preserve-strict save /sys config BIG-IP Administrative Interface From the main menu, go to Local Traffic > Virtual Servers > Virtual Server List. Click on the APM virtual server. Under Configuration, select Advanced. For Source Port, select Preserve Strict. Click Update.” 7. Last, but not least, you need ensure that the machine you’re using to achieve the silent sign-on has the APM Virtual FQDN added to its Local Intranet zone as per the picture below. Voila! You should be all set. Point your browser on the machine to the FQDN of the APM Virtual Server where you assigned the new policy and iRule, and you should be silently authenticated. If you are interested in performing SSO to applications such as Sharepoint, you will need to setup Kerberos SSO in order to perform single sign-on to the Sharepoint based on the NTLM authentication.APM Forms-based logon with NTLM SSO Backend
I've been fighting this a bit and not finding the solution on other DevCentral Articles. Goal Synopsis: User opens internet portal page. Presented with Forms-based login page, user enters this username (e.g. firstinital.lastname) and password A chain of 5 AD forests is tested against this username. On Success, the F5 passes NTLM auth to a backend webserver, in this instance sharepoint 2016. What's working: Everything up until the SSO mapping/ntlm result which needs to be passed to sharepoint. Below is the flow I've made, NTLM auth result I threw in as a test, the message boxes are just debug to see which branch is hit without digging in logs. The All AD Auth is the AD chain I mentioned, I'm also assigning a variable after each success to set the session.logon.last.domain to the corresponding AD in case it's needed later in the chain. I'm also doing a basic 401 challenge for internal NTLM and redirecting to either internal or logon page based on client IP. Backend things: BIG-IP 13.1.1.2 Build 0.0.4 Point Release 2 NTLMv2 SSO is on the SSO cred mapping, however, it's targeting 1 domain only. This one domain is the hub in a hub/spoke AD trust layout, so any user from any domain can auth to it. I'm using iRules to handle the resource assignment since I'm directing to pools based on the hostname requested (we have a lot, it's annoying), but isn't an issue. I've not set up that one NTLM setting I can't remember off the top of my head that can only be done via TMM CLI because I could only find it mentioned in version 11 or older BIG-IPs. Next Steps: I'm really not sure, everything I've been finding says this should be working but it's not and I can't find anything on DevCentral that matches what I'm trying to do. It's all either been 401 challenge pages or something to do with SSO to MS Exchange. So I'm throwing this on here hoping someone has an idea as to what I'm missing.
APM different authentication mechanism based on Hostname
Hello, i wanted to know if it is possible to have for example two different authentication mechanism in one Access Profile and based on the URL which i enter the APM decides which one is used. Configuration: - One virtual server, assigned with the ECA profile in order to use NTLM authentication ltm virtual vs_app-login-sso { description "App for LDAP Login and NTLM SSO" destination 10.254.3.181:https ip-protocol tcp mask 255.255.255.255 pool pool_app-qual profiles { Login_SSO { } clientssl-insecure-compatible { context clientside } eca { } http_redirect_rewrite_all { } rba { } tcp { } websso { } } rules { irule_ECA_NTLM_Auth } source 0.0.0.0/0 source-address-translation { type automap } translate-address enabled translate-port enabled vs-index 17 } iRule: when HTTP_REQUEST { ECA::enable ECA::select select_ntlm:/Common/ntlm_auth } And here is the Access Profile: So the first entry point is "Landing URI", the profile should decide when i come with the Login URL it should use LDAP Login Page and if i come with the SSO URL it should use NTLM. Both authentication are working when they are used in seperate profiles but not combined in one. Is this possible or not? Hope everything is described clearly, if not just ask :) Thanks, Christoph
