On-Prem Dev, Prod, and Lifetime Server: Allow IT Users to Manage End Users

On-Prem Dev, Prod, and Lifetime Server: Allow IT Users to Manage End Users

  

This might be a silly question, but I had to go into the DB to reactive the admin user created by our first app in the dev environment.  I am one of several "IT Users" with Administrator (not just Developer) privs in a local on-prem deployment of 10.0.816.0 with Lifetime configured to manage application lifecycle in dev and production environment.  Neither I nor any other user with Administrator privs could go into DEVSERVER.domain.tld/Users/.  I know that is the default, and that is fine, but is there some form of configuration I ought to do such that we can log in and manage usership in the dev and/or prod environment?  Is there a setting I missed?


Again, to be clear, 10.0.816.0: 1 Dev Env Server (frontend + controller), 1 Prod Env Server (frontend + controller), and 1 Lifetime Server.  Using local authentication, will not use AD or LDAP for this eval yet.  Thanks.

Did any of those users had the UserManager (?) role assigned? Also, you can "assign" the SuperUser (?) role and it will automatically assign you every role created across the environment. This information is related to the Users created within the UserProvider eSpace since LifeTime users are managed on the ServiceCenter eSpace provider. 

The default "Admin/Admin" user has this UserManager role.


Let me know if this helps,

Cheers!

Armando Gomes wrote:

Did any of those users had the UserManager (?) role assigned? Also, you can "assign" the SuperUser (?) role and it will automatically assign you every role created across the environment. This information is related to the Users created within the UserProvider eSpace since LifeTime users are managed on the ServiceCenter eSpace provider. 

The default "Admin/Admin" user has this UserManager role.


Let me know if this helps,

Cheers!

Thanks, that I understand, but if I want to disable that, but allow Administrators in the ServiceCenter/ALM component interact with the apps (Users/MyApp1/MyApp2) or stuff inside an eSpace, how does that work?  That is not clear to me.


The interaction with the apps - assuming you're saying common app usage or, in other words, applicational users - is done by authorized users. These users belong to a user provider. The Service Center uses a different user provider than the default user provider (Users) for applications.


If you want to use the same users, you can either:

- Point the user provider of the eSpaces to the Service Center user provider

- "Clone" the users from Service Center user provider to the Users user provider.


Does this help? I'm struggling a bit in understanding the full scope of your request.


Cheers,

Armando

Armando Gomes wrote:

The interaction with the apps - assuming you're saying common app usage or, in other words, applicational users - is done by authorized users. These users belong to a user provider. The Service Center uses a different user provider than the default user provider (Users) for applications.


If you want to use the same users, you can either:

- Point the user provider of the eSpaces to the Service Center user provider

- "Clone" the users from Service Center user provider to the Users user provider.


Does this help? I'm struggling a bit in understanding the full scope of your request.


Cheers,

Armando

Ok, that makes sense.  I am concerned because this admin user is created by default and documentation instructs not to remove it.  I was curious how to have one ServiceCenter operations admins control app user state.  It is still early days, so it is not a huge deal.  It just means multiple accounts now and I have to clearly explain to staff how and why that works.  Also, some documentation in a simple one server system versus our managed Lifetime server gets confusing.

Keep the admin user but change the default password. Ideally, use "named users" so you can have a proper auditing over what was done :)

Armando Gomes wrote:

Keep the admin user but change the default password. Ideally, use "named users" so you can have a proper auditing over what was done :)

Yeah, that's a no brainer, but I need to be worried about production deployment of apps and this default admin user created and seeding this admin user if pushed to the  prod environment.  It will seed that admin user, right? What then?

Solution

If you have an infrascruture with LifeTime, the users are "shared" across environments. So if you change the admin user in LT, it will be changed everywhere - as far as I'm aware.


If you don't have LifeTime, each environment has their own default admin user. You'll have to change the password in every environment.


Hope this helps.

Solution

Armando Gomes wrote:

If you have an infrascruture with LifeTime, the users are "shared" across environments. So if you change the admin user in LT, it will be changed everywhere - as far as I'm aware.


If you don't have LifeTime, each environment has their own default admin user. You'll have to change the password in every environment.


Hope this helps.

Ahhh, ok.  This makes some more sense.  I will test more thoroughly.  This deployment is very nascent and we are currently evaluating.  I will play more this week.

Thanks again for your help.


No problem Alexander. Just let me know if any other question comes by or just post on the forum. We'll be glad to help! :) Hope you enjoy OutSystems!