Security

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, 

A follow up...

Ah...  Sometimes, all it takes is reading it w/ someone watching over you to realize just how dim-witted you were being...  The Users Guide reads : 

Authentication Source. In Policy Manager, an authentication source is the identity store (Active Directory, LDAP directory, SQL DB, token server) against which users and devices are authenticated. Policy Manager first tests whether the connecting entity - device or user - is present in the ordered list of configured Authentication Sources. Policy Manager looks for the device or user by executing the first Filter associated with the authentication source. Once the device or user is found, Policy Manager then authenticates this entity against this authentication source.

So the first bit is the ldap lookup & the acutal authentication is the AD Auth against the same source that was queried in the LDAP lookup.  We don't have any Authorization Source that isn't a successful Authentication, & if we do I suspect that information is returned as part of the Authorization since it doesn't look as if we're quering any extra Authorization Source.  

Still, when are backup1 & backup2 used?  What would be the difference between relying on backups vs. another configured Authentication Source if they all contain the same IDs & Credentials?  Is there anyway to round-robin the list of Authentication Sources?  

Hopefully some of this sheds some light......

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?

Any authentication to the AD Servers will be visible in the Security Event Log.  Being a domain controller, this can often be very diffcult to track as most environments are logging a great deal of logon events on their DCs.  NPS does not play a role, unless you have CPPM setup as a proxy radius (which it does not sound like you do).   The logs may show a variety of events including Credential Validation (for the logon user and/or bind user) and Kerberos events (from CPPM).  It may show the bind user, it may show CPPM (if added to the domain), or it may show the actual user (if you have "allow bind using user password" enabled).   

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?

The source is used for both Authentication and for fetching of Authorization attributes (configurable).   When you create a source with multiple servers, the backup servers are not used unless the first server does not respond.  If the server responds with a failure (perhaps no user existed), it does not move onto the next servers.   With AD as a source, AD is used as the Authorization source by default; you can additional sources by enabling Authorization on the Service which will show the Authorization tab.   

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)?  

Correct, multiple sources would be used if you had multiple identity stores; multiple AD environments for example.   The authentication always uses the Primary first; then moves to the backup servers if the primary is not available (based on the server timeout defined in the source).   It is possible to configure the source to be AD Site Aware; meaning if AD is setup properly you could point your primary source at domain.com instead of domaincontroller.domain.com.   DNS should return the IP of domain controllers in that site to CPPM (or at a minimum give you round robin responses).

To see more about who CPPM is talking to; you can enable debugging on the Radius service which will reveal more information in the Access Tracker logs.