Conference azur::mcc

For security reasons, you can't create a rule with "by password".
However, you should be able to use "by password" when you enable the rule.

Thanks for the quick reply!!

The password field was set from the access pull down 
is this what is required?? Ie. we were able to 
sucessfully query the device using the password from the
iconic map but figured we had to enter the password because
the rule returned an access control violation with out it.


Note: we were able to get it to work from the fcl by
using enable domain xxx rule xxx, by pass xxx

Regards,

Peter Lamb

I had a brief conversation with Erik Mintz and we believe
we have a workarround but I will have to wait till I
hear from the customer to be sure...

Essentually the "by password" problem occurs any time
I try to create a rule once I have defined a community
password (using ACCESS pulldown).  I get the same message
if I try to define a rule with the BY PASSWORD qualifier.

The workarround apears to be to...

1) Clear the community name password

2) Define/enable the rule

3) reset the password using the access menu

Need-less-to-say this is less then desirable behavior
and my guess is that you will recevie lots and lots of
calls on this...

For further clarification I am trying to do the
equivilent thing from the iconic map as described by
the mcc_fcl example below.

MCC> create domain domain.130-221-208-0-hosts rule mib_tester -
_MCC> expression = (SNMP nml-lantern novell mibDoc lanternEthernet -
_MCC> eUnicastPkts > 225000, at every 00:05:00),
_MCC> severity = major

MCC> disable domain domain.130-221-208-0-hosts rule mib_tester

MCC> enable domain domain.130-221-208-0-hosts rule mib_tester, -
_MCC> by password administrator

Peter,

Am I right, you are using DECmcc for Ultrix V1.2.7?
Because I saw a problem (we use DECmcc for VMS V1.1) with SNMP rules.
We enabled the rule with  "by password = ,,,,,". But we get an access control
violation. We checked the ethernetpacket and saw not our password in, but the
defaultpassword.


Roland

Still looking for help!!

Peter

I spoke to the customer this morning and they confirmed the 
convoluted procedure one must follow to create/enable a rule on
an SNMP device that requires password access.   Here are the
steps one must follow...

1) Delete the password (Under Operations Menu) if already set

2) Create Rule

3) Disable Rule

4) Set password

5) Enable the rule

Note: while this works it is obviously less then desirable!  I'm 
really not sure how we can expect to be a credible SNMP management
system with problems like this...

The customer also mentioned some additional things he noticed
when the password is set.

   *  Show rule status does not work and returns the error 
      "by password" not supported

   *  The same problem occurs when attempting to disable a rule 
      when the password is set.

I'm hoping that something can be done to solve this problem prior
to 1.2 shipping as I really think this is a serious problem.

Regards,

Peter Lamb

I have added this information to QAR 2884, which discusses related
problems with "by password" in alarm rules.

RE: .6

> The customer also mentioned some additional things he noticed
> when the password is set.
>
>   *  Show rule status does not work and returns the error 
>      "by password" not supported
>
>   *  The same problem occurs when attempting to disable a rule 
>      when the password is set.

  Peter,

  fwiw ... When you set the Access Control qualifiers in the Iconic Map,
  their values remain 'sticky' for all subsequent operations.

  So .. if you set the By-Password qualifier for an SNMP operation, then
  access an Alarm Rule, the By-Password qualifier is passed to the Alarms
  Function Module.  Alarms does not accept this qualifier (except for the
  Enable directive) - and therefore rejects the operation.

  For t1.2.7 (field test update) Alarms was modified to accept and
  ignore the Access Control qualifiers (password, user, account)

  /keith

>  For t1.2.7 (field test update) Alarms was modified to accept and
>  ignore the Access Control qualifiers (password, user, account)

I am running 1.2.7 and my problem is that it isn't ignoring the password
qualifiers.

Peter

>I'm confused.. In your note you said 
>
>>  For t1.2.7 (field test update) Alarms was modified to accept and
>>  ignore the Access Control qualifiers (password, user, account)
>
>I am running 1.2.7 and my problem is that it isn't ignoring the password
>qualifiers.
>
>Peter

  Peter .. I just checked the Alarms source.  The change was *ONLY*
  made for the Domain/Rule interface .. 8(

  Which interface are you using?  Domain/Rule or MCC/Alarms/Rule ??

  I will QAR alarms to make sure that both interfaces ignore the
  Access Control Qualifiers

  /keith 

  The problem with Alarms not ignoring Access Control qualifiers has
  been QAR'd ... # 2895

  /keith

Should an SNMP rule with "password" work under V1.1?

A customer of us told me that it does NOT. He created the rule, disabled it and
enabled it again with "by password". But still the exception was fired. He looked
to the ethernetpacket and saw only the default password (communityname) in.

Does somebody use SNMP rules with not default password under V1.1?


Roland