cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
672
Views
0
Helpful
10
Replies

Global Controller -> Local Controller authentication?

jpazahanick
Level 4
Level 4

If you are logged onto the GC and you click on anything (incidents for example), you are redirected to one of the local boxes and asked to log in again. Is this normal operation, or can we pass thru the authentication somehow?

10 Replies 10

mhellman
Level 7
Level 7

I did a proof-of-concept a few weeks ago with a gen 1 GC and I did not have to re-authenticate to the LC.

We are running Gen2 devices... hmm. Anyone else?

FYI, from TAC:

Informed customer this is by design as there is no caching of credentials between GC and

LC

I've got a trace that shows how this works. It has nothing to do with caching of credentials.

I should provide some details. I kind of doubt that the general concept has changed (i.e. you should not have to re-auth to the local controller). You have to touch local controllers far too often in the current distributed MARS model for this to be acceptable IMHO. Perhaps someone running the GC in production can correct me on this? It either requires re-auth or it doesn't...which is it?

I can't seem to find the directory where I stored my POC data. My recollection is this:

when you clicked on an incident in the GC, you hit a page on the GC (NOT the LC) that gave you a security/session identifier [quite possibly by fetching it from the LC] and were then redirected to the LC. The redirect request to the LC contained this session identifier. I can't remember if the session identifier is in the URL, or a cookie, or in POST data. It doesn't really matter though...the key is that the request to the LC already has a valid session id.

According to the book, "Security Monitoring with Cisco Security MARS", you do not have to re-authenticate to the local controller.

"When the GC provides a link to information on an LC, you do not need to reauthenticate. Authentication information is passed through seamlessly, using the certificate-based trust that is already established."

There is more to it than this of course, because the certificates only allow the GC to authenticate to the LC so that it can fetch a session identified to be used in the client request. I believe this was accomplished with a redirect (HTTP 302) where the URL contained said session id.

Here is the URL from the GC on an incident:

https://10.80.1.31/Shared/Zone/LocalConsoleLogin.jsp?Address=10.80.1.30&URL=___sIncidents___sIncidentDetails.jsp___qIncident_u_Id___e37625525

When I click on it, I am prompted to log into the LC.

I assume your GC is at IP address 10.80.1.31 right? What should happen is that that the GC will fetch a session from the LC and then the GC sends you an HTTP redirect to the LC. What URL shows up in the address bar after clicking this link?

Interestingly enough, I'm prompted to login in the LC when I am logged in with a created user ID. When I log into the GC as pnadmin, the pass-through works fine.

Here is the url after clicking the link, logged in as normal user.

https://lc-ip/Incidents/IncidentDetails.jsp?Incident_Id=37625535

But am presented with a login screen.

The request has to contain some sort of session token. You are not seeing all the relevant bits/requests. You might try using a local proxy (webscarab for example) or tamperIE to inspect every request the browser makes to help figure out where the problem is.

This is a new user you created on the GC right [and that didn't already have an account on the LC]?

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: