Cisco RADIUS Authentication w/ Active Directory and Network Policy Server

I'll try to keep this short and sweet. It took me a bit to find the exact commands I used. The configuration below has been validated to work on Cisco routers, switches, and voice gateways.

Part 1. RADIUS Server Configuration

Assuming you already have a Network Policy Server installed on a DC somewhere...

RADIUS Clients and Servers > RADIUS Clients > Right Click > New RADIUS Client

• Add Friendly Name
• IP
• Vendor = Cisco
• Shared Secret
• Manual
• Enter a key (same as used on the cisco device)

Policies > Network Policies > Right Click > New (use defaults unless specified)

• Policy Name (I just called this the same as the client friendly name)
• Conditions
• Windows Groups: AD Group with network administrator accounts
• Client Friendly Name: same as friendly from "RADIUS Clients" (prevents policies from inadvertently being applied to the wrong devices. Optional precaution)
• Authentication Methods > Check "Unencrypted authentication"
• "Configure Settings"
• RADIUS Attributes
• Standard > Remove Framed-Protocol PPP
• Vendor Specific > Add (allows user to launch in to enable mode by default)
• Vendor = Cisco
• Attribute Name = Cisco-AV-Pair
• Value = shell:priv-lvl=15

Part 2: SSH to Cisco Switch/Router

You'll need...

• VLAN/IP that authentication will originate from
• IP of your RADIUS Server
• RADIUS Secret used in part 1.

Run the following from the command line... ​conf t

aaa new-model

aaa authentication login default group radius local

aaa authorization exec default group radius local

ip radius source-interface <<VLAN/IP>> Interface (e.g. Vlan1 or GigabitEthernet0/0)

radius-server host <<IP of RADIUS Server>> auth-port 1645 acct-port 1646

radius-server key <<RADIUS SECRET>>

service password-encryption

Part 3: Testing

1. Ensure your admin account can log in
2. Ensure that other accounts cannot log in. Especially if you have other RADIUS auth policies like we did.
3. Validate that your local account no longer works by default.
4. "Disable" your RADIUS client. Validate that your local account works as a fail safe.

Task Scheduler Change Audit Trail

Background

Walked in today to some questions about why an important scheduled tasks <cringe face here> had been disabled. Turned out that it was intentional so no big deal. However, the question I was asked before we knew it was intentional was this… “how do we see an audit trail for task scheduler changes?” The short answer is that it’s not enabled by default and it’s not super intuitive.

This has to be auditpol.exe

More Here

http://technet.microsoft.com/en-us/library/cc731451.aspx

Auditing consists of categories and subcategories. To do this you need to enable a subcategory. Technically, this is the recommended way to enable non-standard auditing. You don’t want to audit too much or you’ll make your log difficult to read, fill up space, consume processing time, etc. Per Micrsoft…

            http://technet.microsoft.com/en-us/library/cc766468%28v=ws.10%29.aspx

If you are going to use auditing subcategories, you should not use Group Policy to define and distribute your auditing policies. The Group Policy Management Console configures only the top-level auditing categories and enables all of the subcategories within the category and thus cannot be used to set more targeted audit policy. Instead, auditing policy that uses auditing subcategories must be defined by using the command-line tool auditpol.exe and distributed by means of a script.

Execution

So how do I do that? Pretty simple:

From a command prompt:

auditpol.exe /get /category:"Object Access"

I can see that I'm currently set to all "Failure" only which inherited from the Local Policy parent "Object Access". I want to change "Other Object Access Events" which is sort of a misc set of audit events for Task Scheduler and COM+. 

http://technet.microsoft.com/en-us/library/dn319119.aspx

All of that to say, here is the command to enable Task Scheduler auditing to the Event Viewer Security logs.

auditpol.exe /set /subcategory:"Other Object Access Events" /Success:Enabled /Failure:Enabled

You can verify your change in the Security log. Event ID 4719.

So I went and disabled/enabled a scheduled task. Now I can see these logs.

We use System Center Operations Manager. So at this point I could capture on the various event IDs (also in the link above) that this new audit log will generate.

Hopefully this will shortcut the process for you. As you can see, I had to pull together a few resources to understand what I really needed.

Grant Access to Specific Runbooks in Orchestrator

Since I had a hard time finding a clear guide on the topic here goes...

As a systems administrator / domain admin I typically have access to just about any system. As such, no big deal for me to be in the "users" group recommended for the initial Orchestrator install. This group is a bit of a misnomer. These are your designers. So in my case I have a group called “app-scorch-users” which consists for systems administrators.

So the issue is, how to provide runbooks specific to other roles. I want my DBA, developers, and so on to be able to execute their runbooks from the web console with ease but only those we choose. i.e. DBAs can’t run developers runbooks.

• I started by creating a domain group: app-scorch-operators. Anyone who will run (not design) runbooks will go in this group.
• Add that group to the root Runbooks container (right click > permissions)
• Restrict its access to "read"
• Go to Advanced > Select the group > change "Applies to:" to "This object only"

The purpose of the operators group is simply to grant access to read objects under the “Runbooks” node in the connections pane.

 

 

This opens up the ability to assign perms to users/group on the subfolders or directly to runbooks. In this example, I am attempting to grant several individuals to a folder (you could create domain groups per folder too).

• So I'll go to the "Patching" folder > Right click > Permissions
• Add any users or groups you'd like to execute runbooks with ONLY Read

• Once added, you'll need to add one more thing…."Publish". Otherwise you'll get an error stating the user must have publish to run a runbook.
• Go to Advanced > Edit > "Show advanced permissions"
• Read properties and list contents will already be checked.

Now when your "Operators" go to the web Orchestrator Console they'll only see the folders where they were granted read/publish. (note below SC2012 Solutions from the first screenshot is not displayed)