1. 

   xerxes42, Member

   Hi

   We use the Active Directory integration to allow our AD users to log in to myDBR but we have run into a problem.
   Users can sometimes not log in to myDBR and they are removed from local groups in myDBR so they loose access to reports.

   We have a master group in our AD and within that we have a Admin group and several user groups. The groups get imported into myDBR and they are visible under Groups and if we test the Active Directory connection we get a list of about 1500 users. All good!

   If we create a local myDBR group (not imported from AD) and give that group permissions to reports and add AD user to that group it works for a while and then the AD user is missing from that group.
   A similar thing happens for some users in the AD myDBR admin group. They can log in for a while and then all of a sudden they can't anymore but they are still listed as a member of the admin group.

   I tested to use the Synchronize function to import users from the AD but it gives no feedback and only imports four users.

   Any ideas on what could be wrong?

   Brgds
2. 

   myDBR Team, Key Master

   Hi,
   when you use Active Directory, all user and group management happens in AD. When user logs in, the group permissions are updated and therefore any local changes are removed. So, you should manage the users and groups in AD, so they are handled from one place.

   We could disable local group handling when AD is active.

   --
   myDBR Team
3. 

   xerxes42, Member

   Hi,

   I have removed all local groups in MyDBR and it's working better. We are still having issues that some users can't log in to MyDBR with their AD credentials.
   If we look under the Environment Settings->Active Directory and check the members in the group that is specified as Admin group all members are shown. But only 5 of 12 users can log on to MyDBR.

   I can't see anything in the Apache logs and the users have tried different browsers and both ssl and non-ssl with the same result.

   Any ideas?

   Brgds
4. 

   myDBR Team, Key Master

   If the users are listed as myDBR users in AD , there should be no difference between the users.

   When you go to Environment Settings and click the "Active Directory"-link, you will see the myDBR's view to the AD.

   The section "Checking for myDBR Users" lists all users that qualify as myDBR users (they belong to "myDBR Groups" hierarchy). Are all the users listed in that section?

   --
   myDBR Team
5. 

   nbisby, Member

   I am suddenly having this same issue.

   Environment Settings -> Active Directory link -> lists all users under "Checking for myDBR Users"

   When 2 of our 10 users log in or we click on their name for info on the AD list it works fine.
   For the other 8 users, log in returns no response and when clicking on their name in the AD list it times out.
   The synchronize button on the AD page also times out.

   In all of these timeout situations we get a seg fault from PHP.
6. 

   myDBR Team, Key Master

   User logins and user management in general is independent from each other. The problem with some users must with the user configuration in AD and with the PHP/LDAP configuration in your server.

   If there is an segmentation fault in PHP due to the AD calls, there is likely something wrong with the server configuration. Something from those 8 user's AD accounts triggers this fault.

   As there is an duplicate support ticket opened, we'll continue the discussion in support. When the problem and solutions is found we'll post it here if is something others can learn from.

   --
   myDBR Team
7. 

   xerxes42, Member

   Hi

   When I click on a group in ad_check I can see in the apache access log:
   [15/Oct/2012:10:29:08 +0200] "GET /mydbr/apps_v/ad_check_v.php?item=SEC-GG-DHAP-AdminUser&item_type=group HTTP/1.1" 200 1716

   When I do the same for a user that can log in I get:
   [15/Oct/2012:10:28:50 +0200] "GET /mydbr/apps_v/ad_check_v.php?item=kenpas&item_type=user HTTP/1.1" 200 748

   But when I click on one of the users that can't log on nothing is logged and I must reload the page before I can look at another user. The users that can't log in are listed when I click on one of the groups they belong to.

   Is there a way to get more detailed logs of what is going on when the request is sent to the Active Directory?

   I have checked the accounts in AD and I can't find any difference between users that work and not. We have working users in several OU and the users that can't log in are in the same OU so it doesn't look like a path error.

   Brgds
