> On Nov 13, 2023, at 11:54 AM, Veniamin Gvozdikov
> <[email protected]> wrote:
>
> 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.
Yep, makes sense.
> Is it possible to remove objectClasses like inetOrgPerson, ftUserAttrs or
> add/replace classes to avoid being a person for ou=People?
Fortress will ignore any entries that don’t use its schema (objectClasses,
attrs)
It is possible for name collisions if they share the same relative
distinguished name (rdn).
But, if you choose different rdn, say cn for a service account (vs uid), then
that can’t happen.
So, yes, you may store any entries under containers that fortress uses. Things
like service accounts, ldap groups, unix groups may all be stored alongside
fortress entries.
You may also apply different password policies to service accounts vs user. A
good way to enforce the separation at the system level.
--
Shawn
>
>>
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
