New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User not found in AD group #7254

Closed
CZAirwolf opened this Issue Aug 29, 2017 · 24 comments

Comments

Projects
None yet
5 participants
@CZAirwolf

CZAirwolf commented Aug 29, 2017

DO NOT DELETE THIS INFORMATION.

Please read this information carefully.

GitHub issues is for known/validated bugs, please do not post issues asking for help or how to do X, Y or Z.

You can use our irc channel ##librenms on freenode to ask questions or our community site.

If you have a feature request please post this on our community site.

Please confirm each of the sections below by putting an x in the box like [x].

  • Is your install up to date? Updating your install
    Please do not submit an issue if your install is not up to date within the last 24 hours or on a stable monthly release.
  • Please include all of the information between the ==================================== section of ./validate.php which you can run from the cli.
    Component | Version
    --------- | -------
    LibreNMS | 1.31.01
    DB Schema | 205
    PHP | 7.0.19-1
    MySQL | 10.1.23-MariaDB-9+deb9u1
    RRDTool | 1.6.0
    SNMP | NET-SNMP 5.7.3
  • Please provide ALL info asked for here.
    No faq20 available.
    Librenms Debian Stretch
    AD is based on Samba (Debian Jessie), Win 2008r2 level
  • Please provide as much detail as possible.
    Librenms can't find user in specified group in active directory. Tests showed, that pre 1.31.x (with added nested groups support) "html/includes/authentication/active_directory.inc.php" works (restored from backup), but 1.31.x doesn't work. It can find any user in active directory (with $config['auth_ad_require_groupmembership'] = false;), but not in group specified in config.php (with $config['auth_ad_require_groupmembership'] = true;). Comparing output from auth_test.php showed difference in search filters.
  • Please do NOT post more than 10 lines of debug information here, use a pastebin service or GitHub Gists.
    PHP Fatal error: Uncaught LibreNMS\Exceptions\AuthenticationException: User is not in one of the required groups or user/group is outside the base dn in /librenms/html/includes/authentication/active_directory.inc.php:50
    Stack trace:
    #0 /librenms/scripts/auth_test.php(96): authenticate('someuser', 'somepass')
    #1 {main}
    thrown in /librenms/html/includes/authentication/active_directory.inc.php on line 50

Love librenms? Please consider supporting our collective:
👉 https://t.libren.ms/donations

@murrant

This comment has been minimized.

Show comment
Hide comment
@murrant

murrant Aug 29, 2017

Member

Can you give us more information about your AD layout and pastebin the results of ./scripts/auth_test.php -v

I am not able to reproduce this with my Active Directory authentication.

Member

murrant commented Aug 29, 2017

Can you give us more information about your AD layout and pastebin the results of ./scripts/auth_test.php -v

I am not able to reproduce this with my Active Directory authentication.

@murrant murrant added the Bug 🐞 label Aug 29, 2017

@CZAirwolf

This comment has been minimized.

Show comment
Hide comment
@fseesink

This comment has been minimized.

Show comment
Hide comment
@fseesink

fseesink Aug 29, 2017

I'm going to need to toss my hat in the ring on this one. Something has broken with regard to AD authentication that was working before.

CORRECTION: This was manifested by SOME users with global read access saying they are no longer able to "see" any devices. Note if I login (with full admin rights), I'm still able to see devices fine as best I can tell. And some others with global read access CAN see devices.

This just began today, and I run a conservative setup, having followed the instructions here:
https://docs.librenms.org/General/Updating/

and configured LibreNMS from day one to only update to each stable release, as the page says "Choose this branch if you want to have a stable release."

But I see that LibreNMS WAS updated just yesterday (28 Aug 2017), so I'm going to go out on a limb that the update broke things.

Here's my setup:

Component | Version
--------- | -------
LibreNMS  | 1.31.01
DB Schema | 205
PHP       | 7.0.22-0ubuntu0.16.04.1
MySQL     | 10.0.31-MariaDB-0ubuntu0.16.04.2
RRDTool   | 1.5.5
SNMP      | NET-SNMP 5.7.3

