Best Practice: Internal User for Work Repository in DI

[gsmith]

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.

[LinusH]

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.

[gsmith]

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.

[JuanS_OCS · Accepted solution]

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.

[gsmith]

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.

[gsmith]

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.