[c-nsp] switchport trunk allowed vlan

[Tim Durack]

Anyone know what an EEM policy would look like to allow:

rtr-1(config-if)#switchport trunk allowed vlan ?
add add VLANs to the current list
all all VLANs
except all VLANs except the following
none no VLANs
remove remove VLANs from the current list

But deny:

rtr-1(config-if)#switchport trunk allowed vlan ?
WORD VLAN IDs of the allowed VLANs when this port is in trunking mode

I know I can create an alias for adding/removing, but I would like to
see if I can disable the more dangerous form of this command ;-|

--
Tim:>
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Arie Vayner (avayner)]

Tim,

Can you please explain a bit better what you would like to achieve?

Also, which IOS version please?

Tnx
Arie

-----Original Message-----
From: cisco-nsp-***@puck.nether.net
[mailto:cisco-nsp-***@puck.nether.net] On Behalf Of Tim Durack
Sent: Friday, October 22, 2010 19:22
To: cisco-***@puck.nether.net
Subject: [c-nsp] switchport trunk allowed vlan

Anyone know what an EEM policy would look like to allow:

rtr-1(config-if)#switchport trunk allowed vlan ?
add add VLANs to the current list
all all VLANs
except all VLANs except the following
none no VLANs
remove remove VLANs from the current list

But deny:

rtr-1(config-if)#switchport trunk allowed vlan ?
WORD VLAN IDs of the allowed VLANs when this port is in trunking
mode

I know I can create an alias for adding/removing, but I would like to
see if I can disable the more dangerous form of this command ;-|

--
Tim:>
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Tim Durack]

On Sat, Oct 30, 2010 at 5:16 PM, Arie Vayner (avayner)
<***@cisco.com> wrote:
> Tim,
>
> Can you please explain a bit better what you would like to achieve?

Sure. The following command format is relatively safe:

switchport trunk allowed vlan <add/remove/all/except/none> <range>

However, if one forgets to include the <add/remove/all/except/none>
keyword, the command defaults to replace:

switchport trunk allowed vlan <range>

This isn't usually the desired result.

I would like to disable the use of: "switchport trunk allowed vlan
<range>", and replace it with a custom EEM command like: "switchport
trunk allowed vlan range <range>". This would correct a dangerous IOS
syntax.

I don't know if this is really possible, but it could be an
interesting exercise in demonstrating the power of EEM :-)

> Also, which IOS version please?

C6K, Sup720, 12.2(33)SXI3

> Tnx
> Arie
>
> -----Original Message-----
> From: cisco-nsp-***@puck.nether.net
> [mailto:cisco-nsp-***@puck.nether.net] On Behalf Of Tim Durack
> Sent: Friday, October 22, 2010 19:22
> To: cisco-***@puck.nether.net
> Subject: [c-nsp] switchport trunk allowed vlan
>
> Anyone know what an EEM policy would look like to allow:
>
> rtr-1(config-if)#switchport trunk allowed vlan ?
>  add     add VLANs to the current list
>  all     all VLANs
>  except  all VLANs except the following
>  none    no VLANs
>  remove  remove VLANs from the current list
>
> But deny:
>
> rtr-1(config-if)#switchport trunk allowed vlan ?
>  WORD    VLAN IDs of the allowed VLANs when this port is in trunking
> mode
>
> I know I can create an alias for adding/removing, but I would like to
> see if I can disable the more dangerous form of this command ;-|
>
> --
> Tim:>
> _______________________________________________
> cisco-nsp mailing list  cisco-***@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



--
Tim:>

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Arie Vayner (avayner)]

Tim,

It seems that some of the basic functions we need for this in EEM are not yet on SXI... Unfortunately, it does not have the latest EEM code yet.
I guess it would be possible with TCL, but I can't give you a quick example for this right now...

I suggest you try http://forums.cisco.com/eforum/servlet/EEM?page=main
Maybe you can find a good example to start with...

I will try to spend some time on this later if I can...


Arie



-----Original Message-----
From: Tim Durack [mailto:***@gmail.com]
Sent: Saturday, October 30, 2010 23:34
To: Arie Vayner (avayner)
Cc: cisco-***@puck.nether.net
Subject: Re: [c-nsp] switchport trunk allowed vlan

On Sat, Oct 30, 2010 at 5:16 PM, Arie Vayner (avayner)
<***@cisco.com> wrote:
> Tim,
>
> Can you please explain a bit better what you would like to achieve?

Sure. The following command format is relatively safe:

switchport trunk allowed vlan <add/remove/all/except/none> <range>

However, if one forgets to include the <add/remove/all/except/none>
keyword, the command defaults to replace:

switchport trunk allowed vlan <range>

This isn't usually the desired result.

I would like to disable the use of: "switchport trunk allowed vlan
<range>", and replace it with a custom EEM command like: "switchport
trunk allowed vlan range <range>". This would correct a dangerous IOS
syntax.

I don't know if this is really possible, but it could be an
interesting exercise in demonstrating the power of EEM :-)

> Also, which IOS version please?

C6K, Sup720, 12.2(33)SXI3

