User-ID client device specific

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

User-ID client device specific

L1 Bithead

Hi All,

 

I'm trying to figure out a work around to a user-id issue I'm having.  We're currently running Novell Open Enterprise Server as our back end identity store.  I have the User-ID agent installed on a windows box and communicating via ldap to my novell servers.  It will ID people correctly sometimes.  If someone puts their laptop into standby to go to a different classroom or other part of the building, user-id stops being able to properly ID them.  I don't know if it's a failing in the agent or an issue on the Novell side.  We're going to be going all into Microsoft/AD within the next couple of years.  In the meantime, I'd like to ID specific users to allow them access to Twitter/Facebook/etc.

 

Is there a way to force a client machine to send the ID to the palo firewall all of the time independent of the ldap connection?  Static addressing isn't a good option because on the wireless side we're using VLAN pooling which doesn't support static client addresses based on what I have read.

 

Thank you! 

4 REPLIES 4

L4 Transporter

I'm assuming you have a RADIUS server as a back end for wireless authentication? If so, are you sending the username/ip combinations via syslog to the PA User-ID? or how is your User-ID configured currently to get username/ip? After they move, are they coming in as unknown or the wrong user? is their IP address changing? Do you have a captive portal policy in place?

 

I believe the LDAP connection only applies to looking up usernames and group memberships for the use of User-ID in policy, it shouldn't have anything to do with mapping, so not sure Novell vs AD is the situation here, nor may switching to AD be the answer for this specific problem (it would help with the mapping, however, when a user logs in).

 

--
CCNA Security, PCNSE7

Thanks for the quick response.  

 

We don't have radius set up.  Currently we're using a few different pre-shared keys.  I'm hoping to get away from that in the future.  Right now the user-id agent on a windows server and it binds to our edirectory(novell side) servers via ldap.  I believe it pulls the "network address" attribute straight out of the directory and matches that against the client traffic logs on the firewall.  Their IP address shouldn't be changing.  It could be that the network address attribute is getting lost or set to nothing in the process.  

 

The switch to AD isn't just for this small issue but to address some larger strategic goals(how's that for some CTO speak)?

I'm not that well versed in eDirectory but why don't you just map directly to that instead of this whole getup? The PA is capable of connecting directly to eDirectory and you can cut that Windows server out entirely. 

 

Side not one thing to check would be your actual user mapping settings, what's your user id timeout, probe interval setting, and how often does it actually read the log frequency? I imagine that your settings are likely fine and this is because of the weird Windows server mapping but it might be worth a look. 

We were also a heavy Novell shop and for several years had our Palo Alto userID pointing to both eDir and AD as we transistioned our 40k users away from eDir. I had the same problem with our users that were still on the eDir side, and I never really found a solution. Once you get off eDir you won't have anymore problems.... maybe you can just step up your migration. The captive portal might be a temporary solution for you as well.

-Brad
  • 2892 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!