none
Wrong ODBC settings applied to different users via GPO

    Question

  • Hi all,  we have a problem with wrong ODBC settings (System DNS) being applied to some users.
    The scenario:
    We have four different external customers with 4-6 users per customer and every customer has their own OU in our AD where customer user accounts per customer are located.
    External users log on to our server via Citrix so there may be many users and different customer's logged on our server at the same time. They open the Citrix application where ODBC settings have been applied by the Group policies.

    We have one security group per customer where all the corresponding customer's user accounts have been added to. In those GPO's the ODBC settings have been pushed by registry keys. So every customer should get their own customer based ODBC connection settings. All the registry settings are under the hive HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI. Registry keys have been added under the User Configuration (Preferences/Windows Settings/Registry) with action=replace.

    All the customer's user accounts are in their own corresponding OU's and their corresponding GPO's have been linked to those OU's. I have used the Security filtering on GPO, deleted authenticated users and added corresponding customer security group so GPO's should be applied only to the users under that OU and if they are belonging to that certain security group.

    On delegation tab I have modified the default settings that authenticated users have only read permissions and added a corresponding Security group which have apply and read permissions.

    "Gpresult /h /user:xxxx" shows that every customer and user gets their own ODBC registry settings as they should. Usually that works fine, but now it has appeared that sometimes for some reason a random user gets ANOTHER customer's ODBC settings . How is that possible? That's very annoying.  Any ideas why a user gets wrong registry keys loaded?

    I have also tried to add an Item-level targeting to point to the right group in Registry key properties (Common, item-level targeting), but that does not seem to help.

    Thursday, February 25, 2016 1:20 PM

Answers

  • > All the registry settings are under the hive
    > HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI
     
    This does not work - you cannot define different SYSTEM DSNs for
    different users. Scenario:
     
    User A logs on and gets DSN A written to HKLM.
    User B logs on and gets DSN B written to HKLM - DSN A is now GONE.
    User A starts his ODBC application - and obviously will use DSN B
    because DSN B is the current one.
     
    You MUST use HKCU instead of HKLM.
     
    • Marked as answer by FinnTech Friday, February 26, 2016 9:43 AM
    Thursday, February 25, 2016 1:44 PM

All replies

  • > All the registry settings are under the hive
    > HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI
     
    This does not work - you cannot define different SYSTEM DSNs for
    different users. Scenario:
     
    User A logs on and gets DSN A written to HKLM.
    User B logs on and gets DSN B written to HKLM - DSN A is now GONE.
    User A starts his ODBC application - and obviously will use DSN B
    because DSN B is the current one.
     
    You MUST use HKCU instead of HKLM.
     
    • Marked as answer by FinnTech Friday, February 26, 2016 9:43 AM
    Thursday, February 25, 2016 1:44 PM
  • Thanks for the reply!
    That might be the solution. But the next problem is that ODBC settings don't work when HKCU is used!
    Any other ideas to define the
    SYSTEM DSN settings per user?
    Friday, February 26, 2016 9:19 AM
  • > That might be the solution. But the next problem is that ODBC settings
    > don't work when HKCU is used!
     
    Hm - there's always been the option to configure System DSNs and User
    DSNs through odbcad32. Why should it not work for you?
     
    > Any other ideas to define the SYSTEM DSN settings per user?
     
    You can't. Repeat: You can't.
     
    Friday, February 26, 2016 9:59 AM