And to be clear, here's the relevant portion of my config with regard to AD authentication and updates:

$config['auth_ad_require_groupmembership'] = true; // require users to be members of a group listed below
$config['auth_ad_groups']['traffic.wvnet.edu-ADMINS']['level'] = 10;
$config['auth_ad_groups']['Telcomm']['level'] = 10;
$config['auth_ad_groups']['Systems']['level'] = 5;
$config['auth_ad_groups']['traffic.wvnet.edu-GLOBAL-READ']['level'] = 5;
$config['auth_ad_groups']['traffic.wvnet.edu']['level']  = 1;
...
# Uncomment the next line to disable daily updates
#$config['update'] = 0;
$config['update_channel'] = 'release';

where I distinguish between

  • those with administrative access to everything (AD groups 'traffic.wvnet.edu-ADMINS' and 'Telcomm'),
  • those with global read access (AD groups 'Systems' and 'traffic.wvnet.edu-GLOBAL-READ'), and
  • those who are normal users (AD group 'traffic.wvnet.edu').

based on the information here:
https://docs.librenms.org/Extensions/Authentication/#user-levels

CORRECTION: Thus far the users impacted are those in the traffic.wvnet.edu-GLOBAL-READ AD group. Oddly, those in the Systems group are just fine. Yet both are set to the same level.