> Tnx
> Arie
>
> -----Original Message-----
> From: cisco-nsp-***@puck.nether.net
> [mailto:cisco-nsp-***@puck.nether.net] On Behalf Of Tim Durack
> Sent: Friday, October 22, 2010 19:22
> To: cisco-***@puck.nether.net
> Subject: [c-nsp] switchport trunk allowed vlan
>
> Anyone know what an EEM policy would look like to allow:
>
> rtr-1(config-if)#switchport trunk allowed vlan ?
>  add     add VLANs to the current list
>  all     all VLANs
>  except  all VLANs except the following
>  none    no VLANs
>  remove  remove VLANs from the current list
>
> But deny:
>
> rtr-1(config-if)#switchport trunk allowed vlan ?
>  WORD    VLAN IDs of the allowed VLANs when this port is in trunking
> mode
>
> I know I can create an alias for adding/removing, but I would like to
> see if I can disable the more dangerous form of this command ;-|
>
> --
> Tim:>
> _______________________________________________
> cisco-nsp mailing list  cisco-***@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



--
Tim:>

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Keegan Holley]

If you are simply trying to disable a command have you thought about doing
so in tacacs? It sounds like it would be simpler and it also has the
benefit of being centralized so you won't need to configure it on each
individual router.


On Sun, Oct 31, 2010 at 5:11 AM, Arie Vayner (avayner) <***@cisco.com>wrote:

> Tim,
>
> It seems that some of the basic functions we need for this in EEM are not
> yet on SXI... Unfortunately, it does not have the latest EEM code yet.
> I guess it would be possible with TCL, but I can't give you a quick example
> for this right now...
>
> I suggest you try http://forums.cisco.com/eforum/servlet/EEM?page=main
> Maybe you can find a good example to start with...
>
> I will try to spend some time on this later if I can...
>
>
> Arie
>
>
>
> -----Original Message-----
> From: Tim Durack [mailto:***@gmail.com]
> Sent: Saturday, October 30, 2010 23:34
> To: Arie Vayner (avayner)
> Cc: cisco-***@puck.nether.net
> Subject: Re: [c-nsp] switchport trunk allowed vlan
>
> On Sat, Oct 30, 2010 at 5:16 PM, Arie Vayner (avayner)
> <***@cisco.com> wrote:
> > Tim,
> >
> > Can you please explain a bit better what you would like to achieve?
>
> Sure. The following command format is relatively safe:
>
> switchport trunk allowed vlan <add/remove/all/except/none> <range>
>
> However, if one forgets to include the <add/remove/all/except/none>
> keyword, the command defaults to replace:
>
> switchport trunk allowed vlan <range>
>
> This isn't usually the desired result.
>
> I would like to disable the use of: "switchport trunk allowed vlan
> <range>", and replace it with a custom EEM command like: "switchport
> trunk allowed vlan range <range>". This would correct a dangerous IOS
> syntax.
>
> I don't know if this is really possible, but it could be an
> interesting exercise in demonstrating the power of EEM :-)
>
> > Also, which IOS version please?
>
> C6K, Sup720, 12.2(33)SXI3
>
> > Tnx
> > Arie
> >
> > -----Original Message-----
> > From: cisco-nsp-***@puck.nether.net
> > [mailto:cisco-nsp-***@puck.nether.net] On Behalf Of Tim Durack
> > Sent: Friday, October 22, 2010 19:22
> > To: cisco-***@puck.nether.net
> > Subject: [c-nsp] switchport trunk allowed vlan
> >
> > Anyone know what an EEM policy would look like to allow:
> >
> > rtr-1(config-if)#switchport trunk allowed vlan ?
> > add add VLANs to the current list
> > all all VLANs
> > except all VLANs except the following
> > none no VLANs
> > remove remove VLANs from the current list
> >
> > But deny:
> >
> > rtr-1(config-if)#switchport trunk allowed vlan ?
> > WORD VLAN IDs of the allowed VLANs when this port is in trunking
> > mode
> >
> > I know I can create an alias for adding/removing, but I would like to
> > see if I can disable the more dangerous form of this command ;-|
> >
> > --
> > Tim:>
> > _______________________________________________
> > cisco-nsp mailing list cisco-***@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
>
>
>
> --
> Tim:>
>
> _______________________________________________
> cisco-nsp mailing list cisco-***@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Phil Mayers]

On 31/10/10 15:39, Keegan Holley wrote:
> If you are simply trying to disable a command have you thought about doing
> so in tacacs? It sounds like it would be simpler and it also has the
> benefit of being centralized so you won't need to configure it on each
> individual router.

It also has the disadvantage of being centralised, so each router has to
be configured to talk to a central point-of-failure.

:o)

+1 for wanting to disable this w/o TACACS
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Tim Durack]

On Mon, Nov 1, 2010 at 7:58 AM, Phil Mayers <***@imperial.ac.uk> wrote:
> On 31/10/10 15:39, Keegan Holley wrote:
>>
>> If you are simply trying to disable a command have you thought about doing
>> so in tacacs?  It sounds like it would be simpler and it also has the
>> benefit of being centralized so you won't need to configure it on each
>> individual router.
>
> It also has the disadvantage of being centralised, so each router has to be
> configured to talk to a central point-of-failure.
>
> :o)
>
> +1 for wanting to disable this w/o TACACS

Exactly. In my book, "simple" = less operational dependencies. (Plus
configuration management system carries the burden of making these
changes anyway.)

--
Tim:>

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Arie Vayner (avayner)]

Tim,


BTW, In SXI we have enough EEM support to block the command.

See the following script:

event manager applet BLOCK-ALLOWED-VLAN-RANGE
event cli pattern "switchport trunk allowed vlan\s+[0-9]" skip yes sync no
action 1.0 syslog msg "switchport trunk allowed vlan <RANGE> is not allowed"

