In part 1, part 2, and part 3 parts of this series we set up three user types. In part 4 we saw how to secure model elements and DeepSee items. In this last part of the tutorial we conclude with some remarks on DeepSee security and troubleshooting tips. In particular, we see how pivot tables in User Portal can be "hidden".
In part 1, part 2, and part 3 of this series we set up three user types. In this part of the tutorial we see how to secure model elements (such as DeepSee cubes) and DeepSee items (such as a folder containing pivot tables and dashboards in the DeepSee User Portal).
In part 1 and part 2 of this series we set up two user types, simpleuser and poweruser. In this part of the tutorial we create one last user type having privileges typically needed by an administrator/developer in analytics.
Hi I've created a word macro in order to convert doc to txt via the command line, this works fine via the command line by myself or another user but when I try as an the intersystems user which runs under LocalSystem it doesn't work.
So can I change the user, or set the $ZF to run as a different user?
Or do I have to try another way to convert doc to txt - it's looking like libreOffice?
I just wanted to stick with word because I could be guaranteed on the result being accurate.
Our environment has multiple instances of HealthShare installed and most are on separate VMs/servers. Does anyone have any ideas on how to efficiently manage user accounts across all of these multiple instances of HealthShare? As you can imagine, creating 10 separate Cache accounts on each instance during onboarding of new associates is cumbersome and tedious as is disabling them. We have yet to integrate with AD but we do have a Cyberark initiative under way but it is in the very early stages.
I have multiple namespaces in a Cache environment say NS1 & NS2. I want to add some restriction so that a routine running in the NS1 should not access any resource(global/routine) belongs to namespace NS2.
The above restriction need for few of the clients only, so we do not want to write any custom logic in code.
We are looking for some solution provided by Cache where we can restrict the namespace access.
I have a problem with an Ensemble instance on Windows to access to a network shared directory. Ensemble service (services.msc) is executed with a user which has access to this network shared directory :
- When I try to copy or access files from a terminal ==> this is OK : the command w ##class(%SYS.ProcessQuery).%OpenId($Job).OSUserName returns the user defined in Ensemble service logon screen.
In the previous article, I had just started working with Arduino, and got a meteorological station to show as a result. In this article, let's go further: we will set up authentication via RFID cards and Arduino against the InterSystems Caché application.
I know that when specifying Caché password rules (i.e. what constitutes a valid password definition) that the "Pattern Matching" logic is what is getting leveraged under the covers to enforce the "A Password Must conform to X" rule. I was hoping that people could share some more sophisticated pattern matching rules. (in particular, I was wondering what a rule that would require non-repeating mixture of letter, numbers, & punctuation of an overall minimal size)
I need to perform additional checks before Cache user logins (let's say in a terminal for simplicity) and allow access only to those, who passed them. How do I do it?
I'm interested in different approaches on how to store user data in Caché. I'm assuming that application uses Caché security/Caché users and not a self-made authentication system.