Using multiple Active Directory endpoints with 1 connection

[aundreb]

Hello,

I have a scenario where I need to create two different account types(regular and privileged) for users under the same Active Directory domain. These accounts will have different naming conventions.

What is Saviyn'ts best practice for handling such a situation?

Is it better to create two endpoints then from within the connection use ACCOUNTNAMERULE to send regular and privileged accounts to different OUs based on an endpoint condition(not sure if possible)

OR

Is it better to just have separate security systems, endpoints, and connections for different account types even if they are pointing to the same AD domain?

[rushikeshvartak]

If user can have only 1 account then go with 1 Endpoint.

• Use Dynamic Attribute and maintain account name logic in Connection

If user can have more than one account then go with 2 Endpoint

• Maintain account name in Endpoints

[aundreb]

Hi Rushikesh,

This doesn't really answer my question as to what is a best practice. The users can potentially have two different accounts regular and privileged(essentially an admin account) within the same domain.

Question is more so along the lines of is it best practice to use 1 connection and two endpoints for each account type or use a separate connection, endpoint and security system for each account type.

[rushikeshvartak]

Its always better to use 2 different connection 

[Kerasit · Accepted solution]

I know this is an older threat, but for keeping it simple yet as Saviynt is a security and governance product, then managing/governing stuff like orphan accounts, then goin with one connector, marking/tagging accounts and correlating them in the same connector instead of spreading it and having essentially two-three copies of the same objects in two-three "different" endpoints, is a rather important thing.
We have in our development environment, because our implementation partner used this excact solution with having two connectors to same domain, two full copies of entitlements and accounts. This is rather annoying when building roles and looking for entitlements. The reason is that in order to NOT have two full copies, we needed to scope and filter what we would like to import, which effectually makes governance pointless, as any rogue account deviating from expected naming and data convention, is basically just not imported. This makes stuff like Orphan account management a worthless joke. Only other solution is to make:

1. Connector for "regular" users and groups. Filter: Only excactly matching specifics.
2. Connector for "Privileged" users and groups. Filter: Only excactly matching specifics.
3. Connector for "everything else" users and groups. Filter: NOT matching "regular" AND NOT matching "privileged" AND not matching dn of either of the first two.

This is rather ridicouless and would be much mroe powerfull with one connector:

1. Import ALL users and Groups.
2. Tag accounts according to filters or rules.
3. Tag groups according to filters or rules.
4. Everything else is "orphan", hence is subject to analytics, certifications and reporting.
5. Make more rules to fit for serviceaccounts and other types.

All in same connector, and very generic to maintain. Best of all? Only one LDAP connection and data exchange.

[rushikeshvartak]

When you keep same security system and endpoint . You will find maintenance as well as configuration issues

[Kerasit]

Sure. I am aware that this is how Saviynt has designed it, but it is a bad design. Very bad design.

[aundreb]

I agree, it isn't a very good design. I tried to do it from one connector, but with the manual endpoint filtering you would have to do then all the logic needed to provision different accounts to different DNs I decided it was easier just to do the separate connection. Shouldn't be this difficult, as it is the same domain.

[Kerasit]

It is not that I disagree that this is the approach which makes sense in respect to how this product has been designed and build. However I was hoping there where others out there concerned about the very central task of IGA: Governing Identity Policies, and especially deviations from expected state. For this, the product is creating obstacles for itself, so I was hoping some had solved it.