Router(config)#do show run int gig1/22
!
interface GigabitEthernet1/22
switchport
switchport trunk allowed vlan 100-102
shutdown
end

Router(config)#int gig1/22
Router(config-if)# switchport trunk allowed vlan 110
Router(config-if)#
Router(config-if)# do show run int gig1/22
!
interface GigabitEthernet1/22
switchport
switchport trunk allowed vlan 100-102
shutdown
end

Router(config-if)#
08:10:06: %HA_EM-6-LOG: BLOCK-ALLOWED-VLAN-RANGE: switchport trunk allowed vlan <RANGE> is not allowed


In later EEM versions we can do really cool stuff, like adding new commands, string parsing etc, but unfortunately, its not in SXI yet...

Arie


-----Original Message-----
From: cisco-nsp-***@puck.nether.net [mailto:cisco-nsp-***@puck.nether.net] On Behalf Of Tim Durack
Sent: Monday, November 01, 2010 14:16
To: cisco-***@puck.nether.net
Subject: Re: [c-nsp] switchport trunk allowed vlan

On Mon, Nov 1, 2010 at 7:58 AM, Phil Mayers <***@imperial.ac.uk> wrote:
> On 31/10/10 15:39, Keegan Holley wrote:
>>
>> If you are simply trying to disable a command have you thought about doing
>> so in tacacs?  It sounds like it would be simpler and it also has the
>> benefit of being centralized so you won't need to configure it on each
>> individual router.
>
> It also has the disadvantage of being centralised, so each router has to be
> configured to talk to a central point-of-failure.
>
> :o)
>
> +1 for wanting to disable this w/o TACACS

Exactly. In my book, "simple" = less operational dependencies. (Plus
configuration management system carries the burden of making these
changes anyway.)

--
Tim:>

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Tim Durack]

On Mon, Nov 1, 2010 at 9:24 AM, Arie Vayner (avayner) <***@cisco.com> wrote:

> BTW, In SXI we have enough EEM support to block the command.

Nice - I'll give this a spin.

> In later EEM versions we can do really cool stuff, like adding new commands, string parsing etc, but unfortunately, its not in SXI yet...

Gotcha. I think I'm going to need this functionality for what I have in mind:

Administratively disable: "switchport trunk allowed vlan <range>" and
create a replacement command: "switchport trunk allowed vlan range
<range>"

Does that sound about right?

--
Tim:>
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Arie Vayner (avayner)]

Tim,

Yes, in order to create the new command you had in mind, we need some
string parsing capabilities we do not have in SXI...
Let's wait a bit, and try again...

Arie

-----Original Message-----
From: Tim Durack [mailto:***@gmail.com]
Sent: Monday, November 01, 2010 16:23
To: Arie Vayner (avayner)
Cc: cisco-***@puck.nether.net
Subject: Re: [c-nsp] switchport trunk allowed vlan

On Mon, Nov 1, 2010 at 9:24 AM, Arie Vayner (avayner)
<***@cisco.com> wrote:

> BTW, In SXI we have enough EEM support to block the command.

Nice - I'll give this a spin.

> In later EEM versions we can do really cool stuff, like adding new
commands, string parsing etc, but unfortunately, its not in SXI yet...

Gotcha. I think I'm going to need this functionality for what I have in
mind:

Administratively disable: "switchport trunk allowed vlan <range>" and
create a replacement command: "switchport trunk allowed vlan range
<range>"

Does that sound about right?

--
Tim:>

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Tim Durack]

On Mon, Nov 1, 2010 at 5:22 PM, Arie Vayner (avayner) <***@cisco.com> wrote:
> Tim,
>
> Yes, in order to create the new command you had in mind, we need some
> string parsing capabilities we do not have in SXI...
> Let's wait a bit, and try again...
>

Roger.

Seems funny to me that NX-OS repeats the same problem as IOS. Guess it
isn't much of a big deal.

--
Tim:>
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Keegan Holley]

On Mon, Nov 1, 2010 at 8:16 AM, Tim Durack <***@gmail.com> wrote:

> On Mon, Nov 1, 2010 at 7:58 AM, Phil Mayers <***@imperial.ac.uk>
> wrote:
> > On 31/10/10 15:39, Keegan Holley wrote:
> >>
> >> If you are simply trying to disable a command have you thought about
> doing
> >> so in tacacs? It sounds like it would be simpler and it also has the
> >> benefit of being centralized so you won't need to configure it on each
> >> individual router.
> >
> > It also has the disadvantage of being centralised, so each router has to
> be
> > configured to talk to a central point-of-failure.
> >
> > :o)
> >
> > +1 for wanting to disable this w/o TACACS
>
> Exactly. In my book, "simple" = less operational dependencies. (Plus
> configuration management system carries the burden of making these
> changes anyway.)
>
>
I'm not sure I understand the drawback of TACACS. It's obvious that
redundancy is needed there. If you're already using TACACS it seems easier
to place it there. I'm not sure I like the idea of a network using local
auth everywhere but to each his own. If you use EEM what's to stop other
"senior" engineers from just removing the script temporarily?
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Tim Durack]

On Mon, Nov 1, 2010 at 10:08 AM, Keegan Holley
<***@sungard.com> wrote:

> I'm not sure I understand the drawback of TACACS.  It's obvious that
> redundancy is needed there.  If you're already using TACACS it seems easier
> to place it there.  I'm not sure I like the idea of a network using local
> auth everywhere but to each his own.  If you use EEM what's to stop other
> "senior" engineers from just removing the script temporarily?

