In the course of a major redesign of AD Domains at the site I work for, the question arose how to select only those users, which completely migrated to the consolidated domain.
It was impossible to just wait with moving these accounts into the groups, defined as source for synchronization, as it was equally impossible to delete these accounts from the "old" domains.
All in all, there was to be a fortnight overlap, during which accounts would be 'active' in both domains.
Now, it just proves there's yet another meaning to the word "Single" in Single Sign On server: the scenario described above will cause SSO/WNA to fail.
Which is understandable: upon inspection of the user credentials, two entries are found, and there's no way of telling which should be used (well, actually there is by inspecting the Kerberos ticket, but it is not implemented for good reason).
So: catch-22, rock-and-hard-place, etc...
First of all, I implemented separate synchronization profiles for users and groups. There are two blog entries: one on user synchronization, and another one on group synchronization.
Then, the filtering needed to be adapted in order to allow for a simple alteration of the contents of a field to signal completion. Now, I know filtering on basis of exsistance of objectclasses, but not really on the contents. Given some examples in the documentation, it sould be possible.
After some testing, I came up with:
(|(&(objectclass=user)(description=*oracle*))(isDeleted=TRUE))
This allows for Descriptions in Active Directory like "User has been granted access to Oracle", or just simply "oracle" - as long as there's the word "oracle" somewhere in the description.
Of course, you may want to use another attribute.
It was impossible to just wait with moving these accounts into the groups, defined as source for synchronization, as it was equally impossible to delete these accounts from the "old" domains.
All in all, there was to be a fortnight overlap, during which accounts would be 'active' in both domains.
Now, it just proves there's yet another meaning to the word "Single" in Single Sign On server: the scenario described above will cause SSO/WNA to fail.
Which is understandable: upon inspection of the user credentials, two entries are found, and there's no way of telling which should be used (well, actually there is by inspecting the Kerberos ticket, but it is not implemented for good reason).
The Problem
After identifying the SSO/WNA problem, synchronization from the new domain was halted, and users removed from OID. However, there were several parties involved, that could simply not wait for the complete consolidation to be completed. Those parties had consolidated into the new environment, and needed back SSO/WNA. Other parties, yet to be migrated, were not eager to loose their SSO/WNA for at least two weeks.So: catch-22, rock-and-hard-place, etc...
Working towards the solution
First of all, I implemented separate synchronization profiles for users and groups. There are two blog entries: one on user synchronization, and another one on group synchronization.
Then, the filtering needed to be adapted in order to allow for a simple alteration of the contents of a field to signal completion. Now, I know filtering on basis of exsistance of objectclasses, but not really on the contents. Given some examples in the documentation, it sould be possible.
After some testing, I came up with:
(|(&(objectclass=user)(description=*oracle*))(isDeleted=TRUE))
This allows for Descriptions in Active Directory like "User has been granted access to Oracle", or just simply "oracle" - as long as there's the word "oracle" somewhere in the description.
Of course, you may want to use another attribute.