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

Add new method getBindCredentials method to CR script to allow dynamically change AD password #1197

Closed
yurem opened this Issue Sep 10, 2018 · 12 comments

Comments

Projects
None yet
4 participants
@yurem
Contributor

yurem commented Sep 10, 2018

No description provided.

@yurem yurem added this to the 3.1.4 milestone Sep 10, 2018

@yurem yurem self-assigned this Sep 10, 2018

@yurem yurem changed the title from Add new method `getBindCredentials` method to CR script to allow dynamically change AD password to Add new method getBindCredentials method to CR script to allow dynamically change AD password Sep 10, 2018

yurem added a commit that referenced this issue Sep 10, 2018

@yurem

This comment has been minimized.

Contributor

yurem commented Sep 11, 2018

Implemented

@yurem yurem closed this Sep 11, 2018

@yurem

This comment has been minimized.

Contributor

yurem commented Sep 11, 2018

In order to resolve this I added next flow:

  • Call CR script method getBindCredentials if api > 1
  • This method can return null or BindCredentials(“bindDn”, “bindPwd”)
  • If getBindCredentials returns null than use bindDn/bindPassowrd from Source LDAP configuration
  • If getBindCredentials returns not null than use credentials returned from method

Test flow:

  1. Deploy latest 3.1.4 oxTrust.war
  2. Add new method and update getApiVersion method. Example:
    def getApiVersion(self):
        return 2

    def getBindCredentials(self, configId):
        print "Cache refresh. GetBindCredentials method"

        return BindCredentials("bindDn", "bindPwd")
  1. We need to return right credentials instead of "bindDn", "bindPwd" in real method
  2. Specify wrong password in Source LDAP server config
  3. Run CR
  4. Check if it works well
  5. Update return BindCredentials("bindDn", "bindPwd") to return wrong crenetials
  6. Check if CR not works well
  7. Update return BindCredentials(“bindDn”, “bindPwd”) to return None
  8. Check if CR not works well
@willow9886

This comment has been minimized.

Contributor

willow9886 commented Sep 11, 2018

@natt-tester can you do a test of this?

@natt-tester natt-tester reopened this Sep 13, 2018

@natt-tester natt-tester reopened this Sep 13, 2018

@natt-tester

This comment has been minimized.

natt-tester commented Sep 13, 2018

@yurem, @willow9886, I changed the script, but keep getting the error you can check in the log. What can I do to make it work? (For the sake of security, the "bindDn", "bindPwd" are missing in the file)
CR_files.tar.gz

@yurem

This comment has been minimized.

Contributor

yurem commented Sep 14, 2018

It's python code style issue:

Caused by: IndentationError: ('unindent does not match any outer indentation level', ('cache_refresh.py', 56, 4, '    def getBindCredentials(self, configId):\n'))

In python line indent is used to group methods in blocks. It's simular to { and } in java. So, all idents should be in right positions.

@natt-tester

This comment has been minimized.

natt-tester commented Sep 19, 2018

@yurem, could you please try to set up your ldap server with the data that I sent you? When I update and validate the script, it's a success, but during a CR I can't get any users from the database, only my admin. I'd really like to close the issue, but I'm stuck.

@natt-tester

This comment has been minimized.

natt-tester commented Sep 24, 2018

@yurem, I think it still needs improvement. When I updated the script on c7 and validated it, it gave me an error: getBindCredentials() takes exactly 2 arguments (3 given). The full stacktrace is in the log:
script_error_cr.txt

@yurem

This comment has been minimized.

Contributor

yurem commented Sep 24, 2018

Can you apply this update to you script and try again?
GluuFederation/oxExternal@aab7b71

@yurem

This comment has been minimized.

Contributor

yurem commented Sep 25, 2018

I tested it myself too.

  1. After activating CR with wrong password of source LDAP server:
2018-09-25 17:16:54,712 DEBUG [Thread-1144] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:181) - Allowing to run new process exclusively
2018-09-25 17:17:54,889 ERROR [Thread-1157] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:1080) - Failed to connect to LDAP server using configuration source
2018-09-25 17:17:54,905 ERROR [Thread-1157] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:283) - Skipping cache refresh due to invalid server configuration
  1. After enabling script with getBindCredentials which return not None:
ely
2018-09-25 17:31:04,309 ERROR [Thread-129] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:1072) - Using updated password which got fr  om getBindCredentials method
2018-09-25 17:31:06,674 INFO  [Thread-129] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:318) - Attempting to load entries from sour  ce server

According to point 2 it works well.

@yurem

This comment has been minimized.

Contributor

yurem commented Sep 25, 2018

Also I updated sample CR script in CE to help with testing it: GluuFederation/community-edition-setup@0e7ed38

@natt-tester

This comment has been minimized.

natt-tester commented Oct 1, 2018

Tested, it works in gluu-server-3.1.4_1-2.

@natt-tester natt-tester closed this Oct 1, 2018

yurem added a commit that referenced this issue Oct 1, 2018

@aliaksander-samuseu

This comment has been minimized.

aliaksander-samuseu commented Oct 27, 2018

@yurem

I see it only mentions that CR's bind password is updated. But when there is CR enabled, there is most likely oxAuth configured to use the same remote backend directory when handling authentication. Thus simply changing CR's settings won't be enough, we need to update oxAuth's properties too, at the same time, or I believe we'll get a locked out instance. Was this matter attended as well?

In addition, is this enhancement compatible with setups where several different LDAP backends are used?

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