We use RADIUS, which doesn't support administratively disabling
commands (unfortunately.)

I'm also trying to protect from accidental stupidity, rather than
stupidity with intent. (If someone starts disabling safeguards, their
level of accountability increases accordingly.)

Appreciate the suggestion though - just doesn't quite work for us.

--
Tim:>

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Phil Mayers]

On 01/11/10 14:08, Keegan Holley wrote:
> On Mon, Nov 1, 2010 at 8:16 AM, Tim Durack<***@gmail.com> wrote:
>
>> On Mon, Nov 1, 2010 at 7:58 AM, Phil Mayers<***@imperial.ac.uk>
>> wrote:
>>> On 31/10/10 15:39, Keegan Holley wrote:
>>>>
>>>> If you are simply trying to disable a command have you thought about
>> doing
>>>> so in tacacs? It sounds like it would be simpler and it also has the
>>>> benefit of being centralized so you won't need to configure it on each
>>>> individual router.
>>>
>>> It also has the disadvantage of being centralised, so each router has to
>> be
>>> configured to talk to a central point-of-failure.
>>>
>>> :o)
>>>
>>> +1 for wanting to disable this w/o TACACS
>>
>> Exactly. In my book, "simple" = less operational dependencies. (Plus
>> configuration management system carries the burden of making these
>> changes anyway.)
>>
>>
> I'm not sure I understand the drawback of TACACS. It's obvious that
> redundancy is needed there. If you're already using TACACS it seems easier
> to place it there. I'm not sure I like the idea of a network using local
> auth everywhere but to each his own. If you use EEM what's to stop other
> "senior" engineers from just removing the script temporarily?

Common sense?

There are places (e.g. where I work) where there is no senior/junior/ops
hierarchy, and all people with access to routers are trusted
approximately equivalently. Those places don't get a lot of value from
TACACS for authorisation, and might therefore want the ability to filter
"dangerous" commands (i.e. commands that trip you up) without the hassle
of implementing TACACS.

Obviously many places will want TACACS for other reasons, and can get
dangerous command filtering "for free".
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Jeremy Bresley]

On 11/1/2010 7:16 AM, Tim Durack wrote:
> On Mon, Nov 1, 2010 at 7:58 AM, Phil Mayers<***@imperial.ac.uk> wrote:
>> On 31/10/10 15:39, Keegan Holley wrote:
>>> If you are simply trying to disable a command have you thought about doing
>>> so in tacacs? It sounds like it would be simpler and it also has the
>>> benefit of being centralized so you won't need to configure it on each
>>> individual router.
>> It also has the disadvantage of being centralised, so each router has to be
>> configured to talk to a central point-of-failure.
>>
>> :o)
>>
>> +1 for wanting to disable this w/o TACACS
> Exactly. In my book, "simple" = less operational dependencies. (Plus
> configuration management system carries the burden of making these
> changes anyway.)
>

Every Cisco device I've used TACACS on (which is a pretty long list)
supports redundant TACACS servers for failover. If you have a
geographically dispersed network, put a TACACS server in a management
network in multiple sites/cities/states and you have geographic
redundancy. Treat the TACACS servers like you do your DNS/NTP servers.
If the primary server goes unavailable, it will go down the list trying
each of the other servers.

In a properly designed network, the only times I've had to use the
locally configured username/password is when the links into the site are
all down, or when routing to all of the TACACS servers is broken. With
TACACS command authorization and ACS, what you want to do is fairly
straightforward. I know it is possible to do on the freebie tac_plus as
well, as we were doing it 8 or 9 years ago back in IOS 10.3/11.X days
with it.

Hope this helps.

Jeremy "TheBrez" Bresley
***@brezworks.com
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Phil Mayers]

On 01/11/10 16:35, Jeremy Bresley wrote:

>
> In a properly designed network, the only times I've had to use the
> locally configured username/password is when the links into the site are

Sure. But maybe the OP just prefers EEM, right?

Having said that, I'm (genuinely) curious - where do you store the local
admin password, and how often is it exercised? How do you ensure that
everyone knows it, and there won't be a major delay while you have to
dig it out of your password safe?

One reason there's a degree of comfort with only using the local
passwords at our place is that it means everyone knows (has to know) the
"real" router password. There's no possibility of a:

"darn, haven't used this in 6 months, can't remember it, oops the online
password database is down, trudge down to physical storage, open it,
oops someone forgot to update the bit of paper..."

...moment ;o)

(Of course the major reason we don't use TACACS is absence of need due
to absence of hierarchy, but I am curious how you deal with that)
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[David Rothera]

On Mon, Nov 1, 2010 at 5:38 PM, Phil Mayers <***@imperial.ac.uk> wrote:

> On 01/11/10 16:35, Jeremy Bresley wrote:
>
>
>> In a properly designed network, the only times I've had to use the
>> locally configured username/password is when the links into the site are
>>
>
> Sure. But maybe the OP just prefers EEM, right?
>
> Having said that, I'm (genuinely) curious - where do you store the local
> admin password, and how often is it exercised? How do you ensure that
> everyone knows it, and there won't be a major delay while you have to dig it
> out of your password safe?
>
> One reason there's a degree of comfort with only using the local passwords
> at our place is that it means everyone knows (has to know) the "real" router
> password. There's no possibility of a:
>
> "darn, haven't used this in 6 months, can't remember it, oops the online
> password database is down, trudge down to physical storage, open it, oops
> someone forgot to update the bit of paper..."
>
> ...moment ;o)
>
> (Of course the major reason we don't use TACACS is absence of need due to
> absence of hierarchy, but I am curious how you deal with that)
> _______________________________________________
> cisco-nsp mailing list cisco-***@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

We use it simply because if one person leaves the organization it is as
simple as removing one user and then they no longer have access.

Sure we use failover local accounts but these can only be used if the TACACS
server is down (all three of them) and even then the local password is some
obscure string that is stored in our CI database (one of the few advantages
of working in an ITIL house :P)

--
David Rothera
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Phil Mayers]

On 01/11/10 17:46, David Rothera wrote:
>
> We use it simply because if one person leaves the organization it is as
> simple as removing one user and then they no longer have access.

Sure. TACACS has a lot of plusses (pardeon the pun) we just feel
relatively few of them are a big win for us e.g. we have a small team
with low rate of turnover so a leaving, which is very rare, just means a
password change, which is good practice to do often anyway.

I realise we're an outlier in this.

>
> Sure we use failover local accounts but these can only be used if the
> TACACS server is down (all three of them) and even then the local
> password is some obscure string that is stored in our CI database (one
> of the few advantages of working in an ITIL house :P)

...which is what I'm asking: how do you ensure you have fast, reliable
access to that database during a (sufficiently large, probably rare)
outage? How do you know you won't be blocking on availability of that
database?

I can think of a few obvious ways; I'm just wondering what people
actually *do* :o)
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[David Rothera]

On Mon, Nov 1, 2010 at 5:54 PM, Phil Mayers <***@imperial.ac.uk> wrote:

> ...which is what I'm asking: how do you ensure you have fast, reliable
> access to that database during a (sufficiently large, probably rare) outage?
> How do you know you won't be blocking on availability of that database?
>
> I can think of a few obvious ways; I'm just wondering what people actually
> *do* :o)
>

Very good point and it's one that I don't really have an answer to, we have
never had an outage internally so large that we lost access to the CI
database, they are backed up elsewhere as well but I've never had to access
that system :-/

*Goes to check DR plan* :P

--
David Rothera
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Saxon Jones]

Using offline files and folders on our laptops (generally just for the
keepass and a few other folders, because it's annoying). On our
Blackberries and iPhones it gives the option to re-fetch or use the
previous copy, which is often recent enough that I'm not too
concerned. Having our passwords distributed/cached so widely means we
have a lot of work to do when someone leaves, which is about a yearly
event.

We use randomly generated passwords that are unique for every device
in our environment, so could be a PITA when we have to change
passwords but I've got that process scripted so it's only half bad.
It's the testing that's time consuming, though maybe there's a way to
test that the enable secret works when TACACS+ is still available, I
just haven't cared enough to look into it (taking TACACS+ down and
doing it manually is not a big deal in our shop).

-saxon

On 1 November 2010 11:59, David Rothera <***@gmail.com> wrote:
> On Mon, Nov 1, 2010 at 5:54 PM, Phil Mayers <***@imperial.ac.uk> wrote:
>
>> ...which is what I'm asking: how do you ensure you have fast, reliable
>> access to that database during a (sufficiently large, probably rare) outage?
>> How do you know you won't be blocking on availability of that database?
>>
>> I can think of a few obvious ways; I'm just wondering what people actually
>> *do* :o)
>>
>
> Very good point and it's one that I don't really have an answer to, we have
> never had an outage internally so large that we lost access to the CI
> database, they are backed up elsewhere as well but I've never had to access
> that system :-/
>
> *Goes to check DR plan* :P
>
> --
> David Rothera
> _______________________________________________
> cisco-nsp mailing list  cisco-***@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[David Rothera]

You could configure an ACL to block access to the TACACS server on an
upstream device and then test?

On Mon, Nov 1, 2010 at 6:31 PM, Saxon Jones <***@gmail.com> wrote:

> though maybe there's a way to
> test that the enable secret works when TACACS+ is still available, I
> just haven't cared enough to look into it (taking TACACS+ down and
> doing it manually is not a big deal in our shop).
>
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Nick Hilliard]

On 01/11/2010 18:43, David Rothera wrote:
> You could configure an ACL to block access to the TACACS server on an
> upstream device and then test?

typically you will need to test two scenarios: 1. the tacacs daemon being
down, resulting in TCP RSTs being sent to the router/switch, and 2. the
tacacs server being completely unavailable (sending nothing in return).

Adding in "local" (or "line" on IOX) as an aaa authentication method will
usually deal with this.

If you're using authorization, you'll also need to create a DR procedural
note to permit authorization to be disabled if the tacacs server is
completely unavailable, and to document how to do this on whatever device.
Otherwise you need to wait for a TCP timeout every time you issue a
command. This can be teeth-gnashingly frustrating when dealing with
service outages (i.e. think: 02:00am, tired, service down, can't browse
internet to check the exact command, your manager shouting at you, and to
top it all off, each command takes 20 seconds to execute).

Nick
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Lee]

On 11/1/10, Nick Hilliard <***@foobar.org> wrote:
... snip...
> If you're using authorization, you'll also need to create a DR procedural
> note to permit authorization to be disabled if the tacacs server is
> completely unavailable, and to document how to do this on whatever device.
> Otherwise you need to wait for a TCP timeout every time you issue a
> command. This can be teeth-gnashingly frustrating when dealing with
> service outages (i.e. think: 02:00am, tired, service down, can't browse
> internet to check the exact command, your manager shouting at you, and to
> top it all off, each command takes 20 seconds to execute).

