BookmarkSubscribeRSS Feed
MarkNicholas
Obsidian | Level 7


Dear Friends,


I use the below to create metadata on SAS management console with the new list of user accounts created in my unix server

proc metadata in = _outxml out =_respons

run;

However, in my line of work, it so happens that an existing user has 2 different accounts (lets say an induvidual account and another service account is created for a same user id 1234 in unix server)

So, obviously I get the below error while upload to SAS MC since it is incorrect to have > 1 userid under same auth domain (DefaultAuth here).

ERROR: Cannot associate a Login with UserID 1234 to Identity <xxxxxx> because this UserID is already assigned to a Login for Identity <yyyyy>

Now, my input xml file which contains other 'valid' accounts that can be uploaded are also affected because of this error returned from one user id.

I need suggestion on how I can circumvent this issue. (Even the duplicated user account is not uploaded, the other accounts should be uploaded succesfully.)

Could there be any other way other than creating and uploading individual xml for each user id (which is cumbersome). I also tried to use option noerrorabend and it still fails.


Thanks
Mark

8 REPLIES 8
jakarman
Barite | Level 11

Use the mdusecds macros SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition to extract what is the metadata and eliminate the duplicates before adding.
As the user-management process is normally part of a RBAC (Role Based Access Control) process it is weird you are trying to export/import users. It is violating these kind of often mandatory processes.

---->-- ja karman --<-----
acfarrer
Quartz | Level 8

Have you considered creating another AuthDomain for service accounts?

jakarman
Barite | Level 11

acfarred please explain you security model and compliancy to guidelines.   For an inbound login (login to SA metadata use OS services) a normal requirement is being traceable and auditable to the person who started all actions.
By that every key should  be identified to just one person. A person however can use multiple keys for his work (normal and high privileged ones). There can be/ should be more keys than persons.  A service account is a special case of a high privileged account as it used to have the service operational without the need for manual intervention. This is some of the background: Privileged Identity Management - Wikipedia, the free encyclopedia

Having unique keys for each person is very well accepted more a requirement with Windows/Ad. With Unix on the other hand, those Unix admins are often not that cooperative to do it in similar way. Those are pushing the application like a Oracle DBMS should solve it all no bothering for work at their area.  When this is on you SAS area the situation you are in big (data) troubles. May be that MarkNicholas his real issue.

When you can switch to another privileged key using sudo you are safe on the compliancy. The SAS STP and PWS are the ones having issues and causing audit issues.


With inbound logins you can build process to add users. Adding a user that already exists is just a bad idea. 

For outbound logins that making a connection to another external source the situation is more complicated. For those you need authdomains as you cannot guarantee the uniqueness of keys over all external resources as it is defined external.

---->-- ja karman --<-----
MarkNicholas
Obsidian | Level 7

Yes Jaap, as you correctly identified , it is the problem for me. Some not very good maintenance from unix team lands us in trouble.

Now, to resolve the above:

Ideally, I am just supposed to automate to import new account details into my MC using a modified importpw.sas program, but because of these already existing logins with some another descriptions, I have to do the weird way of identifying new accounts by exporting the user list and comparing. Cant help but to write few extra lines of code.


ronan
Lapis Lazuli | Level 10

It depends whether you want to synchronise every user account or some of them only, in other words does the scope of your syncho process involves a restriction list ? The %MDUCMP user import macro can take into account such exceptions list.

In order to run safely the synchronisation task based on "importpw.sas", you should then procede in 3 or 4 steps :

1. backup your metadata

2. define your exceptions list, if any. This might require updating the user account 'external identity' information with the SMC (General Tab)

3. purge every user account registered in metadata  - proc metadata, metadata data step or manually using SMC  - excepted the above mentioned exceptions in addition to the @saspw default technical accounts !

4. run the syncho code once, then regularly.

The initialisation step no.3 should prevent any conflict with existing accounts.

Now, as regards the authentication process, take care to use one source directory and only one for your users account. Having two or more competing authentication domains

for your user accounts is not recommended, ACFARRER above asks a good question : you might also strongly consider isolating service accounts with a specific Auth. Domain.

