This project has moved and is read-only. For the latest updates, please go here.

AD Groups

Feb 10, 2015 at 8:14 PM
I have created the 3 groups within our AD and I added domain admins to both ticketdeskadmin and ticketdeskstaff however it only adds the users within that group to the ticketdeskstaff group and not the ticketdeskadmin. I also added the domain users group to the ticketdesksubmitters group and it doesn't add them to that one either. Any ideas what's going on? BTW, I'm basing this off the cache of users within the AdCachedRoleMembers table. If I add a specific user to any of the 3 ticketdesk groups, it works perfectly...
Coordinator
Feb 11, 2015 at 2:47 AM
The reason it is recommended to create new AD groups for ticketdesk is because of the difficulty of querying AD structures from a custom application. The best practice is to create new AD groups for use with ticketdesk, then assign user accounts directly into those new groups.

It is best NOT to assign other group accounts to these (nested groups), as this creates a heirarchy that will likely perform poorly, and will almost certainly result in accounts appearing in TicketDesk that shouldn't be seen by regular users.

The problems with AD are numerous, but here are the highlights are that Queries against AD take FOREVER. Even a simple "who is in this one little group with no sub-groups" type query can take 5 to 30 seconds, and since AD is very customizable it is difficult to create generic application code that can correctly take into account all possible configurations, security setups, etc.

Case in point, if you assign the domain users account to one of ticket desk's groups, the odds are that the queries against AD will end of containing dozens or hundreds of non-people accounts --service accounts, special os and server accounts, backup accounts, etc. You don't want all those to show up in TicketDesk when you click the "assign" dropdown list.
Feb 11, 2015 at 3:08 PM
Hmm, I completely understand where you are coming from, however the issue is that on a network of any more than 50 or so users, it can be a nightmare to remember all the groups that new users need to be added to if you can't nest groups.

The strange thing is that it is working for the staff group, but not the others. Also, maybe it's because I'm running on an AD controller, but I use AD authentication for the intranet that I developed and I get a list of all groups (and nested groups) the user is a member of during the login which never takes more than a second or so. All the security on my intranet is based on nested AD groups. I do cache them during the login so it doesn't query it in real time, similar to yours, but into a session variable that gets repopulated on every login. I don't want to sound like I don't appreciate what you've done here, as you've created a wonderful tool and it is greatly appreciated, i'm just wondering if there is something that I could do to make managing the submitters group a little easier as everyone should always be able to submit tickets within our domain...

Thanks for all you are doing!!!
Coordinator
Feb 11, 2015 at 10:29 PM
Edited Feb 11, 2015 at 10:31 PM
Generally speaking, nested groups should work. They just aren't recommended... especially the built-in groups like domain users which will contain tons of user accounts and other nested groups which you wouldn't want to see in TicketDesk's drop down lists.

If you can't authenticate at all with those groups, something else is wrong. Check the spelling in web.config, make sure you are using the right kind of slash to delineate the domain names, and make sure you've setup both the main settings at the top of the file, as well as the ones under the location element for the admin section.

AD support in TicketDesk has two parts. The first is pretty much what you describe with your intranet application. TicketDesk handles authentication and authorization with the standard windows membership providers. These are reasonably reliable and perform fairly well. The problem with the membership provider is that it doesn't give you much additional information about the user. You can see their account name, and the list of groups to which they belong... and that's all. TicketDesk also needs their email address and friendly display name. TicketDesk also needs to obtain a list of all users within particular groups, which the memberhsip provider doesn't support. So the second part of TicketDesk's AD system is a background process that uses the directory services API to attempt to query AD for that additional information. This is what populates those AD cache tables in the database.

Custom AD Queries via Directory Services are wrappers for old-fashioned ADSI calls.. and they are painfully slow even on the smallest of AD environments. So TicketDesk builds a cache of that info in the background rather than attempting to query AD in real-time. The biggest difficulty in querying AD directly is that AD is so flexible in how it can be configured. If you know in advance how it is setup, it is simple to author a custom query for what you need. But building a generic all-purpose query that works in all AD setups is quite difficult. TicketDesk's queries work reasonably well for standard single domain AD setups that use the default organization structures. It can even deal with nested groups, as long as there aren't so many that the queries time out waiting for a response.

The difficulties of querying AD directly are fairly well known, and are the main reason so few web applications attempt integration with AD beyond simple logins. These difficulties are also why TicketDesk 2.5 and later will not offer direct AD integration. Fortunately authentication and identity has come a long way over the years, so single sign-on with AD domains will still be possible using OAuth, OpenID Connect, or WSFederation --which should let you get at AD user accounts from ADFS, Azure AD, or products like Identity Server with much less fuss than traditional direct AD integration.