network appliances and authentication

[rasczak]

currently I log on to my appliances (juniper firewall/ cisco routers) via either a serial connection or web interface. the logins are all locally authenticated. is there a way to set logins to authenticate against a domain controller?

 

[theevilsharpie]

Many enterprise-grade network devices can use RADIUS for authentication. Assuming you're running a Windows network, NPS can be used to service RADIUS clients.

 

[seepy83]

^ What theevilsharpie said. I would only add that we have our cisco equipment configured to use local auth if RADIUS fails, just in case there's something really bad happening and the device can't talk to our NPS server.

 

[oddyager]

We use tacacs+ with Cisco ACS in our environment for device authentication.

 

[drebo]

IMO, it should really be separate. Auth for networking gear should be managed by the people who manage the networking gear. If you tie it to AD, anyone with permissions could grant themselves access to any device. This is bad.

TACACS+ is better for Cisco gear as it allows you to do command-level auth at command run time, rather than having to rely on pre-defined privilege levels as with RADIUS. Juniper, not sure, as I've never implemented RADIUS with Junos, but I suspect it has the same restriction.

If you don't care about the second two A's in AAA, then RADIUS will work fine for you. If you do care, use TACACS+. Either way, keep the user database separate from your AD database.

 

[imagoon]

IMO, it should really be separate. Auth for networking gear should be managed by the people who manage the networking gear. If you tie it to AD, anyone with permissions could grant themselves access to any device. This is bad.

TACACS+ is better for Cisco gear as it allows you to do command-level auth at command run time, rather than having to rely on pre-defined privilege levels as with RADIUS. Juniper, not sure, as I've never implemented RADIUS with Junos, but I suspect it has the same restriction.

If you don't care about the second two A's in AAA, then RADIUS will work fine for you. If you do care, use TACACS+. Either way, keep the user database separate from your AD database.

You can support this with access groups (you can bolt this on in the Windows Radius server in the client rules section based on IP's) or using proper LDAP search paths. I can be in AD with Mary Jane Secretary and she can't log in to network gear while I can.

 

[drebo]

You can support this with access groups (you can bolt this on in the Windows Radius server in the client rules section based on IP's) or using proper LDAP search paths. I can be in AD with Mary Jane Secretary and she can't log in to network gear while I can.

No, but Windows Admin #1 who has no business in any of the network gear can grant himself permissions to log in to said networking gear. And, via RADIUS, it's one attribute which determines priv level.

 

[imagoon]

No, but Windows Admin #1 who has no business in any of the network gear can grant himself permissions to log in to said networking gear. And, via RADIUS, it's one attribute which determines priv level.

Sounds like a business / process issue and not a tech / IT issue. And with RADIUS you can assign groups inside the Windows Radius tool via the rules. You can assign it via group, OU or per user (per device also).

 

[6string]

We use Cisco ACS for doing AAA, authentication, authorization and accounting.

 

[drebo]

Sounds like a business / process issue and not a tech / IT issue. And with RADIUS you can assign groups inside the Windows Radius tool via the rules. You can assign it via group, OU or per user (per device also).

Has nothing to do with policy or process. It has to do with removing the opportunity for misuse. If you tie your network device AAA to AD, any Windows admin can modify that, even admins that have no business in the networking gear. That's a huge security hole.

Additinally, TACACS+ provides a much greater granularity for command-level auth and logging that RADIUS does not have.

These are facts that can't be argued and they should absolutely be considered when deploying AAA in a network.

Obviously, VPN AAA should be tied to AD, but unless the people who maintain AD also maintain the networking equipment, device AAA should not be.

 

[imagoon]

Has nothing to do with policy or process. It has to do with removing the opportunity for misuse. If you tie your network device AAA to AD, any Windows admin can modify that, even admins that have no business in the networking gear. That's a huge security hole.

Additinally, TACACS+ provides a much greater granularity for command-level auth and logging that RADIUS does not have.

These are facts that can't be argued and they should absolutely be considered when deploying AAA in a network.

Obviously, VPN AAA should be tied to AD, but unless the people who maintain AD also maintain the networking equipment, device AAA should not be.

Still sounds like a process/policy/(maybe personal) issue. You are making claims like your can't trust your fellow (IT) employees. TACACS+ maybe "better" but it is also not universally supported (at least RADIUS seems to be supported in more cases). The exact same situation applies to your TACACS+ admin. Like it or not (s)he has universal access to any network gear that talks to it. The same feelings can occur when the SAN guys are forced to configure their fiber / iSCSI gear. They feel that the lowly "Network Admins" should not touch their precious gear.

Besides the only "Admin" that should have access to radius (minus the Enterprise Admin) is the Radius Admin accounts. You have to trust them to not screw around. If they do, the network fix may be an incident but after that if falls squarely in the policy and process arena.

Also, you do have an official company process to store these admin accounts and passwords in case you get beer trucked right? Should you be concerned if the security officer or CEO has "the opportunity for misuse?"

IMO this is a non-issue.

 

[seepy83]

Has nothing to do with policy or process. It has to do with removing the opportunity for misuse. If you tie your network device AAA to AD, any Windows admin can modify that, even admins that have no business in the networking gear. That's a huge security hole.

Additinally, TACACS+ provides a much greater granularity for command-level auth and logging that RADIUS does not have.

These are facts that can't be argued and they should absolutely be considered when deploying AAA in a network.

Obviously, VPN AAA should be tied to AD, but unless the people who maintain AD also maintain the networking equipment, device AAA should not be.

So put your switch management on a vlan that can only be accessed by devices used by the networking group?

Also, I can authenticate to our switches/routers/firewalls with my AD credentials, but I still need to supply the Enable password to really do anything.

Also, since it's not applicable to the work I've been doing for the past 5 years my memory is rusty, but can't you put the AD security group that you're using for switch auth into its own OU and use AD ACLs/Delegation of Control wizard to restrict which AD Admins can edit the group?

Every organization is different...there is no one-solution-fits-all approach. But you can put enough other controls in place to make AD auth a non-issue.

 

[6string]

seepy83 you are correct, you can control who can do what in AD. In our organization we have delegated helpdesk the rights to do only certain things like; unlock, reset passwords and move computer accounts. Everything else is done by the system admins. We also tie our AAA server to AD groups that give net admins permissions to manage switches. I could create more AD groups that could give say helpdesk the rights to login to the network gear to just use the show commands (have no rights to make change).