Line One
asked on
Active Directory integration - implications
There is the possibility of having a Dynamics application put on a network. One choice of installation is to have it integrated into Active Directory so that anyone who is an authenticated user of will not have to login to the Dynamics app - their AD credentials will be good enough. In the past we have had a situation with an app of this nature and there was a big hassle when we moved the network to a newer AD e.g. Windows 2000 to Windows 2008 - Dynamics would not recognize the users on the new AD even though the names/passwords would be the same.
I am concerned about any other such issues with AD integration of this Dynamics app. In particular, I am concerned about reverse effects - i.e. a problem at the Dynamics end that will somehow spill back and cause problems in AD. Also any other gotchas - performance issues, security issues, etc.
Any real world input is appreciated on what can go wrong in this type of scenario is appreciated.
I am concerned about any other such issues with AD integration of this Dynamics app. In particular, I am concerned about reverse effects - i.e. a problem at the Dynamics end that will somehow spill back and cause problems in AD. Also any other gotchas - performance issues, security issues, etc.
Any real world input is appreciated on what can go wrong in this type of scenario is appreciated.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
From the security point of MS SQL it is better to run only integrated logins than to run under mixed mode. If you do not use AD integration you will have to run SQL in Mixed Mode which is less secure.
http://download.microsoft.com/download/8/5/e/85eea4fa-b3bb-4426-97d0-7f7151b2011c/SQL2005SecBestPract.doc