Need to share on the defunct admin User

Development
1

Hi, I’m thinking loudly :slight_smile:

I used to authenticate on all web applications with the user admin who has died recently in NS7, indeed, now we authenticate with root in the server-manager.
Therefore when I code a module and I want to authenticate I could have some different approaches

  • Use an admin@yourdomain with ‘yourdomain’ is relevant (a sssd authentication)
  • Use a specific user for each webapp with a password that you can find in /varlib/nethserver/secrets (or in a database property eventually)
  • Use a user for all the webapp which the password is set in /varlib/nethserver/secrets (or in a database property eventually)

I personally do prefer the first solution (create a user admin@yourdomain manually in the user panel), except if I can authenticate with the root user, but I believe that the users with an uid inferior to 1000 are not available in sssd.

1 Like
2

If the module supports it, I think configuring a group of users with administrative role is the best way.

The big hurdle is the assumption we don’t have write access to the accounts DB: we cannot create special accounts for specific modules in the domain accounts DB. However, we could create them in /etc/passwd… mum’s the word! :smile:

3

Maybe this is not a much elegant solution, but I like it.
During the time, many users ask for different access to different applications and this the the most straightforward way to achieve it.

4

Which issues can we encounter taking this way?

5

To @dev_team … hi all

Looking to the choice taken with NS7, I regret some changes like the lost of users in the database accounts. Of course like I say often we fear only what we don’t know, but here, I’m looking a way to store specific settings for a groups or users…and I have no direct solution except to write some code in each module to set in a textarea box each user/group I want to allow…not a nice solution.

I mean for example to store authorisation to access a web content by a db property (‘enabled’ or ‘disabled’ by example) like we could do in NS6 with a ‘RowPluginAction’, it was so simply and so efficient.

My understanding of the Account panel is that settings are not stored, but used as parameters with an event. I suppose that we cannot store extra parameters in this database (whatever it is sssd, openldap, samba4).

I regret also the design choice of the user/group panel, we cannot add code to store settings for a user or a group. the code is closed :frowning: However it is consistent since the choice was made to avoid customisations.

I guess that it could be possible to store settings under the accounts database and following an event, write the configuration where it is needed, but what I don’t know is why this solution was not taken.

Of course if I’m wrong, please correct me and drive to the solution :slight_smile:

1 Like
6

It comes to my mind the Email address page: it gets the list of accounts from NethServer::Database::Passwd and stores specific settings in esmith DB, like IMAP access enabled/disabled or mail forward address.

As said in the past, on ns7 the assumptions changed. We have “multisite”/remote account providers, we need other solutions.

The Users and groups module in ns7 is not designed to be extended by plugins for the same reason.

No it’s not possible. For example, if my account provider is a remote OpenLDAP instance how/when a user-create event can be invoked? As the instance is remote there’s no way to signal user-create on my server from the OpenLDAP instance.

The same for user-modify and user-delete.

Would you mind providing more details about your issue?

7

Just jumping in (take note I am not a devver, but you all know this)
If you want introduce a new application, in my opinion it would be a good idea to give this application a dedicated ‘admin’ user (for database issues etc)
As a default convention you could opt for 'admin_modulename’
The install process should create that user in the account provider and create the same user in the database (mysql or mariadb)
I don’t know if you can trigger the creation of these accounts during the process automaticly?
(I realize now I should have read all replies before jumping in… :wink: )

1 Like
8

Think about this scenario: I can’t think of a situation where you deploy a service and you don’t control the account provider. I mean, you offer a service without you have access to the users using it? That does not compute… I mean, we are still looking at a small business server… What remote LDAP/AD are you thinking of when adding a service that needs authentication?

9

You can’t rely on user create/modify/delete events, but you can still save some local properties in a custom esmith db.

In this case, I’d go with a new modules which uses a “webaccess” db.
Each record is the name of the user with a status prop, something like this:

myuser=webaccess
   status=enabled

You should then add a “Synchronize” button (or something like this), which eventually deletes from webaccess db all non-existent users.

I agree.

Of course you can, but not on the user provider (openldap/samba4). You can surely do inside the app.

You have two servers inside the LAN:

  • mail server with all users
  • a firewall using web filters based on user profile

If the administrator creates a new user inside the mail server, the firewall doesn’t know it.

10

I don’t know if we understand each other here.
If we consider a Network with NethServer(7) as base, the accountprovider is either OpenLDAP or Samba4.
Then all authentication is based on the accountprovider of choice. Isn’t it so that in that case, the mailserver and the firewall use the same accounts in order to provide the service?