8. 

   myDBR Team, Key Master

   Are the users, whose login you have problems with, listed as myDBR users in "Checking for myDBR Users" section?

   Is there something special on those usernames that do not work as the apache log entry should happen anyways?

   Do you get the user info when you enter the url manually for non-working user:
   http://myserver.com/mydbr/apps_v/ad_check_v.php?item=nonworking_user&item_type=user

   --
   myDBR Team
9. 

   xerxes42, Member

   Hi,

   Yes. All users are listed under "Checking for myDBR Users".

   All usernames are six characters and only alphabetical a-z and all lowercase. We have six users of 37 that can't log in and I've checked to see if I can see any pattern between the user accounts. What I can see is that all users that can't log in have more than 15 groups on their account but one user that can log in has > 20 so it's not conclusive.

   When I try the ad_check_v URL directly for a user that can't log in it never returns any result. I've let it run for about 10 minutes without any result.

   Brgds
10. 

    myDBR Team, Key Master

    What myDBR fecthes from the AD about user is the basic user info and groups the user belongs to. As the basic user info query is straightforward the problem may lie in the group definitions.

    As myDBR uses recursive search when it determines the groups user belongs to, you might first want to check that you do not have circular nested groups for those users that you have problems with.

    --
    myDBR Team
11. 

    xerxes42, Member

    Hi

    I have looked at the groups and as far as I can determine there are no circular nested groups. But I don't have complete access to the AD so I can't be 100% sure.

    One thing I did notice is that the length of the complete path to some groups are very long. Is there a limit on how many characters the complete group path for a user can be? Some of the complete group paths are over 83 characters and all users that can't log in are members of these groups.

    Brgds
12. 

    myDBR Team, Key Master

    There are no character limitations in LDAP access. Sounds like the problem comes from the fact that something in your AD schema confuses the adLDAP version that myDBR uses.

    Whether this comes from the circular nested groups or something else cannot be determined without access to the AD.

    We can take a look if we can upate the adLDAP version used in myDBR as newer version uses different code for recursive group search.

    --
    myDBR Team
13. 

    xerxes42, Member

    Hi,

    If I can get access to the AD or at least have someone look at it for me what should we look for other than the circular nested groups?

    Is there anyway to debug what the adLDAP is doing when it's trying to access the information about the users that can't log in? Or any user for that matter to see if we can spot the difference.

    Brgds
14. 

    myDBR Team, Key Master

    Hi,
    we've updated myDBR's undelying AD libraries into newer ones. Run the updater to see if this helps. We've also added some extra settings that allow you to turn off recursive group searches for users to see if it is the circular nested groups that are the problem.

    Please try the new version first and if you still have problem, please open a ticket in support so we can give you more detailed instructions.

    --
    myDBR Team
15. 

    xerxes42, Member

    Hi,

    I did some testing during Sunday with adLDAP 4.04 and wrote a little test to see if it found any circular nested groups. And it did but three levels down from the groups where the troublesome users were members. I also discovered that the new version of adLDAP handled the circular nested groups so I could get information about the users correctly.

    The fix I did during the weekend was to set a more narrow Base DN to exclude the groups that caused the problems. It works for now but later on we will need to grant access to users outside that Base DN.

    The new build 1672 works like a charm with both the Base DN. If I want to turn of the recursive group search do I have to set the $_recursive_groups to false or something else?

    Thanks a lot for the help! Me and my managers are very happy people today!

    Brgds
16. 

    myDBR Team, Key Master

    The new build 1672 works like a charm with both the Base DN. If I want to turn of the recursive group search do I have to set the $_recursive_groups to false or something else?

    The option works for user's groups. There is setting 'active_directory_recursive_user_groups' in defaults.php that you could override in /user/defaults.php. If the recursive group search works, there is really no reason to turn it off.

    Thanks a lot for the help! Me and my managers are very happy people today!

    You're welcome. Glad it works.

    --
    myDBR Team
17. 

    Calliopebrook, Blocked

    But when I click on one of the users that can't log on nothing is logged and I must reload the page before I can look at another user. The users that can't log in are listed when I click on one of the groups they belong to.

    Is there a way to get more detailed logs of what is going on when the request is sent to the Active Directory?

Reply

You must log in to post.