Morning all,
AD connector and the service account returns this error when I try to move a user between OUs.
I’ve done this 50 times in the last few months so the process is fairly nailed down.
I know that the error is a permissions based one, but if I log onto the IQserver using the service account credentials, I can move an account in and out of OU=user/disabled users, I can also enable/disable accounts. The service account is a member of Domain Admins (as per company policy) and has full permissions.
Struggling to understand what could be wrong as it works on the server, but not via Sailpoint. (NB aggregation and test functions work fine from Sailpoint)
Could there be an ACL on port 5052?
Hello @phil_awlings ,
Does service account able to perform other operation like create, disable, delete from SailPoint? or its just with the update account (i.e. OU move)?
The create profile hasn’t been written. The client is only interested in disable/enable and move in/out of the OUs.
I’ve tried removing the AC_NewParent part of the enable process to narrow it down. But it won’t enable the account by itself.
There are no issues if I log onto the server directly using the service account.
The problem appears to exist between Sailpoint and the IQserver, but not enough to stop the TEST connection function to stop working.
Hi @phil_awlings What account are you using on the AD connector? My assumption is moves are done via LDAP rather than IQService.
I may be asking the basic question, does that service account is member of “account operators” groups even though it is member of domain admins?
Its a good question. However, Account Operators doesn’t have the same level of permissions as Domain Admins, so its not that issue
Hi,
I’m using the service account ‘svc_sailpointIDN’. Which has domain admin privileges.
I’m using the ‘UPDATE’ profile to move enable/disable the accounts and AC_NewParent to move OUs.
There is nothing different, from a build perspective, that I haven’t done 50+ times in the last few months. Looking for some out-of-the-box thinking.
I’ve even just deleted the whole IQservice and re-installed it incase some corruption creeped in
Thanks @phil_awlings Just to confirm: that’s the Service Account as set on the Domain Settings, rather than the one which runs the IQService?
There are two service accounts, one connects to the DC (with no privileges) and one runs the IQservice (with domain Admins)
Hi @phil_awlings My understanding is that the Domain Settings account would be used for an OU move. Maybe try adding the IQService account to Domain Settings for a quick test?
That worked, and it shouldn’t have.
We have to have two different service accounts as domain admins are not permitted to ‘log on as a service’ on to the DCs.
That server/connector was set up exactly the same as the other 50+ ones, all of which will not work if the service account on the domain settings page has domain admin rights
Thanks. That was not anything that I would have tried
I wouldn’t necessarily give it domain admins, will need create and delete accounts permissions for a move.
GSOC has requested that it have domain admins rather than account operators so that Sailpoint can managed users who have enhanced privileges.
Sounds like you’re using default groups; I wouldn’t necessarily go down that route (from a least privilege perspective), but up to you I suppose.