Hi.
Do you make plan to enable this feature for authentication through AD or LDAP?
Transparent (pass-through) authentication.
Transparent (pass-through) authentication.
Last edited by Dubolomov on Tue Apr 08, 2008 5:17 am, edited 1 time in total.
Yes, i mean this. So it's make possible don't creating new HM's users but add their from AD. Is it very hard to implement?KS-Soft wrote:Do you mean - use AD/LDAP accounts instead of HostMonitor's user profiles? H'm.. HostMonitor's profiles allows you to setup permissions specific to HostMonitor, not sure it can be replaced by Windows AD accounts
It would be very usefull for accessing users to web interface with their own permissions and tests list without entering one more username/password. So authenticated in AD users can have access to their own zones.
HM can take user information from AD through NTLM. And authenticated in AD users can have seted permissions. Isn't it?KS-Soft wrote:How HostMonitor may setup permissions for the user? How software may know what permissions do you want to grant to each user? How we know do you want to allow userA to add new tests or not?
It can be used for controll permissions to HM of existing AD groups and users. Any user can get access to their folder at once. It is just easy to distribute responsibility.
For example shift (who logged in at workplace) can restart any services, admins of remote branch can have access to any tests of their services etc. So they all can be addedd to any of AD groups that can be setup in HM.
For example shift (who logged in at workplace) can restart any services, admins of remote branch can have access to any tests of their services etc. So they all can be addedd to any of AD groups that can be setup in HM.
Alex,
I think you miss the point in terms of making this a priority. LDAP should never be a requirement of your product, but it should be an option. I will explain why:
In an enterprise environment, centralized user and group maintenance is a critical component of the job. The moment that task is decentralized you have exponentially increased the effort involved in maintaining your environment AND decreased the level of integrity in the system. Orphan accounts, for instance, leave users with more or less access than their current role requires. And when you have multiple directories, dozens of servers, hundreds of groups, and thousands of users this becomes paramount. And if one of your goals is to delegate authority, which your product allows for, LDAP integration isn't just nice, it's crucial.
Having said that, in terms of your product, I'm sure other advantages to LDAP integration could be found, but initially simply being able to query an LDAP directory for groups to assign to specific HM permissions would suffice. I would then assign domain user accounts to the appropriate group(s) and VOILA!
At this point your product wouldn't even require a logon, it could simply pick up the current logged on user account and apply the appropriate permissions - defaulting to a guest equivalent for accounts that aren't members of LDAP groups that have been assigned specific HM permissions. Prividing the option to log onto an HM 'local' account in order to override the current logged on user account would be equally important.
Having said all this - I still love your product!
I think you miss the point in terms of making this a priority. LDAP should never be a requirement of your product, but it should be an option. I will explain why:
In an enterprise environment, centralized user and group maintenance is a critical component of the job. The moment that task is decentralized you have exponentially increased the effort involved in maintaining your environment AND decreased the level of integrity in the system. Orphan accounts, for instance, leave users with more or less access than their current role requires. And when you have multiple directories, dozens of servers, hundreds of groups, and thousands of users this becomes paramount. And if one of your goals is to delegate authority, which your product allows for, LDAP integration isn't just nice, it's crucial.
Having said that, in terms of your product, I'm sure other advantages to LDAP integration could be found, but initially simply being able to query an LDAP directory for groups to assign to specific HM permissions would suffice. I would then assign domain user accounts to the appropriate group(s) and VOILA!
At this point your product wouldn't even require a logon, it could simply pick up the current logged on user account and apply the appropriate permissions - defaulting to a guest equivalent for accounts that aren't members of LDAP groups that have been assigned specific HM permissions. Prividing the option to log onto an HM 'local' account in order to override the current logged on user account would be equally important.
Having said all this - I still love your product!
