Remote AD: forcing bind user

Feature
,
1

As you know, NethServer can join a remote Active Directory and use it as account provider.

When an application authenticates against a remote AD, it can use 2 different protocols:

  • GSSAPI (Kerberos): used by PAM
  • LDAP bind: used by third-party applications which don’t use PAM, like Nextcloud, FreePBX etc.

So, if you have a NethServer joined to an AD, you need to add an extra bind user and bind password if you want to make all applications access the account provider.
The underlying implementation is quite complex and not all users know the difference between these two protocols, and often they forget to configure a valid bind user.

Currently the bind user is optional, what do you think to make it mandatory?
This is choice will drastically reduce user errors and I don’t see any real downside.

So, what do you think?

2

Mandatory can be dangerous:

  • A remote MS AD could be subject to any kind of restricted policy
  • Some NS installations wouldn’t actually require it (i.e. a plain IMAP mail server or a Samba file server)

What if we display a TODO?

We could even display a web splash page in place of the expected web application, if the configuration is not completed:

“Webapp X is not configured…”

2 Likes
3

It seems to be a good idea to me.

But if you’re the sysadmin of the scenario you should know if there’re security policies applied or not.
If you’re not the Microsoft AD sysadmin, the admin in charge to which you ask for the user for the bind should know!

Well, the bind user will simply not be used in that case, right? :slight_smile:

2 Likes
4

…and should be collaborative! Can we assume he’s going to create an additional account for us?

I’d prefer not to make this assumption. I’d prefer a system that fits any environment.

Yes, …and if the AD sysadmin is on holiday (for instance) you’re stuck!

1 Like
5

Yes, since it’s a requirement for many applications. It should be part of the installation process:
allocate IP for a new server and user for AD connection :slight_smile:

I don’t get this, if the user is setup in the join stage, it will be valid even if the AD sysadmin is on vacation.
I would also assume that in most scenarios the AD sysadmin and NS one, are the same person! :smiley:

We need to ease the life of users, not arguing about best practices.

@filippo_carletti @nrauso @CharlieWhiting how many times sysadmins face this kind of problem?
If the problem arises 90% of times, probably it worth to restrict configuration freedom and make it work.
Otherwise, if only few people encountered the problem, we can just add a documentation line inside the join form.

6

I guess that @gg_jr @dnutan @guus @mrmarkuz @enzoturri @mansoor.tariq may be interested in that discussion

2 Likes
7

The IP is required on local accounts provider. Only remote case here. Anyway, the join process has already too many requirements that are difficult to understand. This is another reason to avoid a new mandatory one which could lead to further troubles (even on a minority of cases).

I’d rather say we need to ease the life of users through best practices; …and shorcuts are dangerous.

1 Like
8

I think you already know my point of view regarding the administration of an Information System by a sysadmin.
No matter if that I.S. is at work or at home, the person which administer that I.S., the sysadmin, must have enough knowledge to do that.
Otherwise, no matter how easy to configure is the NethServer (in this case) made, nothing will work!
Another thing related to all from above: all this settings, will never be made by the user(s)! Or never should be made by user(s).

And yes, “…we need to ease the life of users through best practices; …and shortcuts are dangerous.”, with a little amendament, at least in this case: instead of “users”, i’d say “sysadmins”. The users only use!

Kind regards,
Gabriel

3 Likes
9

I agree with you at 120%

NS can’t be (ant IMVHO must not be) used by everybody: and the aim to be used by home users with no knowledge must have a limit… we’re talking about a sever (often exposed to wan)

from murphy’s law:

Make a system even a moron can use and a moron will use it.

1 Like
10

He have to! Or we could not get our job done!
In that case our modules could not work anyway![quote=“davidep, post:4, topic:8229”]
…and if the AD sysadmin is on holiday (for instance) you’re stuck!
[/quote]
The same as above…

In my experience it happens in more than 50% of the cases.

11

This is the current join form

We should ask BOTH a privileged user’s credentials to join the machine AND unprivileged user’s credential for SOGo, WebTop & Co. LDAP simple binds? Mandatory?

I’m still not convinced making it mandatory is a good idea that simplifies the sysadmin work and eases configuration… I still prefer adding a TODO and displaying a comprensible error page in place of /sogo and /webtop URLs.

12

Thank you for the amazing feedback!

To recap we should proceed following these directions:

  • do not make bind user mandatory
  • read-only bind credentials should be more visible inside the UI
  • the UI must inform the user about applications which need bind credentials

I will add it to our roadmap!

Just for reference, we can list applications which uses bind credentials with a code like this:

for PACKAGE in $(grep -l -R -e bindDN -e userDN -e bindUser -e groupDN -e bindPassword /etc/e-smith/events/actions/ /etc/e-smith/templates/ \
    | xargs -- rpm -qf --queryformat '%{NAME}\n' | sort | uniq \
    | grep -v -E 'nethserver-(dc|sssd|directory)' | cut -d'-' -f2); do
    echo "${PACKAGE}"
done
3 Likes
13

Sadly, I know it well :blush:

Instead of seeking dependant packages, we should do the contrary: individual packages subscribe the nethserver-sssd-save event!

14

This feature is now on testing! /cc @quality_team

https://github.com/NethServer/dev/issues/5396

Who wants to run some test cases?

15

What exactly do you want tested ?

16

Test cases description is available from the link above! Please ask if you need explanations!

17

I install the sssd rpm mentioned and start testing right?

I’ll have a go at it tomorrow. It’s a perfect day for some testing as half the company will be busy with meetings :smiley:

1 Like
18

Murphy interfered … I will be testing later today/tonight … sorry for the delay.

2 Likes
19

So … at first glance that looked like not much work … then I read it again and a bit more careful :stuck_out_tongue:

I have 0 experience with OpenLDAP, so I will test that last, as it will be a learning experience as well. Trying to figure out how to work through the cases I can test right now (which is samba AD scenario’s) I came up with the following testplan, please let me know if that would do:

  1. Create VM with fresh Nethserver installation, updated fully.
  2. Clone this machine, correct networking settings and hostname.
  3. snapshot both at this stage.
  4. Install the sssd RPM
  5. Run testcase 2.1 on the first VM, VM1
  6. Run testcase 2.4 on the second VM, VM2
  7. Run testcase 2.5 on the first VM, being a Samba AD server at this point
  8. unbind VM2 from VM1 and install SOGo
  9. Run testcase 3.4 on VM2
  10. reset snapshots
  11. install SOGO on both VM’s
  12. snapshot VM1 again
  13. Install Samba AD on VM1.
  14. Join VM2 to Samba AD on VM1.
  15. install sssd RPM on VM1 and VM2
  16. Run testcase 1.1 on VM1
  17. Run testcase 1.4.2 on VM2
  18. revert VM1 to latest snapshot
  19. install sssd RPM
  20. Run testcase 3.4 on VM1

Is there a preferred format for the output ? Screenshots ?

2 Likes
20

No in general. If you find an error screen it might be useful. Pay attention to error messages in /var/log/messages

1 Like