Authentication setting in confd.conf vs CDB

Core Engine and APIs
1

Hi,
I changed authOrder in confd.conf file.
<authOrder> localAuthentication externalAuthentication </authOrder>
But, for any ssh login, it does not respect confd.conf file. It looks into CDB and which has old data.
<authOrder> externalAuthentication localAuthentication pam </authOrder>

How can I confirm for each login to check auth order from confd.conf?
Please suggest.
Thanks in advance.

Sumeet

2

Hi,

Check your ConfD audit log for info the method(s) used for authentication. See for example here for a sample output: Issue in External Authentication - #6 by Shafath

3

I checked logs. It picks order for authentication from CDB, not from confd.conf file. CDB has old data. But confd.conf file has new data. Auth order is changed in confd.conf.
Here it shows:
In CDB:
localAuthentication externalAuthentication
In confd.conf:
externalAuthentication localAuthentication pam

In logs (It checks first local authentication. user1 is not local user.It takes auth order from CDB, not from confd.conf):
Jan 16 18:26:00 127.0.0.1 2019-01-16 18:26:00,785 [Thread-0] WARN EventLog.confd- AuditNotification[logno=100, user=user1, usid=0, msg=“no such local user”]
Jan 16 18:26:02 127.0.0.1 2019-01-16 18:26:02,486 [Thread-0] WARN EventLog.confd- AuditNotification[logno=103, user=user1, usid=0, msg=“Logged in over ssh using externalauth, member of groups: no-group”]
Jan 16 18:26:02 127.0.0.1 2019-01-16 18:26:02,486 [Thread-0] WARN EventLog.confd- AuditNotification[logno=108, user=user1, usid=0, msg=“logged in over ssh from 172.22.122.142 with authmeth:password”]
Jan 16 18:26:04 127.0.0.1 2019-01-16 18:26:04,020 [Thread-0] WARN EventLog.confd- AuditNotification[logno=105, user=user1, usid=101, msg=“assigned to groups: no-group”]

Thanks,
Sumeet

4

I assume that with “In CDB”, you are referring to settings in the confd_dyncfg namespace/module. And apparently you have set a value for authOrder both there and in confd.conf, but expect ConfD to use the value in confd.conf - and because it’s “newer”???

I’m afraid you need to read up on the documentation for confd_dyncfg, i.e. the section Storing ConfD configuration parameters in CDB in the Advanced Topics chapter of the User Guide. In particular this text towards the end of the section:

   When /confdConfig/runtimeReconfiguration is set to
   _namespace_, any settings in confd.conf for the parameters
   that exist in the confd_dyncfg namespace are ignored, with
   one exception: the configuration under /confdConfig/logs.

I.e. besides that exception, it’s strictly either/or - since authOrder exists in confd_dyncfg, only the setting in confd_dyncfg is used, and anything set for that parameter in confd.conf is ignored.

5

You are right. I have authOrder change in both confd.conf and confd_dyncfg_init.xml. But, it does not pick order from any of these files.
Here is confd_dyncfg_init.xml file content for aaa authOrder:
< config xmlns=“http://tail-f.com/ns/config/1.0”>

< confdConfig xmlns=“http://tail-f.com/ns/confd_dyncfg/1.0”>
< aaa >

 <sshPubkeyAuthentication>none</sshPubkeyAuthentication>
  <authOrder>externalAuthentication localAuthentication pam</ authOrder>

…
…

6

Well, then I would suggest that you start by removing it from confd.conf to avoid confusion, since whatever you set there will always be ignored when you use confd_dyncfg.

There’s nothing “magic” with confd_dyncfg_init.xml, it is just like any other “CDB init file” - to quote the User Guide section “Loading initial data into CDB”:

At startup, when CDB is empty, i.e. no database files are found in
the CDB directory, CDB will try to initialize the database from all
instantiated XML documents found in the CDB directory.

I.e. once CDB has been created, changes to the init files, including confd_dyncfg_init.xml, has no effect. The whole point with confd_dyncfg is that you can change the ConfD daemon configuration by changing the actual contents of CDB, instead of editing a config file and reloading it. If you don’t intend to use this possibility, it is better to not use confd_dyncfg at all, since then the result is just that you have two config files to manage and edit instead of one.

If you do intend to make use of the confd_dyncfg functionality, but wish to have changes to the init file (i.e. new “initial values”) take effect without having to remove CDB and restart ConfD, you can (just as with any other CDB init file) explicitly load the updated file into CDB with maapi_load_config() or the confd_load utility.