Account with domain prefix seen as different to the same account without prefix

Issue #572 new
david smith
created an issue

If you login using an account in the default domain it is not treated as the same account when you specify the domain prefix. A duplicate account is created.

if the user was found in the default domain i would still expect the user created to include the domain prefix

Comments (9)

  1. david smith reporter

    I've had a quick look at the source code for the active directory plugin and I think the problem is in the ActiveDirectoryAuthenticationHandler.

    If no domain prefix is supplied the host variable equals Util.EMPTY_STRING. Perhaps you could just set the host variable to the default naming context?

    Apologizes if this is just nonsense. I’m not a java developer :)

  2. Sebastian Sebastian repo owner

    Such a change could break many existing installations. We could not change the default behaviour without breaking existing installations. The only thing we could do is to add an configuration parameter which changes the behaviour. But at the moment i don't have an active directory to test changes to the scm-activedirectory-auth-plugin.

  3. Karl Waclawek

    Have the same problem. In addition, once an account with a fully qualified domain name is created, I get the error "the resource could not be found" whenever I want to perform any activity on this account, even if I just want to delete it.

    This is more than just "existing behaviour", there is an actual bug there.

  4. david smith reporter

    sebastian: I'm happy to test the change if you add the config parameter.

    kwaclaw: the resource not found error is probably due to an encoding problem with the url. Try opening it Firefox with firebug enabled and see if anything stands out. I originally had some problems with backslashes but I think this has been resolved in the latest releases. Do your usernames contain unusual characters?

    Vladimir: That was my first thought but after reading this I think its only guaranteed to be unique with the domain not the entire forest. That’s why I suggested objectGUID. I might be wrong about this though

  5. Vladimir Baros

    David: I would stick with SIDs as Windows is using them for authentication across the domains. Look here:

    I had another issue with this just now. This is the setup: The same username exists in both domains, say domain1\joe and domain2\joe. And domain1 is inaccessible because of one way trust (domain controller is not accessible). If user domain1\joe tries to login he will be authenticated because the plugin will find it in the other domain with the same username. I've looked inside the logs to confirm this behavior.

    So implementing SIDs is essential for this plugin to work properly. SID could be a property in the users.xml file and the checkbox in the plugin configuration could enable using this parameter for authentication.

  6. Log in to comment