cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2171
Views
9
Helpful
17
Replies

Identity Based Firewall doesn't work using Citrix Published Desktop environment

Hi!

We are using the newest release of AD Agent (1.0.0.32.1, built 598). The ASA Firewalls 5520 are having the software release 8.4(3)8 installed.

The problem:

When somebody tries to connect thru the Identity based firewalls from a citrix published desktop environment (PDI) the connection is not possible. Checking the ip-of-user mapping on the firewalls (show user-identity ip-of-user USERNAME) mostly doesn't show the mapping of the USERNAME and the PDI the user is logged in. The user-of-ip mapping of the PDIs IP-address shows mostly other users, which then are used to authenticate the acces thru the firewalls.

What is interesting, that on the AD Agent using "adacfg.exe cache list | find /i "USERNAME"" i can't see the PDIs IP-address neither because it is mapped to another user.

Questions:

Is Citrix Published Desktop environment supported to connect thru Identity based Firewalls?

Anybody knows how AD Agent, Domain Controllers and Firewalls are working together?

On the firewalls with "show user-identity ad-agent we see, the following:

Authentication Port: udp/1645

Accounting Port: udp/1646

ASA Listening Port: udp/3799

Why Cisco does use 1645 and 1646 and not 1812 and 1813?

The Listening Port is used for what purpose?

Remark: we tried the AD Agent modes full- download and on-demand with the same effect.

Thanks for your replies

Walter

Sent from Cisco Technical Support iPad App

17 Replies 17

Tarik Admani
VIP Alumni
VIP Alumni

Is Citrix Published Desktop environment supported to connect thru Identity based Firewalls? I dont think that is a problem we need to see if they are a member of the domain or not.

Are these desktop environments joined to the domain or are you using local accounts to access these desktops? Also does it work fine with laptops?

Anybody knows how AD Agent, Domain Controllers and Firewalls are working together?

