I'd like to see an enhancement to the security framework that provides a mechanism to specify which domains are used when Windows authentication is enabled. I'd like to be able to limit the application to the current domain or let it seek out the parent and other child domains.

The reason for this request is that the agency I work for is a child domain in a larger AD structure. I've already experienced problems where my application failed because some other child domain was not reachable. As a workaround I've modified the framework to skip child domains that it can't find when it builds the list of child domains.

This weekend there was a power outage in our County's main data center that took down the parent domain's domain controller. This would have been an issue except the power failure also took down our Internet connectivity which prevented our Enterprise Server from accepting new connections since it couldn't "phone home" (Thanks for commitment to fix that). Now that I have the Internet and ES back I'm finding that I my users are experiencing a 60 second delay from the time an application is launched until the login screen is displayed. A little profiling with Ants shows about that much time being spent in "Login.AddChildDomainToList". Since one of our core Cisco routers was damaged in the outage I'm sure it's a network related issue that will eventually get fixed. However since I really have no interest in any of the other domains I'd really like to limit my application's dependance on them. As a test I modified the framework to only list the current domain and the login screen was displayed almost immediately.

Maybe a setting could be added to the security database or other config file that tells the application to look for the parent and child domains or just use (list) the current domain. That would allow applications that use Windows authentication to be easily configured to their environment without having to re-compile. I'd also like to see a fix for unreachable child domains when the domain list is being built.

-Larry

Comments???

This is on our list to look at before the final release of the build...we have given this a cursory glance and it will require a bit of effort as we will have to make some relatively extensive LDAP queries happen.  We current just use the Windows API to populate this combo...so it is on our radar, but I do not have a direct answer for you until we see what will be fully involved to make this happen.

Thanks for the update.

While not the ideal fix, adding a Try Catch block to the shared sub AddChildDomainsToList in the Login class of the security module solves a big part of the problem. It prevents the login from failing if one of the child domains cannot be added. If it's not the domain of the user that is trying to login, no problem. I've been adding this to the Security module with each update. It might be a good idea to display a warning message if a child cannot be added to make the user aware there is a problem on the network.

Private Shared Sub AddChildDomainsToList(ByVal ParentDomain As Domain, ByVal List As List(Of String))
'-- Establish locals
Dim loChild As Domain
'-- Cycle through the children
For Each loChild In ParentDomain.Children
Try
    '-- Add to list
    List.Add(loChild.Name)
    '-- Recursively call child's children
    AddChildDomainsToList(loChild, List)
Catch
    Continue For
End Try

''-- Original code
''-- Add to list
'List.Add(loChild.Name)
''-- Recursively call child's children
'AddChildDomainsToList(loChild, List)

Next

End Sub

At the very least, I will see if I can get this change added before the final release of 1.6.5.  In fact, I will probably add this tonight and post another update tomorrow.

Thanks! That saves me from having to modify the security module on each release.

Sure.  It is in the latest 1.6.5 beta that I posted last night.  We are getting close to releasing the 1.6.5 build and are finalizing a few requests, help, and samples.  So if you get a change, you might load this to make sure it behaves the way you want it to.