Notifications
Clear all
Topic starter
I am thinking of making a change to our security model to go from AD Integrated to standalone CPS. The reason for this is that it is just extra work with no benefit to use AD (that I have been able to ascertain). You end up having to add the user and groups in CPS anyway, and the biggest downside I have found is with the Windows complexity requirements which I would like to enable but had to back off due to CPS's problem with special characters in passwords. I need to be able to better secure Windows and would like to get away from a 3rd party thing I have employed since GE revealed the password issue but now I hear that they have no interest in addressing the problem.
So, before I tear up my test server I would like to know what would happen if I make a change. I would do this alongside an upgrade, likely CPS12, but not sure how to prepare for such a task. Would I have to re-add all of the groups or would changing to standalone security copy the AD groups which seem to be in CPS already. I can't really tell which groups are from AD and which are CPS only but we seem to have both. All I can do is look in AD and see of those groups exist there but that is quite the tedious process. I am OK with manually doing it as it would give me an opportunity to address the security again but that has some potential long lasting ramifications especially if the upgrade doesn't go well for other reasons
So what are most of your clinics doing? AD-Integrated or CPS only?
suggestions/comments appreciated
Mike Zavolas
Tallahassee Neurological Clinic
Posted : January 29, 2014 2:56 am
tnc said:
I am thinking of making a change to our security model to go from AD Integrated to standalone CPS. The reason for this is that it is just extra work with no benefit to use AD (that I have been able to ascertain). You end up having to add the user and groups in CPS anyway, and the biggest downside I have found is with the Windows complexity requirements which I would like to enable but had to back off due to CPS's problem with special characters in passwords. I need to be able to better secure Windows and would like to get away from a 3rd party thing I have employed since GE revealed the password issue but now I hear that they have no interest in addressing the problem.
So, before I tear up my test server I would like to know what would happen if I make a change. I would do this alongside an upgrade, likely CPS12, but not sure how to prepare for such a task. Would I have to re-add all of the groups or would changing to standalone security copy the AD groups which seem to be in CPS already. I can't really tell which groups are from AD and which are CPS only but we seem to have both. All I can do is look in AD and see of those groups exist there but that is quite the tedious process. I am OK with manually doing it as it would give me an opportunity to address the security again but that has some potential long lasting ramifications especially if the upgrade doesn't go well for other reasons
So what are most of your clinics doing? AD-Integrated or CPS only?
suggestions/comments appreciated
Mike Zavolas
Tallahassee Neurological Clinic
We do AD and CPS. They have to match exactly. I am not responsible for AD but I know that is what we are doing.
Posted : March 6, 2014 5:55 am
We use AD synchronization for users and groups. I find it very helpful for our users to have one less password to remember. We also like the integration in our environment as it should be one less thing to manage from an IT perspective. But there is one issue...
If synching groups from AD, there is a serious issue to take note of.
1) Synching works fine when adding a user to an AD group, CPS will sync/add the user to the group on first login to CPS.
2) Synching does NOT work when removing a user from an AD group. CPS does NOT remove the user from the group in CPS.
In order to remove the user, you have to disable AD group sync in CPS and manually remove the user in CPS after you removed the user from AD.
Jake Hinkelman
Valley Medical Center
Posted : March 15, 2014 4:24 pm
Topic starter
hinks2000 said:
We use AD synchronization for users and groups. I find it very helpful for our users to have one less password to remember. We also like the integration in our environment as it should be one less thing to manage from an IT perspective. But there is one issue...
If synching groups from AD, there is a serious issue to take note of.
1) Synching works fine when adding a user to an AD group, CPS will sync/add the user to the group on first login to CPS.
2) Synching does NOT work when removing a user from an AD group. CPS does NOT remove the user from the group in CPS.
In order to remove the user, you have to disable AD group sync in CPS and manually remove the user in CPS after you removed the user from AD.
Jake Hinkelman
Valley Medical Center
Thanks for the comment, it does help to clear up a litte bit for me. Do you have Windows password complexity enabled on your domain by chance? The reason I ask is GE is saying that special characters like (!(@*#&#^%$%#$) cause issues with CPS and that it is a SQL problem, not a CPS problem. I am not sure I agree but willing to accept that with some proof. I had to disable that on my domain to prevent people from using special characters. I find it hard to believe that you can't use a complex password if you use SQL as it would destroy any credibility Microsoft ever had. So as a workaround I purchased 'password policy enforcer' and came up with a different complex password policy without the use of the 'illegal' characters. People hate it, I sort of do also, so getting away from AD integration with CPS would let me relax that policy and re-enable Microsoft complexity but weould require an additional password as you say.
Mike Zavolas
Tallahassee Neurological Clinic
Posted : March 19, 2014 5:28 am
We do have complexity enabled for our domain users, but have not had any users complain of login issues. Our users are mostly using the upper case, lower case and number to meet complexity. To test though, I just changed a test account's password to include a capital, number, special character (*) and lowercase. I was able to log into CPS 10 and open the chart module.
Just grasping at straws, does your test server's application user (jboss) have a special character in it's password? If that were the case though, I would assume nothing would be able to connect.
For reference:
Application server: Server 2008R2
Database Server: Server 2008R2
Sql Server: 2008 R2 SP2
Client connecting from a Server 2008R2 Terminal Server.
Active Directory 2008 R2 running highest functional level
Posted : March 19, 2014 5:48 am
Topic starter
hinks2000 said:
We do have complexity enabled for our domain users, but have not had any users complain of login issues. Our users are mostly using the upper case, lower case and number to meet complexity. To test though, I just changed a test account's password to include a capital, number, special character (*) and lowercase. I was able to log into CPS 10 and open the chart module.
Just grasping at straws, does your test server's application user (jboss) have a special character in it's password? If that were the case though, I would assume nothing would be able to connect.
For reference:
Application server: Server 2008R2
Database Server: Server 2008R2
Sql Server: 2008 R2 SP2
Client connecting from a Server 2008R2 Terminal Server.
Active Directory 2008 R2 running highest functional level
The problem I am referring to is a known issue and does not show up as a login issue. It causes an error after certain users do something in CPS. Authentication credentials get passed many times as a user does different things in CPS. I don't recall exactly which one is an issue but we had many users run into the problem until we disabled the complexity requirements in AD. GE says this is a Microsoft problem but I don't know why because it seems like GE bypasses the Microsoft SQL security with the cpsuser account so I don't know.
Mike Zavolas
Tallahassee Neurological Clinic
Posted : April 14, 2014 1:03 am
