Block LDAP Users

tomasi · February 19, 2021, 1:42pm

Hi,

I searched a lot in the forum about blocking common users (that not belong to any Graylog* group) to login in Graylog, but didn’t find a way to block those common users to login

In my AD, I created two groups: GraylogReader and GraylogAdmin and mapped them to Graylog roles

The problem: any user from LDAP can login with the default role = Reader, even not belonging to any Graylog* group

My config:

3. User mapping

Search Base DN
dc=mycompany,dc=local

User Search Pattern
(&(objectClass=user)(sAMAccountName={0}))

Display Name attribute
givenname

4. Group Mapping (optional)

Group Search Base DN
dc=mycompany,dc=local

Group Search Pattern
(&(objectClass=group)(cn=Graylog*))

Group Name Attribute
cn

Default User Role
Reader

My Graylog version is 3.3.11

What can I do to allow Graylog login only to users belonging to GraylogAdmin or GraylogReader LDAP group? Is there a way to set up Default User Role to a Block/Deny Role instead of Reader?

shoothub · February 19, 2021, 3:20pm

You have 2 options:

Use this User search pattern which include only members of one of the 2 groups:
(&(objectCategory=person)(objectClass=user)(sAMAccountName={0})(|(memberOf=CN=GraylogReader,CN=Users,DC=mycompany,DC=local)(memberOf=CN=GraylogReader,CN=Users,DC=mycompany,DC=local))(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
Or create master group in AD and add all Graylog* groups to it. Then use this User search pattern which includes also nested groups:
(&(objectCategory=person)(objectClass=user)(sAMAccountName={0})(memberOf:1.2.840.113556.1.4.1941:=CN=Graylog_users,CN=Users,DC=mycompany,DC=local)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

Change CN=GraylogReader/GraylogAdmin,CN=Users,DC=mycompany,DC=local to your real path of your groups.
!(userAccountControl:1.2.840.113556.1.4.803:=2) - excludes disabled users

tomasi · February 19, 2021, 5:34pm

Thank you for all those suggestions.

I tried

(&(objectCategory=person)(objectClass=user)(sAMAccountName={0})(|(memberOf=CN=GraylogAdmin,CN=Users,DC=mycompany,DC=local)(memberOf=CN=GraylogReader,CN=Users,DC=mycompany,DC=local))(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

in User Search Pattern field.

But when I include (objectCategory=person) parameter Graylog goes to an error page:

Something went wrong.
It seems like the page you navigated to contained an error.
You can use the navigation to reach other parts of the product, refresh the page or submit an error report.

Then I tried User Search Pattern field without (objectCategory=CN=Person) or (objectCategory=person) parameter:

(&(objectClass=user)(sAMAccountName={0})(|(memberOf=CN=GraylogAdmin,CN=Users,DC=mycompany,DC=local)(memberOf=CN=GraylogReader,CN=Users,DC=mycompany,DC=local)(!(userAccountControl:1.2.840.113556.1.4.803:=2))))

The login test worked.

But, unfortunatelly, common users (that not belong to GraylogAdmin or GraylogReader LDAP groups) still can login to Graylog and get Reader permissions

tmacgbay · February 19, 2021, 6:21pm

I am using Graylog 4.0.3 so it MIGHT be different (They changed LDAP in 4.0) but our system only allows enabled users from the correct AD group log in. Here is the genericized search pattern we use:

(&(objectClass=user)(sAMAccountName={0})(objectCategory=person)(memberOf=CN=graylog_administrator,OU=itApps,OU=appControl,OU=operational,OU=coAG,DC=company,DC=tld))

NOTE: Because we are explicitly defining a group and disabled users in the group will fail at log in, we don’t need to add them to the search pattern

Also of note, we can narrow down the Search Base DN to the OU that the group is in for a tighter search:

OU=pIT,OU=IT,OU=allDept,OU=coAG,DC=company,DC=tld

It seems strange at first when I was looking at it but I think of it this way - when logging in, see if the user is somewhere under the Search Base DN, if true then confirm that the account fits the search pattern. Reversible of course, not sure which goes first but preferably the one that narrows the results the most…

On a side note - make sure you are clear about your choice of OU or CN

tomasi · February 19, 2021, 8:43pm

I tried something similar to your code:

(&(objectClass=user)(sAMAccountName={0})(|(memberof=cn=GraylogAdmin,dc=mycompany,dc=local)(memberof=cn=GraylogReader,dc=mycompany,dc=local)))

or being more specific with OU:

(&(objectClass=user)(sAMAccountName={0})(|(memberof=cn=GraylogAdmin,ou=linuxgroups,dc=mycompany,dc=local)(memberof=cn=GraylogReader,ou=linuxgroups,dc=mycompany,dc=local)))

or being not so strict:

(&(objectClass=user)(sAMAccountName={0})(|(memberof=cn=GraylogAdmin)(memberof=cn=GraylogReader))

or the simplest possible:

(&(objectClass=user)(sAMAccountName={0})(memberof=Graylog*))

But Graylog gave me error in all those attempts:

Something went wrong.
It seems like the page you navigated to contained an error.

Error:
Cannot convert undefined or null to object

It gaves me error when I include or (memberOf=CN=) or (objectCategory=CN=Person) or (objectCategory=person) parameters. Maybe I’m not inputting the correct syntax or it’s something very specific to my LDAP (Active Directory) scenario, I don’t know…

If I use (&(objectClass=user)(sAMAccountName={0}) (as I said in the first message) it works, but I can’t filter permissions and all users from LDAP can login and get Reader role.

tmacgbay · February 19, 2021, 10:19pm

I am guessing that your LDAP DN is wrong - either the path… for instance you have:

(memberof=cn=GraylogAdmin,dc=mycompany,dc=local)

Which would mean you have a security group “GraylogAdmin” on the top level of your AD hierarchy… doesn’t sound right… memberof= is referencing a security group, not an OU…

Or you have a CN= where you need to have an OU= or vise-versa look at the object-tab-properties of the “folder” you are referencing…

Pretty sure you have to put in the full correct path, you can’t just name the OU or the Security Group.

Here is something to read about LDAP search filters that I just found and helped me to understand better just now…

https://confluence.atlassian.com/kb/how-to-write-ldap-search-filters-792496933.html

tomasi · February 20, 2021, 1:02pm

Hi,

It seems the error page it’s something related to the Graylog Login Test Tool

I set this in User Search Pattern field:

(&(objectClass=user)(sAMAccountName={0})(|(memberof=CN=GraylogAdmin,OU=Sistemas,DC=mycompany,DC=local)(memberof=CN=GraylogReader,OU=Sistemas,DC=mycompany,DC=local)))

If user belongs to GraylogAdmin or GraylogReader LDAP group, Graylog doesn’t crash in Test login (5. Login test field)

If user doesn’t belong to GraylogAdmin or GraylogReader LDAP group, Graylog crashes in Test login (5. Login test field) and goes to error page:

Error:
Cannot convert undefined or null to object

tmacgbay · February 20, 2021, 10:22pm

Important to note - even though you have edited your post, the previous versions are still available to view for all. I am assuming you are naming things differently from reality in the final post… as you should.

The Search Base DN should point to an area at or above where the users are located in your hierarchy. It will search for all accounts starting at that point and all folders below.

The Search Pattern sets the requirements that the found user account must have to be able to log in… it’s not really a search pattern, it’s a filter for all the accounts found in the Search Base DN.

Search Base DN: DC=wahoo,DC=tld -This would allow evaluation of all accounts in wahoo.tld if you wanted to restrict that, you could set it to:

OU=pIT,OU=IT,OU=allDept,OU=coAG,DC=wahoo,DC=tld

and it would only examine/allow accounts in the pIT Organizational Unit.

Search Pattern (FILTER!): (breaking it up for clarity)

(&    (objectClass=user)
      (sAMAccountName={0})
        (| 
                (memberof=CN=GraylogAdmin,OU=Sistemas,DC=mycompany,DC=local) 
                (memberof=CN=GraylogReader,OU=Sistemas,DC=mycompany,DC=local)
         ) 
)

This filter will result in items that are of type USER, have a sAMAccountName that matches the login (
that’s the ={0} ), and must be a member of either GraylogAdmin or GraylogReader Security Groups which are located in the Sistemas Organization Unit that resides at the top level of mycompany.local

Not that I am finding anything wrong, just hoping that going over what I was reading would help you find where it needs to be different. I am using Graylog 4.0.3 so there might be a bug in there I am not aware of.

tomasi · February 20, 2021, 11:41pm

Thanks for the explanation

It’s working now. Only users that belong to GraylogAdmin or GraylogReader can login

As you said and explained very well this code will filter an user with name {0} that is member of GraylogAdmin|GraylogReader group:

(&    (objectClass=user)
       (sAMAccountName={0})
         (| 
                 (memberof=CN=GraylogAdmin,OU=Sistemas,DC=mycompany,DC=local) 
                 (memberof=CN=GraylogReader,OU=Sistemas,DC=mycompany,DC=local)
          ) 
 )

I didn’t explained it very well, sorry about that, but it’s working like this:

If user belongs to GraylogAdmin or GraylogReader LDAP group, Graylog doesn’t crash in Test login (5. Login test field) and the user can login to Graylog Server (perfect!).
If user doesn’t belong to GraylogAdmin or GraylogReader LDAP group, Graylog crashes in Test login (5. Login test field) and goes to error page. Those users can not login to Graylog Server.

That filter is working perfectly, I think the error page is something related to Graylog Test Tool, maybe it can’t return that user do not match to the criteria inputted.

Yesterday I was only trusting in the Graylog Test Tool to validate the filter, without trying to login in Graylog Server (a noob testing).

Today I tried the Graylog Server Login even receiving errors from Graylog Test Tool and, for my surprise, it worked!

Thank you all for all help provided!

system · March 6, 2021, 11:41pm

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Stopping Active Directory users having default Graylog access Graylog Central (peer support)	3	534	October 6, 2020
Lock down user search pattern - LDAP query Graylog Central (peer support)	2	2828	April 4, 2017
LDAP authentication fine configuration question Graylog Central (peer support)	3	2086	July 21, 2017
AD/LDAP Authentication with groups, users not found Graylog Central (peer support)	7	6385	January 31, 2020
Graylog Open: Active Directory Group Membership Graylog Central (peer support)	2	1030	October 21, 2022

Block LDAP Users

Related topics