[midPoint] Fwd: switching from SQL server to Postgres

[Lubomir Marton]

Hi, 

Regarding to your use case to move users to an ou=”To Be Deleted” before it you should verify some important parts in configuration like: 
- outbound for attribute DN has exception to skip modify DN for users moved to an ou=”To Be Deleted” 
- in correlation are used attributes like samaAccountName or UserPrincipalName, do not use distinquishedName or dn attribute, 
- in connector configuration for uidAttribute use default value which is objectGUID, 
- for shadows has been used as primary identifier value of active directory attribute objectGUID. 

In case of any issue please send anonymized resource configuration to review. 

-- 
Lubomir Marton 
Identity Management Engineer 


From: "midPoint General Discussion" <midpoint at lists.evolveum.com> 
To: "Tony Tkacik" <tony.tkacik at evolveum.com>, "midPoint General Discussion" <midpoint at lists.evolveum.com> 
Cc: "Ashwill, Steven L" <sashwill at uillinois.edu>, "midPoint General Discussion" <midPoint at lists.evolveum.com> 
Sent: Tuesday, March 5, 2024 9:20:23 PM 
Subject: Re: [midPoint] switching from SQL server to Postgres 



Found a solution by adding a helper bean to the context and calling an external method in it, but I would prefer an API or native solution you might say for the reason you said. 

Our use case is that one of the AD managers at a university in our system will move employees and students to an ou=”To Be Deleted” before midpoint is told about it. This is our attempt to find the matching records in the shadows so that midpoint doesn’t try to insert the record again on a reconcile. Unfortunately it does not work all the time. 




From: Tony Tkacik <tony.tkacik at evolveum.com> 
Sent: Thursday, February 29, 2024 2:29 AM 
To: midPoint General Discussion <midpoint at lists.evolveum.com> 
Cc: midPoint General Discussion <midPoint at lists.evolveum.com>; Ashwill, Steven L <sashwill at uillinois.edu> 
Subject: Re: [midPoint] switching from SQL server to Postgres 





Hi, 
what is your use case for these queries? Maybe there is better supported API for your use case instead of relying on implementation details which may change between releases. 




-- Anton Tkáčik Software Developer evolveum.com 





From: "midPoint General Discussion" < [ mailto:midpoint at lists.evolveum.com | midpoint at lists.evolveum.com ] > 
To: "midPoint General Discussion" < [ mailto:midPoint at lists.evolveum.com | midPoint at lists.evolveum.com ] > 
Cc: "Ashwill, Steven L" < [ mailto:sashwill at uillinois.edu | sashwill at uillinois.edu ] > 
Sent: Tuesday, February 27, 2024 9:54:58 PM 
Subject: [midPoint] switching from SQL server to Postgres 





This works when using SQL server. We have this code in one of our resources to query shadow records: 



SessionFactory sqlService = (SessionFactory) SpringApplicationContextHolder.getApplicationContext().getBean("sessionFactory"); 

Session session = sqlService.openSession(); 

try{ 

Transaction tx = session.beginTransaction(); 

Query dnQuery = session.createSQLQuery(query).addScalar(" name_orig ",StandardBasicTypes.STRING); 



When we switch to the postgres(native) version I get an error that the session is not found(column name changes to nameorig ). Should this work in native mode or how do I get a session? 



As always, any help is appreciated. 





STEVEN L ASHWILL 




_______________________________________________ 
midPoint mailing list 
[ mailto:midPoint at lists.evolveum.com | midPoint at lists.evolveum.com ] 
[ https://urldefense.com/v3/__https:/lists.evolveum.com/mailman/listinfo/midpoint__;!!DZ3fjg!_V_g3XFQ5JEpV4oDAluCNPdoxZbPp-ThwPrB9xN0ybAxVYLbNsKrKq9wm33lhbe8hr8CtNK4aH3j0qT2y5-xosLK6P0$ | https://lists.evolveum.com/mailman/listinfo/midpoint ] 

_______________________________________________ 
midPoint mailing list 
midPoint at lists.evolveum.com 
https://lists.evolveum.com/mailman/listinfo/midpoint 

-- 
Best Regards, 

Matus Macik | Developer and Identity Management Engineer 
matus.macik at evolveum.com | www.evolveum.com 
Evolveum 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20240410/bcd9047b/attachment.htm>