Securing SugarCRM with AD/LDAP

[AboveTheLogic]

Hi All-

I recently just brought up a new install of SugarCRM and am happy with the ability to create my own modules particuarly for inventory purposes. Anyways, I've managed to get LDAP authentication working with my Active Directory list, and I'm pretty happy about that.

The problem is that we have over 100 users who can now log into SugarCRM and have full access to all modules, since this is the default. Everything I've read says to use roles and add users in the roles to restrict access to things, but this will be quite the cat-and-mouse game to check if a new user has logged in and quickly add him/her to a role before they could see something they shouldn't see.

I'd like to have new users go into a default role if possible, but I don't think that is possible.

It looks like the best (although not ideal) option is to set LDAP to only allow a specific group access to log in. Unfortunately, for the life of me, I can't get that to work. I'm comfortable with the LDP tool and have tried quite a few ways of trying to get SugarCRM to see the group I created and recognize the users, to no avail.

If anyone has any examples of this working, please share!

Or, even better, if anyone has any ideas on how to restrict new users that aren't created in Sugar yet (who are instantly created the first time they log in), even better!

I intend to post up some more specifics on what I've tried with the group authentication thing when I get caught up in the office, maybe tomorrow or wed.

[turutosiya]

How about customizing LDAPAuthenticateUser#createUser() method in modules/Users/authentication/LDAPAuthenticate/LDAPAuthenticateUser.php ?

[AboveTheLogic]

Thanks for the lead, that helped a bit.

I changed:

$user->employee_status = 'Active';

to:

$user->employee_status = 'Inactive';

Result:
New user logs in for the first time successfully and is able to browse and change anything. The new account is inactive (you can even click on "My Account" and see that), but the new user can still poke around, view and change things.

The user can't log in a second time until the account is set to Active, but still- not secure...

[AboveTheLogic]

OK, I'm back to attempting group authentication. I think the above mod and group authentication together are the way to go.

Here is my info from the LDP tool.

This is the group:

<removed>

Here is the user:

<removed>

It looks like SugarCRM is trying to match an attribute of the user to an attribute of the group. The only matching attributes I see are the distinguisheName attribute of the user, and the "member" attribute of the group. Maybe even "Dn" of the user (5th line).

[AboveTheLogic]

So, this is exactly what I used, but it does not work:

<removed>

As can be seen from these examples, I tried to get it to see distinguishedName, Dn, dN, all to no avail.

I should also point out that I've tried using displayName (preferred), sAMAccountName, and even userPrincipal name, but it just appears that SugarCRM can't grab the attribute needed from my account's attributes to even compare against the group "member" attribute.

Any ideas?

[AboveTheLogic]

I've removed my LDP info for security reasons.

Group Membership simply does not work for me, but I found I can do the same thing with the User Filter, using the following string:

memberOf=CN=CRMUsers,OU=CRM,DC=Example,DC=local

I have an OU entitled "CRM", and a group within that OU entitled "CRMUsers". With that filter, the user's "memberOf" attribute is looked at and the CN of the group "CRMUsers" must exist for the user to log in.

I tested it and it works fine. Even if the CRMUsers group isn't the first group listed.

For those of you having trouble with LDAP, the LDP tool is very valuable, you can see the attributes of your AD users/groups in plain text, essentially seeing what SugarCRM will see when it attempts to authenticate a user:

http://technet.microsoft.com/en-us/l...8WS.10%29.aspx

So, with this, the "Group Membership" section in there is redundant- at least for me. I suppose it would be good to use that section should I want to use some other sort of user filter.

[wdroush]

Result:
New user logs in for the first time successfully and is able to browse and change anything. The new account is inactive (you can even click on "My Account" and see that), but the new user can still poke around, view and change things.

SugarCRM has weird security bugs like this. Same goes for roles.

[AboveTheLogic]

Yes I have been dissapointed with how the default is wide open access, that is generally a big no-no with things like this.

Its open source so you can work with it, but right out of the box with LDAP, it leaves a lot to be desired.

[porcupine]

Attached is a work-around for Active Directory users that want to specifically use the "memberOf" attribute to compare with the "Group DN" and "Group Name". The first change is to allow "Group Attribute" to be empty - this is no longer needed because the (last) additional ldap_search is not required.

The second change takes the FQDN of "Group DN" and "Group Name" and then loops over the array built for the user in the "memberOf" entries - if there is a match we are successful.

No apologies for coding style or the fact that it most likely will only work for AD using the "memberOf" attribute.

For our test case:-
Group DN: OU=Domain Groups,DC=mydomain,DC=net
Group Name: CN=CRM Users
User Attribute: memberOf

Changes are wrapped with
////changed by Porcupine

////

[AboveTheLogic]

Does it do anything different than the user filter I mentioned above in post #6?