Hi everyone,
I'm importing users and groups from our Active Directory using the importad.sas sample code and ran into this error:
"ERROR: An AuthenticationDomain named DefaultAuth already exists in this server."
Even after modifying the code to use %mduchglb intead of %mduimplb, I'm still getting the same error message. There are no observations in the errors table but one observation in the faildobjs table.
The faildobjs table has one observation with the objtype AuthenticationDomain, name DefaultAuth, and chgtype A.
Has anyone encounter this issue? What was the resolution? Any help and guidance would be greatly appreciate.
Here's the part of the code that is throwing the error:
%macro Execute_Load;
/* if the _EXTRACTONLY macro is set, then return and don't do any load processing. */
%if %symexist(_EXTRACTONLY) %then %return;
%mduchglb(change=change, temp=work, failedobjs=error.faildobjs,
extidtag=&ADExtIDTag);
%mend Execute_Load;
%Execute_Load;
Are you doing an initial load or synchronization? There is sample synchronization code in the SAS documentation here: https://support.sas.com/documentation/cdl/en/bisecag/67045/HTML/default/viewer.htm#p0z36im6qsfk3ln1a...
If you are combining importad.sas with %mduextr to extract existing identities from SAS and then %mducmp to generate the change data required for %mduchglb to apply the changes, then it should have detected the existing DefaultAuth authentication domain and not generated the corresponding add record. I would start backtracking through the tables looking for where the problem is. Start with the AUTHDOMAIN_ADD change table - I assume it has a record for DefaultAuth (which it shouldn't). The target AUTHDOMAIN table? - it should have DefaultAuth. Then the source AUTHDOMAIN table should also have DefaultAuth. It should be in both source and target AUTHDOMAIN tables and %mducmp should then decide it doesn't need to add it. I would cast an eye over your login tables to make sure you are seeing correct change data for those too.
If, after walking through the process, it is not immediately clear where the problem lies then you might consider contacting SAS Professional Services or a local SAS Partner in your area. They will have done lots of these. My company Metacoda also has a commercial point and click plug-in for SAS Management Console to make it easy to do AD synchronization with no code. I wrote a blog post about it a while back with a screencast showing it in action: https://platformadmin.com/blogs/paul/2015/07/synchronizing-sas-platform-identities/
I hope this helps.
Are you doing an initial load or synchronization? There is sample synchronization code in the SAS documentation here: https://support.sas.com/documentation/cdl/en/bisecag/67045/HTML/default/viewer.htm#p0z36im6qsfk3ln1a...
If you are combining importad.sas with %mduextr to extract existing identities from SAS and then %mducmp to generate the change data required for %mduchglb to apply the changes, then it should have detected the existing DefaultAuth authentication domain and not generated the corresponding add record. I would start backtracking through the tables looking for where the problem is. Start with the AUTHDOMAIN_ADD change table - I assume it has a record for DefaultAuth (which it shouldn't). The target AUTHDOMAIN table? - it should have DefaultAuth. Then the source AUTHDOMAIN table should also have DefaultAuth. It should be in both source and target AUTHDOMAIN tables and %mducmp should then decide it doesn't need to add it. I would cast an eye over your login tables to make sure you are seeing correct change data for those too.
If, after walking through the process, it is not immediately clear where the problem lies then you might consider contacting SAS Professional Services or a local SAS Partner in your area. They will have done lots of these. My company Metacoda also has a commercial point and click plug-in for SAS Management Console to make it easy to do AD synchronization with no code. I wrote a blog post about it a while back with a screencast showing it in action: https://platformadmin.com/blogs/paul/2015/07/synchronizing-sas-platform-identities/
I hope this helps.
Thank you very much for your advice. I was able to find where the issue was while backtracking the tables. Correcting the code allow the initial load of users and groups to be loaded. It was a relief to see it in management console.
No problem. Thanks for reporting back and marking the question as solved.
Registration is now open for SAS Innovate 2025 , our biggest and most exciting global event of the year! Join us in Orlando, FL, May 6-9.
Sign up by Dec. 31 to get the 2024 rate of just $495.
Register now!
See how to use one filter for multiple data sources by mapping your data from SAS’ Alexandria McCall.
Find more tutorials on the SAS Users YouTube channel.