Architecting, installing and maintaining your SAS environment

Best Practice: Internal User for Work Repository in DI

Accepted Solution Solved
Reply
Occasional Contributor
Posts: 10
Accepted Solution

Best Practice: Internal User for Work Repository in DI

I am creating a work repository for the first time DI Studio 9.4.2.

 

I attended the DI Studio Fast Track training and so have very good documentation on how to do this from the course materials.

 

Here is my question. I wear two hats in my company, I am the Administrator for our SAS data warehouse, and I am also the lead developer.

 

Therefore I have my administrator login, which uses the DefaultAuth Authentification Domain and is tied to my network login for pass through authentification.

 

I want to create a second Login for myself which I will use when wearing my developer hat. I am reluctant to use the same authentification as my administrator account as I am not sure what hidden, to me at least, consequenses of doing so there might be.

 

So I was considering creating an internal user for my developer account. Would this be a safe and acceptable solution?

 

Also, do I even need to worry about using my netowrk login user for authentication both accounts?

 

EDIT: As I am reading through this it accurs to me that a possible problem with using an internal user for the developer account will be database authentification for our Oracle and SqlServer databases.

 

What is the best procatice for what I am trying to do. My main reason for wanting the developer account is so that I can use a work repositiry, which I am sure is a best practise for a developer in DI Studio. At least it will be in my shop.


Accepted Solutions
Solution
‎06-06-2017 07:20 PM
Trusted Advisor
Posts: 1,312

Re: Best Practice: Internal User for Work Repository in DI

Hello @gsmith

 

If the "hats" is the procedure in your company (as in many others), probably you can get a normal OS account and an admin OS account. This should also be the way to move forward.

 

If this is not possible on any way, I would recomment you 2 SAS metadata accounts:

 

- Admin: just an internal account, to manage the metadata, part of SAS Administrators (I guess). Beware you won't be able to run code, unless it is an stored process or such, since SAS requires an OS account to run code on the Workspace Server.

 

- Developer: since a developer actually needs to run code, this SAS metadata account could have the OS account as login, and restricted roles and permissions in the metadata (and the OS, to be coherent).

 

This would mean your OS account should have restricted access to the OS... which does not make much sense, since you are an admin. Therefore, since your OS account is admin, your developer SAS account would have restricted on the metadata, but extended permission on the OS. Therefore, a hint: careful.

View solution in original post


All Replies
Super User
Posts: 5,426

Re: Best Practice: Internal User for Work Repository in DI

I don't think that an internal account will do. As a developer you need to execute code on a workspace server and for that you need an OS account.

If your admin role requires you to do stuff outside SAS metadata, then I think a best practice would be to a new OS account for that role.
Data never sleeps
Occasional Contributor
Posts: 10

Re: Best Practice: Internal User for Work Repository in DI

Thanks, that makes sense.

 

So a follow up question, would it work to have two accounts which use the same OS identification.

 

Such as 

 

SASloginadm for SAS user (Admin) and OSloginABC for authentication

 

SASlogindev  for SAS user (Dev) and OSloginABC for authentication

 

For compliance reasons we track user access to our buisness system. Having multiple OS logins would not work.

Solution
‎06-06-2017 07:20 PM
Trusted Advisor
Posts: 1,312

Re: Best Practice: Internal User for Work Repository in DI

Hello @gsmith

 

If the "hats" is the procedure in your company (as in many others), probably you can get a normal OS account and an admin OS account. This should also be the way to move forward.

 

If this is not possible on any way, I would recomment you 2 SAS metadata accounts:

 

- Admin: just an internal account, to manage the metadata, part of SAS Administrators (I guess). Beware you won't be able to run code, unless it is an stored process or such, since SAS requires an OS account to run code on the Workspace Server.

 

- Developer: since a developer actually needs to run code, this SAS metadata account could have the OS account as login, and restricted roles and permissions in the metadata (and the OS, to be coherent).

 

This would mean your OS account should have restricted access to the OS... which does not make much sense, since you are an admin. Therefore, since your OS account is admin, your developer SAS account would have restricted on the metadata, but extended permission on the OS. Therefore, a hint: careful.

Occasional Contributor
Posts: 10

Re: Best Practice: Internal User for Work Repository in DI

Posted in reply to JuanS_OCS

I just looked at the SAS Administrator account which was used during the install and which we used to set up all the accounts/authentications/permissions originally.

 

It is set up as an internal account. I was able to use it to do all the administrative actions early on, so I think that is the approach I will use. Set up a new administrative account as an internal one, and change my current admin account, which has OS rights, to my development account.

 

I'll check back when I am done and update how it worked out.

Occasional Contributor
Posts: 10

Re: Best Practice: Internal User for Work Repository in DI

After creating the accounts as indicated above, I've been using both fa a couple days and I have not had any issues.

 

Looks like @JuanS_OCS gave good advice. I marked his post as a solution.

 

Thanks everyone.

☑ This topic is solved.

Need further help from the community? Please ask a new question.

Discussion stats
  • 5 replies
  • 240 views
  • 3 likes
  • 3 in conversation