ADagent is supposed to monitor the login events on the domain controller in order to build the user to ip mapping the firewalls connect to the adagent using radius. (http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/access_idfw.html#wp1287981)

On the firewalls with "show user-identity ad-agent we see, the following:

Authentication Port: udp/1645 - this is the legacy port for radius still in use today

Accounting Port: udp/1646 - same as above but for accounting

ASA Listening Port: udp/3799 - this is typically used for CoA change of authorization, but I am not sure if the ad agent can dynamically terminate sessions.

Why Cisco does use 1645 and 1646 and not 1812 and 1813? My assumption is that these are the ports that the are used when in adagent mode, both of these ports shouldnt be a problem to use.

The Listening Port is used for what purpose? That is a good question but we will someone else to confirm.

Tarik Admani
*Please rate helpful posts*

Are these desktop environments joined to the domain or are you using local accounts to access these desktops? Also does it work fine with laptops?

>The desktop environments are joined to the domain. Working with laptops and/or workstation works fine.

ADagent is supposed to monitor the login events on the domain controller in order to build the user to ip mapping the firewalls connect to the adagent using radius. (http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/access_idfw.html#wp1287981)

Thanks for this. It explains everything except the listening port.

Why Cisco does use 1645 and 1646 and not 1812 and 1813? My assumption is that these are the ports that the are used when in adagent mode, both of these ports shouldnt be a problem to use.

>This is my oppinion as well

The Listening Port is used for what purpose? That is a good question but we will someone else to confirm.

>This would be great!

New question:

For the LDAP communication between AD Agent and the DCs is it better to use LDAPS (TCP Port 636) or LDAP (TCP Port 389)? ( is one of these protocols recommended?)

More informations about the problem we have with the public desktops:

As we have only one user-of-ip mapping of each IP-Address on the AD Agent and there are more users using the same IP-Address we mostly see the last user that logged in on the affected IP-Address (public desktop environment). I think that is the problem we have. What do you think?

Walter

Sent from Cisco Technical Support iPad App

Walter,

New question:

For  the LDAP communication between AD Agent and the DCs is it better to use  LDAPS (TCP Port 636) or LDAP (TCP Port 389)? ( is one of these  protocols recommended?) This is entirely up to you, ldaps provide more security since the the ldap search is performed over ssl.

More informations about the problem we have with the public desktops:

As  we have only one user-of-ip mapping of each IP-Address on the AD Agent  and there are more users using the same IP-Address we mostly see the  last user that logged in on the affected IP-Address (public desktop  environment). I think that is the problem we have. What do you think? After a little bit of reasearch it seems as if the security logs are not replicated amongst all DCs in the domain. I wonder if the client is logging on through one domain controllers then logging off on a different domain controller. When you first configured the adagent, did you run an nslookup from both the member server and the client machine to see if you added all the domain controllers in the adagent configuration? If so, does this adagent have access to all the domain controllers?

Thanks,

Tarik Admani
*Please rate helpful posts*

There are no Firewalls between the AD-Agent and the DCs. We checked the names using nslookup. Everything ok. I asked our AD responsibles to doublecheck the firewall settings and the logs on the DCs and on the AD Agent. As soon i get an answer I will let you know.

What I saw on the firewalls is, that just one (the first) DC is communicating with the firewalls. Is this normal?

fw-1# show aaa-server protocol ldap

Server Group: AD-ALL

Server Protocol: ldap

Server Address: 192.168.229.30

Server port: 0

Server status: ACTIVE, Last transaction at unknown

Number of pending requests 0

Average round trip time 0ms

Number of authentication requests 114

Number of authorization requests 0

Number of accounting requests 0

Number of retransmissions 0

Number of accepts 114

Number of rejects 0

Number of challenges 0

Number of malformed responses 0

Number of bad authenticators 0

Number of timeouts 0

Number of unrecognized responses 0

Server Group: AD-ALL

Server Protocol: ldap

Server Address: 192.168.229.31

Server port: 0

Server status: ACTIVE, Last transaction at unknown

Number of pending requests 0

Average round trip time 0ms

Number of authentication requests 0

Number of authorization requests 0

Number of accounting requests 0

Number of retransmissions 0

Number of accepts 0

Number of rejects 0

Number of challenges 0

Number of malformed responses 0

Number of bad authenticators 0

Number of timeouts 0

Number of unrecognized responses 0

Server Group: AD-ALL

Server Protocol: ldap

Server Address: 192.168.229.39

Server port: 0

Server status: ACTIVE, Last transaction at unknown

Number of pending requests 0

Average round trip time 0ms

Number of authentication requests 0

Number of authorization requests 0

Number of accounting requests 0

Number of retransmissions 0

Number of accepts 0

Number of rejects 0

Number of challenges 0

Number of malformed responses 0

Number of bad authenticators 0

Number of timeouts 0

Number of unrecognized responses 0

Server Group: AD-ALL

Server Protocol: ldap

Server Address: 192.168.229.40

Server port: 0

Server status: ACTIVE, Last transaction at unknown

Number of pending requests 0

Average round trip time 0ms

Number of authentication requests 0

Number of authorization requests 0

Number of accounting requests 0

Number of retransmissions 0

Number of accepts 0

Number of rejects 0

Number of challenges 0

Number of malformed responses 0

Number of bad authenticators 0

Number of timeouts 0

Number of unrecognized responses 0

Server Group: AD-ALL

Server Protocol: ldap

Server Address: 192.168.229.41

Server port: 0

Server status: ACTIVE, Last transaction at unknown

Number of pending requests 0

Average round trip time 0ms

Number of authentication requests 0

Number of authorization requests 0

Number of accounting requests 0

Number of retransmissions 0

Number of accepts 0

Number of rejects 0

Number of challenges 0

Number of malformed responses 0

Number of bad authenticators 0

Number of timeouts 0

Number of unrecognized responses 0

Server Group: AD-ALL

Server Protocol: ldap

Server Address: 192.168.229.42

Server port: 0

Server status: ACTIVE, Last transaction at unknown

Number of pending requests 0

Average round trip time 0ms

Number of authentication requests 0

Number of authorization requests 0

Number of accounting requests 0

Number of retransmissions 0

Number of accepts 0

Number of rejects 0

Number of challenges 0

Number of malformed responses 0

Number of bad authenticators 0

Number of timeouts 0

Number of unrecognized responses 0

fw-1# sho user-identity ad-agent

Primary AD Agent:

Status up

Mode: on-demand

IP address: 192.168.11.8

Authentication port: udp/1645

Accounting port: udp/1646

ASA listening port: udp/3799

Interface: Intranet

Up time: 1 day 0 hours

Average RTT: 0 msec

AD Domain Status:

Domain DOMAIN: up

fw-1#

Sent from Cisco Technical Support iPad App

This is normal if the first DC stays up, meaning it hasnt had to failover to another DC. However this is needed in order to authenticate your vpn users is my assumption. For the identity firewall this is done through radius and it is supposed to hit the adagent using radius, then the adagent should be monitoring the event logs and the ASA should fire a netbios probe in order to the domain\user of the user trying to traverse the firewall.

Hope that helps,

Tarik Admani
*Please rate helpful posts*

Also one thing to consider, and i dont know if you currently use this but if the shared workstations are on their own subnet you can consider cut-through proxy for internet access in order to speed up the user-to-ip mappings?

Thanks,

Tarik Admani
*Please rate helpful posts*

Hi Tarik

Cut-trough-proxy is not an option. I'm still waiting for the feedback of our Windows Team.

Sent from Cisco Technical Support iPad App

Thanks for your replies. I'm still waiting for the feedback of our AD responsibles. As soon I get their feedback I will let you know.

Walter

Sent from Cisco Technical Support iPad App

I got more information about or AD infrastructure. (Picture modified for internet use )

The users we are using to cross the Identity Based Firewalls (IDBF) are all part of the green domain called DOMAIN.

All servers in the domain DOMAIN (green), except the one in the DMZ, whitch is a "Read Only DC" are configured on the Firewalls and on the AD Agent.

Is it necessary, that we have to configure the DCs of the root domain as well?

And about the DC in the DMZ? Is it necessary that we have to configure this one as well, even when it's configured as "Read Only DC"?

Cheers

Walter

The configuration looks fine, I have a question regarding the machine that the ADAgent is installed on, was it already joined to the Green Domain before the AD Agent was installed? You dont have to configure the root domain controllers since the users you are authenticating are a member of the green domain.

I wanted to know if you can verify that all the domain controllers of the Green Domain have these steps and meet these requirements (I hate to reference this material but it looks like you are hitting this issue):

http://support.microsoft.com/kb/973995

This patch fixes a memory leak in Microsoft's WMI, which if left unfixed  can sporadically prevent Active Directory from writing the necessary  authentication-related events to the Security Log for that domain  controller and would prevent the AD Agent from learning about the  mappings corresponding to some of the user logins that authenticate  through that domain controller.

http://www.cisco.com/en/US/docs/security/ibf/setup_guide/ibf10_install.html#wp1060694

Thanks,

Tarik Admani
*Please rate helpful posts*

If you can reproduce this issue please issue "debug user-identity" on the ASA and can you set the debug logs on the IDFW and send a timestamp of when you can reproduce this issue?

Adagent debug section http://www.cisco.com/en/US/docs/security/ibf/setup_guide/ibf10_troubleshooting.html#wp1147840

Thanks,

Tarik Admani
*Please rate helpful posts*

Thank you Tarik!

But what you didn't know is, that we are using domain controller machines running Windows Server 2008 R2 with SP1 installed.

Referencing your Link (http://www.cisco.com/en/US/docs/security/ibf/setup_guide/ibf10_install.html#wp1060694):

For domain controller machines running Windows Server 2008 R2, the following Microsoft hotfix must be installed (unless SP1 is installed):

http://support.microsoft.com/kb/981314

This patch fixes a memory leak in Microsoft's WMI, which if left unfixed can sporadically prevent Active Directory from writing the necessary authentication-related events to the Security Log for that domain controller and would prevent the AD Agent from learning about the mappings corresponding to some of the user logins that authenticate through that domain controller.

In our case. We doesn't have to install any patch fix.

Cheers

Walter

Thanks for the update. Our option now is to run the debug as the issue is reproduced on the ASA and the ADagent.

Thanks,

Tarik Admani
*Please rate helpful posts*

That is what I'm doing next. I will inform you as soon i have some results.

Cheers

Walter

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: