-
Notifications
You must be signed in to change notification settings - Fork 27
Multi Domain query #89
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
Conversation
1b8e607
to
9405990
Compare
🙇, thanks again for the pull request!
That would be ✨! While we're glad to hear that this solution works well for your Active Directory infrastructure, we want to put this behind a configuration switch (with default off) to not change the behavior for other customers.
Another improvement could be to route searches based off of replication configuration in Active Directory Site and Services.
Appreciate these steps! Would it be possible to also add testing in |
9405990
to
0ba3966
Compare
Hello @gnawhleinad, thanks for the review. What do you mean by 'searches based off of replication'?
Writing tests would to be problematic due to it would require interaction with your active directory testing environment that seems currently not to be integrated with travis. |
@connection.search(options, &block) | ||
else | ||
@forest.each_with_object([]) do |(rootdn, server), res| | ||
if options[:base].end_with?(rootdn) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requires to use end_with?()
and not eql?()
which will result in unnecessary requests if you have a setup like DC=foo,DC=bar,DC=com
& DC=bar,DC=com
. Issue is that calls to the library contain requests where the basedn points to the object of interest.
- Login to GHE for example will query the full path:
options[:base]='CN=user,OU=org,DC=foo,DC=bar,DC=com'
- Possible fix would be to form such queries (outside the library) to search for the distinguished name:
options[:filter]='distinguishedName=CN=user,OU=org,DC=foo,DC=bar,DC=com'
with a basednoptions[:base]='DC=foo,DC=bar,DC=com'
Rather than iterating through the list of domain controllers, could we query based off the biases dictated by the replication configuration (e.g. locality, cost, ...)?
While we don't have Active Directory tests integrated with TravisCI, we do have tests that can be run from a local Active Directory environment via
Would it be possible to explore a new /ref: |
@@ -307,6 +331,37 @@ def configure_member_search_strategy(strategy = nil) | |||
end | |||
end | |||
|
|||
# Internal: Queries configuration for available domains | |||
# | |||
# Membership of local or global groups need to be evaluated by contacting referral Donmain Controllers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/Donmain/Domain/g
Will query for the NetBIOS name within the ConfigurationNamingContext to get all available Domains within the configured Parition.
Testing
Details
This modification works within our Active Directory infrastructure with six sub domains and thousands AD servers as well as with the testing example described within the pull request: I can bind to a single AD server and GitHub will show up all available groups: local / global or universal and also allow to login even if my user is present within another AD that I have bound to.
Technically it will do an additional query to CN=Configuration,DC=foobar,DC=com to search for nETBIOSName=* to obtain all available AD server by there DNS names and there responsible root basedn. Within every search this information will be reused and do a query to all available AD to get available users & groups.
Improvement could be done to evaluate the base of the search to only fire requests to the servers if it's basedn is matching the request.
Also this search behavior could be made available by a configuration switch to not break an existing installation.