BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
MarkNicholas
Obsidian | Level 7

Hi All,

 

We newly setup SAS 9.4 and I have an issue with Login password not getting updated in SAS Management Console.

Details :

 

Let us say along with DefaultAuth I have multiple logins specified in my user account properties for different Auth Domains (like Oracle, Teradata).


OracleAuth <user-id> <password>
TeradataAuth <user-id> <password>

 

For your reference, I am using the below program which helps retrieves the account id and encrypted password of the provided Authentication Domain.

 

%macro Auth(AuthenticationDomain);
%global Password UserID;
data _null_;
   length uri UserId Password UserId AuthId AuthenticationDomain $256;
   rc=metadata_getnobj("omsobj:AuthenticationDomain?@Name='&AuthenticationDomain'",1,uri);
   rc=metadata_getattr(uri,"Id",AuthId);
   rc=1;
   tn=1;
do while(rc>0);
    rc=metadata_getnasn("OMSOBJ:AuthenticationDomain\"!!AuthId,"Logins",tn,uri);
     if rc>0 then do;
        arc=metadata_getattr(uri,"UserID",UserID);
        arc=metadata_getattr(uri,"Password",Password);
        call symput("UserID",compress(UserID));
        call symput("Password",compress(Password));
     end;
     tn=tn+1;
end;
run;
%put NOTE: For AuthenticationDomain &AuthenticationDomain., the UserID &UserID has password &Password.. Executed as &sysuserid..;
%mend;

 

Execute:

%Auth(TeradataAuth)

 

When I updated Login detail in the account as


TeradataAuth  ABC  mypass1

 

The macro gives result as
NOTE: For AuthenticationDomain TeradataAuth, the UserID ABC has password {SAS002}ABCD3. Executed as Mark

 

When I updated Login detail in the account as


TeradataAuth  ABC123  mypass2

The macro gives result as
NOTE: For AuthenticationDomain TeradataAuth, the UserID ABC123 has password {SAS002}ABCD3. Executed as Mark

 

Which means the password I am giving is not updated at all but the change I made to user account works. Please help to resolve this issue.

 

Thanks
Mark

1 ACCEPTED SOLUTION

Accepted Solutions
PaulHomes
Rhodochrosite | Level 12

Is the logged password {SAS002}B6535B5C02BB1BC110FD31944FC989D3 by any chance? If so, that's the pwencoded version of 8 asterisks:

 

proc pwencode in='********';
run;

 

... which indicates the metadata query is not being given the real encoded password by the metadata server.

 

I'm guessing that the user Mark has user administration capabilities being a member of the Metadata Server: Unrestricted role or the Metadata Server: User Administration role - possibly via SAS Administrators group membership. Is this correct? Someone who is a user administrator has the ability to see all logins and so is restricted from fetching real passwords from metadata. Does it work when you try it a normal non-administrative user? Your code works for me when it is not run as a user admin (and no cache clearing is required).

 

BTW what are you using this password for? If it's on a libname statement have you consider using the authdomain option and let SAS find the appropriate login (and if there are multiple logins available it will include logic to pick the one closest to the user in their identity hierarchy which the code above does not). See http://blogs.sas.com/content/sasdummy/2010/11/23/five-strategies-to-eliminate-passwords-from-your-sa...

View solution in original post

5 REPLIES 5
PaulHomes
Rhodochrosite | Level 12

Are you running that second query in the same SAS session? Have you tried running it in a new session? Do you still get the old encoded password? The metadata query functions cache metadata. I haven't tested to see if it caches across data step boundaries, but if you find that running the query in a new session returns the new encoded password then you might want to look at the METADATA_PURGE function to clear the cache before your second query.

MarkNicholas
Obsidian | Level 7

Hi Paul,

 

Actually I was supposed to use this TeradataAuth to connect to TD database by triggering jobs from LSF scheduler.
Since, my test job was failing multiple times even though I was changing password and even locking the teradata account, I came up with the above program to replicate this issue so that I can avoid locking the account on database.


Yes, the issue persists through multiple sessions (since issue was spotted on LSF which opens a new session everytime)

 

As I already showed that user id is loaded correctly; issue is with password alone, so by this I understand that cache is cleared well everytime.

My intention is to be able to trigger the job succesfully in LSF.

PaulHomes
Rhodochrosite | Level 12

Is the logged password {SAS002}B6535B5C02BB1BC110FD31944FC989D3 by any chance? If so, that's the pwencoded version of 8 asterisks:

 

proc pwencode in='********';
run;

 

... which indicates the metadata query is not being given the real encoded password by the metadata server.

 

I'm guessing that the user Mark has user administration capabilities being a member of the Metadata Server: Unrestricted role or the Metadata Server: User Administration role - possibly via SAS Administrators group membership. Is this correct? Someone who is a user administrator has the ability to see all logins and so is restricted from fetching real passwords from metadata. Does it work when you try it a normal non-administrative user? Your code works for me when it is not run as a user admin (and no cache clearing is required).

 

BTW what are you using this password for? If it's on a libname statement have you consider using the authdomain option and let SAS find the appropriate login (and if there are multiple logins available it will include logic to pick the one closest to the user in their identity hierarchy which the code above does not). See http://blogs.sas.com/content/sasdummy/2010/11/23/five-strategies-to-eliminate-passwords-from-your-sa...

MarkNicholas
Obsidian | Level 7
Thank you Paul for your expert solution.
Yes,it is pwencoded version of 8 asterisks and is in Unrestricted group.
It was resolved once access is changed.
I will also check to implement authdomain option.
Cheers
Mark
PaulHomes
Rhodochrosite | Level 12

No problem Mark. Glad to hear it's resolved. Thanks for marking the post as solved too.

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
  • 5 replies
  • 3562 views
  • 1 like
  • 2 in conversation