Change name in User Manager in SMC

[Bob_Berto]

Greetings.

I like to follow the recommendation that user names and group names as seen in the General Tab of User Manager in SMC are short and without blanks (and unique of course).  Example

Name:             Franklin Delano Roosevelt

Display Name: [blank]

I change to

Name:             fdroos

Display Name: Franklin Delano Roosevelt

When I come to a site where the previous admins did not read that page of the manual, I usually change the names.

At this site, 9.4 under Linux with grid, the "Name:" field is (ghosted) not modifiable.  Other versions this was always changable.

I have unrestricted Metadata using my own ID.

Why is this field ghosted to me ?

Thanks in advance.

Here is a logic puzzle to ponder -

What can we conclude when

1. Wisconsin beats Kentucky

2. Rutgers beats Wisconsin

My answer is "Nothing logical applies. That's why they play the game(s)!

Thanks in advance, Bob

[ronan]

Very puzzling, indeed and illogical at first guess :smileyconfused:.

The only way I can think of to get a Read-Only pane in the User Plug-ins logged in with unrestricted privileges would be

to have selected the user inside the Members tab of a Group properties windows by clicking on the 'Properties' buttton.

This button would then open a second window wich looks almost exactly like the User individual object selected from the User plugin list,

except it is a (Read-Only) glimpse on the user's properties.

1.select MyGroup then display Members pane, select a user in the list and click on Properties

2. User properties windows is obviously (Read-Only) as suggested by the title, the attributes are greyed out accordingly

Have you tried selecting the user directly in the SMC plug-in or indirectly like the method above ?

[Bob_Berto]

Upon reading the fine manual (RTFM), page 24 of SAS 9.4 Management Console - Guide to Users and Permissions

TIP You cannot change the name of an identity after it is saved.

You can instead add of change the display name of an identity.

My changing of this field has always been before 9.4

I'l have to look at earlier versions of this book & see what is there.

Thanks for your reply, Bob

[Bob_Berto]

Going back to the 9.3 version of the like named manual, page 17, the TIP above is not present.

For now, I will need to live with the real names for users (~200)

I will fix it for the groups with a count of 30 or less.

[ronan]

Thanks for the solution. There are new uniqueness constraints beginning with SAS 9.4 enforced by the SMC User Plug-in :

http://support.sas.com/documentation/cdl/en/bisecag/67045/PDF/default/bisecag.pdf

You cannot change the name of an existing user, group, or role in SAS Management Console. You can change the display name.

:smileyshocked: . so now, back to the metadata data step functions or even proc metadata queries in order to update a simple Group or Role's name ?

[PaulHomes]

You don't have to revert to code as yet. Using SAS Management Console and the Authorization Manager plug-in, navigate to Resource Management > By Type > Person. Right mouse click over NameOfUser and open the Properties dialog. This basic properties dialog still allows you to change the name of the object.

Having said that, I would exercise caution. I'm assuming that there are good reasons for not changing the name of a user after it has been initially created, otherwise the constraint would not have been introduced in SAS 9.4. Perhaps it is related to the use of name based associations rather than object id based associations (like responsible party metadata for example)? Perhaps a SAS employee might post any additional reasons why changing the name post-creation might have some negative consequences.

[PaulHomes]

After a very quick test in SAS 9.4 M2 , I saw that a renamed user retained their link to their old private user folder. The folder had the old name but there is a metadata object association between the user and the folder that survives the rename. I could also see that with some responsible party metadata, whilst the old name could be seen in the metadata, the object association remained intact. This is by no means an endorsement of changing the name, just a follow up on a couple of items I was curious about. Obviously a quick five minute test like this is nowhere near sufficient for a large complex enterprise platform with lots of cooperating software clients/components. I would still recommend holding off any Person object name changes before finding out from SAS what software components might be impacted and what the ramifications might be.

[ronan]

thanks Paul. The test shows the renaming is still robust as regards associations. I can understand the uniqueness constraint on the User (Person) object name because the object might be linked to different sub-systems therefore uniquely defined :

1. Metadata personal folder's name

2. Content server (WebDAV) corresponding pathname

3. Report's authoring (Responsible party)

4.Comment's ownership (id. ?)

5.Audit/performance/usage trace as stored in the SAS Web Infrastructure Platform Data Server (?)

...

But the uniqueness constraint also inexplicably applies  to Groups/Roles names : that's a regression from my point of view because those are not fine-grained 'atomic' objects like users but on the contrary, higher level 'storage' objects.This new requirements means you cannot  change anymore your security model on-the-fly using the SMC User manager, groups & roles names must be carefully planned beforehand. Great.:smileyplain:.

[jakarman]

Ronan a security model planned and designed using ACT's not the roles/groups/users. The last ones are just administrative processes. Andrew's logical choice for using the accounts as the name is avoiding a lot of translations. Having a wrong name you must backup (selective) then delete and add followed with a restore (selective) according following the tips/limitation.

