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

Missing setup streams and user dashboards after entering through the active directory #2516

Closed
angelsedoy opened this Issue Jul 22, 2016 · 10 comments

Comments

Projects
None yet
5 participants
@angelsedoy

angelsedoy commented Jul 22, 2016

Problem description

After obnovlenyai from 1.7 to 2.0 version, settings are lost after entering through Active Directory. So it should be, or am I doing something wrong? Previously, it was possible to adjust the stream and dashboards for each individual.

Steps to reproduce the problem

  1. The user comes to the AD account
  2. I add it streams and dashboards
  3. After you log out and log in, setting the empty again

Environment

  • Graylog Version: 2.0
  • Elasticsearch Version: 2.3.4
  • MongoDB Version: 3.2.8
  • Operating System: ubuntu 14.04
  • Browser version: Chrome
@joschi

This comment has been minimized.

Contributor

joschi commented Jul 22, 2016

@angelsedoy Are you completely sure that the user names are identical? Keep in mind that user names in Graylog are case-sensitive, so "user1" is not identical to "User1".

@angelsedoy

This comment has been minimized.

angelsedoy commented Jul 22, 2016

I think that I have checked everything. Accounts only AD. Members include, but are taken to a page "No streams configured.".
When I rule of law, they are stored in Mongo, but after entering the user erased all. It seems that the account is recreated again.

@kroepke

This comment has been minimized.

Member

kroepke commented Jul 25, 2016

Could you please provide a dump of your user collection in mongodb after you logged in with a user?
This should not break, Graylog never automatically deletes any user accounts.

@angelsedoy

This comment has been minimized.

angelsedoy commented Jul 25, 2016

first login

{
    "_id" : ObjectId("57920ae3e147bb5f94110c91"),
    "password" : "User synced from LDAP.",
    "full_name" : "XXX",
    "session_timeout_ms" : NumberLong(28800000),
    "timezone" : "Europe/Moscow",
    "permissions" : [],
    "roles" : [ 
        ObjectId("560a6aa9e4b03989299b02c7")
    ],
    "external_user" : true,
    "email" : "xxx@.ru",
    "username" : "xxx"
}

Add stream and dashboard

    Update User
        {
            "_id" : ObjectId("57920ae3e147bb5f94110c91"),
            "password" : "User synced from LDAP.",
            "full_name" : "xxx",
            "session_timeout_ms" : NumberLong(28800000),
            "timezone" : "Europe/Moscow",
            "permissions" : [ 
                "streams:read:56b45a6ae4b0ca7e77a1dd47", 
                "streams:read:56d98a69e4b0ca7e77ca3c04", 
                "streams:read:56b45a6ae4b0ca7e77a1dd47", 
                "streams:edit:56b45a6ae4b0ca7e77a1dd47", 
                "dashboards:read:573c7772e4b0b036f10d2569", 
                "dashboards:read:57209966e4b0aa55c1dc195f", 
                "dashboards:read:56b468c9e4b0ca7e77a1ece2", 
                "dashboards:edit:56b468c9e4b0ca7e77a1ece2"
            ],
            "roles" : [ 
                ObjectId("560a6aa9e4b03989299b02c7")
            ],
            "external_user" : true,
            "email" : "xxx@xxx.ru",
            "username" : "xxx"
        }

    Update roles (change timezone, in config Europe/Moscow )
        {
            "_id" : ObjectId("57920ae3e147bb5f94110c91"),
            "password" : "User synced from LDAP.",
            "full_name" : "xxx",
            "session_timeout_ms" : NumberLong(28800000),
            "timezone" : "UTC",
            "permissions" : [ 
                "streams:read:56b45a6ae4b0ca7e77a1dd47", 
                "streams:read:56d98a69e4b0ca7e77ca3c04", 
                "streams:read:56b45a6ae4b0ca7e77a1dd47", 
                "streams:edit:56b45a6ae4b0ca7e77a1dd47", 
                "dashboards:read:573c7772e4b0b036f10d2569", 
                "dashboards:read:57209966e4b0aa55c1dc195f", 
                "dashboards:read:56b468c9e4b0ca7e77a1ece2", 
                "dashboards:edit:56b468c9e4b0ca7e77a1ece2"
            ],
            "roles" : [ 
                ObjectId("560a6aa9e4b03989299b02c7")
            ],
            "external_user" : true,
            "email" : "xxx@xxx.ru",
            "username" : "xxx"
        }

again log in

{
    "_id" : ObjectId("57920ae3e147bb5f94110c91"),
    "password" : "User synced from LDAP.",
    "full_name" : "xxx",
    "session_timeout_ms" : NumberLong(28800000),
    "timezone" : "UTC",
    "permissions" : [],
    "roles" : [ 
        ObjectId("560a6aa9e4b03989299b02c7")
    ],
    "external_user" : true,
    "email" : "xxx@xxx.ru",
    "username" : "xxx"
}

@joschi joschi added bug users ldap and removed cannot reproduce labels Jul 25, 2016

@angelsedoy

This comment has been minimized.

angelsedoy commented Jul 25, 2016

Hello!
I commented out the code line and rebuilt the project, began to work as I have to, but I understand that this is very wrong. Just really, really need this functionality in the way he was.
2.0 (graylog2-server/graylog2-server/src/main/java/org/graylog2/users/UserServiceImpl.java)


   // create new user object if necessary
        if (user == null) {
            user = userFactory.create(Maps.<String, Object>newHashMap());
        }

        // update user attributes from ldap entry
       ------>>>>/// updateFromLdap(user, userEntry, ldapSettings, username);

        try {
            save(user);
        } catch (ValidationException e) {
            LOG.error("Cannot save user.", e);
            return null;
        }
@kroepke

This comment has been minimized.

Member

kroepke commented Jul 25, 2016

Ah I see. This happened during a bugfix in 2.0.0 beta.3 apparently 9b746fa

We should merge the permission list, rather than overwriting them with the empty list.
Should get fixed in 2.1 then.

Thanks for the input!

@kroepke kroepke added this to the 2.1.0 milestone Jul 25, 2016

@kroepke kroepke added S2 P2 labels Jul 25, 2016

kroepke added a commit that referenced this issue Jul 25, 2016

@kroepke

This comment has been minimized.

Member

kroepke commented Jul 25, 2016

@angelsedoy the workaround should be to create a role for this user and then assigning it.
please note that in 3.0 the individual permission sets are most likely gone, they are already deprecated for quite a while.

@kroepke kroepke self-assigned this Jul 25, 2016

@angelsedoy

This comment has been minimized.

angelsedoy commented Jul 26, 2016

@angelsedoy the workaround should be to create a role for this user and then assigning it.

@kroepke , I think it does not work

please note that in 3.0 the individual permission sets are most likely gone, they are already deprecated for quite a while.

It would be useful to keep this possibility, I understand that it is necessary to set right through Active Directory, but in some cases it is convenient to carry out authorization through Active Directory and give rights to GL

@joschi joschi closed this in #2529 Jul 26, 2016

joschi added a commit that referenced this issue Jul 26, 2016

@kroepke kroepke added triaged and removed triaged labels Sep 21, 2016

@davidchua

This comment has been minimized.

davidchua commented Mar 24, 2017

I'm having a similar issue RE: this but I"m not sure if its a bug or a potential feature in the future.

I have a LDAP + group mapping setup on GL 2.1.2 for our users.

A typical flow would be:

  1. User logins via AD to Graylog
  2. Admin adds new roles to the User.
  3. Confirms that roles have been added to the User
  4. User logs out and relogs in.
  5. User loses the custom roles that have been added and reverts to the original group mapping.

My only workaround this is to disable group mapping totally and manually add permissions for them.

@jalogisch

This comment has been minimized.

Member

jalogisch commented Mar 24, 2017

@davidchua

please update to the latest release and check if the problem still present. Additional please do not highjack old closed issues.

If the problem is present in the latest release please open a new issue with a reference to this.

dennisoelkers added a commit that referenced this issue Apr 3, 2017

Restore removal of role permissions upon roles update.
In #2529, while fixing #2516, persisting all permissions of roles
assigned to a user was reintroduced (fixed in
35c9325 before). This happened due to
the introduction of a temporary variable that was not used effctively.

After this change, LDAP permissions are not modified blindly but the
permission set of a user still stays denormalized when modified and
saved.

dennisoelkers added a commit that referenced this issue Apr 3, 2017

Restore removal of role permissions upon roles update.
In #2529, while fixing #2516, persisting all permissions of roles
assigned to a user was reintroduced (fixed in
35c9325 before). This happened due to
the introduction of a temporary variable that was not used effctively.

After this change, LDAP permissions are not modified blindly but the
permission set of a user still stays denormalized when modified and
saved.

(cherry picked from commit 1f2aeb5)

kroepke added a commit that referenced this issue Apr 3, 2017

Restore removal of role permissions upon roles update. (#3684)
In #2529, while fixing #2516, persisting all permissions of roles
assigned to a user was reintroduced (fixed in
35c9325 before). This happened due to
the introduction of a temporary variable that was not used effctively.

After this change, LDAP permissions are not modified blindly but the
permission set of a user still stays denormalized when modified and
saved.

(cherry picked from commit 1f2aeb5)

kroepke added a commit that referenced this issue Apr 3, 2017

Restore removal of role permissions upon roles update. (#3683)
In #2529, while fixing #2516, persisting all permissions of roles
assigned to a user was reintroduced (fixed in
35c9325 before). This happened due to
the introduction of a temporary variable that was not used effctively.

After this change, LDAP permissions are not modified blindly but the
permission set of a user still stays denormalized when modified and
saved.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment