Passive Authentication not working in FireSight

[rgnelson]

We just cannot get Firesight to be user aware at all. I can match logon events from the DC, to the SF User Agent to traffic being processed through the SFR module, and have it either hit my unknown/Anon user rule, or be denied based on no identity. I have just not been able to make this work. 

We are using the Firesight Management Center for vMware, 6.0. SFR module in 5515-X: 

SFR# show module sfr details
Getting details from the Service Module, please wait...

Card Type: FirePOWER Services Software Module
Model: ASA5515
Hardware version: N/A
Serial Number: <clip>
Firmware version: N/A
Software version: 6.0.0-1005
MAC Address Range: <clip>
App. name: ASA FirePOWER
App. Status: Up
App. Status Desc: Normal Operation
App. version: 6.0.0-1005
Data Plane Status: Up
Console session: Ready
Status: Up
DC addr: <clip>
Mgmt IP addr: <clip>
Mgmt Network mask: <clip>
Mgmt Gateway: <clip>
Mgmt web ports: 443
Mgmt TLS enabled: true

Firepower User Agent for Active Directory v2.3 b10 is installed on Win2K12R2. AD servers are configured, real-time events are enabled each DC status is Green." The Firesight appliance is configured in same, status is also 'Green'

I believe output from debug logging shows events are reported to Firesight appliance. 

"12/15/2015 5:25:45 PM","debug","[2329] - Real Time Event Received - 12/15/2015 5:25:45 PM,<username>,<IP>,interactive"
"12/15/2015 5:25:45 PM","debug","[2203] - Reported 1 events (<dc fqdn> -> <firesight fqdn>)."

User Agent has been run as both a minimum rights user and as a domain admin for testing purposes. 

Integration -> Identity Sources have the User Agents configured. Have tried both FQDN and IP. 

In the Firesight Management Center a realm has been configured. I've selected 10 groups to include, I have not excluded any groups. When Download users is clicked, it downloads 10 groups, and an appropriate amount of users. 

LDAP Download 1s
Download users/groups from Active Directory.
LDAP download successful: 10 groups, 235 users downloaded

The Identity Policy is configured for Passive Auth, and set to use the configured Realm. The Access Control Policy has the Identity Policy selected, and the rules have AD groups from the Realm sync. There are not so many options selected in the rules that traffic will not match, just some URL categories and the users's Groups. 

Reviewing traffic in Analysis -> Connection Events, the only value in 'Initiator User' is Unknown. 

Rules without users specified will have traffic match and 'work'

Analysis -> User Activity lists some users, mostly with "No Authentication"  as the Auth type. 

System Users are set to use External Authentication to the same AD GC's as configured in the Realm config. This works. 

TIA folks!

[rgnelson]

I started a TAC case, and have more info. There is a bug, also a workaround, but it won't work in a multi-domain or subdomain environment. 

https://tools.cisco.com/bugsearch/bug/CSCux39125

The UA reports exactly what it scrapes out of the Security Event log to Firesight, which is NETBIOS DOMAIN NAME\sAMAccountName

Firesight is trying to match the UA data with the value set here: 

System > Integration > Realms > Pencil Icon > Realm Configuration  > AD Primary Domain

If the primary domain is set to fqdn as the example shows, Firesight isn't intelligent enough to make the match (or is broken, the bug ID is unclear). 

If the whole AD forest is a single flat domain, changing the AD primary domain in realm config to NETBIOS name works. 

In our case, we have a forest root domain used for administrative purposes, and several sub-domains where the users and their resources are defined. The workaround fixes the issue for one sub-domain, but thoroughly breaks it for any other. Part of this is because of the way the identity policy and access control rules are configured. 

Identity policy doesn't allow multiple rules with unique realms to be active. Configuring a subsequent passive auth rule pops a warning the new rule its preemted by the above rule.

Configuring multiple identity policies also doesn't work, as only a single Access Control Policy is allowed per targeted device, and only a single Identity policy is allowed per Access Control Policy.

So we're still stuck. 

[tellis002]

Yeah I am running into the same issue, the workaround however for me is not working.  I have tried several different ways to get this to work, no luck.    

I just get 'unknown' for my authentication.  I am going to open a tac case as well and will update you with what I find out, but it appears my issue is related.  

My current version's I am working with:

Firepower Management Center:  6

ASA's:  5515x's 9.5.2

Sensors:  6.0.0-1005

User Agent:  2.3

Regards

[marinogr]

I have the same problem.

For me worked to put netbiosdomain.domain-name

Examle:

netbiosdomain: domain

domain-name: domain.com

Username: fireuser@domain.com

Enter into: System > Integration > Realms > Pencil Icon > Realm Configuration  > AD Primary Domain

AD Primary Domain: domain.domain.com

Directory Username: fireuser

Regards

[craig-allen]

