Hello, thanks for the explanation.
On Sun, Nov 12, 2023 at 6:55 PM Shawn McKinney <[email protected]> wrote: > > > > On Nov 10, 2023, at 10:28 AM, Veniamin Gvozdikov < > [email protected]> wrote: > > > > Hello. > > > > I have some services which use ldap to login over ldap like scripts or > > daemons. What is the best way to define service accounts with Fortress > RBAC > > schema? The ou=People looks not relevant for that task and no one exists > > like ou=Services for services. > > > > Currently, fortress specifies user entry location in its config: > > ``` > # RBAC Users: > user.root=ou=People,dc=example,dc=com > ``` > > And so if you placed service accounts under ou=Services they wouldn’t work > with the Fortress API. > > Do the services need to use Fortress API for checks? Is there a reason > the accounts must be in a separate container? > Possible both for some accounts like cron scripts use fortress api and some applications like postfix use direct access to openldap. Is it possible to remove objectClasses like inetOrgPerson, ftUserAttrs or add/replace classes to avoid being a person for ou=People? > > You may of course create a new container and place service accounts in > there. Won’t cause any problems and follows an established convention of > separating users from service accounts. > > It’s fine, but just a convention. You may place these accounts with the > others (ou=People) and that’s OK too. There are ways to harden a fortress > account so that it behaves like a service account. > > One is by setting more restrictive password policies. Two there is a flag > that prevents changing its password. Three it can be issued admin roles > which apply separate policies (more restrictive, powerful, etc). > > — > Shawn > > > -- > > Regards, > > Veniami > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Regards, Veniamin
