SecurityAdmin - bending the rules

[gtonkin]

I have a client with a SecurityAdmin that needs to administer 9 TM1 instances across 3 servers.
Users login via intregrated login and come from three different domains.
To facilitate the multiple domains and username variants, we have attributes on the }Clients dimension.
I then use a rule to test if the SignOn and Domain attributes are non-blank then derive UniqueID based on the client/signon and domain.
This works well unless you are SecurityAdmin as you can add the user but cannot update the attributes due to the restrictions imposed on SecurityAdmin.
SecurityAdmin is able to run TI's either - whether or not Security Access is checked or not.
Creating and additional group with permissions to access client attributes or a custom cube which is then used to rule derive UniqueID also does not work as the privileges do not inherit/are limited.

I was considering a process that the user could execute outside of TM1 to do a TM1RunTi with credentials allowing update only of the relevant cube but this would obviously mean creating password files, TI's etc. etc.

I fully understand why security has been implemented like it has been but looking for some leeway to facilitate update of attributes.
Have I missed something?
Any ideas?

edit: forgot to mention that they use a domain ID e.g. WXYZ0123 as the Client name rather than a fully qualified name e.g. WXYZ0123@DOMAIN

[mattgoff]

We also use a rule to assemble the UniqueID field, but instead of an attribute we've added an element to the }ClientProperties dimension ("ClientDomain") which is joined with the TM1 username (which is the same as the non-qualified domain username) by a rule to make the UniqueID. We don't make use of the SecurityAdmin account, so I don't fully understand the restrictions, but perhaps this would not be blocked. You have to use TI to insert the element-- the GUI won't allow it.

If that cell is also not writeable to SecurityAdmin, could you move away from the rule-assembled UniqueID and enter it manually? I have to assume that field is directly accessible to SecurityAdmin.

As a last resort, is there a reason why you couldn't move to using fully-qualified usernames as your TM1 usernames?

[gtonkin]

Thank you for the suggestions.

I considered tweaking the system dimensions but reluctant as I am unsure of future upgrade impacts but definitely something to consider testing from at least a write-back point of view.

With regards to going to a fully qualified name, no other reasons come to mind other than the work involved trying to migrate I.e. Potentially create new users, rather than just "swapping alias", renaming user folders to retain subs, views etc. Definitely plausible.

[gtonkin]

Have implemented a solution per Matgoff's post i.e. add new measures to }ClientProperties.
SecurityAdmin can write directly to this cube without any need for processes etc. Have saved a view with what they need.
Will post back if I encounter anything untoward.