Have a look at this clear-cut paper by Charyn Faenza, presented at the last Global Forum,even if it adresses Windows authentication issues, it could be helpful for Unix/Linux as well :

3479 - SAS® Metadata Security 101: A Primer for SAS Administrators and Users Not Familiar with SAS

https://sasglobalforum.activeevents.com/2015/connect/fileDownload/session/9CF651E6B76F88D03DC9B600BB...

jakarman
Barite | Level 11

Ronan, that is a nice paper as it clearly defines the Authentication Authorization and Audit goals being different. Would like SAS would promote that as required understanding before going into architecture and design.
The DBMS security as the DBA being in control of that. Mentioning all the OS layers being in control for access. So far so good. High privileged accounts - service accounts are NOT mentioned avoiding the use of shared accounts is NOT mentioned.

Anyway it is Windows where the admins are used to personal users on the OS level as shown by the figures showing the sasusers structure. This point is exactly where Unix/Linux admins are having their troubles (not accepting personal users).

Back to the service accounts. When you have SP or PWS defined or a batch server those shared ! service accounts (outbound) are stored in "general servers" group. No not at the account definition but at the group.
The bad thing is you can do a login (inbound) with those shared accounts at the group level. There can be a need for that as being the owner of the data. 

It is also possible to store shared outbound accounts at groups. SAS(R) 9.4 Management Console: Guide to Users and Permissions

Having all accounts with SAS is an option to avoid business security compliancy. The avoiding of that compliancy is easy at installing but not really sensible.    
  

---->-- ja karman --<-----
ronan
Lapis Lazuli | Level 10

Jaap Karman wrote:

...

Back to the service accounts. When you have SP or PWS defined or a batch server those shared ! service accounts (outbound) are stored in "general servers" group. No not at the account definition but at the group.
The bad thing is you can do a login (inbound) with those shared accounts at the group level. There can be a need for that as being the owner of the data.

this relates to the uniqueness constraint stated above: a login must be unique in metadata, so that it woulnd't be possible to add the same service login to every user account as a supplementary (outbound) login; the same generic service login must be shared at group level which is a  better solution (less faulty, easier to track & change, more secure). I am not sure being able to do a login in metadata using this kind of special account is a bad thing. Internal sessions in metadata are based on those connections. The distinction between inbound and outbound login is controlled by Authentication Domains, which means security scope really. A service account defined with a proper Authentication Domain won't do much harm imho. Of course, this can be very damaging in the wrong hands : just think of sharing a service account with a unrestricted Group of users; this opens the possibility of impersonating an unrestricted admin if the service account credentials are known to the bad guy.

jakarman
Barite | Level 11

Ronan, There is some difference with Windows and Unix(Linux). The Unix environments are heavily relying on the security as being set by the "owner". That is best implemented by a service account associated with a group (same name).  This makes actions by that "high privileged service account" a key factor  in the data-governance. You will need access to that using sudo ("runas") and having monitored that switched access.
The mentioned service-accounts within the metadata are playing that same role but sadly the password is in the metadata. That is breaking normal governance rules on data security. I you would connect data (import the sas metadata it becomes more weird. Starting that action from SMC you have to login using that password.  Running a batch-process with that identity on the OS will bypass the authentication stages as it trusted (no login, immediate connect). You could run a batch job using sudo with that.


Coming from Windows that concept of ownership looks strange, but windows is using that too Takeown . It are security admins having taken the overruling options for that setting security  centrally managed. Unix is lacking that.    

The authdomains in SAS are doing some segregation of administration, and that is the best description to give it are security domain administrations. Often being wrong interpreted as some tool segregation. oracelauth is an example of that confusion. Within the SAS metadata there is no real physical segregation of outbound and inbound logins. That difference has been missed from the start of that design. Would they have been physical segregated you would not see those trusts working. The unrestricted admin key can be found in config-files and that encoded string can be used in sas coding without knowing the real password. Just copy/paste that string.
Yep that can be damaging when in the wrong hands. 


 

---->-- ja karman --<-----

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 8 replies
  • 2096 views
  • 3 likes
  • 4 in conversation