Hello,
I have a few questions regarding Authentication & Authorization in CPPM against a MS AD DOMAIN.
CPPM (5.2.0) is joined to the DOMAIN in order to perform 802.1x Auth for clients. Our 802.1x service uses EAP-PEAP & EAP-TTLS for Authentication Methods agains our AD Auth Source. Our AD Auth Source talks to a primay & 2 backup AD servers (out of 5, soon to be 4). I'm slowly coming to grips w/ the fact that Authentication & Authorization are the same in our evnironment (there is no visible Authorization tab in our CPPM config for our 802.1x service). I'm slowly understaning more as I read & re-read the CPPM Users Guide (See Chapter 11 : Authentication & Authorization).
"Authentication Source... CPPM 1st tests whether the connecting entitiy - device or user - is present in the ordered list of configured Authentication Srouces. CPPM looks for the device or user by executing the first Filter associated w/ the authentication source." ...
Ah, our first filter as seed in the Summary tab, Attributes, of our Authentication Srouces config states :
1. (&(sAMAcountName=%{Authentication:Username})(objectClass=user))
..."Once the device or user is found, CPPM then authenticates this entity against this authentication source."...
I think I can follow the flow. I believe this occures as an LDAP lookup in our CPPM logs (more on that in a bit).
"Authorization Source... Authentication & authorization soruce definition is interchangeable in most use cases, because CPPM uses the same identity store to fetch role mapping attributes as it does for authenticating the user or device. Once the connecting entity is successfully authenticated, CPPM retrieves role mapping attributes from the authorization sources. In most use cases, Authentication & Authorization source refers to the same identity store."
I believe this is most evident in the CPPM logs where there is both an LDAP lookup (which I'm assuming is the filter bit ?) & an MSCHAPv2 authorization (which I assume is the authorization / role fetching ?).
2013-01-22: 11:12:50,080 [Th 13821 Req 215407608 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_service: Starting Service Categorization
2013-01-22: 11:12:50,083 [Th 13821 Req 215407608 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_service: The request has been categorized into service "Nagios Checks"
2013-01-22: 11:12:50,083 [Th 13821 Req 215407608 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_eap_peap: Initiate
2013-01-22: 11:12:50,084 [Th 13812 Req 215407609 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_service: The request was categorized into service "Nagios Checks"
2013-01-22: 11:12:50,084 [Th 13812 Req 215407609 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_eap_ttls: Initiate
2013-01-22: 11:12:50,085 [Th 13819 Req 215407610 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_service: The request was categorized into service "Nagios Checks"
2013-01-22: 11:12:50,089 [Th 13819 Req 215407610 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - TLS_accept:error in SSLv3 read client certificate A
2013-01-22: 11:12:50,089 [Th 13814 Req 215407611 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_service: The request was categorized into service "Nagios Checks"
2013-01-22: 11:12:50,090 [Th 13815 Req 215407612 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_service: The request was categorized into service "Nagios Checks"
2013-01-22: 11:12:50,090 [Th 13816 Req 215407613 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_service: The request was categorized into service "Nagios Checks"
2013-01-22: 11:12:50,091 [Th 13818 Req 215407614 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_service: The request was categorized into service "Nagios Checks"
2013-01-22: 11:12:50,092 [Th 13813 Req 215407615 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_service: The request was categorized into service "Nagios Checks"
2013-01-22: 11:12:50,093 [Th 13817 Req 215407616 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_service: The request was categorized into service "Nagios Checks"
2013-01-22: 11:12:50,093 [Th 13817 Req 215407616 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_ldap: searching for user DREXEL
agtest in AD:foobar.drexel.edu
2013-01-22: 11:12:50,094 [Th 13817 Req 215407616 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_ldap: found user DREXEL
agtest in AD:foobar.drexel.edu
2013-01-22: 11:12:50,094 [Th 13817 Req 215407616 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_eap_mschapv2: Issuing Challenge
2013-01-22: 11:12:50,095 [Th 13820 Req 215407617 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_service: The request was categorized into service "Nagios Checks"
2013-01-22: 11:12:50,095 [Th 13820 Req 215407617 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_service: The request was categorized into service "Nagios Checks"
2013-01-22: 11:12:50,095 [Th 13820 Req 215407617 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_eap_mschapv2: Received MSCHAPv2 Response from client
2013-01-22: 11:12:50,095 [Th 13820 Req 215407617 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_mschap: authenticating user nagtest, domain DREXEL
2013-01-22: 11:12:50,097 [Th 13820 Req 215407617 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_mschap: user nagtest authenticated successfully
2013-01-22: 11:12:50,097 [Th 13820 Req 215407617 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_eap_mschapv2: Sending MSCHAPv2 Success reply
2013-01-22: 11:12:50,097 [Th 13821 Req 215407618 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_service: The request was categorized into service "Nagios Checks"
2013-01-22: 11:12:50,098 [Th 13821 Req 215407618 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_service: The request was categorized into service "Nagios Checks"
2013-01-22: 11:12:50,098 [Th 13821 Req 215407618 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_eap_mschapv2: Received MSCHAPv2 Success from client
2013-01-22: 11:12:50,098 [Th 13821 Req 215407618 SessId R019186e8-05-50feba82] INFO RadiusServer.Radius - rlm_policy: Starting Policy Evaluation.
Please do let me know if I have this totally backwards or if I'm not understanding this properly.
Okay, now here come the questions...
I'm not a windows guy, nor do I administer the AD servers but I'm working w/ the windows folks to try and track down where my CPPM boxes are ultimately authenticating our users. They've given me access to Splunk, however there don't appear to be any direct relationship in the number of entires from our CPPM boxes vs. the number of Users CPPM claims to authenticate.
For those of you w/ CPPM labs & AD...
1) In our AD servers, where can I locate Authentication & Authorization log entries from CPPM? Would they be in Security logs, RADIUS logs, NPS logs? What is the default? Would I see a direct correlation w/ the user that is authenticating or would it be from the Bind User CPPM uses?
I understand that CPPM might be performing some kind of caching, however it looks as if it does a lookup & an authentication for the majority (if not all) users. I would assume that I should be able to see some kind of log entry unless the Windows Admins are not logging them...
2) In our CPPM Auth Sources config, we entered a primary & 2 backups. Does that function for both Authentication & Authorization or only for the 1st filter, which I'm assuming is the LDAP lookup? Is there any way to enable debugging in CPPM for the Authorization bit so that it logs which AD server it does that against?
3) What is the difference between a single Authentication Source w/ Primary & Backups vs. configuring multiple Authentication Sources in the Service Config such that each source points to different AD Primary & Backup Servers? I assume the latter would be for multiple Domains or different Auth Sources. Is the authorization round-robin'ed based on the AD Domain Config, or can CPPM be configured to randomize which Authentication / Authorization Source it queries (in the event that they're all the same ID store)?
Knowing a bit about how CPPM relies upon winbind I'm assuming its using SAMBA / winbind to do most of the authentication (http://technet.microsoft.com/en-us/magazine/2008.12.linux.aspx). I'm asking all of this because I belive something in our network, setup, or config isn't quite right. When the WIndows Admins take down one of the AD Servers, CPPM failes to move to a backup for Auth & users can't get on-line, wirelessly. CPPM logs time outs for the RADIUS request for the Auth only, it seems to be able to lookup the user via LDAP but it doesn't receive the "rlm_mschap: user: UID authentication successfuly" response in time & thus times out the request. I'm trying to track down logging on the AD end, but I figure it would be almost as effecitent for me to see if CPPM is able to log more info about which AD Controller it performs its Authorization / Authentication against.
Any recommendations on making AD Auth more... robust, would be greatly appreciated.
Thanks for taking the time to read through this long-winded post & thank you for any feedback,