BookmarkSubscribeRSS Feed
lavi
Calcite | Level 5

Hi All,

I am new to SAS and trying to add login for our DB so that users can access the DB seamlessly. When I try to do that I get the following error "Cannot add login. userid is already used by another user or group". We are using the same user id for Prod environment but want to use it for UAT environment also . As per excerpts from SAS documentation shown below I should be able to use the same ID as long as I am using different domain. Is this really possible ?

"If you give a user two logins that contain the same user ID, the logins must be in different authentication domains. Within an authentication domain, each user ID must be unique. For example, if you give Tara O'Toole two logins that both have a user ID of tara, then you cannot associate both of those logins with the OraAuth authentication domain. As with the previous requirement, this requirement is case-insensitive and is applied to the fully qualified form of the user ID. "                  

7 REPLIES 7
jklaverstijn
Rhodochrosite | Level 12

Hi Lavi and all,

This question was never answered. There is a similar thread () that also was not answered, at least to my satisfaction. I would like to get some attention to this again as I am struggling with the same.

The quote in the original post holds, but only for a single group. So if you have Lara in authdomain OracleProdAuth and authdomain OracleDevAuth than both logins can be defined for group A but not one in group A and the other in group B. I would argue both logins are not the same in both cases and it should be allowed. My thought: just because the accounts sound the same doesn't mean they are.

So I hope someone can shed some light on these matters, either regarding the ratio behind this behaviour or a solid approach.

jakarman
Barite | Level 11

Hi jan en allemaal.  Nou niet blijven worstelen Jan, het zit gewoon echt fout.

Nice to see as it seems to be this issue is still not solved.  Would have amazed me as it looks to me as design error not getting attention.

Some stubbornness at the SAS side.

Let me see and try to explain:

- The authentication domain is a domain concept not one of  some tooling.

  LDAP AD and more of those kind are implementing identity management and they are the references for some security domain (RBAC proces).      

  Within that segregation a user-id can be member of many domains (0-*). Within a domain each user is unique (0-1).

  This relationship is important.    

- The naming of an authenticationdomain can become a misleading one.

   It is not the type of DBMS a department or even a persons name, it should reflect the responsibility of the identity management staff conventions.

   Yes thre are still locations with a DBMS-DBA hero isolated from the business. Expect that to be stopped when the security and auditing on security will become more strict.

   (Jan that are for NL; NEN 7510,7511 US Hipaa and more generic ISO/IEC 27001 27002)

   With Oracle Authentication can be set up as a LDAP one. The Idnetification Autentication wil be still internal Oracle approaches. Oracle Lightweight Directory Access Protocol (LDAP)

- Authdomain with SAS is NOT implemented conforming those principles.

  There is a Login table part of the metadata database. All id's are stored there an the real logical name that you see is some attribute of a field. (you can rename user-ids)

  The check on uniqueness of that logical name and memberships is not done correctly. A seen it is requiring uniqueness over all domains not in everyone isolated.

  I had the fist experiences with this even requiring inbound and outbound logins could not be the same.

  For auditing reasons it should be verified and clear the id cannot be used outside you personal one.

  The authdomain however can be inherited from other metadata objects (group accounts) without being aware. Group accounts should be avoided with auditability traceability

- Are you using OS service accounts like Stored Process,  Pooled Workspace than the preassigned libraries will not able the ones having the personal security settings.

  It is weird to see SAS is trying the overrule the external security by using groups accounts taking the responsibility away from those owners and trying to implement it by themself.

  This will lead to a true bashing of SAS by security people because SAS is needing all that access rights.

---->-- ja karman --<-----
JasonAmoratis
SAS Employee

Hello Jaap,

Have you tried setting the authentication Domain to outbound only for both auth domains that generate the conflict?

SAS MC> Server Manger / Properties > Authentication Domains

jakarman
Barite | Level 11

Jason, please explain your question.  For the auth-domains you will find in the sas- docs examples like oracle that is a tool naming not a domain naming.
You could possible integrate local managed installations by eg LDAP.  By that all tools will go into one security-domain. -> Avoid the naming associated to tools.

When this association by tools happens (made wrong decision) you can get into that several external security providers are sharing the same authdomain. when both are setting policies using the same accounts with different policies you have a confliction situation by the logical flow of information.   

The other nasty problem is also a logical one. You can design processes using a shared account to be used (SP WS) at he moment you needing to do some updates at setting OS security or updating some shared files you login (DI Eguide) with that shared "high privileged" account. You will get the security setting as valid for "general servers".

The question of Jan is related to release management (vertical line DTAP SDLM ALM) not the be confused with version management (horizontal line development). 
Mixing operatios (OracleProdAuth P) and developers (oracleDevAuth D) with test data and production data in the same metadata-database is not a very good approach. Do you know the contents of those ISO 27002:2013 guideline? Starts after 27001  It is about risk-management, an introduction to that could be: Cybersecurity and Managing Risk   The first action is building a simple normal defense ....  (than get to 14.2.2 of 27002).   

---->-- ja karman --<-----
jklaverstijn
Rhodochrosite | Level 12

Hi Jason,

Thanks for pointing this out. Outbound authentication domains are new in 9.4M2 and judging by the docs alone (didn't test yet) this would be the solution to the problem. Personally this has been puzzling me since probably 9.1. Patience is a virtue.

Many Thanks

-Jan

Stephane
Quartz | Level 8

Hi Jan,

just to confirm you that the Outbound authentication domains is the solution. I use two domains with the same login to access to 2 DB servers. It worked immediatly.

Have a nice day.

Stéphane.

bheinsius
Lapis Lazuli | Level 10

Hi,

 

I have one 94M3 environment that does not allow two domains with the same login without setting Outbound to Yes.

I have another 94M3 environment that does allow two domains with the same login without setting Outbound to Yes.

 

What can be the difference?

 

Bart

 

 

sas-innovate-2024.png

Join us for SAS Innovate April 16-19 at the Aria in Las Vegas. Bring the team and save big with our group pricing for a limited time only.

Pre-conference courses and tutorials are filling up fast and are always a sellout. Register today to reserve your seat.

 

Register now!

SAS Enterprise Guide vs. SAS Studio

What’s the difference between SAS Enterprise Guide and SAS Studio? How are they similar? Just ask SAS’ Danny Modlin.

Find more tutorials on the SAS Users YouTube channel.

Click image to register for webinarClick image to register for webinar

Classroom Training Available!

Select SAS Training centers are offering in-person courses. View upcoming courses for:

View all other training opportunities.

Discussion stats
  • 7 replies
  • 4552 views
  • 0 likes
  • 6 in conversation