Controller Based WLANs

How do I troubleshoot NTLM client authentication failures on an Aruba Mobility_Controller?

by on ‎07-08-2014 11:09 AM

Question:  How do I troubleshoot NTLM client authentication failures on an Aruba Mobility_Controller?

 

Product and Software: This article applies to all Aruba Mobility Controllers and ArubaOS 3.4.1 and later.
NT LAN Manager (NTLM) authentication works by snooping on NTLM exchange between client and server. When the authentication is successful, the user role is changed to the NTLM default role (configured in the 'stateful-ntlm' profile).

To troubleshoot NTLM client authentication failures on an Aruba Mobility Controller, follow these steps:

1) Ensure that the client is actually using NTLM as the domain mechanism. For Microsoft Windows hosts starting from Window 2000, Kerberos is the default authentication mechanism. In these cases, the client will be stuck in the initial role (configured in 'aaa' profile). Refer to Microsoft documentation to enable NTLM authentication for Windows server and Windows clients.

2) Ensure that the configuration is correct and that the correct stateful-ntlm profile is associated with the initial role. The initial role should have rules that enable ArubaOS to snoop on NTLM frames in addition to allowing DHCP, DNS, and NetBIOS and other control protocols as shown in the following example. Here 'logon-ntlm' is initial role.
(DHLN-O) #show rights logon-ntlm
Derived Role = 'logon-ntlm'
Up BW:No Limit Down BW:No Limit
L2TP Pool = default-l2tp-pool
PPTP Pool = default-pptp-pool
Periodic reauthentication: Disabled
ACL Number = 42/0
Max Sessions = 65535
Stateful-NTLM profile = ntlm-sd
access-list List
----------------
Position Name Location
-------- ---- --------
1 stateful-ntlm
2 control-ntlm
stateful-ntlm
-------------
Priority Source Destination Service Action TimeRange Log Expired Queue TOS 8021P Blacklist Mirror DisScan
-------- ------ ----------- ------- ------ --------- --- ------- ----- --- ----- --------- ------ -------
1 any 192.168.62.100 tcp 445 redirect opcode 130 Low
2 any 192.168.62.100 tcp 139 redirect opcode 130 Low
control-ntlm
------------
Priority Source Destination Service Action TimeRange Log Expired Queue TOS 8021P Blacklist Mirror DisScan
-------- ------ ----------- ------- ------ --------- --- ------- ----- --- ----- --------- ------ -------
1 user any udp 68 deny Low
2 any any svc-icmp permit Low
3 any any svc-dns permit Low
4 any any svc-dhcp permit Low
5 any any svc-netbios-dgm permit Low
6 any any udp 137 permit Low
Expired Policies (due to time constraints) = 0


As in the example, 192.168.62.100 is a Windows 2003 domain server. All traffic to this IP address on tcp ports 139 and 445 is configured for snooping by setting action to 'redirect opcode 130'. The ACL 'control-ntlm' permits control protocols.

To quickly verify the configuration, follow these steps:

a) Ensure that the Windows server is configured correctly and added to server group by issuing these commands:
show aaa authentication-server windows <windows-server-name>
show aaa server-group
Examples
(DHLN-O) #show aaa authentication-server windows sd-dc

Windows Server "SD-DC"
----------------------
Parameter Value
--------- -----
Host 192.168.62.100
Mode Enabled


(DHLN-O) #show aaa server-group sg-sd-dc-ntlm

Fail Through:No
Auth Servers
------------
Name Server-Type trim-FQDN Match-Type Match-Op Match-Str
---- ----------- --------- ---------- -------- ---------
sd-dc Windows No
Role/VLAN derivation rules
---------------------------
Priority Attribute Operation Operand Type Action Value Validated
-------- --------- --------- ------- ---- ------ ----- ---------

b) Verify the NTLM profile configuration for the server-group and default role.
show aaa authentication stateful-ntlm <ntlm-profile-name>
Example

(DHLN-O) #show aaa authentication stateful-ntlm ntlm-sd

Stateful NTLM Authentication Profile "ntlm-sd"
----------------------------------------------
Parameter Value
--------- -----
Default Role authenticated-ntlm
Server Group sg-sd-dc-ntlm
Timeout 10 sec

c) Ensure that the NTLM profile is associated with initial role by issuing the 'show rights <name-of-initial-role>', as shown in the previous output.

d) Verify the configuration of the aaa profile used for wired authentication vis-a-vis initial role.
show aaa profile <name-of-profile>
show aaa authentication wired
Example

(DHLN-O) #show aaa profile aaa-wired-ntlm

AAA Profile "aaa-wired-ntlm"
----------------------------
Parameter Value
--------- -----
Initial role logon-ntlm
MAC Authentication Profile N/A
MAC Authentication Default Role guest
MAC Authentication Server Group default
802.1X Authentication Profile N/A
802.1X Authentication Default Role guest
802.1X Authentication Server Group N/A
RADIUS Accounting Server Group N/A
XML API server N/A
RFC 3576 server N/A
User derivation rules N/A
Wired to Wireless Roaming Enabled
SIP authentication role N/A


(DHLN-O) #show aaa authentication wired
Wired Authentication Profile
----------------------------
Parameter Value
--------- -----
AAA Profile aaa-wired-ntlm

3) On the Aruba Mobility Controller, client authentication can be debugged by client MAC address by issuing the configuration mode commands:

logging level debugging user-debug <mac_address>


Example

(DHLN-O) #configure terminal
Enter Configuration commands, one per line. End with CNTL/Z
(DHLN-O) (config) #logging level debugging user-debug <mac_address>

Debug messages are logged in the 'user-debug' log file and can be viewed using the 'show log user-debug <number of lines / all>' command in privilege mode.
Example

