CDB AAA username/password pairs

General
1

Hi,

I see there are 4 pairs of username/password in confd CDB, they are admin/admin, oper/oper, private/private and public/public. I cannot see the difference between them yet. Seems logon using any of them I can do get or edit-config.

Can you tell what are the difference between these 4 pairs of username/pw?

Best

Wu

2

Note that if you are using the confd_cli tool logging in to the CLI your group id is different (unless you used the --group flag), so that the NACM rules will not trigger as expected.

Try logging in using the confd_cli --group (or -g) flag, NETCONF or SSH when you test your nacm rule. For example:

$ confd_cli -u my-username -g my-group

or

$ ssh -l my-username 127.0.0.1 -p 2024

Demo of difference between confd_cli with and w/o -g flag and SSH:

$ confd_cli -u oper
# id
user = oper(501), gid=20, groups=oper,staff,access_bpf,everyone,localaccounts,_appserverusr,admin,_appserveradm,_lpadmin,_appstore,_lpoperator,_developer,com.apple.access_screensharing,com.apple.access_ssh, gids=12,20,33,61,79,80,81,98,100,204,398,399,503
# exit
$ ssh -l oper 127.0.0.1 -p 2024
oper@127.0.0.1's password: 
# id
user = oper(9000), gid=20, groups=oper, gids=
# exit
$ confd_cli -u oper -g oper
# id 
user = oper(501), gid=20, groups=oper, gids=12,20,33,61,79,80,81,98,100,204,398,399,503
#
3

admin and oper are meant to be there as default user accounts for all northbound interfaces whereas private and public are meant to be used by snmp only as they are the typical default user accounts there.

The key to understanding the authorization rules in aaa_init.xml is in the nacm section of the xml file:

<nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
...
</nacm>

Inside of the nacm section, the groups block defines the admin and oper user groups accordingly as follows:

<groups>
  <group>
    <name>admin</name>
    <user-name>admin</user-name>
    <user-name>private</user-name>
  </group>
  <group>
    <name>oper</name>
    <user-name>oper</user-name>
    <user-name>public</user-name>
  </group>
</groups>

Next is the rule-list blocks. To determine an user’s authorization, ConfD will start from the top of the rule-list blocks and look for the first possible match. The first rule-list block defines that the admin group has authorization to perform any operations on any YANG models.

<rule-list>
  <name>admin</name>
  <group>admin</group>
  <rule>
    <name>any-access</name>
    <action>permit</action>
  </rule>
</rule-list>

The second rule-list is for any non-admin user groups:

<rule-list>
  <name>any-group</name>
  <group>*</group>
  <rule>
    <name>tailf-aaa-authentication</name>
    <module-name>tailf-aaa</module-name>
    <path>/aaa/authentication/users/user[name='$USER']</path>
    <access-operations>read update</access-operations>
    <action>permit</action>
  </rule>
  <rule>
    <name>tailf-aaa-user</name>
    <module-name>tailf-aaa</module-name>
    <path>/user[name='$USER']</path>
    <access-operations>create read update delete</access-operations>
    <action>permit</action>
  </rule>
  <rule>
    <name>tailf-webui-user</name>
    <module-name>tailf-webui</module-name>
    <path>/webui/data-stores/user-profile[username='$USER']</path>
    <access-operations>create read update delete</access-operations>
    <action>permit</action>
  </rule>
</rule-list>

The first rule in the any-group section tells you that any non-admin users can only read and update their own user specific information as defined by path which points to the corresponding part of the YANG model. The second rule tells you that any non-admin users can only modify (including create, read, update and delete) their own user specific default CLI session parameters. The third rule tells you that any non-admin users can only modify (including create, read, update and delete) their own webui user profile settings.

You can refer to the authorization section of “The AAA Infrastructure” in the ConfD User Guide for more information.