[389-users] Windows Sync Agreement Help
Rich Megginson
rmeggins at redhat.com
Thu Jun 2 14:04:38 UTC 2011
On 06/01/2011 07:26 PM, ÅíʤÎÄ wrote:
>
> nss_base_passwd cn=Users,dc=dev,dc=jz,dc=com
> nss_base_shadow cn=Users,dc=dev,dc=jz,dc=com
> nss_base_group cn=Users,dc=dev,dc=jz,dc=com
>
> ##----AD------------------
> nss_map_objectclass posixAccount user
> nss_map_objectclass shadowAccount user
> nss_map_attribute uid sAMAccountName
> nss_map_attribute homeDirectory unixHomeDirectory
> nss_map_attribute shadowLastChange pwdLastSet
> nss_map_objectclass posixGroup group
> nss_map_attribute uniqueMember member
> pam_login_attribute sAMAccountName
> pam_filter objectclass=User
>
> ssl no
> tls_cacertdir /etc/openldap/cacerts
> pam_password md5
>
>
>
> --
> BR,
> Thanks!
>
> ÔÚ2011-06-02£¬"Rich Megginson" <rmeggins at redhat.com> дµÀ£º
>
> ----- ÔʼÓʼþ-----
> *·¢¼þÈË:*"Rich Megginson" <rmeggins at redhat.com>
> *·¢ËÍʱ¼ä:*2011Äê6ÔÂ2ÈÕ ÐÇÆÚËÄ
> *ÊÕ¼þÈË:*"Albert Teh" <teh.albert at gmail.com>
> *³ËÍ:*"General discussion list for the 389 Directory server
> project." <389-users at lists.fedoraproject.org>
> *Ö÷Ìâ:*Re: [389-users] Windows Sync Agreement Help
>
> On 06/01/2011 09:21 AM, Albert Teh wrote:
>> The user: mailadm should have a full privilege from the AD
>> because we are using this user for SUN's IDSYNC
>> synchronizing/passwdsyc from the AD to the SUN's DS which is our
>> current LDAP environment. We are trying to change SUN's Directory
>> server to the Linux's 389-Directory server.
> Ok. I don't know how Sun's IDSYNC works - it is possible it
> doesn't use the DirSync control which requires Replicator
> privileges. Can you confirm that
> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
> has Replication/Replicator rights in AD/Windows?
>
I don't think the reply answers this question.
>
>>
>>
>> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
>> has Replication/Replicator rights in AD/Windows?
>>
>> Thanks.
>> Albert
>>
>> On Wed, Jun 1, 2011 at 10:12 AM, Rich
>> Megginson<rmeggins at redhat.com <mailto:rmeggins at redhat.com>> wrote:
>>
>> On 05/31/2011 06:30 PM, Albert Teh wrote:
>>>
>>>
>>> On Tue, May 31, 2011 at 2:58 PM, Rich
>>> Megginson<rmeggins at redhat.com <mailto:rmeggins at redhat.com>>
>>> wrote:
>>>
>>> On 05/31/2011 12:49 PM, Albert Teh wrote:
>>>> Hi Rich,
>>>>
>>>> Sorry, What I understand doing the OneWay Sync from the
>>>> AD to the DS
>>>>
>>>> Users in the Active Directory domain are synced if it
>>>> is configured in the sync agreement by selecting
>>>> the*Sync New Windows Users*option. All of the Windows
>>>> users are copied to the Directory Server when
>>>> synchronization is initiated and then new users are
>>>> synced over when they are created.
>>>>
>>>> I do not need to do any AD to DS Group Sync
>>>>
>>>> and I am not doing any DS sync to the AD.
>>> /usr/lib/mozldap/ldapsearch -x
>>> -hwodcstage-1.ottawa.ad.algonquincollege.com
>>> <http://wodcstage-1.ottawa.ad.algonquincollege.com> -w -
>>> -D
>>> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
>>> -s base -b "" "objectclass=*"
>>>
>>> You should get the contents of the AD
>>>
>>> /usr/lib/mozldap/ldapsearch -x
>>> -hwodcstage-1.ottawa.ad.algonquincollege.com
>>> <http://wodcstage-1.ottawa.ad.algonquincollege.com> -w -
>>> -D
>>> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
>>> -s sub -b
>>> "cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
>>> "objectclass=person"
>>>
>>> you should get the list of users
>>>
>>>>
>>>>
>>>> Thanks.
>>>> Al
>>>>
>>>> On Tue, May 31, 2011 at 1:40 PM, Rich
>>>> Megginson<rmeggins at redhat.com
>>>> <mailto:rmeggins at redhat.com>> wrote:
>>>>
>>>> On 05/31/2011 10:30 AM, Albert Teh wrote:
>>>>>
>>>>> HI Rich,
>>>>>
>>>>> [root at algldap ~]# /usr/lib/mozldap/ldapsearch -x
>>>>> -w - -D cn="Directory Manager" -b
>>>>> "ou=People,dc=algonquincollege,dc=com"
>>>>> "(|(objectclass=ntuser)(objectclass=ntgroup))"
>>>>> Enter bind password:
>>>>> [root at algldap ~]#
>>>>>
>>>>> No Entry found !!!.
>>>> You have to tell directory server which entries you
>>>> want to sync.
>>>> Seehttp://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Windows_Sync-About_Windows_Sync
>>>>
>>>>>
>>>>> Thanks.
>>>>> Albert
>>>>>
>>>>> On Tue, May 31, 2011 at 11:42 AM, Rich
>>>>> Megginson<rmeggins at redhat.com
>>>>> <mailto:rmeggins at redhat.com>> wrote:
>>>>>
>>>>> On 05/30/2011 08:32 AM, Albert Teh wrote:
>>>>>> Hi Rich,
>>>>>>
>>>>>> I followed the Guide and still got the same
>>>>>> result. Checked with the AD administrator,
>>>>>> the AD's user: mailadm has a full privilege.
>>>>> /usr/bin/ldapsearch -x -w - -D cn="Directory
>>>>> Manager"-b
>>>>> "ou=People,dc=algonquincollege,dc=com"
>>>>> "(|(objectclass=ntuser)(objectclass=ntgroup))"
>>>>>
>>>>> How many entries match that search?
>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>> Albert
>>>>>>
>>>>>> Here is the Windows Sync Agreement info:
>>>>>>
>>>>>> [root at algldap slapd-algldap]#
>>>>>> /usr/lib/mozldap/ldapsearch -w - -D
>>>>>> cn="Directory Manager" -b cn=config cn=ADSync
>>>>>> Enter bind password:
>>>>>> version: 1
>>>>>> dn:
>>>>>> cn=ADSync,cn=replica,cn=dc\3Dalgonquincollege\2Cdc\3Dcom,cn=mapping
>>>>>> tree,c
>>>>>> n=config
>>>>>> objectClass: top
>>>>>> objectClass: nsDSWindowsReplicationAgreement
>>>>>> description: AD Sync Agreement
>>>>>> cn: ADSync
>>>>>> nsds7WindowsReplicaSubtree:
>>>>>> cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=co
>>>>>> m
>>>>>> nsds7DirectoryReplicaSubtree: ou=People,
>>>>>> dc=algonquincollege,dc=com
>>>>>> nsds7NewWinUserSyncEnabled: on
>>>>>> nsds7NewWinGroupSyncEnabled: on
>>>>>> nsds7WindowsDomain:
>>>>>> ottawa.ad.algonquincollege.com
>>>>>> <http://ottawa.ad.algonquincollege.com>
>>>>>> nsDS5ReplicaRoot: dc=algonquincollege,dc=com
>>>>>> nsDS5ReplicaHost:
>>>>>> wodcstage-1.ottawa.ad.algonquincollege.com
>>>>>> <http://wodcstage-1.ottawa.ad.algonquincollege.com>
>>>>>> nsDS5ReplicaPort: 389
>>>>>> nsDS5ReplicaBindDN:
>>>>>> cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc
>>>>>> =com
>>>>>> nsDS5ReplicaBindMethod: SIMPLE
>>>>>> nsDS5ReplicaCredentials:
>>>>>> {DES}U68ooQM3C15xjJ/taDmy0A==
>>>>>> nsds5replicareapactive: 0
>>>>>> nsds5replicaLastUpdateStart: 20110530141648Z
>>>>>> nsds5replicaLastUpdateEnd: 20110530141648Z
>>>>>> nsds5replicaChangesSentSinceStartup:
>>>>>> nsds5replicaLastUpdateStatus: 0 Replica
>>>>>> acquired successfully: Incremental upd
>>>>>> ate succeeded
>>>>>> nsds5replicaUpdateInProgress: FALSE
>>>>>> nsds5replicaLastInitStart: 20110530140648Z
>>>>>> nsds5replicaLastInitEnd: 20110530140648Z
>>>>>> nsds5replicaLastInitStatus: 0 Total update
>>>>>> succeeded
>>>>>> [root at algldap slapd-algldap]#
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, May 27, 2011 at 10:57 AM, Rich
>>>>>> Megginson<rmeggins at redhat.com
>>>>>> <mailto:rmeggins at redhat.com>> wrote:
>>>>>>
>>>>>> On 05/27/2011 04:22 AM, Albert Teh wrote:
>>>>>>> Hi Rich,
>>>>>>>
>>>>>>> I reinstalled 389-ds-base 1.2.8.3 from
>>>>>>> EPEL5 and added onewaysync set as
>>>>>>> fromWindows in the multimaster
>>>>>>> replication plugin. I still got the same
>>>>>>> result with no user created in the DS
>>>>>>> subtree.
>>>>>> Have you read
>>>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Windows_Sync-About_Windows_Sync
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Errors log:
>>>>>>>
>>>>>>> [27/May/2011:06:18:26 -0400]
>>>>>>> NSMMReplicationPlugin - Beginning total
>>>>>>> update of replica "agmt="cn=ADSync"
>>>>>>> (wodcstage-1:389)".
>>>>>>> [27/May/2011:06:18:26 -0400]
>>>>>>> NSMMReplicationPlugin - Finished total
>>>>>>> update of replica "agmt="cn=ADSync"
>>>>>>> (wodcstage-1:389)". Sent 0 entries.
>>>>>>>
>>>>>>>
>>>>>>> Access log:
>>>>>>>
>>>>>>> [27/May/2011:06:18:29 -0400] conn=1
>>>>>>> op=114 SRCH
>>>>>>> base="cn=ADSync,cn=replica,cn=dc\3Dalgonquincollege\2Cdc\3Dcom,cn=mapping
>>>>>>> tree,cn=config" scope=0
>>>>>>> filter="(|(objectClass=*)(objectClass=ldapsubentry))"
>>>>>>> attrs="nsds5replicaLastUpdateStart
>>>>>>> nsds5replicaLastUpdateEnd
>>>>>>> nsds5replicaChangesSentSinceStartup
>>>>>>> nsds5replicaLastUpdateStatus
>>>>>>> nsds5replicaUpdateInProgress
>>>>>>> nsds5replicaLastInitStart
>>>>>>> nsds5replicaLastInitEnd
>>>>>>> nsds5replicaLastInitStatus
>>>>>>> nsds5BeginReplicaRefresh"
>>>>>>> [27/May/2011:06:18:29 -0400] conn=1
>>>>>>> op=114 RESULT err=0 tag=101 nentries=1
>>>>>>> etime=
>>>>>>>
>>>>>>> Thanks for your help.
>>>>>>>
>>>>>>> Albert
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 26, 2011 at 11:13 AM, Rich
>>>>>>> Megginson<rmeggins at redhat.com
>>>>>>> <mailto:rmeggins at redhat.com>> wrote:
>>>>>>>
>>>>>>> On 05/26/2011 08:58 AM, Albert Teh
>>>>>>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> We are setting up a new CENTOS-DS
>>>>>>>> version 8.1.0. and CENTOS 5.5 and
>>>>>>>> attempt to synchronize with the
>>>>>>>> existing 2003 Windows AD server.
>>>>>>>> Performing the full sync completed.
>>>>>>>> There is no user created in the DS
>>>>>>>> subtree.
>>>>>>>>
>>>>>>>> We would like to perform one way
>>>>>>>> Sync: AD ----> DS. Once it works,
>>>>>>>> we will set up the password Sync
>>>>>>>> from the AD to DS.
>>>>>>> One way sync isn't supported with
>>>>>>> 8.1.0. I suggest using 389-ds-base
>>>>>>> 1.2.8.3 from EPEL5 which does
>>>>>>> support one way sync.
>>>>>>> http://directory.fedoraproject.org/wiki/One_Way_Active_Directory_Sync
>>>>>>>>
>>>>>>>> AD:
>>>>>>>> cn=Users,cn=location,dc=ad,dc=domain,dc=com
>>>>>>>> DS: ou=Peoples,dc=domain,dc=com
>>>>>>>>
>>>>>>>> errors log:
>>>>>>>>
>>>>>>>>
>>>>>>>> [26/May/2011:10:20:34 -0400]
>>>>>>>> NSMMReplicationPlugin - Beginning
>>>>>>>> total update of replica
>>>>>>>> "agmt="cn=ADsync" (wodcstage-1:389)".
>>>>>>>> [26/May/2011:10:20:34 -0400]
>>>>>>>> NSMMReplicationPlugin - Finished
>>>>>>>> total update of replica
>>>>>>>> "agmt="cn=ADsync"
>>>>>>>> (wodcstage-1:389)". Sent 0 entries.
>>>>>>>>
>>>>>>>> access log:
>>>>>>>>
>>>>>>>> 26/May/2011:10:20:37 -0400] conn=11
>>>>>>>> op=819 SRCH base="cn=ADsync,
>>>>>>>> cn=replica,
>>>>>>>> cn=\22dc=algonquincollege,
>>>>>>>> dc=com\22, cn=mapping tree,
>>>>>>>> cn=config" scope=0
>>>>>>>> filter="(|(objectClass=*)(objectClass=ldapsubentry))"
>>>>>>>> attrs="nsds5replicaLastUpdateStart
>>>>>>>> nsds5replicaLastUpdateEnd
>>>>>>>> nsds5replicaChangesSentSinceStartup
>>>>>>>> nsds5replicaLastUpdateStatus
>>>>>>>> nsds5replicaUpdateInProgress
>>>>>>>> nsds5replicaLastInitStart
>>>>>>>> nsds5replicaLastInitEnd
>>>>>>>> nsds5replicaLastInitStatus
>>>>>>>> nsds5BeginReplicaRefresh"
>>>>>>>> [26/May/2011:10:20:37 -0400]
>>>>>>>> conn=11 op=819 RESULT err=0 tag=101
>>>>>>>> nentries=1 etime=0
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>> Albert
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 389 users mailing list
>>>>>>>> 389-users at lists.fedoraproject.org <mailto:389-users at lists.fedoraproject.org>
>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Albert Teh
>>>>>>> Email:Teh.Albert at Gmail.com
>>>>>>> <mailto:Teh.Albert at Gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Albert Teh
>>>>>> Email:Teh.Albert at Gmail.com
>>>>>> <mailto:Teh.Albert at Gmail.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Albert Teh
>>>>> Email:Teh.Albert at Gmail.com
>>>>> <mailto:Teh.Albert at Gmail.com>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Albert Teh
>>>> Email:Teh.Albert at Gmail.com <mailto:Teh.Albert at Gmail.com>
>>>
>>>
>>>
>>> HI Rich,
>>>
>>> These two commands worked and got the result. I have been
>>> gone through the Windows Sync agreement setup for many
>>> times. I could not figure out what went wrong.
>>> Thanks a lot for your help again.
>> Are you sure that the user
>> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
>> has Replication/Replicator rights in AD/Windows?
>>
>>>
>>> Albert
>>>
>>> /usr/lib/mozldap/ldapsearch -x
>>> -hwodcstage-1.ottawa.ad.algonquincollege.com
>>> <http://wodcstage-1.ottawa.ad.algonquincollege.com/> -w - -D
>>> "cn=mailadm,cn=Users,dc=[root at algldap ~]#
>>> /usr/lib/mozldap/ldapsearch -x
>>> -hwodcstage-1.ottawa.ad.algonquincollege.com
>>> <http://wodcstage-1.ottawa.ad.algonquincollege.com> -w - -D
>>> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
>>> -s base -b "" "objectclass=*" Enter bind password:
>>> version: 1
>>> dn:
>>> currentTime: 20110601001342.0Z
>>> subschemaSubentry:
>>> CN=Aggregate,CN=Schema,CN=Configuration,DC=ad,DC=algonquinc
>>> ollege,DC=com
>>> dsServiceName: CN=NTDS
>>> Settings,CN=WODCSTAGE-1,CN=Servers,CN=Default-First-Sit
>>> e-Name,CN=Sites,CN=Configuration,DC=ad,DC=algonquincollege,DC=com
>>> namingContexts:
>>> CN=Configuration,DC=ad,DC=algonquincollege,DC=com
>>> namingContexts:
>>> CN=Schema,CN=Configuration,DC=ad,DC=algonquincollege,DC=com
>>> namingContexts: DC=ottawa,DC=ad,DC=algonquincollege,DC=com
>>> defaultNamingContext: DC=ottawa,DC=ad,DC=algonquincollege,DC=com
>>> schemaNamingContext:
>>> CN=Schema,CN=Configuration,DC=ad,DC=algonquincollege,DC=c
>>> om
>>> configurationNamingContext:
>>> CN=Configuration,DC=ad,DC=algonquincollege,DC=com
>>> rootDomainNamingContext: DC=ad,DC=algonquincollege,DC=com
>>> supportedControl: 1.2.840.113556.1.4.319
>>> supportedControl: 1.2.840.113556.1.4.801
>>> supportedControl: 1.2.840.113556.1.4.473
>>> supportedControl: 1.2.840.113556.1.4.528
>>> supportedControl: 1.2.840.113556.1.4.417
>>> supportedControl: 1.2.840.113556.1.4.619
>>> supportedControl: 1.2.840.113556.1.4.841
>>> supportedControl: 1.2.840.113556.1.4.529
>>> supportedControl: 1.2.840.113556.1.4.805
>>> supportedControl: 1.2.840.113556.1.4.521
>>> supportedControl: 1.2.840.113556.1.4.970
>>> supportedControl: 1.2.840.113556.1.4.1338
>>> supportedControl: 1.2.840.113556.1.4.474
>>> supportedControl: 1.2.840.113556.1.4.1339
>>> supportedControl: 1.2.840.113556.1.4.1340
>>> supportedControl: 1.2.840.113556.1.4.1413
>>> supportedControl: 2.16.840.1.113730.3.4.9
>>> supportedControl: 2.16.840.1.113730.3.4.10
>>> supportedControl: 1.2.840.113556.1.4.1504
>>> supportedControl: 1.2.840.113556.1.4.1852
>>> supportedControl: 1.2.840.113556.1.4.802
>>> supportedControl: 1.2.840.113556.1.4.1907
>>> supportedControl: 1.2.840.113556.1.4.1948
>>> supportedLDAPVersion: 3
>>> supportedLDAPVersion: 2
>>> supportedLDAPPolicies: MaxPoolThreads
>>> supportedLDAPPolicies: MaxDatagramRecv
>>> supportedLDAPPolicies: MaxReceiveBuffer
>>> supportedLDAPPolicies: InitRecvTimeout
>>> supportedLDAPPolicies: MaxConnections
>>> supportedLDAPPolicies: MaxConnIdleTime
>>> supportedLDAPPolicies: MaxPageSize
>>> supportedLDAPPolicies: MaxQueryDuration
>>> supportedLDAPPolicies: MaxTempTableSize
>>> supportedLDAPPolicies: MaxResultSetSize
>>> supportedLDAPPolicies: MaxNotificationPerConn
>>> supportedLDAPPolicies: MaxValRange
>>> highestCommittedUSN:3103418 <tel:3103418>
>>> supportedSASLMechanisms: GSSAPI
>>> supportedSASLMechanisms: GSS-SPNEGO
>>> supportedSASLMechanisms: EXTERNAL
>>> supportedSASLMechanisms: DIGEST-MD5
>>> dnsHostName:WODCStage-1.ottawa.ad.algonquincollege.com
>>> <http://WODCStage-1.ottawa.ad.algonquincollege.com>
>>> ldapServiceName:ad.algonquincollege.com:wodcstage-1$@OTTAWA.AD.ALGONQUINCOLLE
>>> <mailto:ad.algonquincollege.com:wodcstage-1$@OTTAWA.AD.ALGONQUINCOLLE>
>>> GE.COM <http://GE.COM>
>>> serverName:
>>> CN=WODCSTAGE-1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=C
>>> onfiguration,DC=ad,DC=algonquincollege,DC=com
>>> supportedCapabilities: 1.2.840.113556.1.4.800
>>> supportedCapabilities: 1.2.840.113556.1.4.1670
>>> supportedCapabilities: 1.2.840.113556.1.4.1791
>>> isSynchronized: TRUE
>>> isGlobalCatalogReady: TRUE
>>> domainFunctionality: 2
>>> forestFunctionality: 2
>>> domainControllerFunctionality: 2
>>> [root at algldap ~]#
>>>
>>> Partial out:
>>>
>>> [root at algldap ~]# /usr/lib/mozldap/ldapsearch -x
>>> -hwodcstage-1.ottawa.ad.algonquincollege.com
>>> <http://wodcstage-1.ottawa.ad.algonquincollege.com> -w - -D
>>> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
>>> -s sub -b
>>> "cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
>>> "objectclass=person" | more
>>> Enter bind password:
>>> version: 1
>>> dn:
>>> CN=isp-transfer,CN=Users,DC=ottawa,DC=ad,DC=algonquincollege,DC=com
>>> objectClass: top
>>> objectClass: person
>>> objectClass: organizationalPerson
>>> objectClass: user
>>> cn: isp-transfer
>>> description: Transfer for Genesis Data to International
>>> Student Program share
>>> givenName: isp-transfer
>>> distinguishedName:
>>> CN=isp-transfer,CN=Users,DC=ottawa,DC=ad,DC=algonquincolleg
>>> e,DC=com
>>> instanceType: 4
>>> whenCreated: 20040517155823.0Z
>>> whenChanged: 20081016173006.0Z
>>> displayName: isp-transfer
>>> uSNCreated: 255422
>>> memberOf:
>>> CN=NAS_Transfer_Genesis_ISP,OU=Groups,DC=ottawa,DC=ad,DC=algonquinco
>>> llege,DC=com
>>> uSNChanged: 255422
>>> name: isp-transfer
>>> objectGUID:: EaeRW3KiMUac6hzEs//X/g==
>>> userAccountControl: 66048
>>> badPwdCount: 0
>>> codePage: 0
>>> countryCode: 0
>>> badPasswordTime: 0
>>> lastLogoff: 0
>>> lastLogon: 0
>>> pwdLastSet: 127292831041031250
>>> primaryGroupID: 513
>>> objectSid:: AQUAAAAAAAUVAAAArhyVdhR1dBOOfkA4DN8BAA==
>>> accountExpires: 9223372036854775807
>>> logonCount: 0
>>> sAMAccountName: isp-transfer
>>> sAMAccountType: 805306368
>>> userPrincipalName:isp-transfer at algonquincollege.com
>>> <mailto:isp-transfer at algonquincollege.com>
>>> lockoutTime: 0
>>> objectCategory:
>>> CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=algonquincollege
>>> ,DC=com
>>> dSCorePropagationData: 20110131155635.0Z
>>> dSCorePropagationData: 20091227191115.0Z
>>> dSCorePropagationData: 20090127144505.0Z
>>> dSCorePropagationData: 20081201175842.0Z
>>> dSCorePropagationData: 16010714223649.0Z
>>> lastLogonTimestamp: 128686221598537375
>>>
>>> dn:
>>> CN=heatweb,CN=Users,DC=ottawa,DC=ad,DC=algonquincollege,DC=com
>>> objectClass: top
>>> objectClass: person
>>> objectClass: organizationalPerson
>>> objectClass: user
>>> cn: heatweb
>>> sn: heatweb
>>> description: Used to communicate between HEAT and IIS
>>> distinguishedName:
>>> CN=heatweb,CN=Users,DC=ottawa,DC=ad,DC=algonquincollege,DC=
>>> com
>>> instanceType: 4
>>> whenCreated: 20050218192725.0Z
>>> whenChanged: 20081016172611.0Z
>>> displayName: heatweb
>>> uSNCreated: 89976
>>> memberOf: CN=Heat
>>> Users,OU=Groups,DC=ottawa,DC=ad,DC=algonquincollege,DC=com
>>> uSNChanged: 89976
>>> name: heatweb
>>> objectGUID:: 07KJaAgkGUapXbQN7VprrQ==
>>> userAccountControl: 66048
>>> badPwdCount: 0
>>> codePage: 0
>>> countryCode: 0
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Albert Teh
>>> Email:Teh.Albert at Gmail.com <mailto:Teh.Albert at Gmail.com>
>>
>>
>>
>>
>> --
>> Albert Teh
>> Email:Teh.Albert at Gmail.com
>
>
>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20110602/867471ac/attachment.html>
More information about the 389-users
mailing list