At 2am all my managers are busy sleeping :) But regardless, doesn't
if-authenticated fix that horrible timeout wait? - ie:
aaa authorization exec default group tacacs+ if-authenticated

Lee
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Nick Hilliard]

On 01/11/2010 19:55, Lee wrote:
> At 2am all my managers are busy sleeping :) But regardless, doesn't
> if-authenticated fix that horrible timeout wait? - ie:
> aaa authorization exec default group tacacs+ if-authenticated

It does, yes. But it also authorises anything if you're authenticated.
You may not want this.

Nick
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Nick Hilliard]

On 01/11/2010 21:13, Nick Hilliard wrote:
> It does, yes. But it also authorises anything if you're authenticated.
> You may not want this.

Saku Ytti points out that "if-authenticated" will Do The Right Thing. i.e.
if authenticated locally, it will not bother trying to contact a tacacs+
server. However, if authenticated remotely, it will.

Nick
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Lee]

On 11/1/10, Nick Hilliard <***@foobar.org> wrote:
> On 01/11/2010 19:55, Lee wrote:
>> At 2am all my managers are busy sleeping :) But regardless, doesn't
>> if-authenticated fix that horrible timeout wait? - ie:
>> aaa authorization exec default group tacacs+ if-authenticated
>
> It does, yes. But it also authorises anything if you're authenticated.
> You may not want this.

Ahh.. right, hadn't thought of that. We used to have a group of
people that were allowed to do switch port changes (set the vlan &
up/dn ports) but that went away several years ago. So now if you're
allowed enable mode there's no [tacacs] restrictions on what you can
do.

Lee
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[David Rothera]

On 1 Nov 2010, at 23:57, Lee wrote:

> On 11/1/10, Nick Hilliard <***@foobar.org> wrote:
>> On 01/11/2010 19:55, Lee wrote:
>>> At 2am all my managers are busy sleeping :) But regardless, doesn't
>>> if-authenticated fix that horrible timeout wait? - ie:
>>> aaa authorization exec default group tacacs+ if-authenticated
>>
>> It does, yes. But it also authorises anything if you're authenticated.
>> You may not want this.
>
> Ahh.. right, hadn't thought of that. We used to have a group of
> people that were allowed to do switch port changes (set the vlan &
> up/dn ports) but that went away several years ago. So now if you're
> allowed enable mode there's no [tacacs] restrictions on what you can
> do.
>
> Lee

We just have two levels, one for the first-line guys who can run show commands but no config changes or clearing of things and another level for everyone else.

It seems to work pretty well for us and then there is the accounting side of being able to point fingers at people when things break... :P



_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Lee]

On 11/1/10, David Rothera <***@gmail.com> wrote:
> On 1 Nov 2010, at 23:57, Lee wrote:
>
>> On 11/1/10, Nick Hilliard <***@foobar.org> wrote:
>>> On 01/11/2010 19:55, Lee wrote:
>>>> At 2am all my managers are busy sleeping :) But regardless, doesn't
>>>> if-authenticated fix that horrible timeout wait? - ie:
>>>> aaa authorization exec default group tacacs+ if-authenticated
>>>
>>> It does, yes. But it also authorises anything if you're authenticated.
>>> You may not want this.
>>
>> Ahh.. right, hadn't thought of that. We used to have a group of
>> people that were allowed to do switch port changes (set the vlan &
>> up/dn ports) but that went away several years ago. So now if you're
>> allowed enable mode there's no [tacacs] restrictions on what you can
>> do.
>>
>> Lee
>
> We just have two levels, one for the first-line guys who can run show
> commands but no config changes or clearing of things and another level for
> everyone else.
>
> It seems to work pretty well for us and then there is the accounting side of
> being able to point fingers at people when things break... :P

exactly :) Just because there's no technical restriction on what
we're allowed to do doesn't mean there aren't any managerial
restrictions.

Lee
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Mark Tinka]

On Tuesday, November 02, 2010 08:01:13 am David Rothera
wrote:

> We just have two levels, one for the first-line guys who
> can run show commands but no config changes or clearing
> of things and another level for everyone else.
>
> It seems to work pretty well for us and then there is the
> accounting side of being able to point fingers at people
> when things break... :P

I've always wondered why (maybe it's supported and I just
haven't figured out how) RANCID updates don't include the
username of the person that made the changes which caused
the updates in the first place in Cisco, like Juniper does.

I write/understand code for sh**, so I'm not sure whether
this is a limitation in IOS(-**) or RANCID. But having this
for Juniper helps a great deal, as it's much easier to tell
who made the last change(s).

Cheers,

Mark.

[Andrew Koch]

On Tue, Nov 2, 2010 at 03:35, Mark Tinka <***@globaltransit.net> wrote:
> I've always wondered why (maybe it's supported and I just
> haven't figured out how) RANCID updates don't include the
> username of the person that made the changes which caused
> the updates in the first place in Cisco, like Juniper does.

I don't use RANCID, but I suspect that it is using SNMP WriteNet to
effect its changes. This is an SNMP set command that contains the IP
address of a TFTP server and a string of the filename to import into
the running configuration. As IOS has no user associated with the
SNMP daemon, when updates are made via this method, no username is
shown as the last change. However, typically, the log will show a
SNMP WriteNet request was processed.