Where I want to get to is: do we want to support a remote account provider for services hosted by NethServer?
I also realize that IF we don’t want to support a remote accountprovider, we must change the current way Samba4 is implemented, since it is now impossible to join an existing AD domain as a (fullblown) DC. In order to be able to add/change/delete accounts in an existing AD, NethServer Samba4 implementaion must change to allow for that scenario. @Christian what do you think?

11

Yes, we already do it! The nsdc container is actually a “remote” account provider. In the future I’d like to provide an additional DC to an existing AD domain. Here we talk about “replacing” (i guess there are limitations on what can be replaced) but should be similar to “add”:

12

@davidep: In previous discussions it has been mentioned: currently it is not possible to add a NS7 server as a DC in an existing AD domain. IMO this means that NS is supporting a 'cripled’Samba4 implementation, since samba4 allows this. And what I understood from the previous discussion is that the main reason is that there is no anonymous bind to the Samba4 directory.
Without the intention of doing that whole discussion again, I still don’t get exactly why the choice of limiting access to authenticated users to the directory has been done. Maybe I overlooked the statement or (more likely) just didn’t understand the statement when I read it, but I sure would like to know (and understand)

13

Right, it is a (still) unsupported scenario. We’re working on it.

No, this is not related with the scenario above.

No such choice was made, AFAIK it’s the default behavior of Samba (and MS AD, too).

14

You hit the bell, I got it now. Indeed if I modify locally I can not do the sync on the remote authenticator.

Well this option is nice but it is not the one I choose. I do prefer to get one ‘admin’ for every webapp…let’s things simple…the name is ‘admin’. I just need it to authenticate in apache, for other purposes like for mysql DB, each database gets its user.

Yeah one way, for now I store all users in one property from a textArea box in Nethgui…the cons is that the separation between user name is not a comma but a line break and therefore you cannot modify manually the property by the command line. the pro is that the content is easily readable.

and the template

Thanks a lot all, it seems clear now

2 Likes
15

I like it! We could define a simple convention. Just a couple of props in config DB…

sysconfig=configuration
    ...
    adminUser=administrator
    adminGroup=administrators

…and the @domain suffix added by templates. Individual packages that need an administrative identity can read those props and use them in their configurations.

The default values proposed above would fit 90% of our account providers. AD has them, our OpenLDAP can be provisioned in the same way. For remote LDAP directories where we cannot make any kind of assumption (the 10%), the two props can be fixed and a system-adjust event issued at the end.

4 Likes
16

Indeed the Idea to have a generic user created from base with a default password is great for me. It will avoid to create it manually like I ask it now for my modules. Of course all Module authors could in the future rely on it also.

Obviously only the rpm nethserver-directory needs to be modified, some idea on how to do it ?

17

Can you give a list of modules that would benefit from this convention?

When the LDAP tree is provisioned for the first time we could run luseradd and lgroupadd to create the administrator user and administrators group.

Are you going to open a PR? :wink:

1 Like
18

Honestly, near quite all web applications I did for NS6

nethserver-BackupPC-1.0.1-2.ns6.src.rpm
nethserver-linux-dash-1.0.0-1.ns6.src.rpm
nethserver-shellinabox-0.0.8-1.ns6.sdl.src.rpm
nethserver-tt-rss-1.0.0-5.ns6.sdl.src.rpm
nethserver-urbackup-0.0.2-1.ns6.sdl.src.rpm

For NS7, some module are done (shellinabox, tt-rss) but my dream would be to use a token in the server-manager like it is possible in Formagick and get rid of the password authentication…it could be so cool

{
    $OUT .= "LoadModule auth_tkt_module modules/mod_auth_tkt.so\n";

    my $secret = ${'httpd-admin'}{TKTAuthSecret} || "34322500-7330-4400-423A-3A00434F5245";
    $OUT .= "TKTAuthSecret \"$secret\"\n";
}

Like this you can display the web application and restrict it if you are authenticated in the server-manager…the solution of the random url is nice also, but not enough secured

1 Like
19

2 posts were merged into an existing topic: Apache TKTAuth for modules proposal

22

Ok, I will try a go next week, this wk is like a mini fossdem for me…good time, meet people, share on code!!!

What else :slight_smile:

the action /etc/e-smith/events/actions/nethserver-directory-init-admin in NS6 is probably a good starting point