Hi,
We are setting up a new Windows 2K3 AD server and attempting to syncronise the users from our LDAP server version 8.1.0.
Performing the full sync fails after about 30 seconds with a message in the error log:
[14/Jul/2010:07:46:10 -0400] - add value "^V" to attribute type "ARecord" in entry "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value [14/Jul/2010:07:46:10 -0400] - add value "null or non-ASCII" to attribute type "dnsproperty" in entry "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value
and none of the users or groups are sent to AD. I am guessing it may be how our LDAP server schema is setup as we use something like:
dc=domain,dc=com |_ o=Internal |___o=a0000 |____ou=Desktops |_____uid=fred
We have set the Windows subtree to be dc=domain,dc=com and the replication subtree to be dc=domain,dc=com with a DS subtree of o=Internal,dc=domain,dc=com.
Our understanding was that within AD Users & Groups GUI we should have seen a similar schema created.
Though for some reason the replication is traversing the whole of the internal AD tree. Should we create a new Organisational Unit within AD called, for arguments sake, clients and set the Windows subtree to be ou=clients,dc=domain,dc=com so that it forces it to that branch ?
--[ UxBoD ]-- wrote:
Hi,
We are setting up a new Windows 2K3 AD server and attempting to syncronise the users from our LDAP server version 8.1.0.
Performing the full sync fails after about 30 seconds with a message in the error log:
[14/Jul/2010:07:46:10 -0400] - add value "^V" to attribute type "ARecord" in entry "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value [14/Jul/2010:07:46:10 -0400] - add value "null or non-ASCII" to attribute type "dnsproperty" in entry "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value
and none of the users or groups are sent to AD. I am guessing it may be how our LDAP server schema is setup as we use something like:
dc=domain,dc=com |_ o=Internal |___o=a0000 |____ou=Desktops |_____uid=fred
We have set the Windows subtree to be dc=domain,dc=com and the replication subtree to be dc=domain,dc=com with a DS subtree of o=Internal,dc=domain,dc=com.
Our understanding was that within AD Users & Groups GUI we should have seen a similar schema created.
Though for some reason the replication is traversing the whole of the internal AD tree.
Because you set the AD subtree to be dc=domain,dc=com ?
Should we create a new Organisational Unit within AD called, for arguments sake, clients and set the Windows subtree to be ou=clients,dc=domain,dc=com so that it forces it to that branch ?
I think that's the way it was designed. Usually AD trees have a CN=Users,DC=domain,DC=com where all of the user entries live, and winsync is designed to work with that sort of structure.
On Wed, 2010-07-14 at 15:40 -0600, Rich Megginson wrote:
--[ UxBoD ]-- wrote:
Hi,
We are setting up a new Windows 2K3 AD server and attempting to syncronise the users from our LDAP server version 8.1.0.
Performing the full sync fails after about 30 seconds with a message in the error log:
[14/Jul/2010:07:46:10 -0400] - add value "^V" to attribute type "ARecord" in entry "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value [14/Jul/2010:07:46:10 -0400] - add value "null or non-ASCII" to attribute type "dnsproperty" in entry "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value
and none of the users or groups are sent to AD. I am guessing it may be how our LDAP server schema is setup as we use something like:
dc=domain,dc=com |_ o=Internal |___o=a0000 |____ou=Desktops |_____uid=fred
We have set the Windows subtree to be dc=domain,dc=com and the replication subtree to be dc=domain,dc=com with a DS subtree of o=Internal,dc=domain,dc=com.
Our understanding was that within AD Users & Groups GUI we should have seen a similar schema created.
Though for some reason the replication is traversing the whole of the internal AD tree.
Because you set the AD subtree to be dc=domain,dc=com ?
Should we create a new Organisational Unit within AD called, for arguments sake, clients and set the Windows subtree to be ou=clients,dc=domain,dc=com so that it forces it to that branch ?
I think that's the way it was designed. Usually AD trees have a CN=Users,DC=domain,DC=com where all of the user entries live, and winsync is designed to work with that sort of structure.
<snip> Hmm . . . we've rooted AD in dc=myad,dc=domain,dc=com and synchronized at cn=users,dc=myad,dc=domain,dc=com but still have the exact same problem :(
On Mon, 2010-07-19 at 04:15 -0400, John A. Sullivan III wrote:
On Wed, 2010-07-14 at 15:40 -0600, Rich Megginson wrote:
--[ UxBoD ]-- wrote:
Hi,
We are setting up a new Windows 2K3 AD server and attempting to syncronise the users from our LDAP server version 8.1.0.
Performing the full sync fails after about 30 seconds with a message in the error log:
[14/Jul/2010:07:46:10 -0400] - add value "^V" to attribute type "ARecord" in entry "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value [14/Jul/2010:07:46:10 -0400] - add value "null or non-ASCII" to attribute type "dnsproperty" in entry "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value
and none of the users or groups are sent to AD. I am guessing it may be how our LDAP server schema is setup as we use something like:
dc=domain,dc=com |_ o=Internal |___o=a0000 |____ou=Desktops |_____uid=fred
We have set the Windows subtree to be dc=domain,dc=com and the replication subtree to be dc=domain,dc=com with a DS subtree of o=Internal,dc=domain,dc=com.
Our understanding was that within AD Users & Groups GUI we should have seen a similar schema created.
Though for some reason the replication is traversing the whole of the internal AD tree.
Because you set the AD subtree to be dc=domain,dc=com ?
Should we create a new Organisational Unit within AD called, for arguments sake, clients and set the Windows subtree to be ou=clients,dc=domain,dc=com so that it forces it to that branch ?
I think that's the way it was designed. Usually AD trees have a CN=Users,DC=domain,DC=com where all of the user entries live, and winsync is designed to work with that sort of structure.
<snip> Hmm . . . we've rooted AD in dc=myad,dc=domain,dc=com and synchronized at cn=users,dc=myad,dc=domain,dc=com but still have the exact same problem :(
<snip> I also tried creating an ou in AD, e.g., ou=LDAPUSers,dc=myad,dc=domain,dc=com in case it did not like building Organizations under CNs but that also failed - John
On Mon, 2010-07-19 at 04:26 -0400, John A. Sullivan III wrote:
On Mon, 2010-07-19 at 04:15 -0400, John A. Sullivan III wrote:
On Wed, 2010-07-14 at 15:40 -0600, Rich Megginson wrote:
--[ UxBoD ]-- wrote:
Hi,
We are setting up a new Windows 2K3 AD server and attempting to syncronise the users from our LDAP server version 8.1.0.
Performing the full sync fails after about 30 seconds with a message in the error log:
[14/Jul/2010:07:46:10 -0400] - add value "^V" to attribute type "ARecord" in entry "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value [14/Jul/2010:07:46:10 -0400] - add value "null or non-ASCII" to attribute type "dnsproperty" in entry "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value
and none of the users or groups are sent to AD. I am guessing it may be how our LDAP server schema is setup as we use something like:
dc=domain,dc=com |_ o=Internal |___o=a0000 |____ou=Desktops |_____uid=fred
We have set the Windows subtree to be dc=domain,dc=com and the replication subtree to be dc=domain,dc=com with a DS subtree of o=Internal,dc=domain,dc=com.
Our understanding was that within AD Users & Groups GUI we should have seen a similar schema created.
Though for some reason the replication is traversing the whole of the internal AD tree.
Because you set the AD subtree to be dc=domain,dc=com ?
Should we create a new Organisational Unit within AD called, for arguments sake, clients and set the Windows subtree to be ou=clients,dc=domain,dc=com so that it forces it to that branch ?
I think that's the way it was designed. Usually AD trees have a CN=Users,DC=domain,DC=com where all of the user entries live, and winsync is designed to work with that sort of structure.
<snip> Hmm . . . we've rooted AD in dc=myad,dc=domain,dc=com and synchronized at cn=users,dc=myad,dc=domain,dc=com but still have the exact same problem :(
<snip> I also tried creating an ou in AD, e.g., ou=LDAPUSers,dc=myad,dc=domain,dc=com in case it did not like building Organizations under CNs but that also failed - John
<snip> Hmm .. .more inconsistent behavior. I thought it might be a schema violation to put an O under a CN or O. I tried creating it under DC; that did not work. I tried synching an OU instead of an O. That appeared to work but only transferred one of five users. I wonder if it is a 64 bit problem. The system where it is working is a 32 bit version of Windows
John A. Sullivan III wrote:
On Mon, 2010-07-19 at 04:26 -0400, John A. Sullivan III wrote:
On Mon, 2010-07-19 at 04:15 -0400, John A. Sullivan III wrote:
On Wed, 2010-07-14 at 15:40 -0600, Rich Megginson wrote:
--[ UxBoD ]-- wrote:
Hi,
We are setting up a new Windows 2K3 AD server and attempting to syncronise the users from our LDAP server version 8.1.0.
Performing the full sync fails after about 30 seconds with a message in the error log:
[14/Jul/2010:07:46:10 -0400] - add value "^V" to attribute type "ARecord" in entry "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value [14/Jul/2010:07:46:10 -0400] - add value "null or non-ASCII" to attribute type "dnsproperty" in entry "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value
and none of the users or groups are sent to AD. I am guessing it may be how our LDAP server schema is setup as we use something like:
dc=domain,dc=com |_ o=Internal |___o=a0000 |____ou=Desktops |_____uid=fred
We have set the Windows subtree to be dc=domain,dc=com and the replication subtree to be dc=domain,dc=com with a DS subtree of o=Internal,dc=domain,dc=com.
Our understanding was that within AD Users & Groups GUI we should have seen a similar schema created.
Though for some reason the replication is traversing the whole of the internal AD tree.
Because you set the AD subtree to be dc=domain,dc=com ?
Should we create a new Organisational Unit within AD called, for arguments sake, clients and set the Windows subtree to be ou=clients,dc=domain,dc=com so that it forces it to that branch ?
I think that's the way it was designed. Usually AD trees have a CN=Users,DC=domain,DC=com where all of the user entries live, and winsync is designed to work with that sort of structure.
<snip> Hmm . . . we've rooted AD in dc=myad,dc=domain,dc=com and synchronized at cn=users,dc=myad,dc=domain,dc=com but still have the exact same problem :(
<snip> I also tried creating an ou in AD, e.g., ou=LDAPUSers,dc=myad,dc=domain,dc=com in case it did not like building Organizations under CNs but that also failed - John
<snip> Hmm .. .more inconsistent behavior. I thought it might be a schema violation to put an O under a CN or O.
No. Maybe some sort of naming violation, not a schema violation, but I don't think AD enforces those anyway, so it shouldn't matter.
I tried creating it under DC; that did not work. I tried synching an OU instead of an O. That appeared to work but only transferred one of five users. I wonder if it is a 64 bit problem. The system where it is working is a 32 bit version of Windows
I doubt it is a 64-bit issue. Try turning on the replication log level http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
John A. Sullivan III wrote:
On Mon, 2010-07-19 at 04:15 -0400, John A. Sullivan III wrote:
On Wed, 2010-07-14 at 15:40 -0600, Rich Megginson wrote:
--[ UxBoD ]-- wrote:
Hi,
We are setting up a new Windows 2K3 AD server and attempting to syncronise the users from our LDAP server version 8.1.0.
Performing the full sync fails after about 30 seconds with a message in the error log:
[14/Jul/2010:07:46:10 -0400] - add value "^V" to attribute type "ARecord" in entry "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value [14/Jul/2010:07:46:10 -0400] - add value "null or non-ASCII" to attribute type "dnsproperty" in entry "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value
and none of the users or groups are sent to AD. I am guessing it may be how our LDAP server schema is setup as we use something like:
dc=domain,dc=com |_ o=Internal |___o=a0000 |____ou=Desktops |_____uid=fred
We have set the Windows subtree to be dc=domain,dc=com and the replication subtree to be dc=domain,dc=com with a DS subtree of o=Internal,dc=domain,dc=com.
Our understanding was that within AD Users & Groups GUI we should have seen a similar schema created.
Though for some reason the replication is traversing the whole of the internal AD tree.
Because you set the AD subtree to be dc=domain,dc=com ?
Should we create a new Organisational Unit within AD called, for arguments sake, clients and set the Windows subtree to be ou=clients,dc=domain,dc=com so that it forces it to that branch ?
I think that's the way it was designed. Usually AD trees have a CN=Users,DC=domain,DC=com where all of the user entries live, and winsync is designed to work with that sort of structure.
<snip> Hmm . . . we've rooted AD in dc=myad,dc=domain,dc=com and synchronized at cn=users,dc=myad,dc=domain,dc=com but still have the exact same problem :(
<snip> I also tried creating an ou in AD, e.g., ou=LDAPUSers,dc=myad,dc=domain,dc=com in case it did not like building Organizations under CNs but that also failed - John
Not sure what you mean by "building Organizations" - but it shouldn't matter if it is under a CN or not.
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
On Mon, 2010-07-19 at 07:01 -0600, Rich Megginson wrote:
John A. Sullivan III wrote:
On Mon, 2010-07-19 at 04:15 -0400, John A. Sullivan III wrote:
On Wed, 2010-07-14 at 15:40 -0600, Rich Megginson wrote:
--[ UxBoD ]-- wrote:
Hi,
We are setting up a new Windows 2K3 AD server and attempting to syncronise the users from our LDAP server version 8.1.0.
Performing the full sync fails after about 30 seconds with a message in the error log:
[14/Jul/2010:07:46:10 -0400] - add value "^V" to attribute type "ARecord" in entry "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value [14/Jul/2010:07:46:10 -0400] - add value "null or non-ASCII" to attribute type "dnsproperty" in entry "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value
and none of the users or groups are sent to AD. I am guessing it may be how our LDAP server schema is setup as we use something like:
dc=domain,dc=com |_ o=Internal |___o=a0000 |____ou=Desktops |_____uid=fred
We have set the Windows subtree to be dc=domain,dc=com and the replication subtree to be dc=domain,dc=com with a DS subtree of o=Internal,dc=domain,dc=com.
Our understanding was that within AD Users & Groups GUI we should have seen a similar schema created.
Though for some reason the replication is traversing the whole of the internal AD tree.
Because you set the AD subtree to be dc=domain,dc=com ?
Should we create a new Organisational Unit within AD called, for arguments sake, clients and set the Windows subtree to be ou=clients,dc=domain,dc=com so that it forces it to that branch ?
I think that's the way it was designed. Usually AD trees have a CN=Users,DC=domain,DC=com where all of the user entries live, and winsync is designed to work with that sort of structure.
<snip> Hmm . . . we've rooted AD in dc=myad,dc=domain,dc=com and synchronized at cn=users,dc=myad,dc=domain,dc=com but still have the exact same problem :(
<snip> I also tried creating an ou in AD, e.g., ou=LDAPUSers,dc=myad,dc=domain,dc=com in case it did not like building Organizations under CNs but that also failed - John
Not sure what you mean by "building Organizations" - but it shouldn't matter if it is under a CN or not.
<snip> We're running 8.1. Based upon some of the change logs I've seen for some of the more recent versions of 389, I wonder if this is just a problem between 8.1 and Windows Server 2008. We are downgrading a Domain Controller to 2003 to see if the problem goes away - John
----- Original Message -----
On Mon, 2010-07-19 at 07:01 -0600, Rich Megginson wrote:
John A. Sullivan III wrote:
On Mon, 2010-07-19 at 04:15 -0400, John A. Sullivan III wrote:
On Wed, 2010-07-14 at 15:40 -0600, Rich Megginson wrote:
--[ UxBoD ]-- wrote:
Hi,
We are setting up a new Windows 2K3 AD server and attempting to syncronise the users from our LDAP server version 8.1.0.
Performing the full sync fails after about 30 seconds with a message in the error log:
[14/Jul/2010:07:46:10 -0400] - add value "^V" to attribute type "ARecord" in entry "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value [14/Jul/2010:07:46:10 -0400] - add value "null or non-ASCII" to attribute type "dnsproperty" in entry "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value
and none of the users or groups are sent to AD. I am guessing it may be how our LDAP server schema is setup as we use something like:
dc=domain,dc=com |_ o=Internal |___o=a0000 |____ou=Desktops |_____uid=fred
We have set the Windows subtree to be dc=domain,dc=com and the replication subtree to be dc=domain,dc=com with a DS subtree of o=Internal,dc=domain,dc=com.
Our understanding was that within AD Users & Groups GUI we should have seen a similar schema created.
Though for some reason the replication is traversing the whole of the internal AD tree.
Because you set the AD subtree to be dc=domain,dc=com ?
Should we create a new Organisational Unit within AD called, for arguments sake, clients and set the Windows subtree to be ou=clients,dc=domain,dc=com so that it forces it to that branch ?
I think that's the way it was designed. Usually AD trees have a CN=Users,DC=domain,DC=com where all of the user entries live, and winsync is designed to work with that sort of structure.
<snip> Hmm . . . we've rooted AD in dc=myad,dc=domain,dc=com and synchronized at cn=users,dc=myad,dc=domain,dc=com but still have the exact same problem :(
<snip> I also tried creating an ou in AD, e.g., ou=LDAPUSers,dc=myad,dc=domain,dc=com in case it did not like building Organizations under CNs but that also failed - John
Not sure what you mean by "building Organizations" - but it shouldn't matter if it is under a CN or not.
<snip> We're running 8.1. Based upon some of the change logs I've seen for some of the more recent versions of 389, I wonder if this is just a problem between 8.1 and Windows Server 2008. We are downgrading a Domain Controller to 2003 to see if the problem goes away - John
The problem still exists on W2K3/32bit and we see the following error:
windows_tot_run: failed to obtain data to send to the consumer; LDAP error - 1
The user we are bind with in AD is a member of Domain Admins; do we need to add some other group or security membership ?
--[ UxBoD ]-- wrote:
----- Original Message -----
On Mon, 2010-07-19 at 07:01 -0600, Rich Megginson wrote:
John A. Sullivan III wrote:
On Mon, 2010-07-19 at 04:15 -0400, John A. Sullivan III wrote:
On Wed, 2010-07-14 at 15:40 -0600, Rich Megginson wrote:
--[ UxBoD ]-- wrote:
> Hi, > > We are setting up a new Windows 2K3 AD server and attempting to > syncronise the users from our LDAP server version 8.1.0. > > Performing the full sync fails after about 30 seconds with a > message in the error log: > > [14/Jul/2010:07:46:10 -0400] - add value "^V" to attribute type > "ARecord" in entry > "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" > failed: duplicate new value > [14/Jul/2010:07:46:10 -0400] - add value "null or non-ASCII" to > attribute type "dnsproperty" in entry > "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" > failed: duplicate new value > > and none of the users or groups are sent to AD. I am guessing > it may be how our LDAP server schema is setup as we use > something like: > > dc=domain,dc=com > |_ o=Internal > |___o=a0000 > |____ou=Desktops > |_____uid=fred > > We have set the Windows subtree to be dc=domain,dc=com and the > replication subtree to be dc=domain,dc=com with a DS subtree of > o=Internal,dc=domain,dc=com. > > Our understanding was that within AD Users & Groups GUI we > should have seen a similar schema created. > > Though for some reason the replication is traversing the whole > of the internal AD tree. > > Because you set the AD subtree to be dc=domain,dc=com ?
> Should we create a new Organisational Unit within AD called, > for arguments sake, clients and set the Windows subtree to be > ou=clients,dc=domain,dc=com so that it forces it to that branch > ? > > > I think that's the way it was designed. Usually AD trees have a CN=Users,DC=domain,DC=com where all of the user entries live, and winsync is designed to work with that sort of structure.
<snip> Hmm . . . we've rooted AD in dc=myad,dc=domain,dc=com and synchronized at cn=users,dc=myad,dc=domain,dc=com but still have the exact same problem :(
<snip> I also tried creating an ou in AD, e.g., ou=LDAPUSers,dc=myad,dc=domain,dc=com in case it did not like building Organizations under CNs but that also failed - John
Not sure what you mean by "building Organizations" - but it shouldn't matter if it is under a CN or not.
<snip> We're running 8.1. Based upon some of the change logs I've seen for some of the more recent versions of 389, I wonder if this is just a problem between 8.1 and Windows Server 2008. We are downgrading a Domain Controller to 2003 to see if the problem goes away - John
The problem still exists on W2K3/32bit and we see the following error:
windows_tot_run: failed to obtain data to send to the consumer; LDAP error - 1
Enable the replication log level - http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting
The user we are bind with in AD is a member of Domain Admins; do we need to add some other group or security membership ?
----- Original Message -----
--[ UxBoD ]-- wrote:
----- Original Message -----
On Mon, 2010-07-19 at 07:01 -0600, Rich Megginson wrote:
John A. Sullivan III wrote:
On Mon, 2010-07-19 at 04:15 -0400, John A. Sullivan III wrote:
On Wed, 2010-07-14 at 15:40 -0600, Rich Megginson wrote:
> --[ UxBoD ]-- wrote: > > >> Hi, >> >> We are setting up a new Windows 2K3 AD server and attempting >> to >> syncronise the users from our LDAP server version 8.1.0. >> >> Performing the full sync fails after about 30 seconds with a >> message in the error log: >> >> [14/Jul/2010:07:46:10 -0400] - add value "^V" to attribute >> type >> "ARecord" in entry >> "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" >> failed: duplicate new value >> [14/Jul/2010:07:46:10 -0400] - add value "null or non-ASCII" >> to >> attribute type "dnsproperty" in entry >> "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" >> failed: duplicate new value >> >> and none of the users or groups are sent to AD. I am guessing >> it may be how our LDAP server schema is setup as we use >> something like: >> >> dc=domain,dc=com >> |_ o=Internal >> |___o=a0000 >> |____ou=Desktops >> |_____uid=fred >> >> We have set the Windows subtree to be dc=domain,dc=com and the >> replication subtree to be dc=domain,dc=com with a DS subtree >> of >> o=Internal,dc=domain,dc=com. >> >> Our understanding was that within AD Users & Groups GUI we >> should have seen a similar schema created. >> >> Though for some reason the replication is traversing the whole >> of the internal AD tree. >> >> > Because you set the AD subtree to be dc=domain,dc=com ? > > >> Should we create a new Organisational Unit within AD called, >> for arguments sake, clients and set the Windows subtree to be >> ou=clients,dc=domain,dc=com so that it forces it to that >> branch >> ? >> >> >> > I think that's the way it was designed. Usually AD trees have a > CN=Users,DC=domain,DC=com where all of the user entries live, > and > winsync is designed to work with that sort of structure. > >
<snip> Hmm . . . we've rooted AD in dc=myad,dc=domain,dc=com and synchronized at cn=users,dc=myad,dc=domain,dc=com but still have the exact same problem :(
<snip> I also tried creating an ou in AD, e.g., ou=LDAPUSers,dc=myad,dc=domain,dc=com in case it did not like building Organizations under CNs but that also failed - John
Not sure what you mean by "building Organizations" - but it shouldn't matter if it is under a CN or not.
<snip> We're running 8.1. Based upon some of the change logs I've seen for some of the more recent versions of 389, I wonder if this is just a problem between 8.1 and Windows Server 2008. We are downgrading a Domain Controller to 2003 to see if the problem goes away - John
The problem still exists on W2K3/32bit and we see the following error:
windows_tot_run: failed to obtain data to send to the consumer; LDAP error - 1
Enable the replication log level - http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting
The user we are bind with in AD is a member of Domain Admins; do we need to add some other group or security membership ?
Hi Rich,
that is what I did not get the error message. Here is the complete output:
[20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Received result code 32 (0000208D: NameErr: DSID-031001CD, problem 2001 (NO_OBJECT), data 0, best match of: 'CN=Users,DC=ad,DC=domain,DC=com' ) for add operation [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): windows_replay_update: Cannot replay add operation. [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Beginning linger on the connection [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): windows_tot_run: failed to obtain data to send to the consumer; LDAP error - 1 [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): No linger to cancel on the connection [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Disconnected from the consumer [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): State: start -> ready_to_acquire_replica
--[ UxBoD ]-- wrote:
----- Original Message -----
--[ UxBoD ]-- wrote:
----- Original Message -----
On Mon, 2010-07-19 at 07:01 -0600, Rich Megginson wrote:
John A. Sullivan III wrote:
On Mon, 2010-07-19 at 04:15 -0400, John A. Sullivan III wrote:
> On Wed, 2010-07-14 at 15:40 -0600, Rich Megginson wrote: > > > >> --[ UxBoD ]-- wrote: >> >> >> >>> Hi, >>> >>> We are setting up a new Windows 2K3 AD server and attempting >>> to >>> syncronise the users from our LDAP server version 8.1.0. >>> >>> Performing the full sync fails after about 30 seconds with a >>> message in the error log: >>> >>> [14/Jul/2010:07:46:10 -0400] - add value "^V" to attribute >>> type >>> "ARecord" in entry >>> "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" >>> failed: duplicate new value >>> [14/Jul/2010:07:46:10 -0400] - add value "null or non-ASCII" >>> to >>> attribute type "dnsproperty" in entry >>> "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" >>> failed: duplicate new value >>> >>> and none of the users or groups are sent to AD. I am guessing >>> it may be how our LDAP server schema is setup as we use >>> something like: >>> >>> dc=domain,dc=com >>> |_ o=Internal >>> |___o=a0000 >>> |____ou=Desktops >>> |_____uid=fred >>> >>> We have set the Windows subtree to be dc=domain,dc=com and the >>> replication subtree to be dc=domain,dc=com with a DS subtree >>> of >>> o=Internal,dc=domain,dc=com. >>> >>> Our understanding was that within AD Users & Groups GUI we >>> should have seen a similar schema created. >>> >>> Though for some reason the replication is traversing the whole >>> of the internal AD tree. >>> >>> >>> >> Because you set the AD subtree to be dc=domain,dc=com ? >> >> >> >>> Should we create a new Organisational Unit within AD called, >>> for arguments sake, clients and set the Windows subtree to be >>> ou=clients,dc=domain,dc=com so that it forces it to that >>> branch >>> ? >>> >>> >>> >>> >> I think that's the way it was designed. Usually AD trees have a >> CN=Users,DC=domain,DC=com where all of the user entries live, >> and >> winsync is designed to work with that sort of structure. >> >> >> > <snip> > Hmm . . . we've rooted AD in dc=myad,dc=domain,dc=com and > synchronized > at cn=users,dc=myad,dc=domain,dc=com but still have the exact > same > problem :( > > >
<snip> I also tried creating an ou in AD, e.g., ou=LDAPUSers,dc=myad,dc=domain,dc=com in case it did not like building Organizations under CNs but that also failed - John
Not sure what you mean by "building Organizations" - but it shouldn't matter if it is under a CN or not.
<snip> We're running 8.1. Based upon some of the change logs I've seen for some of the more recent versions of 389, I wonder if this is just a problem between 8.1 and Windows Server 2008. We are downgrading a Domain Controller to 2003 to see if the problem goes away - John
The problem still exists on W2K3/32bit and we see the following error:
windows_tot_run: failed to obtain data to send to the consumer; LDAP error - 1
Enable the replication log level - http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting
The user we are bind with in AD is a member of Domain Admins; do we need to add some other group or security membership ?
Hi Rich,
that is what I did not get the error message. Here is the complete output:
[20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Received result code 32 (0000208D: NameErr: DSID-031001CD, problem 2001 (NO_OBJECT), data 0, best match of: 'CN=Users,DC=ad,DC=domain,DC=com' ) for add operation
This is saying that the DN mapping is not working - are you trying to add an RHDS entry like uid=foo,ou=bar,ou=people,DC=domain,DC=com to AD, but AD doesn't have ou=bar,CN=Users,DC=ad,DC=domain,DC=com
? Note that winsync will not add sub-ou containers
[20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): windows_replay_update: Cannot replay add operation. [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Beginning linger on the connection [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): windows_tot_run: failed to obtain data to send to the consumer; LDAP error - 1 [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): No linger to cancel on the connection [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Disconnected from the consumer [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): State: start -> ready_to_acquire_replica
----- Original Message ----- <SNIP> >
Hi Rich,
that is what I did not get the error message. Here is the complete output:
[20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Received result code 32 (0000208D: NameErr: DSID-031001CD, problem 2001 (NO_OBJECT), data 0, best match of: 'CN=Users,DC=ad,DC=domain,DC=com' ) for add operation
This is saying that the DN mapping is not working - are you trying to add an RHDS entry like uid=foo,ou=bar,ou=people,DC=domain,DC=com to AD, but AD doesn't have ou=bar,CN=Users,DC=ad,DC=domain,DC=com
? Note that winsync will not add sub-ou containers
[20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): windows_replay_update: Cannot replay add operation. [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Beginning linger on the connection [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): windows_tot_run: failed to obtain data to send to the consumer; LDAP error - 1 [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): No linger to cancel on the connection [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Disconnected from the consumer [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): State: start -> ready_to_acquire_replica
In AD we have the standard mappings of CN=Users,DC=ad,DC=domain,DC=com and we are trying to sync across users from RHDS DS o=Internal,dc=domain,dc=com. Our RHDS schema looks like:
dc=domain,dc=com |_ o=Internal |___o=a0000 |____ou=Desktops |_____uid=fred
Am I right in assuming that we would need to create those levels in AD manually instead of the replication plugin creating them ?
--[ UxBoD ]-- wrote:
----- Original Message ----- <SNIP> >
Hi Rich,
that is what I did not get the error message. Here is the complete output:
[20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Received result code 32 (0000208D: NameErr: DSID-031001CD, problem 2001 (NO_OBJECT), data 0, best match of: 'CN=Users,DC=ad,DC=domain,DC=com' ) for add operation
This is saying that the DN mapping is not working - are you trying to add an RHDS entry like uid=foo,ou=bar,ou=people,DC=domain,DC=com to AD, but AD doesn't have ou=bar,CN=Users,DC=ad,DC=domain,DC=com
? Note that winsync will not add sub-ou containers
[20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): windows_replay_update: Cannot replay add operation. [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Beginning linger on the connection [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): windows_tot_run: failed to obtain data to send to the consumer; LDAP error - 1 [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): No linger to cancel on the connection [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Disconnected from the consumer [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): State: start -> ready_to_acquire_replica
In AD we have the standard mappings of CN=Users,DC=ad,DC=domain,DC=com and we are trying to sync across users from RHDS DS o=Internal,dc=domain,dc=com. Our RHDS schema looks like:
dc=domain,dc=com |_ o=Internal |___o=a0000 |____ou=Desktops |_____uid=fred
Am I right in assuming that we would need to create those levels in AD manually instead of the replication plugin creating them ?
Yes.
----- Original Message -----
--[ UxBoD ]-- wrote:
----- Original Message ----- <SNIP> >
Hi Rich,
that is what I did not get the error message. Here is the complete output:
[20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Received result code 32 (0000208D: NameErr: DSID-031001CD, problem 2001 (NO_OBJECT), data 0, best match of: 'CN=Users,DC=ad,DC=domain,DC=com' ) for add operation
This is saying that the DN mapping is not working - are you trying to add an RHDS entry like uid=foo,ou=bar,ou=people,DC=domain,DC=com to AD, but AD doesn't have ou=bar,CN=Users,DC=ad,DC=domain,DC=com
? Note that winsync will not add sub-ou containers
[20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): windows_replay_update: Cannot replay add operation. [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Beginning linger on the connection [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): windows_tot_run: failed to obtain data to send to the consumer; LDAP error - 1 [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): No linger to cancel on the connection [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Disconnected from the consumer [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): State: start -> ready_to_acquire_replica
In AD we have the standard mappings of CN=Users,DC=ad,DC=domain,DC=com and we are trying to sync across users from RHDS DS o=Internal,dc=domain,dc=com. Our RHDS schema looks like:
dc=domain,dc=com |_ o=Internal |___o=a0000 |____ou=Desktops |_____uid=fred
Am I right in assuming that we would need to create those levels in AD manually instead of the replication plugin creating them ?
Yes.
Thanks Rich
Would the entry look something like cn=fred,ou=Desktops,ou=a0000,ou=Internal,dc=ad,dc=domain,dc=com
Just trying to visualise how to set it up in AD.
--[ UxBoD ]-- wrote:
----- Original Message -----
--[ UxBoD ]-- wrote:
----- Original Message ----- <SNIP> >
Hi Rich,
that is what I did not get the error message. Here is the complete output:
[20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Received result code 32 (0000208D: NameErr: DSID-031001CD, problem 2001 (NO_OBJECT), data 0, best match of: 'CN=Users,DC=ad,DC=domain,DC=com' ) for add operation
This is saying that the DN mapping is not working - are you trying to add an RHDS entry like uid=foo,ou=bar,ou=people,DC=domain,DC=com to AD, but AD doesn't have ou=bar,CN=Users,DC=ad,DC=domain,DC=com
? Note that winsync will not add sub-ou containers
[20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): windows_replay_update: Cannot replay add operation. [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Beginning linger on the connection [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): windows_tot_run: failed to obtain data to send to the consumer; LDAP error - 1 [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): No linger to cancel on the connection [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Disconnected from the consumer [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): State: start -> ready_to_acquire_replica
In AD we have the standard mappings of CN=Users,DC=ad,DC=domain,DC=com and we are trying to sync across users from RHDS DS o=Internal,dc=domain,dc=com. Our RHDS schema looks like:
dc=domain,dc=com |_ o=Internal |___o=a0000 |____ou=Desktops |_____uid=fred
Am I right in assuming that we would need to create those levels in AD manually instead of the replication plugin creating them ?
Yes.
Thanks Rich
Would the entry look something like cn=fred,ou=Desktops,ou=a0000,ou=Internal,dc=ad,dc=domain,dc=com
I think so
Just trying to visualise how to set it up in AD.
On Tue, 2010-07-20 at 10:05 -0600, Rich Megginson wrote:
--[ UxBoD ]-- wrote:
----- Original Message ----- <SNIP> >
<snip>>>
? Note that winsync will not add sub-ou containers
<snip>>
In AD we have the standard mappings of CN=Users,DC=ad,DC=domain,DC=com and we are trying to sync across users from RHDS DS o=Internal,dc=domain,dc=com. Our RHDS schema looks like:
dc=domain,dc=com |_ o=Internal |___o=a0000 |____ou=Desktops |_____uid=fred
Am I right in assuming that we would need to create those levels in AD manually instead of the replication plugin creating them ?
Yes.
<snip> Strange - in the past it has for us and it did again when testing yesterday. However, it did not create an O subcontainer. In the past, we have had: dc=domain,dc=com |_o=Internal |_o=Client |_ou=Desktops |_ou=Groups
and synchronized o=Client at dc=client,dc=com in the client's AD and got: dc=client,dc=com |_ou=Desktops |_ou=Groups
I'll play with it some more. I hope we do not have to redefine all the O's under O=Internal as OU's. That would be a nightmare. Thanks - John
On Tue, 2010-07-20 at 14:15 -0400, John A. Sullivan III wrote:
On Tue, 2010-07-20 at 10:05 -0600, Rich Megginson wrote:
--[ UxBoD ]-- wrote:
----- Original Message ----- <SNIP> >
<snip>>>
? Note that winsync will not add sub-ou containers
<snip>>
In AD we have the standard mappings of CN=Users,DC=ad,DC=domain,DC=com and we are trying to sync across users from RHDS DS o=Internal,dc=domain,dc=com. Our RHDS schema looks like:
dc=domain,dc=com |_ o=Internal |___o=a0000 |____ou=Desktops |_____uid=fred
Am I right in assuming that we would need to create those levels in AD manually instead of the replication plugin creating them ?
Yes.
<snip> Strange - in the past it has for us and it did again when testing yesterday. However, it did not create an O subcontainer. In the past, we have had: dc=domain,dc=com |_o=Internal |_o=Client |_ou=Desktops |_ou=Groups
and synchronized o=Client at dc=client,dc=com in the client's AD and got: dc=client,dc=com |_ou=Desktops |_ou=Groups
I'll play with it some more. I hope we do not have to redefine all the O's under O=Internal as OU's. That would be a nightmare. Thanks - John
This is starting to make sense but it is also looking really, really ugly. We do have this working but I think it is by accident. When we first set it up in the working instance, it failed. Strangely, after a second attempt (and there may have been a reboot of the Windows PDC), it worked. I do not know how but, in some cases even in our testing today, OU objects are created. Most of the time they are not. I do not know what trips that unexpected behavior but I have seen it. That must have happened in this "successful" attempt. When we tried the second time, the OUs were in place and the users were successfully created and maintained. It happened by accident.
Now, we are pushing further. We are trying to create a hierarchy of Organizations and OUs. As you explained earlier, I suppose the synch tools don't do that.
So, I thought I would bite the bullet and create the hierarchy. Alas, I see no way to create an object of type Organization in AD. Is there a way and I'm just completely ignorant?
I then thought I'd cheat and try to sync an Organization to the top of the tree. That worked. I created a user and they appeared at the top of the tree. I then tried to create an Organization to see if that would work. The synchronization seemed successful but the Organization does not display.
I checked the Microsoft Schema reference and it says they have an Organization. Does anyone know how one enables the AD management tools to see it and create new ones? Then we might be able to get it to sync with 389. Thanks - John
On Tue, 2010-07-20 at 18:08 -0400, John A. Sullivan III wrote:
On Tue, 2010-07-20 at 14:15 -0400, John A. Sullivan III wrote:
On Tue, 2010-07-20 at 10:05 -0600, Rich Megginson wrote:
--[ UxBoD ]-- wrote:
----- Original Message ----- <SNIP> >
<snip>>>
? Note that winsync will not add sub-ou containers
<snip>>
In AD we have the standard mappings of CN=Users,DC=ad,DC=domain,DC=com and we are trying to sync across users from RHDS DS o=Internal,dc=domain,dc=com. Our RHDS schema looks like:
dc=domain,dc=com |_ o=Internal |___o=a0000 |____ou=Desktops |_____uid=fred
Am I right in assuming that we would need to create those levels in AD manually instead of the replication plugin creating them ?
Yes.
<snip> Strange - in the past it has for us and it did again when testing yesterday. However, it did not create an O subcontainer. In the past, we have had: dc=domain,dc=com |_o=Internal |_o=Client |_ou=Desktops |_ou=Groups
and synchronized o=Client at dc=client,dc=com in the client's AD and got: dc=client,dc=com |_ou=Desktops |_ou=Groups
I'll play with it some more. I hope we do not have to redefine all the O's under O=Internal as OU's. That would be a nightmare. Thanks - John
This is starting to make sense but it is also looking really, really ugly. We do have this working but I think it is by accident. When we first set it up in the working instance, it failed. Strangely, after a second attempt (and there may have been a reboot of the Windows PDC), it worked. I do not know how but, in some cases even in our testing today, OU objects are created. Most of the time they are not. I do not know what trips that unexpected behavior but I have seen it. That must have happened in this "successful" attempt. When we tried the second time, the OUs were in place and the users were successfully created and maintained. It happened by accident.
Now, we are pushing further. We are trying to create a hierarchy of Organizations and OUs. As you explained earlier, I suppose the synch tools don't do that.
So, I thought I would bite the bullet and create the hierarchy. Alas, I see no way to create an object of type Organization in AD. Is there a way and I'm just completely ignorant?
I then thought I'd cheat and try to sync an Organization to the top of the tree. That worked. I created a user and they appeared at the top of the tree. I then tried to create an Organization to see if that would work. The synchronization seemed successful but the Organization does not display.
I checked the Microsoft Schema reference and it says they have an Organization. Does anyone know how one enables the AD management tools to see it and create new ones? Then we might be able to get it to sync with 389. Thanks - John
<snip> Well . . .I've been battling this literally all day and it still looks ugly. As far as I can tell, just as Rich said, the sync does not handle O and OU objects. Ours worked by accident as explained previously.
We hit a problem if we try to reproduce the hierarchy because Windows AD seems to have not way to define an Organization object even though the schema supposedly includes it. If the hierarchy contains only OU objects and is predefined, the users populate throughout the hierarchy.
I tried using views to "convert" the O objects to OU objects in a parallel hierarchy. The synchronization does not error but no users are created.
It looks like we need to design our entire multi-tenant LDAP structure to eliminate all references to O= (which seems absolutely stupid and a project fraught with potential production impact) or we need to find a way to manipulate Organization objects in AD. Does anyone have any idea how to do the latter? Thanks - John
On Tue, 2010-07-20 at 23:15 -0400, John A. Sullivan III wrote:
On Tue, 2010-07-20 at 18:08 -0400, John A. Sullivan III wrote:
On Tue, 2010-07-20 at 14:15 -0400, John A. Sullivan III wrote:
On Tue, 2010-07-20 at 10:05 -0600, Rich Megginson wrote:
--[ UxBoD ]-- wrote:
----- Original Message ----- <SNIP> >
<snip>>>
? Note that winsync will not add sub-ou containers
<snip>>
In AD we have the standard mappings of CN=Users,DC=ad,DC=domain,DC=com and we are trying to sync across users from RHDS DS o=Internal,dc=domain,dc=com. Our RHDS schema looks like:
dc=domain,dc=com |_ o=Internal |___o=a0000 |____ou=Desktops |_____uid=fred
Am I right in assuming that we would need to create those levels in AD manually instead of the replication plugin creating them ?
Yes.
<snip> Strange - in the past it has for us and it did again when testing yesterday. However, it did not create an O subcontainer. In the past, we have had: dc=domain,dc=com |_o=Internal |_o=Client |_ou=Desktops |_ou=Groups
and synchronized o=Client at dc=client,dc=com in the client's AD and got: dc=client,dc=com |_ou=Desktops |_ou=Groups
I'll play with it some more. I hope we do not have to redefine all the O's under O=Internal as OU's. That would be a nightmare. Thanks - John
This is starting to make sense but it is also looking really, really ugly. We do have this working but I think it is by accident. When we first set it up in the working instance, it failed. Strangely, after a second attempt (and there may have been a reboot of the Windows PDC), it worked. I do not know how but, in some cases even in our testing today, OU objects are created. Most of the time they are not. I do not know what trips that unexpected behavior but I have seen it. That must have happened in this "successful" attempt. When we tried the second time, the OUs were in place and the users were successfully created and maintained. It happened by accident.
Now, we are pushing further. We are trying to create a hierarchy of Organizations and OUs. As you explained earlier, I suppose the synch tools don't do that.
So, I thought I would bite the bullet and create the hierarchy. Alas, I see no way to create an object of type Organization in AD. Is there a way and I'm just completely ignorant?
I then thought I'd cheat and try to sync an Organization to the top of the tree. That worked. I created a user and they appeared at the top of the tree. I then tried to create an Organization to see if that would work. The synchronization seemed successful but the Organization does not display.
I checked the Microsoft Schema reference and it says they have an Organization. Does anyone know how one enables the AD management tools to see it and create new ones? Then we might be able to get it to sync with 389. Thanks - John
<snip> Well . . .I've been battling this literally all day and it still looks ugly. As far as I can tell, just as Rich said, the sync does not handle O and OU objects. Ours worked by accident as explained previously.
We hit a problem if we try to reproduce the hierarchy because Windows AD seems to have not way to define an Organization object even though the schema supposedly includes it. If the hierarchy contains only OU objects and is predefined, the users populate throughout the hierarchy.
I tried using views to "convert" the O objects to OU objects in a parallel hierarchy. The synchronization does not error but no users are created.
It looks like we need to design our entire multi-tenant LDAP structure to eliminate all references to O= (which seems absolutely stupid and a project fraught with potential production impact) or we need to find a way to manipulate Organization objects in AD. Does anyone have any idea how to do the latter? Thanks - John
<snip> We were finally successful in our endeavors but it was not easy. We first needed to use ADSI Edit. This allowed us to create an Organization at the top level of our tree. Then we hit the next problem. Our LDAP DIT has a second organization under the first. The Microsoft AD schema only allows Countries, Localities, and Domain Components to be superior to Organizations and not other Organizations.
We thus needed to modify the AD schema in order to allow nested Organizations by using a combination of lde.exe and ADSI Edit. We launched ldp.exe, connected to local host and did a bind as the current user (since we were administrator). We next chose Browse / Modify and entered CN=Organization,CN=Schema,CN=Configuration,DC=pacad,DC=pacifera,DC=com as the DN. We entered the systemPossSuperiors attribute.
Unfortunately, I did not document the next steps as well as I should have. I believe simply adding organization gave us a not very helpful error 19. I think we had to delete the current value "country;locality;domainDNS" and replace it with "organization;country;locality;domainDNS". Once this was added we returned to ADSI Edit, right clicked on the RootDSE and reloaded the schema. Hope this helps someone else! - John
389-users@lists.fedoraproject.org
-
John A. Sullivan III -
Phil Daws -
Rich Megginson