> I write/understand code for sh**, so I'm not sure whether
> this is a limitation in IOS(-**) or RANCID. But having this
> for Juniper helps a great deal, as it's much easier to tell
> who made the last change(s).

Yes, it would be nice to see who changed the configuration, but the
SNMP WriteNet doesn't have a user to go with.

Regards,
Andy Koch
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Andrew Hoyos]

On Tue, Nov 2, 2010 at 3:35 AM, Mark Tinka <***@globaltransit.net> wrote:
> I've always wondered why (maybe it's supported and I just
> haven't figured out how) RANCID updates don't include the
> username of the person that made the changes which caused
> the updates in the first place in Cisco, like Juniper does.

There is a line you can comment out in the RANCID script to include
the info at the top of a 'show running-config'

/^! (Last configuration|NVRAM config last)/ && next;

Which will in turn include the output at the top of a typical 'show
run' executed from the console, like below:

!
! Last configuration change at 13:52:22 CDT Mon Nov 1 2010 by admin
! NVRAM config last updated at 10:33:31 CDT Fri Oct 29 2010 by admin
!

--
Andrew Hoyos
***@gmail.com
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Lee]

On 11/2/10, Mark Tinka <***@globaltransit.net> wrote:
>
> I've always wondered why (maybe it's supported and I just
> haven't figured out how) RANCID updates don't include the
> username of the person that made the changes which caused
> the updates in the first place in Cisco, like Juniper does.

If you're talking about the "Last configuration change at .. by .."
line, it's a rancid design decision. If you'd like the line included
in rancid updates just delete or comment out the

/^! (Last configuration|NVRAM config last)/ && next;

line in rancid.

Regards,
Lee
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Mark Tinka]

On Tuesday, November 02, 2010 10:57:08 pm Lee wrote:

> If you're talking about the "Last configuration change at
> .. by .." line, it's a rancid design decision. If you'd
> like the line included in rancid updates just delete or
> comment out the
>
> /^! (Last configuration|NVRAM config last)/ && next;
>
> line in rancid.

Thanks Lee, Andrew.

Cheers,

Mark.

[Keegan Holley]

On Mon, Nov 1, 2010 at 3:55 PM, Lee <***@gmail.com> wrote:

> On 11/1/10, Nick Hilliard <***@foobar.org> wrote:
> ... snip...
> > If you're using authorization, you'll also need to create a DR procedural
> > note to permit authorization to be disabled if the tacacs server is
> > completely unavailable, and to document how to do this on whatever
> device.
> > Otherwise you need to wait for a TCP timeout every time you issue a
> > command. This can be teeth-gnashingly frustrating when dealing with
> > service outages (i.e. think: 02:00am, tired, service down, can't browse
> > internet to check the exact command, your manager shouting at you, and to
> > top it all off, each command takes 20 seconds to execute).
>
> At 2am all my managers are busy sleeping :) But regardless, doesn't
> if-authenticated fix that horrible timeout wait? - ie:
> aaa authorization exec default group tacacs+ if-authenticated
>
> Yea, most people don't want to auth every single command. I think that's
off by default by the way. The above command sequence lets you into enable
mode if you were able to get into the router at all if I remember correctly.
If you implement it correctly TACACS can be pretty resilient. I've seen
gigantic companies auth several hundred devices with almost no downtime (for
TACACS anyway). It's not like you're strapping the tacacs servers to the
outside of the building in the middle of a storm. Most just make sure they
have more than one server and remember to do a hardware refresh before the
harddrive platters turn to dust. but YMMV.
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Lee]

On 11/1/10, Saxon Jones <***@gmail.com> wrote:
..snip..
>
> We use randomly generated passwords that are unique for every device
> in our environment, so could be a PITA when we have to change
> passwords but I've got that process scripted so it's only half bad.
> It's the testing that's time consuming, though maybe there's a way to
> test that the enable secret works when TACACS+ is still available,

Use john the ripper to check the password. Create a one line wordlist
with the clear-text password & give john the encrypted password from
the config

Lee
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Keegan Holley]

On Mon, Nov 1, 2010 at 1:38 PM, Phil Mayers <***@imperial.ac.uk> wrote:

> On 01/11/10 16:35, Jeremy Bresley wrote:
>
>
>> In a properly designed network, the only times I've had to use the
>> locally configured username/password is when the links into the site are
>>
>
> Sure. But maybe the OP just prefers EEM, right?
>

I'm glad this became a new thread. We already established that the OP is
using radius so most of this is moot.

>
> Having said that, I'm (genuinely) curious - where do you store the local
> admin password, and how often is it exercised? How do you ensure that
> everyone knows it, and there won't be a major delay while you have to dig it
> out of your password safe?
>

There are a number of password databases. In my experience most engineers
just had them written down somewhere though. Especially if the management
network is a closed system and requires secure authentication (not that I'm
advocating this). I've also seen the password database stored on a jump
host as an encrypted text file. Still fallible, but if all the jumpservers
and all the TACACS servers are all down at the same time I'd probably be
more concerned with that than finding passwords.


>
> One reason there's a degree of comfort with only using the local passwords
> at our place is that it means everyone knows (has to know) the "real" router
> password. There's no possibility of a:
>
> "darn, haven't used this in 6 months, can't remember it, oops the online
> password database is down, trudge down to physical storage, open it, oops
> someone forgot to update the bit of paper..."
>

