BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
mwong
Fluorite | Level 6

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;

 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
PaulHomes
Rhodochrosite | Level 12

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.

View solution in original post

3 REPLIES 3
PaulHomes
Rhodochrosite | Level 12

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.

mwong
Fluorite | Level 6

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. 

PaulHomes
Rhodochrosite | Level 12

No problem. Thanks for reporting back and marking the question as solved.

sas-innovate-2024.png

Don't miss out on SAS Innovate - Register now for the FREE Livestream!

Can't make it to Vegas? No problem! Watch our general sessions LIVE or on-demand starting April 17th. Hear from SAS execs, best-selling author Adam Grant, Hot Ones host Sean Evans, top tech journalist Kara Swisher, AI expert Cassie Kozyrkov, and the mind-blowing dance crew iLuminate! Plus, get access to over 20 breakout sessions.

 

Register now!

Tips for filtering data sources in SAS Visual Analytics

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.

Discussion stats
  • 3 replies
  • 1648 views
  • 2 likes
  • 2 in conversation