I do note that the ones having issues have been building custom dashboards. Don't know if that plays a role. But at this point the only thing I can do to truly "see" what they're experiencing (as they're remote users) is to reset their AD password, log in as them, and dig around.

If you have any insights into this, whether I need to manually roll back that file mentioned in the original post, or if you find the issue and fix it requiring doing a manual update (as I would like to otherwise stick to the stable releases), please advise.

And if there's anything I can do on my end to help, let me know, too.

fseesink commented Aug 29, 2017

I'm going to need to toss my hat in the ring on this one. Something has broken with regard to AD authentication that was working before.

CORRECTION: This was manifested by SOME users with global read access saying they are no longer able to "see" any devices. Note if I login (with full admin rights), I'm still able to see devices fine as best I can tell. And some others with global read access CAN see devices.

This just began today, and I run a conservative setup, having followed the instructions here:
https://docs.librenms.org/General/Updating/

and configured LibreNMS from day one to only update to each stable release, as the page says "Choose this branch if you want to have a stable release."

But I see that LibreNMS WAS updated just yesterday (28 Aug 2017), so I'm going to go out on a limb that the update broke things.

Here's my setup:

Component | Version
--------- | -------
LibreNMS  | 1.31.01
DB Schema | 205
PHP       | 7.0.22-0ubuntu0.16.04.1
MySQL     | 10.0.31-MariaDB-0ubuntu0.16.04.2
RRDTool   | 1.5.5
SNMP      | NET-SNMP 5.7.3

And to be clear, here's the relevant portion of my config with regard to AD authentication and updates:

$config['auth_ad_require_groupmembership'] = true; // require users to be members of a group listed below
$config['auth_ad_groups']['traffic.wvnet.edu-ADMINS']['level'] = 10;
$config['auth_ad_groups']['Telcomm']['level'] = 10;
$config['auth_ad_groups']['Systems']['level'] = 5;
$config['auth_ad_groups']['traffic.wvnet.edu-GLOBAL-READ']['level'] = 5;
$config['auth_ad_groups']['traffic.wvnet.edu']['level']  = 1;
...
# Uncomment the next line to disable daily updates
#$config['update'] = 0;
$config['update_channel'] = 'release';

where I distinguish between

  • those with administrative access to everything (AD groups 'traffic.wvnet.edu-ADMINS' and 'Telcomm'),
  • those with global read access (AD groups 'Systems' and 'traffic.wvnet.edu-GLOBAL-READ'), and
  • those who are normal users (AD group 'traffic.wvnet.edu').

based on the information here:
https://docs.librenms.org/Extensions/Authentication/#user-levels

CORRECTION: Thus far the users impacted are those in the traffic.wvnet.edu-GLOBAL-READ AD group. Oddly, those in the Systems group are just fine. Yet both are set to the same level.

I do note that the ones having issues have been building custom dashboards. Don't know if that plays a role. But at this point the only thing I can do to truly "see" what they're experiencing (as they're remote users) is to reset their AD password, log in as them, and dig around.

If you have any insights into this, whether I need to manually roll back that file mentioned in the original post, or if you find the issue and fix it requiring doing a manual update (as I would like to otherwise stick to the stable releases), please advise.

And if there's anything I can do on my end to help, let me know, too.

@laf

This comment has been minimized.

Show comment
Hide comment
@laf

laf Aug 29, 2017

Member

If you want to try replacing this file: https://raw.githubusercontent.com/librenms/librenms/50b3ffb3cfa8c9379ba4fbdef1341a43d4bea026/html/includes/authentication/active_directory.inc.php

and see if that fixes it so we can narrow down the commit then that would be ace.

Member

laf commented Aug 29, 2017

If you want to try replacing this file: https://raw.githubusercontent.com/librenms/librenms/50b3ffb3cfa8c9379ba4fbdef1341a43d4bea026/html/includes/authentication/active_directory.inc.php

and see if that fixes it so we can narrow down the commit then that would be ace.

@murrant

This comment has been minimized.

Show comment
Hide comment
@murrant

murrant Aug 29, 2017

Member

Hmm, perhaps the characters aren't properly escaped or something?

Can you try #7245 and see if it gives a more specific error?

Member

murrant commented Aug 29, 2017

Hmm, perhaps the characters aren't properly escaped or something?

Can you try #7245 and see if it gives a more specific error?

laf added a commit to laf/librenms that referenced this issue Aug 29, 2017

@murrant

This comment has been minimized.

Show comment
Hide comment
@murrant

murrant Aug 29, 2017

Member

@fseesink Ok, I discovered the periods are causing your issue.

@CZAirwolf Does your group name have any periods in it?

Member

murrant commented Aug 29, 2017

@fseesink Ok, I discovered the periods are causing your issue.

@CZAirwolf Does your group name have any periods in it?

@laf laf closed this in #7257 Aug 29, 2017

laf added a commit that referenced this issue Aug 29, 2017

@murrant murrant reopened this Aug 29, 2017

@NetworkNub

This comment has been minimized.

Show comment
Hide comment
@NetworkNub

NetworkNub Aug 29, 2017

Contributor

#7257 fixed this issue for me.

Contributor

NetworkNub commented Aug 29, 2017

#7257 fixed this issue for me.

@laf laf referenced this issue Aug 29, 2017

Merged

feature: Active Directory user in nested groups #7175

1 of 1 task complete
@fseesink

This comment has been minimized.

Show comment
Hide comment
@fseesink

fseesink Aug 29, 2017

@murrant and @laf,

Thanks! Ok, now next question. Considering I'd like to stick to stable releases otherwise, what is the best way to apply such a change? Do I simply run

./daily.sh

as indicated in the docs? Do I need to do the

cd /opt/librenms
git pull
php includes/sql-schema/update.php

commands?

fseesink commented Aug 29, 2017

@murrant and @laf,

Thanks! Ok, now next question. Considering I'd like to stick to stable releases otherwise, what is the best way to apply such a change? Do I simply run

./daily.sh

as indicated in the docs? Do I need to do the

cd /opt/librenms
git pull
php includes/sql-schema/update.php

commands?

@murrant

This comment has been minimized.

Show comment
Hide comment
@murrant

murrant Aug 30, 2017

Member

@fseesink We reverted that patch for the stable release 1.31.1, so, when daily.sh runs from your cron it will pull it in. I would like to get it back into master if we can figure out the issue (I have a suspect).

I would suggest staying on stable releases, but we could always use help testing to prevent issues like this from reaching stable.

Member

murrant commented Aug 30, 2017

@fseesink We reverted that patch for the stable release 1.31.1, so, when daily.sh runs from your cron it will pull it in. I would like to get it back into master if we can figure out the issue (I have a suspect).

I would suggest staying on stable releases, but we could always use help testing to prevent issues like this from reaching stable.

@CZAirwolf

This comment has been minimized.

Show comment
Hide comment
@CZAirwolf

CZAirwolf Aug 30, 2017

@laf I replaced the file with your posted version and voila, it works.
@murrant my groups have "_" in name, rest is alfanumeric.

CZAirwolf commented Aug 30, 2017

@laf I replaced the file with your posted version and voila, it works.
@murrant my groups have "_" in name, rest is alfanumeric.

@murrant

This comment has been minimized.

Show comment
Hide comment
@murrant

murrant Aug 30, 2017

Member

@CZAirwolf @fseesink @NetworkNub

Can you test #7259 and see if that fixes your issues? Thanks.

Member

murrant commented Aug 30, 2017

@CZAirwolf @fseesink @NetworkNub

Can you test #7259 and see if that fixes your issues? Thanks.

@fseesink

This comment has been minimized.

Show comment
Hide comment
@fseesink

fseesink Aug 30, 2017

@murrant @CZAirwolf

I'm afraid that revert didn't work. After my initial post I had one user let me reset their AD password so I could go in as them to see what they were experiencing. Sadly, today just as yesterday, this user, who SHOULD have global read access (they're part of the traffic.wvnet.edu-GLOBAL-READ AD group), could see NO devices at all. It was if they were being treated as a Normal user.

Typically they are able to see all devices, just in read-only mode. And until yesterday, this all worked well. This particular user remembers using it last week without issue, and we don't really make changes to this server shy of standard Ubuntu updates.

@CZAirwolf regarding your last request, walk me through how you'd normally have me do that. I'm used to doing basic git pulls of entire repos, but to test that #7259, what exactly would I need to do on my end? And just as important, how do I roll it back if it doesn't work?

P.S. To confirm the authentication file was reverted, I re-ran daily.sh as the librenms user and retested. But still no go.

fseesink commented Aug 30, 2017

@murrant @CZAirwolf

I'm afraid that revert didn't work. After my initial post I had one user let me reset their AD password so I could go in as them to see what they were experiencing. Sadly, today just as yesterday, this user, who SHOULD have global read access (they're part of the traffic.wvnet.edu-GLOBAL-READ AD group), could see NO devices at all. It was if they were being treated as a Normal user.

Typically they are able to see all devices, just in read-only mode. And until yesterday, this all worked well. This particular user remembers using it last week without issue, and we don't really make changes to this server shy of standard Ubuntu updates.

@CZAirwolf regarding your last request, walk me through how you'd normally have me do that. I'm used to doing basic git pulls of entire repos, but to test that #7259, what exactly would I need to do on my end? And just as important, how do I roll it back if it doesn't work?

P.S. To confirm the authentication file was reverted, I re-ran daily.sh as the librenms user and retested. But still no go.

@NetworkNub

This comment has been minimized.

Show comment
Hide comment
@NetworkNub

NetworkNub Aug 30, 2017

Contributor

@murrant #7259 breaks AD login again. This toast message is displayed:

Login error
Invalid credentials

Our group names contain alpha, spaces, and hyphens.

Output from ./scripts/auth_test.php -v :

PHP Fatal error: Uncaught LibreNMS\Exceptions\AuthenticationException: User is not in one of the required groups or user/group is outside the base dn in /opt/librenms/html/includes/authentication/active_directory.inc.php:49
Stack trace:
#0 /opt/librenms/scripts/auth_test.php(96): authenticate('USERNAME', 'PASSWORD')
#1 {main}
thrown in /opt/librenms/html/includes/authentication/active_directory.inc.php on line 49

Contributor

NetworkNub commented Aug 30, 2017

@murrant #7259 breaks AD login again. This toast message is displayed:

Login error
Invalid credentials

Our group names contain alpha, spaces, and hyphens.

Output from ./scripts/auth_test.php -v :

PHP Fatal error: Uncaught LibreNMS\Exceptions\AuthenticationException: User is not in one of the required groups or user/group is outside the base dn in /opt/librenms/html/includes/authentication/active_directory.inc.php:49
Stack trace:
#0 /opt/librenms/scripts/auth_test.php(96): authenticate('USERNAME', 'PASSWORD')
#1 {main}
thrown in /opt/librenms/html/includes/authentication/active_directory.inc.php on line 49

@murrant

This comment has been minimized.

Show comment
Hide comment
@murrant

murrant Aug 30, 2017

Member

@fseesink That doesn't make much sense. This is the only change to AD auth. Run ./validate.php

@NetworkNub Can you give me more info? Like I said I still can't reproduce this. So I need your help to figure out why it is breaking on your system.

Member

murrant commented Aug 30, 2017

@fseesink That doesn't make much sense. This is the only change to AD auth. Run ./validate.php

@NetworkNub Can you give me more info? Like I said I still can't reproduce this. So I need your help to figure out why it is breaking on your system.

@fseesink

This comment has been minimized.

Show comment
Hide comment
@fseesink

fseesink Aug 30, 2017

@murrant

Ok, ran ./validate.php and here's what you likely wanted to see:

====================================
Component | Version
--------- | -------
LibreNMS  | 1.31.02
DB Schema | 205
PHP       | 7.0.22-0ubuntu0.16.04.1
MySQL     | 10.0.31-MariaDB-0ubuntu0.16.04.2
RRDTool   | 1.5.5
SNMP      | NET-SNMP 5.7.3
====================================

Now here's what I can tell you. Since the issue appears to be that the AD auth code isn't supporting the full set of permitted characters for AD group names since you specifically mentioned the periods being an issue (and those ARE valid characters in AD naming), I decided to do my own testing.

I renamed the AD group from traffic.wvnet.edu-GLOBAL-READ to simply LibreNMS-GLOBAL-READ (notice just hyphens, no periods), adjusted the config.php file to match, and voila! All devices reappeared for that same user account.

I then put everything back with the original names, and once again, it was if the user was defined as a Normal user (i.e., level 1) vs. a user with global-read privileges (i.e., level 5). That is, they could see NO devices since we had not specifically defined devices for them (since we THOUGHT that having them configured with global read would suffice, and which, until Monday, did.)

It does seem the AD auth code NOW is having issues with periods in AD group names, as until now (and we've had this instance in production since June) it was working just fine.

fseesink commented Aug 30, 2017

@murrant

Ok, ran ./validate.php and here's what you likely wanted to see:

====================================
Component | Version
--------- | -------
LibreNMS  | 1.31.02
DB Schema | 205
PHP       | 7.0.22-0ubuntu0.16.04.1
MySQL     | 10.0.31-MariaDB-0ubuntu0.16.04.2
RRDTool   | 1.5.5
SNMP      | NET-SNMP 5.7.3
====================================

Now here's what I can tell you. Since the issue appears to be that the AD auth code isn't supporting the full set of permitted characters for AD group names since you specifically mentioned the periods being an issue (and those ARE valid characters in AD naming), I decided to do my own testing.

I renamed the AD group from traffic.wvnet.edu-GLOBAL-READ to simply LibreNMS-GLOBAL-READ (notice just hyphens, no periods), adjusted the config.php file to match, and voila! All devices reappeared for that same user account.

I then put everything back with the original names, and once again, it was if the user was defined as a Normal user (i.e., level 1) vs. a user with global-read privileges (i.e., level 5). That is, they could see NO devices since we had not specifically defined devices for them (since we THOUGHT that having them configured with global read would suffice, and which, until Monday, did.)

It does seem the AD auth code NOW is having issues with periods in AD group names, as until now (and we've had this instance in production since June) it was working just fine.

@murrant

This comment has been minimized.

Show comment
Hide comment
@murrant

murrant Aug 31, 2017

Member

@fseesink You only posted part of validate output, there should be at least two more lines. I am concerned that you do not actually have the code reverted in your local install if you are still having issues on 1.30.2.

I do apologize for the issue as I tested this before hand but don't have any periods in my groups so I failed to see the subtle mistake that caused that error. As always, any help testing patches is always appreciated. By the way, the issue with periods in names should be fixed in the updated version of the nested groups support patch here: #7259.

Member

murrant commented Aug 31, 2017

@fseesink You only posted part of validate output, there should be at least two more lines. I am concerned that you do not actually have the code reverted in your local install if you are still having issues on 1.30.2.

I do apologize for the issue as I tested this before hand but don't have any periods in my groups so I failed to see the subtle mistake that caused that error. As always, any help testing patches is always appreciated. By the way, the issue with periods in names should be fixed in the updated version of the nested groups support patch here: #7259.

@CZAirwolf

This comment has been minimized.

Show comment
Hide comment
@CZAirwolf

CZAirwolf Aug 31, 2017

./scripts/github-apply 7259
error: unrecognized input

Anyway, i upgraded to: LibreNMS | 1.31.02, auth doesn't works. But if i downloaded/replaced active_directory.inc.php with current version on github (patched 7259), it works.

CZAirwolf commented Aug 31, 2017

./scripts/github-apply 7259
error: unrecognized input

Anyway, i upgraded to: LibreNMS | 1.31.02, auth doesn't works. But if i downloaded/replaced active_directory.inc.php with current version on github (patched 7259), it works.

@murrant

This comment has been minimized.

Show comment
Hide comment
@murrant

murrant Aug 31, 2017

Member

Thanks @CZAirwolf looks like 1.31.02 didn't include all the commits. Thanks for informing us.

Member

murrant commented Aug 31, 2017

Thanks @CZAirwolf looks like 1.31.02 didn't include all the commits. Thanks for informing us.

@fseesink

This comment has been minimized.

Show comment
Hide comment
@fseesink

fseesink Aug 31, 2017

I re-ran

./daily.sh

and now everything's working as before. Oh, and just for completeness, here's the output from validate.php:

...
====================================
Component | Version
--------- | -------
LibreNMS  | 1.31.03
DB Schema | 205
PHP       | 7.0.22-0ubuntu0.16.04.1
MySQL     | 10.0.31-MariaDB-0ubuntu0.16.04.2
RRDTool   | 1.5.5
SNMP      | NET-SNMP 5.7.3
====================================

[OK]    Database connection successful
[OK]    Database schema correct
[WARN]  Your local git branch is not master, this will prevent automatic updates.
[WARN]  Your local git contains modified files, this could prevent automatic updates.
Modified files:
	 mibs/infoblox/IB-DHCPONE-MIB
	 mibs/infoblox/IB-DNSONE-MIB
	 mibs/infoblox/IB-PLATFORMONE-MIB
	 mibs/infoblox/IB-SMI-MIB

Note the updated MIB files are because we're polling some Infoblox appliances and I found the MIBs included weren't polling sufficiently for our needs, so I found updated versions. (This, to be clear, has been in place since June, so nothing recent.)

But I'm guessing all you typically want to see are the lines between dashes and the 2 after regarding the database, correct?

fseesink commented Aug 31, 2017

I re-ran

./daily.sh

and now everything's working as before. Oh, and just for completeness, here's the output from validate.php:

...
====================================
Component | Version
--------- | -------
LibreNMS  | 1.31.03
DB Schema | 205
PHP       | 7.0.22-0ubuntu0.16.04.1
MySQL     | 10.0.31-MariaDB-0ubuntu0.16.04.2
RRDTool   | 1.5.5
SNMP      | NET-SNMP 5.7.3
====================================

[OK]    Database connection successful
[OK]    Database schema correct
[WARN]  Your local git branch is not master, this will prevent automatic updates.
[WARN]  Your local git contains modified files, this could prevent automatic updates.
Modified files:
	 mibs/infoblox/IB-DHCPONE-MIB
	 mibs/infoblox/IB-DNSONE-MIB
	 mibs/infoblox/IB-PLATFORMONE-MIB
	 mibs/infoblox/IB-SMI-MIB

Note the updated MIB files are because we're polling some Infoblox appliances and I found the MIBs included weren't polling sufficiently for our needs, so I found updated versions. (This, to be clear, has been in place since June, so nothing recent.)

But I'm guessing all you typically want to see are the lines between dashes and the 2 after regarding the database, correct?

@laf

This comment has been minimized.

Show comment
Hide comment
@laf

laf Sep 1, 2017

Member

To be fair we like to see all of it, helps in seeing if you've got other issues that might be related.

MIBs by themselves don't usually do anything, if these do or you've modified code then please submit those back to us upstream so others can benefit.

Member

laf commented Sep 1, 2017

To be fair we like to see all of it, helps in seeing if you've got other issues that might be related.

MIBs by themselves don't usually do anything, if these do or you've modified code then please submit those back to us upstream so others can benefit.

@NetworkNub

This comment has been minimized.

Show comment
Hide comment
@NetworkNub

NetworkNub Sep 1, 2017

Contributor

@murrant My AD is organized like this:

dc=example,dc=com
├── ou=corpUsers
│ ├── cn=User1
│ ├── cn=User2
│ ├── cn=User3
├── ou=corpGroups
│ ├── cn=Group1
│ ├── cn=Group2
│ └── cn=Group3

And my config looks like this:

$config['auth_ad_base_dn'] = "ou=corpUsers,dc=example,dc=com"
$config['auth_ad_groups']['Group1']['level'] = 5;
$config['auth_ad_groups']['Group2']['level'] = 10;

The original code did not care where the groups lived in AD. With #7259, AD groups must be under auth_ad_base_dn

Changing the config to this fixed my login issue with #7259:

$config['auth_ad_base_dn'] = "dc=example,dc=com"

Contributor

NetworkNub commented Sep 1, 2017

@murrant My AD is organized like this:

dc=example,dc=com
├── ou=corpUsers
│ ├── cn=User1
│ ├── cn=User2
│ ├── cn=User3
├── ou=corpGroups
│ ├── cn=Group1
│ ├── cn=Group2
│ └── cn=Group3

And my config looks like this:

$config['auth_ad_base_dn'] = "ou=corpUsers,dc=example,dc=com"
$config['auth_ad_groups']['Group1']['level'] = 5;
$config['auth_ad_groups']['Group2']['level'] = 10;

The original code did not care where the groups lived in AD. With #7259, AD groups must be under auth_ad_base_dn

Changing the config to this fixed my login issue with #7259:

$config['auth_ad_base_dn'] = "dc=example,dc=com"

@murrant

This comment has been minimized.

Show comment
Hide comment
@murrant

murrant Sep 4, 2017

Member

@NetworkNub Interesting, that is the intended way base dn should work, it was just a quirk that it worked before. Thanks for letting us know :)

Member

murrant commented Sep 4, 2017

@NetworkNub Interesting, that is the intended way base dn should work, it was just a quirk that it worked before. Thanks for letting us know :)

@murrant

This comment has been minimized.

Show comment
Hide comment
@murrant

murrant Sep 7, 2017

Member

Closing this, please test #7259 and comment there. Thanks.

Member

murrant commented Sep 7, 2017

Closing this, please test #7259 and comment there. Thanks.

@murrant murrant closed this Sep 7, 2017

@lock

This comment has been minimized.

Show comment
Hide comment
@lock

lock bot May 16, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed.

lock bot commented May 16, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed.

@lock lock bot locked as resolved and limited conversation to collaborators May 16, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.