Question

Trying to edit netd.conf to add an AD group to groups_with_edit, to allow netedit-like privileges

  • 1 April 2020
  • 5 replies
  • 92 views

I’m trying to add a group that my LDAP authenticated users belong to, to the groups_with_edit line, to allow them the same permissions on netd as the netedit group.  However, when I add this group after netedit, and I log out and back in with that user, and restart the netd service, I cannot issue any net commands with that user. Not show or edit. 

It seems that as long as that group is specified in that list, in /etc/netd.conf, and the user belongs to that group, it should work. Am I missing something here?

Also, the documentation is wrong here. It shows the same names for the users as the groups, groups_with_edit and groups_with_show. Should show netedit and netshow, respectively. 


5 replies

Userlevel 4

Good catch on the doc problem @dubu2. I’ll get that fixed today.

As for the user not working, did you log out and in before restarting the netd service? I wonder if that made a difference?

Yes, I tried to answer that before it was asked in the explanation of this issue… Maybe I didn’t make that clear enough, apologies.

I’ve tried a few other methods as well, such as having the user automagically added to the netedit group upon LDAPS auth and login, using pam_group.so and an entry in /etc/pam.d/common-auth. This does successfully add the user to the group, but… and a BIG BUT… it does not concatenate the username onto the end of the group in the list /etc/group.  This is normally what happens when you perform a command such as

sudo usermod -aG netedit my_user

I found this out when I recognized that my new method “worked” (id - showed the group added to the user) but I could not issue net show config still. I’m perturbed as to why in the world this would half-way work. I’m asking the general Linux community for some assistance staying sane through this endeavor. Any assistance here is greatly appreciated as well.

Userlevel 5

These kinds of authentication issues are deep in the weeds. To maintain your sanity I strongly recommend opening up a GSS case to make sure the config is correct and to be able to dig deeper to identify a bug if there is one here also just to share best practices and see what others have done.

Unfortunately I haven’t seen enough LDAP configurations to comment more but I have seen a fair amount of TACACS and I know the TACACS libs have some tactics to handle this by adding users to a dummy group and then the dummy group gets added to netd.conf

Our support team has some LDAP folks on it that would probably be able to better address this question.

Userlevel 4

@dubu2 to file a ticket, click here.

Ok, so the big blunder on my part here was (and yes I felt like an idiot after finally seeing it) I was trying to run a show command, as verification that the group membership was working. However (and you’re probably already seeing where I’m going with this) I was not including my AD group in the “groups_with_show = “ line. Just in the “groups_with_edit = “ line… 

Yep, that simple. So, Cumulus’ netd.conf file works as expected for AD groups that an LDAP authenticated user belongs to, if they’re properly added to the configuration file, that is. 

On another note… PAM, does not work like it’s supposed to… and that is a hard thing to imagine, as the developers of PAM surely built the pam_group.so just for that occasion. I must be missing a line in a file that creates a connection of inodes in the background, or something. There are about 3 moving parts that I’ve found to make that aspect of PAM work, so its possible I’ve missed one.  The documentation on PAM is made for someone that already knows PAM inside and out… so, theres that. 

Thanks everyone for the help! Hopefully this will point someone else in the right direction if they overlook this as well. 

Reply