Rich,

I found a problem, seems to be a bug:

When I delete the user from my AD the plugin did not update the group (did not test deleting first in 389 DS). So the user does not exist, but in 389 DS group shows me the entry.

When I create the user again, the 389 (replication plugin or whatever) delete everyone from my group in 389 DS.

I´m not sure if is a 389 DS console problem or plugin replication problem.

Could not found anything related to it on bugs.

Thanks



On Thu, Jul 5, 2012 at 4:42 PM, Rich Megginson <rmeggins@redhat.com> wrote:
On 07/05/2012 01:32 PM, Alberto Viana wrote:
I have a replication with a 389 DS server and my AD domain. According to the documentation the field used to control the replication is "NT user ID" on 389 DS and it is populated from Active directory´s field "sAMAccountName".

The fact is that "sAMAccountName" is limited to 20 characters. 


My problem is that I always create my user´s in the active directory first, so when I create a user longer than 20 characters, 389 DS create it missing letters (off corse the problem is about windows limitation and I know that), I´m just trying to find out the esiest solution to my problem.

For example, I have an user called "therezinha.figueiredo" and when I create it on my AD the "sAMAccountName" is "therezinha.figueired", so the replication plugin create in the 389 Server an user Called "therezinha.figueired"

I Also tried to modifify the user uid and keep the "NT user ID". For example:

After the replication plugin created the user called "therezinha.figueired" I modified it manually to ""therezinha.figueiredo" and kept the "NT user ID", but something strange hapenned with this user groups (in the 389 DS and also in the Active Directory).


Any clues? Can I use another field to populate users "NT user ID" and  change it on the replication plugin?

It will be a manual process, but you might be able to create the user first in AD, then manually create the user in 389, with the ntUniqueID field set to the objectGUID of the AD entry.  389 winsync uses the uid -> samAccountName for the initial mapping, but once that is established, it uses ntUniqueID -> objectGUID.

At any rate, please file a ticket at
https://fedorahosted.org/389


Thanks 

Alberto Viana




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users