Thanks for the quick reply. So is the primary issue here that ITFlow is using the same login / password technology for its users that it is for the client infrastructure / users?
In the case of the ITFlow hosting company's LDAP it would require a separate area to record that companies LDAP credentials, and a way to test connectivity before saving. Moving forward since they have 'enabled' LDAP, the first thing the code would check for is the username/password validates against the LDAP server. Once that is accomplished, it can check to see if there is a matching username already in the existing ITFlow database. If so, it can update that. If not, it can create that user. So essentially upon login it validates against LDAP / AD and syncs it to the existing solution. If LDAP is turned off by the host, it switches to local users and validates against the DB first.
If the user is at any client dashboard pages, LDAP would automatically be bypassed and the local database used for validation.
Just some thoughts here based on previous models I've seen. I'm no expert and there's probably gotcha's in this or evolutions to improve it.