Not a very nice one for just a wrong name, something to improve. 

[ronan]

Hi Jaap. I'm sorry, I don't quite follow you. SAS ACTs are interfaces linking target resources (Servers, Folders, Reports) with Users/Groups. Would you recommend not to use Groups but only Users in ACTs ? This wouldn't be a good practice, generally speaking.

We design our own security models based on Metadata Groups/Roles/ACT/Servers + Operating System permissions (groups/accounts/permissions profiles on folders) + SAS restricted options.Since we implement multitenancy DI + EBI platforms, the standard single SASApp + default groups installment is not sufficient.

SAS metadata security can be very flexible and doesn't require external systems like LDAP Directories security (filters, groups, roles), for instance.

In turn, this flexibility relies for a good part on the convenience to create/alter/delete the main components like Groups, Roles or ACTs.

As you say, it's always possible in order to change the Name attribute of a Group/User/Role to purge it then to re-create it slightly modified : but this is quite tedious instead of a modification on the fly, isn't it ? especially now when we've reached the 4th generation of metadata servers.

Anyway, an explanation for this technical change would be welcome, as Paul suggested.

[PaulHomes]

Hi Ronan,

Please could you expand on your thoughts regarding how this prevents changing the security model on-the-fly? My take on this is that whilst the name now cannot be, or should not be, changed post-creation, the Display Name (which is shown to the user in most cases) can still be changed. Clearly thought would need to go into setting the Names in the first place (given they need to be unique and preferably have no whitespace/special characters) but you still have the flexibility to change the Display Name at a later date. The Name attribute is used in the userid of any Internal Accounts created, but there would normally be very few of those, and they would most likely be for admin-type people who could probably get by using the old name for login with the Internal Account when needed? I'd be interested to hear of any other areas you're aware of where a constant Name would be a concern (but where the Display Name could still be changed)?

Thanks

Paul

[ronan]

Hi Paul,

The so-called 'security model' is not affected by changing any attributes of the User. We all agree that it's preferable to keep a user name stable over time, especially since it often comes for the external directory (security requirement) and, as Andrew points out, is used as a primary key in the synchronization process (%MDU) between metadata and LDAP. The security model is like the fortress walls of defence, it doesn't go as far as the soldier's uniform (in my own personal view).

It's not the same with the underlying Metadata Groups or Roles structure supporting the permissions : in this case, the distinction between Name and Display Name is pointless in my opinion ; as far as I know, there is only one default interface to display both and it's the SMC User Manager (+New Environment Manager). The Diagnostic Portlet of the SAS BI Portal is the only exception I can think of which also displays Groups and Roles (actual names). Besides at least wirh 9.2/9.3, the Display Name is not a required attribute for the Group or Role so that usually we simply omit to fill in the place with a value.

Since the Group name might be used elsewhere as a security parameter : OLAP Dimension MDX condition, Information Map Group-based filter, we don't change it every week, of course : its naming must be stable over time. However, setting up a new model might involve many change of names and we speak of dozens of Groups / Roles on large multitenant platforms... The unability to change the names 'conveniently' using the User Manager implies tedious workarounds :

1. Systematically using the Display Name in addition to the Name : great, two values instead of one previously:smileyplain:

2. Purging/re-creating the Group / Role whenever we change our minds to rename it ...

3. Coding a new User Manager based on Metadata requests which adresses the need ...

This new requirement might not be very cost-efficient in the long run.

[PaulHomes]

Thanks for expanding on your previous comment Ronan. It's good to hear the how other admins use SAS and the impacts on their workflow. In regards to the key for identity synchronization, in my case, I prefer not to use the user id, due to its capacity to change over time. I have worked with sites in the past where user ids change due to natural name changes, and in some cases contractors get a new user id (but same display name) for each non-contiguous contract term [ that presented some challenges ]. My personal preference for the key is a GUID, SID, or employee id where available - something that is less likely to change over time.

[ronan]

Good advice. Thanks Paul.

[jakarman]

Nice nice there us a change going on. I see also this one: SAS(R) 9.4 Management Console: Guide to Users and Permissions

" Tip: We recommend that you avoid using spaces or special characters in the name of a user, group, or role that you create. Not all components support spaces and special characters in identity names."

Until now you could change the name as the products were using that generic URI that the metadata is really using.

These Tips are indicators that not all products are using that anymore or never did or changed by design or never knew that object-uri approach. So they used the typed names instead of that.
Now you have to design a naming convention to solve that. you could use the object-uri or login-id. And than we see this happening again.

Just an update checking for the word user name. These are used for both the Login-s  the name and uri-object.
Would like to know wich product have become dependend of the user name seen int SMC. SAS-VA? event-manager? VMfabric/midtier? all of them.  

Message was edited by: Jaap Karman