Odd things have been happening lately. Just by chance, I found a Memo created by an agent (really should have been an activity-but that's another story). I have security set up so that group cannot add Memos. Then this morning I found a policy screen created by an agent where again they should not be able to do this. I scoured the security for that group and the individuals in question and it all looks good. This has never happened before this week. I have not installed any Tam updates since installing 10.3 a while ago.
I was thinking I should create another group for the agents and setup all the security from scratch, then test with a test account. If no one thinks that will work, I'll need to call Applied because right now I can't trust any setups.
Any ideas?
Quote from: Alice on June 10, 2010, 02:06:08 PM
I was thinking I should create another group for the agents and setup all the security from scratch, then test with a test account. If no one thinks that will work, I'll need to call Applied because right now I can't trust any setups.
Any ideas?
That seems reasonable. If you don't trust your setups your best bet is to start over from scratch. Did you check that the users in question didn't get granted access under their specific user ID rather than through the group?
Yes I did and everything showed the blue inherited arrows or arrows with a green check mark. Very baffling. Tomorrow I'll create the group and test. Supposed to be off today :-\
Inherited means nothing! When in doubt deny deny deny! ok maybe not so harshly...
Quote from: Charlie Charbonneau on June 10, 2010, 05:34:38 PM
Inherited means nothing! When in doubt deny deny deny! ok maybe not so harshly...
Tyrant!
It wasn't me!!! (thank you shaggy!)
Seriously though... I seem to remember seeing somewhere not to rely on inheritable rights. If you don't want users to have access to something deny rights instead.
Charlie - I understand the concept but doing this for 50 individual user accounts seems a bit unrealistic. But here's a thought...if I edit one user to deny access instead of letting the rights inherit, will using the option "Grant same as" work? I wasn't sure how you set up your users - individually or with this option.
Thanks!!
Well "grant same as" would require that all other security rights be the same as well wouldn't it? That could seriously mess up other rights that individual users might have. Do you have them grouped? If I remember rightly users rights supersede the rights of the group, so yes you'd have to do it individually and grant same as only if they had the exact same rights. I'd recommend trying it first to see if it even fixes the issue.
Silly question, but have you tried editing the template, saving it, and then editing it back the way it was? Sometimes these things just need to be rewritten, and editing and saving and then reversing it will put a fresh copy of the file back out there. It's worth a shot.
Not a silly question Jeff. I tried that on Tuesday and no joy. I think this weekend I'll futz around with it a bit more but I'll probably end up creating another group and test it with my test user. Then I'll add a real one and grant same as the test user and test that. Test test test...
I feel like a doctor that always practices :o
This is getting stranger by the day. I was checking the logs and when looking at sec.log, the last entry is 6/7/10. I was messing around with security manager a lot yesterday and it looks like nothing recorded in the log. Running pack & reindex tonight so I'm going to make a minor change tomorrow, save it and check the log again.
This is turning out to be not so good.
Update.
I moved the sec.log and made a change to my ID. The log recreated but it's empty.
I contacted Applied at the web site (tried to look for something similar I might be able to use). I don't think it's a good idea to keep making changes when they are not logging.
I'll report back just in case others want to know ;)
Well I'll be darned. I did not know this. Also now have PMR 196822 asking to record more data. I don't really know what made me think it logged everything.
Is There A Report That Will Track Changes Made In Security Manager?
Product: 10.4, 10.3, 10.2, 10.1, 10.0, 9.4, 9.3, 9.2, 9.1, 9.0, 8.5, 8.4, 8.3, 8.2.0, 8.1, 8.0, 7.6.0, 7.5.0, 7.4.0, 7.3.0, 7.2.0, 7.1.1, 7.1.0, 7.0
Solution:
There is a report called SEC.LOG available in the X:\LOG folder that is viewable in both Log Viewer and Notepad. It keeps track of the following items:
• Users created & who created them.
• Users deleted & who deleted them.
• If a user is added to a group & who added them to that group.
• If a user's CSR code is changed & who changed it.
• If a user's producer code is changed & who changed it.
• If a user's WHO code is changed & who changed it.
• If a user is disabled & who disabled it (Note: This will not record if a user disable's oneself by incorrectly typing their password at the login screen too many times)
• If a user is enabled & who enabled it.
• If a user is granted the same rights as a another user & who made this change.
• If a group is created & who created it.
• If a group is deleted & who deleted it.
• If the user's security mode is changed from Expert to Novice (or vice versa) & who made the change.
• If a user's first or last name is changed & who changed it.
I was able to successfully create a new group, add test user and add all other agents using the "Grant same as...". Started moving them over on Tuesday and moved the last 5 over this morning. Haven't heard a peep out of anyone...so far. 8)
Unable to explain what happened with the original group and how it got corrupted. Anyone think I should keep the busted group around for any reason? I was going to wait a week before I removed it (just because I usually wait a week before deleting just about anything).
If no one is using the corrupted group, and you're sure that your securities for the new group are the same as the old group (but working!) I'd say that there's no harm in deleting.