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(a)redhat.com> ������
----- ��������-----
*������:*"Rich Megginson" <rmeggins(a)redhat.com>
*��������:*2011��6��2�� ������
*������:*"Albert Teh" <teh.albert(a)gmail.com>
*����:*"General discussion list for the 389 Directory server
project." <389-users(a)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(a)redhat.com <mailto:rmeggins@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(a)redhat.com <mailto:rmeggins@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(a)redhat.com
>>> <mailto:rmeggins@redhat.com>> wrote:
>>>
>>> On 05/31/2011 10:30 AM, Albert Teh wrote:
>>>>
>>>> HI Rich,
>>>>
>>>> [root@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@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-si...
>>>
>>>>
>>>> Thanks.
>>>> Albert
>>>>
>>>> On Tue, May 31, 2011 at 11:42 AM, Rich
>>>> Megginson<rmeggins(a)redhat.com
>>>> <mailto:rmeggins@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@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@algldap slapd-algldap]#
>>>>>
>>>>>
>>>>>
>>>>> On Fri, May 27, 2011 at 10:57 AM, Rich
>>>>> Megginson<rmeggins(a)redhat.com
>>>>> <mailto:rmeggins@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-singl...
>>>>>
>>>>>
>>>>>>
>>>>>> 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(a)redhat.com
>>>>>> <mailto:rmeggins@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(a)lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>
>>>>>>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Albert Teh
>>>>>> Email:Teh.Albert@Gmail.com
>>>>>> <mailto:Teh.Albert@Gmail.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Albert Teh
>>>>> Email:Teh.Albert@Gmail.com
>>>>> <mailto:Teh.Albert@Gmail.com>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Albert Teh
>>>> Email:Teh.Albert@Gmail.com
>>>> <mailto:Teh.Albert@Gmail.com>
>>>
>>>
>>>
>>>
>>> --
>>> Albert Teh
>>> Email:Teh.Albert@Gmail.com <mailto:Teh.Albert@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@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@algldap ~]#
>>
>> Partial out:
>>
>> [root@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@algonquincollege.com
>> <mailto:isp-transfer@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@Gmail.com <mailto:Teh.Albert@Gmail.com>
>
>
>
>
> --
> Albert Teh
> Email:Teh.Albert@Gmail.com
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users