I think most large networks use some sort of centralized authentication
method, but I could be wrong. Every company I've worked for in the last 10
years or so has used TACACS or RADIUS and sometimes both. I cannot remember
auth being unavailable for more than a few minutes at any one company. Even
if it would have been it would have taken an hour or so to restore from the
latest backup. It's pretty cheap to scatter intel boxes about for auth and
jump access depending on the size of your network.

>
> ...moment ;o)
>
> (Of course the major reason we don't use TACACS is absence of need due to
> absence of hierarchy, but I am curious how you deal with that)
>

What do you mean by hierarchy? Most of the companies I've seen have a
single level of access and just use tacacs as a way to grant or revoke
access to everything at once. The biggest problem with local passwords is
that they almost never change. So anyone that can convince someone to give
them a password or has worked at the company in the past can login to
equipment provided they can gain access to the correct resources.

Then there's policy enforcement. For example how do you prevent an engineer
from accidentally deploying a router with "cisco" as the password or without
any password at all. Or a password with too few characters... etc.
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Phil Mayers]

On 11/01/2010 08:02 PM, Keegan Holley wrote:
> What do you mean by hierarchy? Most of the companies I've seen have a
> single level of access and just use tacacs as a way to grant or revoke
> access to everything at once. The biggest problem with local passwords

Interesting. I was under the impression that a common use-case for
TACACS was command authorization; letting "2nd line" engineers do things
like provision new gig ports, but needing a "3rd line" engineer to
change IP routing etc.

> is that they almost never change. So anyone that can convince someone
> to give them a password or has worked at the company in the past can
> login to equipment provided they can gain access to the correct resources.

Shrug. We change passwords & SNMP communities pretty frequently.

We certainly don't have hundreds of routers, and I'm not advocating this
method for huge networks or those with large teams / high turnover, but
it works well for us.

>
> Then there's policy enforcement. For example how do you prevent an
> engineer from accidentally deploying a router with "cisco" as the
> password or without any password at all. Or a password with too few
> characters... etc.

Templated configs.

If occurs to me that if one is archiving "fallback" passwords into some
kind of database, it should be pretty trivial to do an SHA of the
plaintext and compare that to the value on the router. Any differences
== bad. Obviously that would work just as well for "merely" local passwords.
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Keegan Holley]

On Mon, Nov 1, 2010 at 5:03 PM, Phil Mayers <***@imperial.ac.uk> wrote:

> On 11/01/2010 08:02 PM, Keegan Holley wrote:
>
>> What do you mean by hierarchy? Most of the companies I've seen have a
>> single level of access and just use tacacs as a way to grant or revoke
>> access to everything at once. The biggest problem with local passwords
>>
>
> Interesting. I was under the impression that a common use-case for TACACS
> was command authorization; letting "2nd line" engineers do things like
> provision new gig ports, but needing a "3rd line" engineer to change IP
> routing etc.


Oh not at all. That's one of things that's available but no one remembers
or needs. The most common use case for TACACS is centralized authentication
and sometimes accounting. It usually ends up tied to a database such as
active directory or LDAP as well so that all of the engineers accounts can
be managed from the same place. I have seen complex deployments like that.
For example the linux jump servers and routers (via TACACS) all
authenticated to AD. Then the AD administrators would grant and revoke
rights simply by moving user accounts into preconfigured OU"s in active
directory.

>
>
> is that they almost never change. So anyone that can convince someone
>> to give them a password or has worked at the company in the past can
>> login to equipment provided they can gain access to the correct resources.
>>
>
> Shrug. We change passwords & SNMP communities pretty frequently.
>

Interesting. To each his own I suppose. Do you configure local accounts or
is it just the single vty password? One of the other things TACACS buys you
is auditing and tying individual engineers to specific changes.

>
> We certainly don't have hundreds of routers, and I'm not advocating this
> method for huge networks or those with large teams / high turnover, but it
> works well for us.


Even better. I've seen small networks use the freeware TACACS daemon just
for the centralized auth. It honestly comes in pretty handy. Depending on
how it's configured and the size of your network you should probably have a
redundant server or two. I've even seen people regionalize this where there
were a couple of servers for each region. Compute is cheap these days.

>
>
>
>> Then there's policy enforcement. For example how do you prevent an
>> engineer from accidentally deploying a router with "cisco" as the
>> password or without any password at all. Or a password with too few
>> characters... etc.
>>
>
> Templated configs.
>

What if someone decides to change the pw after the template has been rolled
out? I assume this is scripted as well or there is also danger of mistyping
something or adding an extra space into the pw when pasting it in.

>
> If occurs to me that if one is archiving "fallback" passwords into some
> kind of database, it should be pretty trivial to do an SHA of the plaintext
> and compare that to the value on the router. Any differences == bad.
> Obviously that would work just as well for "merely" local passwords.
>

True. You could also use the same mechanism in reverse to store the
passwords locally. I think this is even built into openssl.
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[s***@nethelp.no]

> > Interesting. I was under the impression that a common use-case for TACACS
> > was command authorization; letting "2nd line" engineers do things like
> > provision new gig ports, but needing a "3rd line" engineer to change IP
> > routing etc.
>
>
> Oh not at all. That's one of things that's available but no one remembers
> or needs.

I can't comment on how common it is, but we use it. We block commands
like "switchport trunk allowed vlan <digits>", while allowing "none",
"add" and "remove" forms of the same. It's a way of preventing a too
common case of shooting yourself in the foot.

Steinar Haug, Nethelp consulting, ***@nethelp.no
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/