I've just run into a simliar issue where all my users were unknown in FMC; my domain is set to fqdn in the Realm Configuration. User identification was working 100% but I had to re-image the SFR and when I re-set it up I made some minor changes to the config but it took quite some time to identify the issue.

During setup I configured DNS search domains which included the fqdn for my AD domain; once I removed the AD fqdn in the DNS search config on the SFR users started getting identified via their LDAP name on the FMC connection events.

So I suggest you check your DNS search domain config on the SFR and leave it blank.

[Ed Padilla Jr]

Request Cisco TAC to escalated the case to p1 all of you since too many customer are complaining on this issue.   It requires urgency.

[tellis002]

Hey everyone, getting back here with my issue.  I found my issue, the operating system that I installed the user agent on, had TCP port 3306 closed.  My mistake, once I opened that it started working.  Also, don't forget TCP 135 needs to be open as well on the same system.  

Regards.

[rgnelson]

I've gotten this back from TAC: 

Engineering has informed me that your configuration is a limitation we
have at this point and will have to be addressed in a future release.

So I guess that is that. I am shocked that this is an issue in today's world, and extremely disappointed that we didn't identify this prior to committing to a 3-year subscription. 

[lmsistemas]

Cisco says the Bug is fixed (status:Fixed) but sadly it still happening with me.

We will have to migrate this solution to another manufacturer, like blue coat or checkpoint, we're still evaluating the options.

[Jetsy Mathew]

Hello Team,

There are several customers who uses the passive authentication method. It had few issues with older versions. So first of all make sure that you are in the latest and stable software version . To validate and investigate further, please contact the Cisco TAC. If you confirm that the issue is not resolved with the version as promised Cisco TAC can help you with a solution.

Regards

Jetsy 

[Akhil.Balachandran]

Hi Everyone,

I know this Post is a year old, but just wanted to update a possible solution for Realm configuration with Multiple domains.  In Global catalog AD server, the port thats used to getUser/Group information from the parent and child domain is 3268 and not the default 389. LDAP over 389 only pulls the parent domain information.

So under the firepower REALM configuration , while adding the active directory, use port 3268 along with the IP address, instead of 389. This way the firepower pulls the entire forest user/group information. 

Hope this helps.

Regards

Akhil

[rgnelson]

Good note Akhil, Its been a long time, and I cannot recall if that was tested. I do know we are aware of the Global Catalog ports and use them in many other integrations - Cisco and otherwise. I do have a Firepower refresh cycle coming up and will revisit this at that deployment. If I find success, I will be sure to update this conversation. 

Also, for others, please note that 3269 is the secure port connection to the Global Catalog, analogous to LDAP 636. 

[thilton68]

I had the same issue. After spending hours checking and rechecking all of the following:

AD-User agent was operating correctly and all the required ports were open,

The realm was configured correctly using either the long domain name or the  NetBIOS name

The Identity policy was correctly setup and

The identity policy was assigned to the appropriate policy in access control advanced settings

on spec I recreated my realm using the copy realm button.  I checked that this copy was able to still download the directory groups and users.  So the only difference was the name.

I also created a new realm using passive authentication but this time selecting the realm copy.

I replaced the original identity policy in the access control policy with the new one and once deployed it started working???

I changed back to the original identity  policy and it stopped working again and again got the no authentication required. 

I had a colleague confirm that there were no differences between the realms and identity policies but for one reason  or another the new one works.

No real logic to this but something to try if you are desperate to get it up and running quickly.

Cheers

T

[Ehsanreza Haghzare]

I ran to the same issue https://bst.cloudapps.cisco.com/bugsearch/bug/CSCux39125

and I have switched the Domain name under Realm configuration to NETBIOS name and it worked right away.  Here is the catch :

Turns out my customer NETBIOS name was a different character from (Domain).com , easiest way to figure out go to Active Directory Users and Groups , right click on the domain and click on properties , under PRE-Windows 2003 Name : you will see the real NETBIOS name.

Put the same name for AD Agent Domain and Realm config Domain and it should start working with a save and download user.

Thanks

Ehsan 

[Ivan K.]

I have the similar problem.

When I create Rule for any user (without Users) to block some URL pages (Gambling, Cheating...) - this works.
When I change this Rule to hit for user or group form AD, the Rule is skipped and continue with "Default Action".

Where is the problem?

User Agent is operating correctly and all the required ports are open.
CFUA Tools: "Able to connect to read security logs. Polling OK. Listener Successfully Attached. "

Integration -> Identity Sources -> User Agents - Have tried FQDN and IP.

The Identity policy is correctly setup and is assigned in access control advanced settings.
The Identity Policy is configured for Passive Auth, and set to use the configured Realm.
The Realm is correctly setup - have tried FQDN, NetBIOS - LDAP download successful: 1 groups, 77 users downloaded


Firepower User Agent for Active Directory 2.3 b10
ASA 5516 9.6.1(5)
ASDM 7.6.1
FirePOWER 6.0.1 (29)