(DHLN-O) # show log user-debug all
Oct 27 08:20:46 :522035: <INFO> |authmgr| MAC=00:0d:60:78:fc:74 Station UP: BSSID=01:80:c2:00:00:03 ESSID=n/a VLAN=162 AP-name=
Oct 27 08:20:46 :522004: <DBUG> |authmgr| MAC=00:0d:60:78:fc:74 ingress 0x1022 (1/2), u_encr 1, m_encr 1, slotport 0x1022 wired
Oct 27 08:20:46 :522004: <DBUG> |authmgr| AAA profile for wired user is "aaa-wired-ntlm"
Oct 27 08:20:46 :522004: <DBUG> |authmgr| Deriving AAA profile from user attributes
Oct 27 08:20:46 :522004: <DBUG> |authmgr| AAA profile for wired user is "aaa-wired-ntlm"
Oct 27 08:20:46 :522004: <DBUG> |authmgr| MAC=00:0d:60:78:fc:74 def_vlan 162 derive vlan: 0 auth_type 0 auth_subtype 0
Oct 27 08:20:46 :522026: <INFO> |authmgr| MAC=00:0d:60:78:fc:74 IP=192.168.62.194 User miss: ingress=0x1022, VLAN=162
Oct 27 08:20:46 :522006: <INFO> |authmgr| MAC=00:0d:60:78:fc:74 IP=192.168.62.194 User entry added: reason=Sibtye
Oct 27 08:20:46 :522004: <DBUG> |authmgr| Deriving AAA profile from user attributes
Oct 27 08:20:46 :522004: <DBUG> |authmgr| AAA profile for wired user is "aaa-wired-ntlm"
Oct 27 08:20:46 :522004: <DBUG> |authmgr| Station inherit: IP=192.168.62.194 start bssid:00:00:00:00:00:00 essid: port:0x1022 (0x1022)
Oct 27 08:20:46 :522004: <DBUG> |authmgr| {L3} Update role from logon-ntlm to logon-ntlm for IP=192.168.62.194
Oct 27 08:20:46 :522004: <DBUG> |authmgr| Reset BWM contract: IP=192.168.62.194 role=logon-ntlm, contract= (0), type=Per role
Oct 27 08:20:46 :522004: <DBUG> |authmgr| station inherit IP=192.168.62.194 bssid:01:80:c2:00:00:03 essid: auth:0 type: role:logon-ntlm port:0x1022
Oct 27 08:20:46 :522004: <DBUG> |authmgr| {192.168.62.194} autTable (" Unauthenticated logon-ntlm ")
Oct 27 08:20:46 :522004: <DBUG> |authmgr| download: ip=192.168.62.194 acl=42/0 role=logon-ntlm, Ubwm=0, Dbwm=0 tunl=0x1022, PA=0, HA=1, RO=0, VPN=0
Oct 27 08:20:56 :522004: <DBUG> |authmgr| {L3} Update role from logon-ntlm to authenticated-ntlm for IP=192.168.62.194
Oct 27 08:20:56 :522004: <DBUG> |authmgr| Reset BWM contract: IP=192.168.62.194 role=authenticated-ntlm, contract= (0), type=Per role
Oct 27 08:20:56 :522004: <DBUG> |authmgr| download: ip=192.168.62.194 acl=48/0 role=authenticated-ntlm, Ubwm=0, Dbwm=0 tunl=0x1022, PA=0, HA=1, RO=0, VPN=0
Oct 27 08:20:56 :522008: <NOTI> |authmgr| User authenticated: Name=Administrator MAC=00:0d:60:78:fc:74 IP=192.168.62.194 method=NTLM server=n/a role=authenticated-ntlm
Oct 27 08:20:56 :522004: <DBUG> |authmgr| {192.168.62.194} autTable ("Administrator Authenticated NTLM authenticated-ntlm ")
In this log file output, the user with MAC address 00:0d:60:78:fc:74 comes up on port 1/2. The BSSID is set to 01:80:c2:00:00:03, which is used for wired authentication. The AAA profile "aaa-wired-ntlm" is derived for the user and the user gets IP address 192.168.62.194 and is placed in the logon-ntlm role. After NTLM is successful, the user (Administrator in this case) is placed in the 'authenticated-ntlm' role.

4) Debug the security logs.
Debugging for security logs can be enabled using the configuration mode command called 'logging level debugging security process authmgr'. In case of successful login, the following messages are logged, which indicate NTLM login success.
Oct 27 08:28:26 :124004: <DBUG> |authmgr| <-- NTLMSSP Resp
Oct 27 08:28:26 :124004: <DBUG> |authmgr| Fwd NTLM packet
Oct 27 08:28:26 :124004: <DBUG> |authmgr| NTLM 192.168.62.194:1323 -> 192.168.62.100:445
Oct 27 08:28:26 :124004: <DBUG> |authmgr| --> NTLMSSP Req
Oct 27 08:28:26 :124004: <DBUG> |authmgr| New NTLM ctx created for User Administrator, uid 28672
Oct 27 08:28:26 :124004: <DBUG> |authmgr| Fwd NTLM packet
Oct 27 08:28:26 :124004: <DBUG> |authmgr| NTLM 192.168.62.100:445 -> 192.168.62.194:1323
Oct 27 08:28:26 :124004: <DBUG> |authmgr| <-- NTLMSSP Resp
Oct 27 08:28:26 :124004: <DBUG> |authmgr| Tx message to Sibyte. Opcode = 17, msglen = 136
Oct 27 08:28:26 :124004: <DBUG> |authmgr| NTLM user authenticated. user Administrator, uid 28672

Search Airheads
Showing results for 
Search instead for 
Did you mean: 
Is this a frequent problem?

Request an official Aruba knowledge base article to be written by our experts.