From abartlet at samba.org Wed Nov 1 03:44:02 2006 From: abartlet at samba.org (Andrew Bartlett) Date: Wed, 01 Nov 2006 14:44:02 +1100 Subject: [Fedora-directory-devel] Attribute to determine allowed write attributes? Message-ID: <1162352642.31477.123.camel@localhost.localdomain> In working towards the Samba4/FDS glue, I was wondering if I could make a feature request. From discussions around the office, I think this may have already been asked for... I would like an attribute that can act as a 'get effective rights', for the current user. Apparently Microsoft's MMC uses such an attribute to determine what to grey out in the management console. I'm told there is a exop I can use, but for simple implementation reasons, it would be much easier if this were a special attribute instead. (That way, I can include it with the rest of my munged search). Does anybody have any pointers to an existing feature request like this, or should I file one in Bugzilla? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david_list at boreham.org Wed Nov 1 04:05:58 2006 From: david_list at boreham.org (David Boreham) Date: Tue, 31 Oct 2006 21:05:58 -0700 Subject: [Fedora-directory-devel] Attribute to determine allowed write attributes? In-Reply-To: <1162352642.31477.123.camel@localhost.localdomain> References: <1162352642.31477.123.camel@localhost.localdomain> Message-ID: <45481D26.2020409@boreham.org> Andrew Bartlett wrote: >Does anybody have any pointers to an existing feature request like this, >or should I file one in Bugzilla? > > This is what is implemented : http://www.redhat.com/docs/manuals/dir-server/ag/7.1/acl.html#1216899 From abartlet at samba.org Wed Nov 1 08:36:29 2006 From: abartlet at samba.org (Andrew Bartlett) Date: Wed, 01 Nov 2006 19:36:29 +1100 Subject: [Fedora-directory-devel] Attribute to determine allowed write attributes? In-Reply-To: <45481D26.2020409@boreham.org> References: <1162352642.31477.123.camel@localhost.localdomain> <45481D26.2020409@boreham.org> Message-ID: <1162370189.31477.127.camel@localhost.localdomain> On Tue, 2006-10-31 at 21:05 -0700, David Boreham wrote: > Andrew Bartlett wrote: > > >Does anybody have any pointers to an existing feature request like this, > >or should I file one in Bugzilla? > > > > > This is what is implemented : > > http://www.redhat.com/docs/manuals/dir-server/ag/7.1/acl.html#1216899 That has: > Information is not given for attributes in an entry that do not have a > value; for example, if the userPassword value is removed, then a > future effective rights search on the entry above would not return any > effective rights for userPassword, even though self-write and > self-delete rights could be allowed. Likewise, if the street attribute > were added with read, compare, and search rights, then street: rsc > would appear in the attributeLevelRights results. I need information on unknown attributes, so that MMC can show them as valid, writable fields (not greyed out). My preferred format is a list of writable fields, as permitted by the current schema for that entry. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david_list at boreham.org Wed Nov 1 13:23:09 2006 From: david_list at boreham.org (David Boreham) Date: Wed, 01 Nov 2006 06:23:09 -0700 Subject: [Fedora-directory-devel] Attribute to determine allowed write attributes? In-Reply-To: <1162370189.31477.127.camel@localhost.localdomain> References: <1162352642.31477.123.camel@localhost.localdomain> <45481D26.2020409@boreham.org> <1162370189.31477.127.camel@localhost.localdomain> Message-ID: <45489FBD.3080908@boreham.org> Andrew Bartlett wrote: >>Information is not given for attributes in an entry that do not have a >>value; for example, if the userPassword value is removed, then a >>future effective rights search on the entry above would not return any >>effective rights for userPassword, even though self-write and >>self-delete rights could be allowed. Likewise, if the street attribute >>were added with read, compare, and search rights, then street: rsc >>would appear in the attributeLevelRights results. >> >> > >I need information on unknown attributes, so that MMC can show them as >valid, writable fields (not greyed out). My preferred format is a list >of writable fields, as permitted by the current schema for that entry. > > Do you need it to come up with a list of all allowed attributes (probably not a good idea for implementation and performance reasons), or do you want to supply the list (better, but not the way the GER control works) ? I suppose you could supply an attribute list for the search and GER could use that. That'd be reasonably efficient and easy to implement, I think. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Nov 1 14:05:33 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Wed, 01 Nov 2006 07:05:33 -0700 Subject: [Fedora-directory-devel] Attribute to determine allowed write attributes? In-Reply-To: <1162370189.31477.127.camel@localhost.localdomain> References: <1162352642.31477.123.camel@localhost.localdomain> <45481D26.2020409@boreham.org> <1162370189.31477.127.camel@localhost.localdomain> Message-ID: <4548A9AD.7090408@redhat.com> Andrew Bartlett wrote: > On Tue, 2006-10-31 at 21:05 -0700, David Boreham wrote: > >> Andrew Bartlett wrote: >> >> >>> Does anybody have any pointers to an existing feature request like this, >>> or should I file one in Bugzilla? >>> >>> >>> >> This is what is implemented : >> >> http://www.redhat.com/docs/manuals/dir-server/ag/7.1/acl.html#1216899 >> > > That has: > > >> Information is not given for attributes in an entry that do not have a >> value; for example, if the userPassword value is removed, then a >> future effective rights search on the entry above would not return any >> effective rights for userPassword, even though self-write and >> self-delete rights could be allowed. Likewise, if the street attribute >> were added with read, compare, and search rights, then street: rsc >> would appear in the attributeLevelRights results. >> > > I need information on unknown attributes, so that MMC can show them as > valid, writable fields (not greyed out). My preferred format is a list > of writable fields, as permitted by the current schema for that entry. > This could be useful in any general purpose GUI app, to have the ability to perform one query and get back a list of 1) regular attributes available according to the schema 2) operational attributes - writable vs. read-only 3) virtual attributes - writable vs. read-only I would like to support the openldap "+" special attribute which retrieves all operational attributes, and I would also like to support the Sun DS real and virtual attrs controls. Andrew, I think it would be beneficial to me if you could post an example ldapsearch and an example return entry in LDIF. > Andrew Bartlett > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From prowley at redhat.com Wed Nov 1 18:29:58 2006 From: prowley at redhat.com (Pete Rowley) Date: Wed, 01 Nov 2006 10:29:58 -0800 Subject: [Fedora-directory-devel] Attribute to determine allowed write attributes? In-Reply-To: <4548A9AD.7090408@redhat.com> References: <1162352642.31477.123.camel@localhost.localdomain> <45481D26.2020409@boreham.org> <1162370189.31477.127.camel@localhost.localdomain> <4548A9AD.7090408@redhat.com> Message-ID: <4548E7A6.1040802@redhat.com> Richard Megginson wrote: > Andrew Bartlett wrote: >> On Tue, 2006-10-31 at 21:05 -0700, David Boreham wrote: >> >>> Andrew Bartlett wrote: >>> >>> >>>> Does anybody have any pointers to an existing feature request like >>>> this, >>>> or should I file one in Bugzilla? >>>> >>>> >>>> >>> This is what is implemented : >>> >>> http://www.redhat.com/docs/manuals/dir-server/ag/7.1/acl.html#1216899 >>> >> >> That has: >> >> >>> Information is not given for attributes in an entry that do not have a >>> value; for example, if the userPassword value is removed, then a >>> future effective rights search on the entry above would not return any >>> effective rights for userPassword, even though self-write and >>> self-delete rights could be allowed. Likewise, if the street attribute >>> were added with read, compare, and search rights, then street: rsc >>> would appear in the attributeLevelRights results. >>> >> >> I need information on unknown attributes, so that MMC can show them as >> valid, writable fields (not greyed out). My preferred format is a list >> of writable fields, as permitted by the current schema for that entry. >> > This could be useful in any general purpose GUI app, to have the > ability to perform one query and get back a list of > 1) regular attributes available according to the schema > 2) operational attributes - writable vs. read-only > 3) virtual attributes - writable vs. read-only > > I would like to support the openldap "+" special attribute which > retrieves all operational attributes, and I would also like to support > the Sun DS real and virtual attrs controls. > I wrote the Sun DS real and virtual attrs controls before the fork, so we do :) Attached a little rootDSE decoder python script. -- Pete -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ldapinfo URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Wed Nov 1 22:32:51 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Wed, 01 Nov 2006 15:32:51 -0700 Subject: [Fedora-directory-devel] Redux: Please review: Bug 213352: autotools: support redhat/fedora rpmbuild %configure and %makeinstall Message-ID: <45492093.2050107@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213352 Bug(s) fixed: 213352 Bug Description: autotools: support redhat/fedora rpmbuild %configure and %makeinstall Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The standard way to do an rpmbuild on fedora/redhat is to use the %configure macro in the %prep section of the spec file and the %makeinstall macro in the %install section. These set all of the bindir, libdir, datadir, sysconfdir, etc. paths used by the application. %configure sets them to their "real" runtime locations e.g. /usr/lib, and %makeinstall sets them to their paths used for rpm packaging e.g. /var/tmp/fedora-ds-foo-bar-baz/usr/lib. There were a few places in our autotools files where we were running afoul of this. Another thing is that configure defines bindir etc. as literally '${exec_prefix}/bin' so that the real value doesn't get expanded until make or make install time. This means that we cannot create scripts from templates in configure, we have to do that in make. So this adds a sed command to Makefile.am in order to do all of the script and config file path replacement at make time. Since we do the subst this way, whatever $prefix is set during make will be incorporated into the value of $bindir etc. so we can omit directly referencing @prefix@ in the template files. Platforms tested: RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139919&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Wed Nov 1 23:11:24 2006 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 02 Nov 2006 10:11:24 +1100 Subject: [Fedora-directory-devel] Attribute to determine allowed write attributes? In-Reply-To: <4548A9AD.7090408@redhat.com> References: <1162352642.31477.123.camel@localhost.localdomain> <45481D26.2020409@boreham.org> <1162370189.31477.127.camel@localhost.localdomain> <4548A9AD.7090408@redhat.com> Message-ID: <1162422685.31477.155.camel@localhost.localdomain> On Wed, 2006-11-01 at 07:05 -0700, Richard Megginson wrote: > Andrew Bartlett wrote: > > On Tue, 2006-10-31 at 21:05 -0700, David Boreham wrote: > > > >> Andrew Bartlett wrote: > >> > >> > >>> Does anybody have any pointers to an existing feature request like this, > >>> or should I file one in Bugzilla? > >>> > >>> > >>> > >> This is what is implemented : > >> > >> http://www.redhat.com/docs/manuals/dir-server/ag/7.1/acl.html#1216899 > >> > > > > That has: > > > > > >> Information is not given for attributes in an entry that do not have a > >> value; for example, if the userPassword value is removed, then a > >> future effective rights search on the entry above would not return any > >> effective rights for userPassword, even though self-write and > >> self-delete rights could be allowed. Likewise, if the street attribute > >> were added with read, compare, and search rights, then street: rsc > >> would appear in the attributeLevelRights results. > >> > > > > I need information on unknown attributes, so that MMC can show them as > > valid, writable fields (not greyed out). My preferred format is a list > > of writable fields, as permitted by the current schema for that entry. > > > This could be useful in any general purpose GUI app, to have the ability > to perform one query and get back a list of > 1) regular attributes available according to the schema > 2) operational attributes - writable vs. read-only > 3) virtual attributes - writable vs. read-only > > I would like to support the openldap "+" special attribute which > retrieves all operational attributes, and I would also like to support > the Sun DS real and virtual attrs controls. > > Andrew, I think it would be beneficial to me if you could post an > example ldapsearch and an example return entry in LDIF. Using Samba's ldbsearch: bin/ldbsearch -H ldap://win2k3dc.win2k3.abartlet.net cn=administrator allowedAttributes allowedAttributesEffective allowedClasses AllowedClassesEffective -Uadministrator%penguin (see attached). Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- Unknown parameter encountered: "tls enable" Ignoring unknown parameter "tls enable" # record 1 dn: CN=Administrator,CN=Users,DC=win2k3,DC=abartlet,DC=net allowedAttributes: msExchOmaAdminExtendedSettings allowedAttributes: msExchOmaAdminWirelessEnable allowedAttributes: msExchTUISpeed allowedAttributes: msExchTUIVolume allowedAttributes: msExchTUIPassword allowedAttributes: msExchVoiceMailboxID allowedAttributes: msExchOriginatingForest allowedAttributes: msExchIMAPOWAURLPrefixOverride allowedAttributes: msExchPfRootUrl allowedAttributes: msExchMailboxUrl allowedAttributes: msExchPoliciesExcluded allowedAttributes: msExchPoliciesIncluded allowedAttributes: msExchCustomProxyAddresses allowedAttributes: msExchProxyCustomProxy allowedAttributes: msExchPolicyEnabled allowedAttributes: msExchPolicyOptionList allowedAttributes: msExchQueryBaseDN allowedAttributes: dLMemDefault allowedAttributes: msExchRecipLimit allowedAttributes: msExchMailboxFolderSet allowedAttributes: msExchMailboxGuid allowedAttributes: mDBOverHardQuotaLimit allowedAttributes: msExchFBURL allowedAttributes: msExchConferenceMailboxBL allowedAttributes: msExchControllingZone allowedAttributes: msExchResourceProperties allowedAttributes: msExchResourceGUID allowedAttributes: msExchIMAddress allowedAttributes: msExchIMVirtualServer allowedAttributes: msExchIMPhysicalURL allowedAttributes: msExchIMMetaPhysicalURL allowedAttributes: msExchIMACL allowedAttributes: msExchUserAccountControl allowedAttributes: msExchInconsistentState allowedAttributes: msExchPreviousAccountSid allowedAttributes: msExchUnmergedAttsPt allowedAttributes: msExchMasterAccountSid allowedAttributes: msExchMailboxSecurityDescriptor allowedAttributes: msExchHideFromAddressLists allowedAttributes: msExchUseOAB allowedAttributes: msExchADCGlobalNames allowedAttributes: msExchALObjectVersion allowedAttributes: replicationSignature allowedAttributes: msExchExpansionServerName allowedAttributes: unmergedAtts allowedAttributes: msExchHomeServerName allowedAttributes: labeledURI allowedAttributes: subSchemaSubEntry allowedAttributes: modifyTimeStamp allowedAttributes: createTimeStamp allowedAttributes: structuralObjectClass allowedAttributes: userPKCS12 allowedAttributes: preferredLanguage allowedAttributes: thumbnailLogo allowedAttributes: thumbnailPhoto allowedAttributes: middleName allowedAttributes: departmentNumber allowedAttributes: carLicense allowedAttributes: jpegPhoto allowedAttributes: audio allowedAttributes: pager allowedAttributes: mobile allowedAttributes: secretary allowedAttributes: homePhone allowedAttributes: manager allowedAttributes: photo allowedAttributes: roomNumber allowedAttributes: mail allowedAttributes: textEncodedORAddress allowedAttributes: uid allowedAttributes: userSMIMECertificate allowedAttributes: msExchRequireAuthToSendTo allowedAttributes: msDRM-IdentityCertificate allowedAttributes: msDS-ObjectReferenceBL allowedAttributes: msDs-masteredBy allowedAttributes: msDS-TasksForAzRoleBL allowedAttributes: msDS-OperationsForAzRoleBL allowedAttributes: msDS-TasksForAzTaskBL allowedAttributes: msDS-OperationsForAzTaskBL allowedAttributes: msDS-MembersForAzRoleBL allowedAttributes: msDS-NonMembersBL allowedAttributes: msDS-AllowedToDelegateTo allowedAttributes: msIIS-FTPDir allowedAttributes: msIIS-FTPRoot allowedAttributes: msDS-KeyVersionNumber allowedAttributes: msDS-ReplValueMetaData allowedAttributes: msDS-ReplAttributeMetaData allowedAttributes: msDS-NCReplOutboundNeighbors allowedAttributes: msDS-NCReplInboundNeighbors allowedAttributes: msDS-NCReplCursors allowedAttributes: lastLogonTimestamp allowedAttributes: msDS-Approx-Immed-Subordinates allowedAttributes: msDS-User-Account-Control-Computed allowedAttributes: msDS-Site-Affinity allowedAttributes: msDS-Cached-Membership-Time-Stamp allowedAttributes: msDS-Cached-Membership allowedAttributes: msCOM-UserPartitionSetLink allowedAttributes: msCOM-UserLink allowedAttributes: msCOM-PartitionSetLink allowedAttributes: tokenGroupsGlobalAndUniversal allowedAttributes: mS-DS-CreatorSID allowedAttributes: masteredBy allowedAttributes: mS-DS-ConsistencyChildCount allowedAttributes: mS-DS-ConsistencyGuid allowedAttributes: otherWellKnownObjects allowedAttributes: dSCorePropagationData allowedAttributes: accountNameHistory allowedAttributes: sDRightsEffective allowedAttributes: tokenGroupsNoGCAcceptable allowedAttributes: tokenGroups allowedAttributes: proxiedObjectName allowedAttributes: msRASSavedFramedRoute allowedAttributes: msRASSavedFramedIPAddress allowedAttributes: msRASSavedCallbackNumber allowedAttributes: msRADIUSServiceType allowedAttributes: msRADIUSFramedRoute allowedAttributes: msRADIUSFramedIPAddress allowedAttributes: msRADIUSCallbackNumber allowedAttributes: msNPSavedCallingStationID allowedAttributes: msNPCallingStationID allowedAttributes: msNPAllowDialin allowedAttributes: mSMQSignCertificatesMig allowedAttributes: mSMQDigestsMig allowedAttributes: mSMQDigests allowedAttributes: mSMQSignCertificates allowedAttributes: canonicalName allowedAttributes: possibleInferiors allowedAttributes: allowedAttributesEffective allowedAttributes: allowedAttributes allowedAttributes: allowedChildClassesEffective allowedAttributes: allowedChildClasses allowedAttributes: fromEntry allowedAttributes: uSNSource allowedAttributes: terminalServer allowedAttributes: fRSMemberReferenceBL allowedAttributes: frsComputerReferenceBL allowedAttributes: isCriticalSystemObject allowedAttributes: altSecurityIdentities allowedAttributes: netbootSCPBL allowedAttributes: bridgeheadServerListBL allowedAttributes: lastKnownParent allowedAttributes: aCSPolicyName allowedAttributes: servicePrincipalName allowedAttributes: userSharedFolderOther allowedAttributes: userSharedFolder allowedAttributes: url allowedAttributes: otherIpPhone allowedAttributes: ipPhone allowedAttributes: partialAttributeDeletionList allowedAttributes: lockoutTime allowedAttributes: userPrincipalName allowedAttributes: legacyExchangeDN allowedAttributes: managedObjects allowedAttributes: assistant allowedAttributes: otherMailbox allowedAttributes: mhsORAddress allowedAttributes: primaryInternationalISDNNumber allowedAttributes: primaryTelexNumber allowedAttributes: otherMobile allowedAttributes: otherFacsimileTelephoneNumber allowedAttributes: userCert allowedAttributes: showInAddressBook allowedAttributes: partialAttributeSet allowedAttributes: isPrivilegeHolder allowedAttributes: wellKnownObjects allowedAttributes: sIDHistory allowedAttributes: queryPolicyBL allowedAttributes: dynamicLDAPServer allowedAttributes: nonSecurityMemberBL allowedAttributes: serverReferenceBL allowedAttributes: siteObjectBL allowedAttributes: systemFlags allowedAttributes: fSMORoleOwner allowedAttributes: desktopProfile allowedAttributes: groupPriority allowedAttributes: groupsToIgnore allowedAttributes: sAMAccountType allowedAttributes: wbemPath allowedAttributes: division allowedAttributes: defaultClassStore allowedAttributes: controlAccessRights allowedAttributes: logonCount allowedAttributes: groupMembershipSAM allowedAttributes: lmPwdHistory allowedAttributes: accountExpires allowedAttributes: comment allowedAttributes: rid allowedAttributes: adminCount allowedAttributes: revision allowedAttributes: operatorCount allowedAttributes: versionNumber allowedAttributes: profilePath allowedAttributes: userParameters allowedAttributes: supplementalCredentials allowedAttributes: securityIdentifier allowedAttributes: primaryGroupID allowedAttributes: preferredOU allowedAttributes: pwdLastSet allowedAttributes: ntPwdHistory allowedAttributes: otherLoginWorkstations allowedAttributes: unicodePwd allowedAttributes: userWorkstations allowedAttributes: maxStorage allowedAttributes: logonWorkstation allowedAttributes: logonHours allowedAttributes: scriptPath allowedAttributes: localeID allowedAttributes: dBCSPwd allowedAttributes: lastLogon allowedAttributes: lastLogoff allowedAttributes: badPasswordTime allowedAttributes: homeDrive allowedAttributes: homeDirectory allowedAttributes: flags allowedAttributes: employeeID allowedAttributes: countryCode allowedAttributes: codePage allowedAttributes: badPwdCount allowedAttributes: userAccountControl allowedAttributes: replUpToDateVector allowedAttributes: replPropertyMetaData allowedAttributes: objectGUID allowedAttributes: name allowedAttributes: homePostalAddress allowedAttributes: language allowedAttributes: personalTitle allowedAttributes: employeeType allowedAttributes: personalPager allowedAttributes: employeeNumber allowedAttributes: formData allowedAttributes: forwardingAddress allowedAttributes: replicatedObjectVersion allowedAttributes: extensionAttribute15 allowedAttributes: extensionAttribute14 allowedAttributes: extensionAttribute13 allowedAttributes: extensionAttribute12 allowedAttributes: extensionAttribute11 allowedAttributes: supportedAlgorithms allowedAttributes: msExchHouseIdentifier allowedAttributes: msExchLabeledURI allowedAttributes: attributeCertificate allowedAttributes: internetEncoding allowedAttributes: protocolSettings allowedAttributes: dnQualifier allowedAttributes: enabledProtocols allowedAttributes: USNIntersite allowedAttributes: pOPCharacterSet allowedAttributes: languageCode allowedAttributes: pOPContentFormat allowedAttributes: wWWHomePage allowedAttributes: networkAddress allowedAttributes: heuristics allowedAttributes: mailNickname allowedAttributes: msExchAssistantName allowedAttributes: kMServer allowedAttributes: directReports allowedAttributes: extensionAttribute10 allowedAttributes: extensionAttribute9 allowedAttributes: extensionAttribute8 allowedAttributes: extensionAttribute7 allowedAttributes: extensionAttribute6 allowedAttributes: extensionAttribute5 allowedAttributes: extensionAttribute4 allowedAttributes: extensionAttribute3 allowedAttributes: extensionAttribute2 allowedAttributes: extensionAttribute1 allowedAttributes: expirationTime allowedAttributes: mAPIRecipient allowedAttributes: displayNamePrintable allowedAttributes: targetAddress allowedAttributes: folderPathname allowedAttributes: mDBUseDefaults allowedAttributes: garbageCollPeriod allowedAttributes: publicDelegatesBL allowedAttributes: altRecipientBL allowedAttributes: dLMemRejectPermsBL allowedAttributes: unauthOrigBL allowedAttributes: dLMemSubmitPermsBL allowedAttributes: authOrigBL allowedAttributes: autoReplyMessage allowedAttributes: autoReply allowedAttributes: submissionContLength allowedAttributes: otherHomePhone allowedAttributes: mDBOverQuotaLimit allowedAttributes: uSNDSALastObjRemoved allowedAttributes: mDBStorageQuota allowedAttributes: importedFrom allowedAttributes: streetAddress allowedAttributes: homeMDB allowedAttributes: deliveryMechanism allowedAttributes: publicDelegates allowedAttributes: extensionData allowedAttributes: extensionName allowedAttributes: adminDescription allowedAttributes: replicationSensitivity allowedAttributes: unauthOrig allowedAttributes: proxyAddresses allowedAttributes: adminDisplayName allowedAttributes: deliverAndRedirect allowedAttributes: homeMTA allowedAttributes: showInAdvancedViewOnly allowedAttributes: company allowedAttributes: dLMemSubmitPerms allowedAttributes: department allowedAttributes: delivExtContTypes allowedAttributes: delivContLength allowedAttributes: co allowedAttributes: authOrig allowedAttributes: altRecipient allowedAttributes: uSNLastObjRem allowedAttributes: uSNChanged allowedAttributes: otherPager allowedAttributes: deletedItemFlags allowedAttributes: businessRoles allowedAttributes: ownerBL allowedAttributes: memberOf allowedAttributes: repsFrom allowedAttributes: repsTo allowedAttributes: securityProtocol allowedAttributes: info allowedAttributes: telephoneAssistant allowedAttributes: objectVersion allowedAttributes: dSASignature allowedAttributes: isDeleted allowedAttributes: dLMemRejectPerms allowedAttributes: uSNCreated allowedAttributes: otherTelephone allowedAttributes: displayName allowedAttributes: subRefs allowedAttributes: whenChanged allowedAttributes: whenCreated allowedAttributes: attributeCertificateAttribute allowedAttributes: houseIdentifier allowedAttributes: distinguishedName allowedAttributes: x500uniqueIdentifier allowedAttributes: generationQualifier allowedAttributes: initials allowedAttributes: givenName allowedAttributes: userCertificate allowedAttributes: userPassword allowedAttributes: seeAlso allowedAttributes: preferredDeliveryMethod allowedAttributes: destinationIndicator allowedAttributes: registeredAddress allowedAttributes: internationalISDNNumber allowedAttributes: x121Address allowedAttributes: facsimileTelephoneNumber allowedAttributes: teletexTerminalIdentifier allowedAttributes: telexNumber allowedAttributes: telephoneNumber allowedAttributes: physicalDeliveryOfficeName allowedAttributes: postOfficeBox allowedAttributes: postalCode allowedAttributes: postalAddress allowedAttributes: businessCategory allowedAttributes: description allowedAttributes: title allowedAttributes: ou allowedAttributes: o allowedAttributes: street allowedAttributes: st allowedAttributes: l allowedAttributes: c allowedAttributes: serialNumber allowedAttributes: sn allowedAttributes: objectCategory allowedAttributes: sAMAccountName allowedAttributes: objectSid allowedAttributes: nTSecurityDescriptor allowedAttributes: instanceType allowedAttributes: cn allowedAttributes: objectClass allowedAttributesEffective: thumbnailPhoto allowedAttributesEffective: middleName allowedAttributesEffective: departmentNumber allowedAttributesEffective: carLicense allowedAttributesEffective: jpegPhoto allowedAttributesEffective: audio allowedAttributesEffective: pager allowedAttributesEffective: mobile allowedAttributesEffective: secretary allowedAttributesEffective: homePhone allowedAttributesEffective: manager allowedAttributesEffective: photo allowedAttributesEffective: roomNumber allowedAttributesEffective: mail allowedAttributesEffective: textEncodedORAddress allowedAttributesEffective: uid allowedAttributesEffective: userSMIMECertificate allowedAttributesEffective: msExchRequireAuthToSendTo allowedAttributesEffective: msDRM-IdentityCertificate allowedAttributesEffective: thumbnailLogo allowedAttributesEffective: preferredLanguage allowedAttributesEffective: userPKCS12 allowedAttributesEffective: labeledURI allowedAttributesEffective: msExchHomeServerName allowedAttributesEffective: unmergedAtts allowedAttributesEffective: msExchExpansionServerName allowedAttributesEffective: replicationSignature allowedAttributesEffective: msDS-AllowedToDelegateTo allowedAttributesEffective: msIIS-FTPDir allowedAttributesEffective: msIIS-FTPRoot allowedAttributesEffective: msExchALObjectVersion allowedAttributesEffective: msExchADCGlobalNames allowedAttributesEffective: msExchUseOAB allowedAttributesEffective: msExchHideFromAddressLists allowedAttributesEffective: msExchMailboxSecurityDescriptor allowedAttributesEffective: msExchMasterAccountSid allowedAttributesEffective: lastLogonTimestamp allowedAttributesEffective: msExchUnmergedAttsPt allowedAttributesEffective: msExchPreviousAccountSid allowedAttributesEffective: msDS-Site-Affinity allowedAttributesEffective: msDS-Cached-Membership-Time-Stamp allowedAttributesEffective: msDS-Cached-Membership allowedAttributesEffective: msCOM-UserPartitionSetLink allowedAttributesEffective: msExchInconsistentState allowedAttributesEffective: msExchUserAccountControl allowedAttributesEffective: msExchIMACL allowedAttributesEffective: mS-DS-CreatorSID allowedAttributesEffective: msExchIMMetaPhysicalURL allowedAttributesEffective: mS-DS-ConsistencyChildCount allowedAttributesEffective: mS-DS-ConsistencyGuid allowedAttributesEffective: otherWellKnownObjects allowedAttributesEffective: dSCorePropagationData allowedAttributesEffective: accountNameHistory allowedAttributesEffective: msExchIMPhysicalURL allowedAttributesEffective: msExchIMVirtualServer allowedAttributesEffective: msExchIMAddress allowedAttributesEffective: proxiedObjectName allowedAttributesEffective: msRASSavedFramedRoute allowedAttributesEffective: msRASSavedFramedIPAddress allowedAttributesEffective: msRASSavedCallbackNumber allowedAttributesEffective: msRADIUSServiceType allowedAttributesEffective: msRADIUSFramedRoute allowedAttributesEffective: msRADIUSFramedIPAddress allowedAttributesEffective: msRADIUSCallbackNumber allowedAttributesEffective: msNPSavedCallingStationID allowedAttributesEffective: msNPCallingStationID allowedAttributesEffective: msNPAllowDialin allowedAttributesEffective: mSMQSignCertificatesMig allowedAttributesEffective: mSMQDigestsMig allowedAttributesEffective: mSMQDigests allowedAttributesEffective: mSMQSignCertificates allowedAttributesEffective: msExchResourceGUID allowedAttributesEffective: msExchResourceProperties allowedAttributesEffective: msExchControllingZone allowedAttributesEffective: msExchFBURL allowedAttributesEffective: mDBOverHardQuotaLimit allowedAttributesEffective: msExchMailboxGuid allowedAttributesEffective: msExchMailboxFolderSet allowedAttributesEffective: uSNSource allowedAttributesEffective: terminalServer allowedAttributesEffective: msExchRecipLimit allowedAttributesEffective: dLMemDefault allowedAttributesEffective: isCriticalSystemObject allowedAttributesEffective: altSecurityIdentities allowedAttributesEffective: msExchQueryBaseDN allowedAttributesEffective: msExchPolicyOptionList allowedAttributesEffective: lastKnownParent allowedAttributesEffective: aCSPolicyName allowedAttributesEffective: servicePrincipalName allowedAttributesEffective: userSharedFolderOther allowedAttributesEffective: userSharedFolder allowedAttributesEffective: url allowedAttributesEffective: otherIpPhone allowedAttributesEffective: ipPhone allowedAttributesEffective: partialAttributeDeletionList allowedAttributesEffective: lockoutTime allowedAttributesEffective: userPrincipalName allowedAttributesEffective: legacyExchangeDN allowedAttributesEffective: msExchPolicyEnabled allowedAttributesEffective: assistant allowedAttributesEffective: otherMailbox allowedAttributesEffective: mhsORAddress allowedAttributesEffective: primaryInternationalISDNNumber allowedAttributesEffective: primaryTelexNumber allowedAttributesEffective: otherMobile allowedAttributesEffective: otherFacsimileTelephoneNumber allowedAttributesEffective: userCert allowedAttributesEffective: showInAddressBook allowedAttributesEffective: partialAttributeSet allowedAttributesEffective: msExchProxyCustomProxy allowedAttributesEffective: wellKnownObjects allowedAttributesEffective: sIDHistory allowedAttributesEffective: msExchCustomProxyAddresses allowedAttributesEffective: dynamicLDAPServer allowedAttributesEffective: msExchPoliciesIncluded allowedAttributesEffective: msExchPoliciesExcluded allowedAttributesEffective: msExchMailboxUrl allowedAttributesEffective: systemFlags allowedAttributesEffective: fSMORoleOwner allowedAttributesEffective: desktopProfile allowedAttributesEffective: groupPriority allowedAttributesEffective: groupsToIgnore allowedAttributesEffective: sAMAccountType allowedAttributesEffective: wbemPath allowedAttributesEffective: division allowedAttributesEffective: defaultClassStore allowedAttributesEffective: controlAccessRights allowedAttributesEffective: logonCount allowedAttributesEffective: groupMembershipSAM allowedAttributesEffective: lmPwdHistory allowedAttributesEffective: accountExpires allowedAttributesEffective: comment allowedAttributesEffective: rid allowedAttributesEffective: adminCount allowedAttributesEffective: revision allowedAttributesEffective: operatorCount allowedAttributesEffective: versionNumber allowedAttributesEffective: profilePath allowedAttributesEffective: userParameters allowedAttributesEffective: supplementalCredentials allowedAttributesEffective: securityIdentifier allowedAttributesEffective: primaryGroupID allowedAttributesEffective: preferredOU allowedAttributesEffective: pwdLastSet allowedAttributesEffective: ntPwdHistory allowedAttributesEffective: otherLoginWorkstations allowedAttributesEffective: unicodePwd allowedAttributesEffective: userWorkstations allowedAttributesEffective: maxStorage allowedAttributesEffective: logonWorkstation allowedAttributesEffective: logonHours allowedAttributesEffective: scriptPath allowedAttributesEffective: localeID allowedAttributesEffective: dBCSPwd allowedAttributesEffective: lastLogon allowedAttributesEffective: lastLogoff allowedAttributesEffective: badPasswordTime allowedAttributesEffective: homeDrive allowedAttributesEffective: homeDirectory allowedAttributesEffective: flags allowedAttributesEffective: employeeID allowedAttributesEffective: countryCode allowedAttributesEffective: codePage allowedAttributesEffective: badPwdCount allowedAttributesEffective: userAccountControl allowedAttributesEffective: replUpToDateVector allowedAttributesEffective: replPropertyMetaData allowedAttributesEffective: objectGUID allowedAttributesEffective: name allowedAttributesEffective: homePostalAddress allowedAttributesEffective: language allowedAttributesEffective: personalTitle allowedAttributesEffective: employeeType allowedAttributesEffective: personalPager allowedAttributesEffective: employeeNumber allowedAttributesEffective: formData allowedAttributesEffective: forwardingAddress allowedAttributesEffective: replicatedObjectVersion allowedAttributesEffective: extensionAttribute15 allowedAttributesEffective: extensionAttribute14 allowedAttributesEffective: extensionAttribute13 allowedAttributesEffective: extensionAttribute12 allowedAttributesEffective: extensionAttribute11 allowedAttributesEffective: supportedAlgorithms allowedAttributesEffective: msExchHouseIdentifier allowedAttributesEffective: msExchLabeledURI allowedAttributesEffective: attributeCertificate allowedAttributesEffective: internetEncoding allowedAttributesEffective: protocolSettings allowedAttributesEffective: dnQualifier allowedAttributesEffective: enabledProtocols allowedAttributesEffective: USNIntersite allowedAttributesEffective: pOPCharacterSet allowedAttributesEffective: languageCode allowedAttributesEffective: pOPContentFormat allowedAttributesEffective: wWWHomePage allowedAttributesEffective: networkAddress allowedAttributesEffective: heuristics allowedAttributesEffective: mailNickname allowedAttributesEffective: msExchAssistantName allowedAttributesEffective: kMServer allowedAttributesEffective: msExchPfRootUrl allowedAttributesEffective: extensionAttribute10 allowedAttributesEffective: extensionAttribute9 allowedAttributesEffective: extensionAttribute8 allowedAttributesEffective: extensionAttribute7 allowedAttributesEffective: extensionAttribute6 allowedAttributesEffective: extensionAttribute5 allowedAttributesEffective: extensionAttribute4 allowedAttributesEffective: extensionAttribute3 allowedAttributesEffective: extensionAttribute2 allowedAttributesEffective: extensionAttribute1 allowedAttributesEffective: expirationTime allowedAttributesEffective: mAPIRecipient allowedAttributesEffective: displayNamePrintable allowedAttributesEffective: targetAddress allowedAttributesEffective: folderPathname allowedAttributesEffective: mDBUseDefaults allowedAttributesEffective: garbageCollPeriod allowedAttributesEffective: msExchIMAPOWAURLPrefixOverride allowedAttributesEffective: msExchOriginatingForest allowedAttributesEffective: msExchVoiceMailboxID allowedAttributesEffective: msExchTUIPassword allowedAttributesEffective: msExchTUIVolume allowedAttributesEffective: msExchTUISpeed allowedAttributesEffective: autoReplyMessage allowedAttributesEffective: autoReply allowedAttributesEffective: submissionContLength allowedAttributesEffective: otherHomePhone allowedAttributesEffective: mDBOverQuotaLimit allowedAttributesEffective: uSNDSALastObjRemoved allowedAttributesEffective: mDBStorageQuota allowedAttributesEffective: importedFrom allowedAttributesEffective: streetAddress allowedAttributesEffective: homeMDB allowedAttributesEffective: deliveryMechanism allowedAttributesEffective: publicDelegates allowedAttributesEffective: extensionData allowedAttributesEffective: extensionName allowedAttributesEffective: adminDescription allowedAttributesEffective: replicationSensitivity allowedAttributesEffective: unauthOrig allowedAttributesEffective: proxyAddresses allowedAttributesEffective: adminDisplayName allowedAttributesEffective: deliverAndRedirect allowedAttributesEffective: homeMTA allowedAttributesEffective: showInAdvancedViewOnly allowedAttributesEffective: company allowedAttributesEffective: dLMemSubmitPerms allowedAttributesEffective: department allowedAttributesEffective: delivExtContTypes allowedAttributesEffective: delivContLength allowedAttributesEffective: co allowedAttributesEffective: authOrig allowedAttributesEffective: altRecipient allowedAttributesEffective: uSNLastObjRem allowedAttributesEffective: uSNChanged allowedAttributesEffective: otherPager allowedAttributesEffective: deletedItemFlags allowedAttributesEffective: businessRoles allowedAttributesEffective: msExchOmaAdminWirelessEnable allowedAttributesEffective: msExchOmaAdminExtendedSettings allowedAttributesEffective: repsFrom allowedAttributesEffective: repsTo allowedAttributesEffective: securityProtocol allowedAttributesEffective: info allowedAttributesEffective: telephoneAssistant allowedAttributesEffective: objectVersion allowedAttributesEffective: dSASignature allowedAttributesEffective: isDeleted allowedAttributesEffective: dLMemRejectPerms allowedAttributesEffective: uSNCreated allowedAttributesEffective: otherTelephone allowedAttributesEffective: displayName allowedAttributesEffective: subRefs allowedAttributesEffective: whenChanged allowedAttributesEffective: whenCreated allowedAttributesEffective: attributeCertificateAttribute allowedAttributesEffective: houseIdentifier allowedAttributesEffective: distinguishedName allowedAttributesEffective: x500uniqueIdentifier allowedAttributesEffective: generationQualifier allowedAttributesEffective: initials allowedAttributesEffective: givenName allowedAttributesEffective: userCertificate allowedAttributesEffective: userPassword allowedAttributesEffective: seeAlso allowedAttributesEffective: preferredDeliveryMethod allowedAttributesEffective: destinationIndicator allowedAttributesEffective: registeredAddress allowedAttributesEffective: internationalISDNNumber allowedAttributesEffective: x121Address allowedAttributesEffective: facsimileTelephoneNumber allowedAttributesEffective: teletexTerminalIdentifier allowedAttributesEffective: telexNumber allowedAttributesEffective: telephoneNumber allowedAttributesEffective: physicalDeliveryOfficeName allowedAttributesEffective: postOfficeBox allowedAttributesEffective: postalCode allowedAttributesEffective: postalAddress allowedAttributesEffective: businessCategory allowedAttributesEffective: description allowedAttributesEffective: title allowedAttributesEffective: ou allowedAttributesEffective: o allowedAttributesEffective: street allowedAttributesEffective: st allowedAttributesEffective: l allowedAttributesEffective: c allowedAttributesEffective: serialNumber allowedAttributesEffective: sn allowedAttributesEffective: objectCategory allowedAttributesEffective: sAMAccountName allowedAttributesEffective: objectSid allowedAttributesEffective: nTSecurityDescriptor allowedAttributesEffective: instanceType allowedAttributesEffective: cn allowedAttributesEffective: objectClass # Referral ref: ldap://exchange.win2k3.abartlet.net/DC=exchange,DC=win2k3,DC=abartlet,DC=net # Referral ref: ldap://ForestDnsZones.win2k3.abartlet.net/DC=ForestDnsZones,DC=win2k3,DC=abartlet,DC=net # Referral ref: ldap://DomainDnsZones.win2k3.abartlet.net/DC=DomainDnsZones,DC=win2k3,DC=abartlet,DC=net # Referral ref: ldap://win2k3.abartlet.net/CN=Configuration,DC=win2k3,DC=abartlet,DC=net # returned 5 records # 1 entries # 4 referrals -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rmeggins at redhat.com Thu Nov 2 01:54:36 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Wed, 01 Nov 2006 18:54:36 -0700 Subject: [Fedora-directory-devel] Attribute to determine allowed write attributes? In-Reply-To: <1162422685.31477.155.camel@localhost.localdomain> References: <1162352642.31477.123.camel@localhost.localdomain> <45481D26.2020409@boreham.org> <1162370189.31477.127.camel@localhost.localdomain> <4548A9AD.7090408@redhat.com> <1162422685.31477.155.camel@localhost.localdomain> Message-ID: <45494FDC.5000509@redhat.com> Andrew Bartlett wrote: > On Wed, 2006-11-01 at 07:05 -0700, Richard Megginson wrote: > >> Andrew Bartlett wrote: >> >>> On Tue, 2006-10-31 at 21:05 -0700, David Boreham wrote: >>> >>> >>>> Andrew Bartlett wrote: >>>> >>>> >>>> >>>>> Does anybody have any pointers to an existing feature request like this, >>>>> or should I file one in Bugzilla? >>>>> >>>>> >>>>> >>>>> >>>> This is what is implemented : >>>> >>>> http://www.redhat.com/docs/manuals/dir-server/ag/7.1/acl.html#1216899 >>>> >>>> >>> That has: >>> >>> >>> >>>> Information is not given for attributes in an entry that do not have a >>>> value; for example, if the userPassword value is removed, then a >>>> future effective rights search on the entry above would not return any >>>> effective rights for userPassword, even though self-write and >>>> self-delete rights could be allowed. Likewise, if the street attribute >>>> were added with read, compare, and search rights, then street: rsc >>>> would appear in the attributeLevelRights results. >>>> >>>> >>> I need information on unknown attributes, so that MMC can show them as >>> valid, writable fields (not greyed out). My preferred format is a list >>> of writable fields, as permitted by the current schema for that entry. >>> >>> >> This could be useful in any general purpose GUI app, to have the ability >> to perform one query and get back a list of >> 1) regular attributes available according to the schema >> 2) operational attributes - writable vs. read-only >> 3) virtual attributes - writable vs. read-only >> >> I would like to support the openldap "+" special attribute which >> retrieves all operational attributes, and I would also like to support >> the Sun DS real and virtual attrs controls. >> >> Andrew, I think it would be beneficial to me if you could post an >> example ldapsearch and an example return entry in LDIF. >> > > Using Samba's ldbsearch: > > bin/ldbsearch -H ldap://win2k3dc.win2k3.abartlet.net cn=administrator > allowedAttributes allowedAttributesEffective allowedClasses > AllowedClassesEffective -Uadministrator%penguin > What do allowedAttributes and allowedAttributesEffective mean? Are they the writable attributes as allowed by schema and access control? What does the "Effective" mean? What are allowedClasses and AllowedClassesEffective? > (see attached). > > Andrew Bartlett > > > ------------------------------------------------------------------------ > > Unknown parameter encountered: "tls enable" > Ignoring unknown parameter "tls enable" > # record 1 > dn: CN=Administrator,CN=Users,DC=win2k3,DC=abartlet,DC=net > allowedAttributes: msExchOmaAdminExtendedSettings > allowedAttributes: msExchOmaAdminWirelessEnable > allowedAttributes: msExchTUISpeed > allowedAttributes: msExchTUIVolume > allowedAttributes: msExchTUIPassword > allowedAttributes: msExchVoiceMailboxID > allowedAttributes: msExchOriginatingForest > allowedAttributes: msExchIMAPOWAURLPrefixOverride > allowedAttributes: msExchPfRootUrl > allowedAttributes: msExchMailboxUrl > allowedAttributes: msExchPoliciesExcluded > allowedAttributes: msExchPoliciesIncluded > allowedAttributes: msExchCustomProxyAddresses > allowedAttributes: msExchProxyCustomProxy > allowedAttributes: msExchPolicyEnabled > allowedAttributes: msExchPolicyOptionList > allowedAttributes: msExchQueryBaseDN > allowedAttributes: dLMemDefault > allowedAttributes: msExchRecipLimit > allowedAttributes: msExchMailboxFolderSet > allowedAttributes: msExchMailboxGuid > allowedAttributes: mDBOverHardQuotaLimit > allowedAttributes: msExchFBURL > allowedAttributes: msExchConferenceMailboxBL > allowedAttributes: msExchControllingZone > allowedAttributes: msExchResourceProperties > allowedAttributes: msExchResourceGUID > allowedAttributes: msExchIMAddress > allowedAttributes: msExchIMVirtualServer > allowedAttributes: msExchIMPhysicalURL > allowedAttributes: msExchIMMetaPhysicalURL > allowedAttributes: msExchIMACL > allowedAttributes: msExchUserAccountControl > allowedAttributes: msExchInconsistentState > allowedAttributes: msExchPreviousAccountSid > allowedAttributes: msExchUnmergedAttsPt > allowedAttributes: msExchMasterAccountSid > allowedAttributes: msExchMailboxSecurityDescriptor > allowedAttributes: msExchHideFromAddressLists > allowedAttributes: msExchUseOAB > allowedAttributes: msExchADCGlobalNames > allowedAttributes: msExchALObjectVersion > allowedAttributes: replicationSignature > allowedAttributes: msExchExpansionServerName > allowedAttributes: unmergedAtts > allowedAttributes: msExchHomeServerName > allowedAttributes: labeledURI > allowedAttributes: subSchemaSubEntry > allowedAttributes: modifyTimeStamp > allowedAttributes: createTimeStamp > allowedAttributes: structuralObjectClass > allowedAttributes: userPKCS12 > allowedAttributes: preferredLanguage > allowedAttributes: thumbnailLogo > allowedAttributes: thumbnailPhoto > allowedAttributes: middleName > allowedAttributes: departmentNumber > allowedAttributes: carLicense > allowedAttributes: jpegPhoto > allowedAttributes: audio > allowedAttributes: pager > allowedAttributes: mobile > allowedAttributes: secretary > allowedAttributes: homePhone > allowedAttributes: manager > allowedAttributes: photo > allowedAttributes: roomNumber > allowedAttributes: mail > allowedAttributes: textEncodedORAddress > allowedAttributes: uid > allowedAttributes: userSMIMECertificate > allowedAttributes: msExchRequireAuthToSendTo > allowedAttributes: msDRM-IdentityCertificate > allowedAttributes: msDS-ObjectReferenceBL > allowedAttributes: msDs-masteredBy > allowedAttributes: msDS-TasksForAzRoleBL > allowedAttributes: msDS-OperationsForAzRoleBL > allowedAttributes: msDS-TasksForAzTaskBL > allowedAttributes: msDS-OperationsForAzTaskBL > allowedAttributes: msDS-MembersForAzRoleBL > allowedAttributes: msDS-NonMembersBL > allowedAttributes: msDS-AllowedToDelegateTo > allowedAttributes: msIIS-FTPDir > allowedAttributes: msIIS-FTPRoot > allowedAttributes: msDS-KeyVersionNumber > allowedAttributes: msDS-ReplValueMetaData > allowedAttributes: msDS-ReplAttributeMetaData > allowedAttributes: msDS-NCReplOutboundNeighbors > allowedAttributes: msDS-NCReplInboundNeighbors > allowedAttributes: msDS-NCReplCursors > allowedAttributes: lastLogonTimestamp > allowedAttributes: msDS-Approx-Immed-Subordinates > allowedAttributes: msDS-User-Account-Control-Computed > allowedAttributes: msDS-Site-Affinity > allowedAttributes: msDS-Cached-Membership-Time-Stamp > allowedAttributes: msDS-Cached-Membership > allowedAttributes: msCOM-UserPartitionSetLink > allowedAttributes: msCOM-UserLink > allowedAttributes: msCOM-PartitionSetLink > allowedAttributes: tokenGroupsGlobalAndUniversal > allowedAttributes: mS-DS-CreatorSID > allowedAttributes: masteredBy > allowedAttributes: mS-DS-ConsistencyChildCount > allowedAttributes: mS-DS-ConsistencyGuid > allowedAttributes: otherWellKnownObjects > allowedAttributes: dSCorePropagationData > allowedAttributes: accountNameHistory > allowedAttributes: sDRightsEffective > allowedAttributes: tokenGroupsNoGCAcceptable > allowedAttributes: tokenGroups > allowedAttributes: proxiedObjectName > allowedAttributes: msRASSavedFramedRoute > allowedAttributes: msRASSavedFramedIPAddress > allowedAttributes: msRASSavedCallbackNumber > allowedAttributes: msRADIUSServiceType > allowedAttributes: msRADIUSFramedRoute > allowedAttributes: msRADIUSFramedIPAddress > allowedAttributes: msRADIUSCallbackNumber > allowedAttributes: msNPSavedCallingStationID > allowedAttributes: msNPCallingStationID > allowedAttributes: msNPAllowDialin > allowedAttributes: mSMQSignCertificatesMig > allowedAttributes: mSMQDigestsMig > allowedAttributes: mSMQDigests > allowedAttributes: mSMQSignCertificates > allowedAttributes: canonicalName > allowedAttributes: possibleInferiors > allowedAttributes: allowedAttributesEffective > allowedAttributes: allowedAttributes > allowedAttributes: allowedChildClassesEffective > allowedAttributes: allowedChildClasses > allowedAttributes: fromEntry > allowedAttributes: uSNSource > allowedAttributes: terminalServer > allowedAttributes: fRSMemberReferenceBL > allowedAttributes: frsComputerReferenceBL > allowedAttributes: isCriticalSystemObject > allowedAttributes: altSecurityIdentities > allowedAttributes: netbootSCPBL > allowedAttributes: bridgeheadServerListBL > allowedAttributes: lastKnownParent > allowedAttributes: aCSPolicyName > allowedAttributes: servicePrincipalName > allowedAttributes: userSharedFolderOther > allowedAttributes: userSharedFolder > allowedAttributes: url > allowedAttributes: otherIpPhone > allowedAttributes: ipPhone > allowedAttributes: partialAttributeDeletionList > allowedAttributes: lockoutTime > allowedAttributes: userPrincipalName > allowedAttributes: legacyExchangeDN > allowedAttributes: managedObjects > allowedAttributes: assistant > allowedAttributes: otherMailbox > allowedAttributes: mhsORAddress > allowedAttributes: primaryInternationalISDNNumber > allowedAttributes: primaryTelexNumber > allowedAttributes: otherMobile > allowedAttributes: otherFacsimileTelephoneNumber > allowedAttributes: userCert > allowedAttributes: showInAddressBook > allowedAttributes: partialAttributeSet > allowedAttributes: isPrivilegeHolder > allowedAttributes: wellKnownObjects > allowedAttributes: sIDHistory > allowedAttributes: queryPolicyBL > allowedAttributes: dynamicLDAPServer > allowedAttributes: nonSecurityMemberBL > allowedAttributes: serverReferenceBL > allowedAttributes: siteObjectBL > allowedAttributes: systemFlags > allowedAttributes: fSMORoleOwner > allowedAttributes: desktopProfile > allowedAttributes: groupPriority > allowedAttributes: groupsToIgnore > allowedAttributes: sAMAccountType > allowedAttributes: wbemPath > allowedAttributes: division > allowedAttributes: defaultClassStore > allowedAttributes: controlAccessRights > allowedAttributes: logonCount > allowedAttributes: groupMembershipSAM > allowedAttributes: lmPwdHistory > allowedAttributes: accountExpires > allowedAttributes: comment > allowedAttributes: rid > allowedAttributes: adminCount > allowedAttributes: revision > allowedAttributes: operatorCount > allowedAttributes: versionNumber > allowedAttributes: profilePath > allowedAttributes: userParameters > allowedAttributes: supplementalCredentials > allowedAttributes: securityIdentifier > allowedAttributes: primaryGroupID > allowedAttributes: preferredOU > allowedAttributes: pwdLastSet > allowedAttributes: ntPwdHistory > allowedAttributes: otherLoginWorkstations > allowedAttributes: unicodePwd > allowedAttributes: userWorkstations > allowedAttributes: maxStorage > allowedAttributes: logonWorkstation > allowedAttributes: logonHours > allowedAttributes: scriptPath > allowedAttributes: localeID > allowedAttributes: dBCSPwd > allowedAttributes: lastLogon > allowedAttributes: lastLogoff > allowedAttributes: badPasswordTime > allowedAttributes: homeDrive > allowedAttributes: homeDirectory > allowedAttributes: flags > allowedAttributes: employeeID > allowedAttributes: countryCode > allowedAttributes: codePage > allowedAttributes: badPwdCount > allowedAttributes: userAccountControl > allowedAttributes: replUpToDateVector > allowedAttributes: replPropertyMetaData > allowedAttributes: objectGUID > allowedAttributes: name > allowedAttributes: homePostalAddress > allowedAttributes: language > allowedAttributes: personalTitle > allowedAttributes: employeeType > allowedAttributes: personalPager > allowedAttributes: employeeNumber > allowedAttributes: formData > allowedAttributes: forwardingAddress > allowedAttributes: replicatedObjectVersion > allowedAttributes: extensionAttribute15 > allowedAttributes: extensionAttribute14 > allowedAttributes: extensionAttribute13 > allowedAttributes: extensionAttribute12 > allowedAttributes: extensionAttribute11 > allowedAttributes: supportedAlgorithms > allowedAttributes: msExchHouseIdentifier > allowedAttributes: msExchLabeledURI > allowedAttributes: attributeCertificate > allowedAttributes: internetEncoding > allowedAttributes: protocolSettings > allowedAttributes: dnQualifier > allowedAttributes: enabledProtocols > allowedAttributes: USNIntersite > allowedAttributes: pOPCharacterSet > allowedAttributes: languageCode > allowedAttributes: pOPContentFormat > allowedAttributes: wWWHomePage > allowedAttributes: networkAddress > allowedAttributes: heuristics > allowedAttributes: mailNickname > allowedAttributes: msExchAssistantName > allowedAttributes: kMServer > allowedAttributes: directReports > allowedAttributes: extensionAttribute10 > allowedAttributes: extensionAttribute9 > allowedAttributes: extensionAttribute8 > allowedAttributes: extensionAttribute7 > allowedAttributes: extensionAttribute6 > allowedAttributes: extensionAttribute5 > allowedAttributes: extensionAttribute4 > allowedAttributes: extensionAttribute3 > allowedAttributes: extensionAttribute2 > allowedAttributes: extensionAttribute1 > allowedAttributes: expirationTime > allowedAttributes: mAPIRecipient > allowedAttributes: displayNamePrintable > allowedAttributes: targetAddress > allowedAttributes: folderPathname > allowedAttributes: mDBUseDefaults > allowedAttributes: garbageCollPeriod > allowedAttributes: publicDelegatesBL > allowedAttributes: altRecipientBL > allowedAttributes: dLMemRejectPermsBL > allowedAttributes: unauthOrigBL > allowedAttributes: dLMemSubmitPermsBL > allowedAttributes: authOrigBL > allowedAttributes: autoReplyMessage > allowedAttributes: autoReply > allowedAttributes: submissionContLength > allowedAttributes: otherHomePhone > allowedAttributes: mDBOverQuotaLimit > allowedAttributes: uSNDSALastObjRemoved > allowedAttributes: mDBStorageQuota > allowedAttributes: importedFrom > allowedAttributes: streetAddress > allowedAttributes: homeMDB > allowedAttributes: deliveryMechanism > allowedAttributes: publicDelegates > allowedAttributes: extensionData > allowedAttributes: extensionName > allowedAttributes: adminDescription > allowedAttributes: replicationSensitivity > allowedAttributes: unauthOrig > allowedAttributes: proxyAddresses > allowedAttributes: adminDisplayName > allowedAttributes: deliverAndRedirect > allowedAttributes: homeMTA > allowedAttributes: showInAdvancedViewOnly > allowedAttributes: company > allowedAttributes: dLMemSubmitPerms > allowedAttributes: department > allowedAttributes: delivExtContTypes > allowedAttributes: delivContLength > allowedAttributes: co > allowedAttributes: authOrig > allowedAttributes: altRecipient > allowedAttributes: uSNLastObjRem > allowedAttributes: uSNChanged > allowedAttributes: otherPager > allowedAttributes: deletedItemFlags > allowedAttributes: businessRoles > allowedAttributes: ownerBL > allowedAttributes: memberOf > allowedAttributes: repsFrom > allowedAttributes: repsTo > allowedAttributes: securityProtocol > allowedAttributes: info > allowedAttributes: telephoneAssistant > allowedAttributes: objectVersion > allowedAttributes: dSASignature > allowedAttributes: isDeleted > allowedAttributes: dLMemRejectPerms > allowedAttributes: uSNCreated > allowedAttributes: otherTelephone > allowedAttributes: displayName > allowedAttributes: subRefs > allowedAttributes: whenChanged > allowedAttributes: whenCreated > allowedAttributes: attributeCertificateAttribute > allowedAttributes: houseIdentifier > allowedAttributes: distinguishedName > allowedAttributes: x500uniqueIdentifier > allowedAttributes: generationQualifier > allowedAttributes: initials > allowedAttributes: givenName > allowedAttributes: userCertificate > allowedAttributes: userPassword > allowedAttributes: seeAlso > allowedAttributes: preferredDeliveryMethod > allowedAttributes: destinationIndicator > allowedAttributes: registeredAddress > allowedAttributes: internationalISDNNumber > allowedAttributes: x121Address > allowedAttributes: facsimileTelephoneNumber > allowedAttributes: teletexTerminalIdentifier > allowedAttributes: telexNumber > allowedAttributes: telephoneNumber > allowedAttributes: physicalDeliveryOfficeName > allowedAttributes: postOfficeBox > allowedAttributes: postalCode > allowedAttributes: postalAddress > allowedAttributes: businessCategory > allowedAttributes: description > allowedAttributes: title > allowedAttributes: ou > allowedAttributes: o > allowedAttributes: street > allowedAttributes: st > allowedAttributes: l > allowedAttributes: c > allowedAttributes: serialNumber > allowedAttributes: sn > allowedAttributes: objectCategory > allowedAttributes: sAMAccountName > allowedAttributes: objectSid > allowedAttributes: nTSecurityDescriptor > allowedAttributes: instanceType > allowedAttributes: cn > allowedAttributes: objectClass > allowedAttributesEffective: thumbnailPhoto > allowedAttributesEffective: middleName > allowedAttributesEffective: departmentNumber > allowedAttributesEffective: carLicense > allowedAttributesEffective: jpegPhoto > allowedAttributesEffective: audio > allowedAttributesEffective: pager > allowedAttributesEffective: mobile > allowedAttributesEffective: secretary > allowedAttributesEffective: homePhone > allowedAttributesEffective: manager > allowedAttributesEffective: photo > allowedAttributesEffective: roomNumber > allowedAttributesEffective: mail > allowedAttributesEffective: textEncodedORAddress > allowedAttributesEffective: uid > allowedAttributesEffective: userSMIMECertificate > allowedAttributesEffective: msExchRequireAuthToSendTo > allowedAttributesEffective: msDRM-IdentityCertificate > allowedAttributesEffective: thumbnailLogo > allowedAttributesEffective: preferredLanguage > allowedAttributesEffective: userPKCS12 > allowedAttributesEffective: labeledURI > allowedAttributesEffective: msExchHomeServerName > allowedAttributesEffective: unmergedAtts > allowedAttributesEffective: msExchExpansionServerName > allowedAttributesEffective: replicationSignature > allowedAttributesEffective: msDS-AllowedToDelegateTo > allowedAttributesEffective: msIIS-FTPDir > allowedAttributesEffective: msIIS-FTPRoot > allowedAttributesEffective: msExchALObjectVersion > allowedAttributesEffective: msExchADCGlobalNames > allowedAttributesEffective: msExchUseOAB > allowedAttributesEffective: msExchHideFromAddressLists > allowedAttributesEffective: msExchMailboxSecurityDescriptor > allowedAttributesEffective: msExchMasterAccountSid > allowedAttributesEffective: lastLogonTimestamp > allowedAttributesEffective: msExchUnmergedAttsPt > allowedAttributesEffective: msExchPreviousAccountSid > allowedAttributesEffective: msDS-Site-Affinity > allowedAttributesEffective: msDS-Cached-Membership-Time-Stamp > allowedAttributesEffective: msDS-Cached-Membership > allowedAttributesEffective: msCOM-UserPartitionSetLink > allowedAttributesEffective: msExchInconsistentState > allowedAttributesEffective: msExchUserAccountControl > allowedAttributesEffective: msExchIMACL > allowedAttributesEffective: mS-DS-CreatorSID > allowedAttributesEffective: msExchIMMetaPhysicalURL > allowedAttributesEffective: mS-DS-ConsistencyChildCount > allowedAttributesEffective: mS-DS-ConsistencyGuid > allowedAttributesEffective: otherWellKnownObjects > allowedAttributesEffective: dSCorePropagationData > allowedAttributesEffective: accountNameHistory > allowedAttributesEffective: msExchIMPhysicalURL > allowedAttributesEffective: msExchIMVirtualServer > allowedAttributesEffective: msExchIMAddress > allowedAttributesEffective: proxiedObjectName > allowedAttributesEffective: msRASSavedFramedRoute > allowedAttributesEffective: msRASSavedFramedIPAddress > allowedAttributesEffective: msRASSavedCallbackNumber > allowedAttributesEffective: msRADIUSServiceType > allowedAttributesEffective: msRADIUSFramedRoute > allowedAttributesEffective: msRADIUSFramedIPAddress > allowedAttributesEffective: msRADIUSCallbackNumber > allowedAttributesEffective: msNPSavedCallingStationID > allowedAttributesEffective: msNPCallingStationID > allowedAttributesEffective: msNPAllowDialin > allowedAttributesEffective: mSMQSignCertificatesMig > allowedAttributesEffective: mSMQDigestsMig > allowedAttributesEffective: mSMQDigests > allowedAttributesEffective: mSMQSignCertificates > allowedAttributesEffective: msExchResourceGUID > allowedAttributesEffective: msExchResourceProperties > allowedAttributesEffective: msExchControllingZone > allowedAttributesEffective: msExchFBURL > allowedAttributesEffective: mDBOverHardQuotaLimit > allowedAttributesEffective: msExchMailboxGuid > allowedAttributesEffective: msExchMailboxFolderSet > allowedAttributesEffective: uSNSource > allowedAttributesEffective: terminalServer > allowedAttributesEffective: msExchRecipLimit > allowedAttributesEffective: dLMemDefault > allowedAttributesEffective: isCriticalSystemObject > allowedAttributesEffective: altSecurityIdentities > allowedAttributesEffective: msExchQueryBaseDN > allowedAttributesEffective: msExchPolicyOptionList > allowedAttributesEffective: lastKnownParent > allowedAttributesEffective: aCSPolicyName > allowedAttributesEffective: servicePrincipalName > allowedAttributesEffective: userSharedFolderOther > allowedAttributesEffective: userSharedFolder > allowedAttributesEffective: url > allowedAttributesEffective: otherIpPhone > allowedAttributesEffective: ipPhone > allowedAttributesEffective: partialAttributeDeletionList > allowedAttributesEffective: lockoutTime > allowedAttributesEffective: userPrincipalName > allowedAttributesEffective: legacyExchangeDN > allowedAttributesEffective: msExchPolicyEnabled > allowedAttributesEffective: assistant > allowedAttributesEffective: otherMailbox > allowedAttributesEffective: mhsORAddress > allowedAttributesEffective: primaryInternationalISDNNumber > allowedAttributesEffective: primaryTelexNumber > allowedAttributesEffective: otherMobile > allowedAttributesEffective: otherFacsimileTelephoneNumber > allowedAttributesEffective: userCert > allowedAttributesEffective: showInAddressBook > allowedAttributesEffective: partialAttributeSet > allowedAttributesEffective: msExchProxyCustomProxy > allowedAttributesEffective: wellKnownObjects > allowedAttributesEffective: sIDHistory > allowedAttributesEffective: msExchCustomProxyAddresses > allowedAttributesEffective: dynamicLDAPServer > allowedAttributesEffective: msExchPoliciesIncluded > allowedAttributesEffective: msExchPoliciesExcluded > allowedAttributesEffective: msExchMailboxUrl > allowedAttributesEffective: systemFlags > allowedAttributesEffective: fSMORoleOwner > allowedAttributesEffective: desktopProfile > allowedAttributesEffective: groupPriority > allowedAttributesEffective: groupsToIgnore > allowedAttributesEffective: sAMAccountType > allowedAttributesEffective: wbemPath > allowedAttributesEffective: division > allowedAttributesEffective: defaultClassStore > allowedAttributesEffective: controlAccessRights > allowedAttributesEffective: logonCount > allowedAttributesEffective: groupMembershipSAM > allowedAttributesEffective: lmPwdHistory > allowedAttributesEffective: accountExpires > allowedAttributesEffective: comment > allowedAttributesEffective: rid > allowedAttributesEffective: adminCount > allowedAttributesEffective: revision > allowedAttributesEffective: operatorCount > allowedAttributesEffective: versionNumber > allowedAttributesEffective: profilePath > allowedAttributesEffective: userParameters > allowedAttributesEffective: supplementalCredentials > allowedAttributesEffective: securityIdentifier > allowedAttributesEffective: primaryGroupID > allowedAttributesEffective: preferredOU > allowedAttributesEffective: pwdLastSet > allowedAttributesEffective: ntPwdHistory > allowedAttributesEffective: otherLoginWorkstations > allowedAttributesEffective: unicodePwd > allowedAttributesEffective: userWorkstations > allowedAttributesEffective: maxStorage > allowedAttributesEffective: logonWorkstation > allowedAttributesEffective: logonHours > allowedAttributesEffective: scriptPath > allowedAttributesEffective: localeID > allowedAttributesEffective: dBCSPwd > allowedAttributesEffective: lastLogon > allowedAttributesEffective: lastLogoff > allowedAttributesEffective: badPasswordTime > allowedAttributesEffective: homeDrive > allowedAttributesEffective: homeDirectory > allowedAttributesEffective: flags > allowedAttributesEffective: employeeID > allowedAttributesEffective: countryCode > allowedAttributesEffective: codePage > allowedAttributesEffective: badPwdCount > allowedAttributesEffective: userAccountControl > allowedAttributesEffective: replUpToDateVector > allowedAttributesEffective: replPropertyMetaData > allowedAttributesEffective: objectGUID > allowedAttributesEffective: name > allowedAttributesEffective: homePostalAddress > allowedAttributesEffective: language > allowedAttributesEffective: personalTitle > allowedAttributesEffective: employeeType > allowedAttributesEffective: personalPager > allowedAttributesEffective: employeeNumber > allowedAttributesEffective: formData > allowedAttributesEffective: forwardingAddress > allowedAttributesEffective: replicatedObjectVersion > allowedAttributesEffective: extensionAttribute15 > allowedAttributesEffective: extensionAttribute14 > allowedAttributesEffective: extensionAttribute13 > allowedAttributesEffective: extensionAttribute12 > allowedAttributesEffective: extensionAttribute11 > allowedAttributesEffective: supportedAlgorithms > allowedAttributesEffective: msExchHouseIdentifier > allowedAttributesEffective: msExchLabeledURI > allowedAttributesEffective: attributeCertificate > allowedAttributesEffective: internetEncoding > allowedAttributesEffective: protocolSettings > allowedAttributesEffective: dnQualifier > allowedAttributesEffective: enabledProtocols > allowedAttributesEffective: USNIntersite > allowedAttributesEffective: pOPCharacterSet > allowedAttributesEffective: languageCode > allowedAttributesEffective: pOPContentFormat > allowedAttributesEffective: wWWHomePage > allowedAttributesEffective: networkAddress > allowedAttributesEffective: heuristics > allowedAttributesEffective: mailNickname > allowedAttributesEffective: msExchAssistantName > allowedAttributesEffective: kMServer > allowedAttributesEffective: msExchPfRootUrl > allowedAttributesEffective: extensionAttribute10 > allowedAttributesEffective: extensionAttribute9 > allowedAttributesEffective: extensionAttribute8 > allowedAttributesEffective: extensionAttribute7 > allowedAttributesEffective: extensionAttribute6 > allowedAttributesEffective: extensionAttribute5 > allowedAttributesEffective: extensionAttribute4 > allowedAttributesEffective: extensionAttribute3 > allowedAttributesEffective: extensionAttribute2 > allowedAttributesEffective: extensionAttribute1 > allowedAttributesEffective: expirationTime > allowedAttributesEffective: mAPIRecipient > allowedAttributesEffective: displayNamePrintable > allowedAttributesEffective: targetAddress > allowedAttributesEffective: folderPathname > allowedAttributesEffective: mDBUseDefaults > allowedAttributesEffective: garbageCollPeriod > allowedAttributesEffective: msExchIMAPOWAURLPrefixOverride > allowedAttributesEffective: msExchOriginatingForest > allowedAttributesEffective: msExchVoiceMailboxID > allowedAttributesEffective: msExchTUIPassword > allowedAttributesEffective: msExchTUIVolume > allowedAttributesEffective: msExchTUISpeed > allowedAttributesEffective: autoReplyMessage > allowedAttributesEffective: autoReply > allowedAttributesEffective: submissionContLength > allowedAttributesEffective: otherHomePhone > allowedAttributesEffective: mDBOverQuotaLimit > allowedAttributesEffective: uSNDSALastObjRemoved > allowedAttributesEffective: mDBStorageQuota > allowedAttributesEffective: importedFrom > allowedAttributesEffective: streetAddress > allowedAttributesEffective: homeMDB > allowedAttributesEffective: deliveryMechanism > allowedAttributesEffective: publicDelegates > allowedAttributesEffective: extensionData > allowedAttributesEffective: extensionName > allowedAttributesEffective: adminDescription > allowedAttributesEffective: replicationSensitivity > allowedAttributesEffective: unauthOrig > allowedAttributesEffective: proxyAddresses > allowedAttributesEffective: adminDisplayName > allowedAttributesEffective: deliverAndRedirect > allowedAttributesEffective: homeMTA > allowedAttributesEffective: showInAdvancedViewOnly > allowedAttributesEffective: company > allowedAttributesEffective: dLMemSubmitPerms > allowedAttributesEffective: department > allowedAttributesEffective: delivExtContTypes > allowedAttributesEffective: delivContLength > allowedAttributesEffective: co > allowedAttributesEffective: authOrig > allowedAttributesEffective: altRecipient > allowedAttributesEffective: uSNLastObjRem > allowedAttributesEffective: uSNChanged > allowedAttributesEffective: otherPager > allowedAttributesEffective: deletedItemFlags > allowedAttributesEffective: businessRoles > allowedAttributesEffective: msExchOmaAdminWirelessEnable > allowedAttributesEffective: msExchOmaAdminExtendedSettings > allowedAttributesEffective: repsFrom > allowedAttributesEffective: repsTo > allowedAttributesEffective: securityProtocol > allowedAttributesEffective: info > allowedAttributesEffective: telephoneAssistant > allowedAttributesEffective: objectVersion > allowedAttributesEffective: dSASignature > allowedAttributesEffective: isDeleted > allowedAttributesEffective: dLMemRejectPerms > allowedAttributesEffective: uSNCreated > allowedAttributesEffective: otherTelephone > allowedAttributesEffective: displayName > allowedAttributesEffective: subRefs > allowedAttributesEffective: whenChanged > allowedAttributesEffective: whenCreated > allowedAttributesEffective: attributeCertificateAttribute > allowedAttributesEffective: houseIdentifier > allowedAttributesEffective: distinguishedName > allowedAttributesEffective: x500uniqueIdentifier > allowedAttributesEffective: generationQualifier > allowedAttributesEffective: initials > allowedAttributesEffective: givenName > allowedAttributesEffective: userCertificate > allowedAttributesEffective: userPassword > allowedAttributesEffective: seeAlso > allowedAttributesEffective: preferredDeliveryMethod > allowedAttributesEffective: destinationIndicator > allowedAttributesEffective: registeredAddress > allowedAttributesEffective: internationalISDNNumber > allowedAttributesEffective: x121Address > allowedAttributesEffective: facsimileTelephoneNumber > allowedAttributesEffective: teletexTerminalIdentifier > allowedAttributesEffective: telexNumber > allowedAttributesEffective: telephoneNumber > allowedAttributesEffective: physicalDeliveryOfficeName > allowedAttributesEffective: postOfficeBox > allowedAttributesEffective: postalCode > allowedAttributesEffective: postalAddress > allowedAttributesEffective: businessCategory > allowedAttributesEffective: description > allowedAttributesEffective: title > allowedAttributesEffective: ou > allowedAttributesEffective: o > allowedAttributesEffective: street > allowedAttributesEffective: st > allowedAttributesEffective: l > allowedAttributesEffective: c > allowedAttributesEffective: serialNumber > allowedAttributesEffective: sn > allowedAttributesEffective: objectCategory > allowedAttributesEffective: sAMAccountName > allowedAttributesEffective: objectSid > allowedAttributesEffective: nTSecurityDescriptor > allowedAttributesEffective: instanceType > allowedAttributesEffective: cn > allowedAttributesEffective: objectClass > > # Referral > ref: ldap://exchange.win2k3.abartlet.net/DC=exchange,DC=win2k3,DC=abartlet,DC=net > > # Referral > ref: ldap://ForestDnsZones.win2k3.abartlet.net/DC=ForestDnsZones,DC=win2k3,DC=abartlet,DC=net > > # Referral > ref: ldap://DomainDnsZones.win2k3.abartlet.net/DC=DomainDnsZones,DC=win2k3,DC=abartlet,DC=net > > # Referral > ref: ldap://win2k3.abartlet.net/CN=Configuration,DC=win2k3,DC=abartlet,DC=net > > # returned 5 records > # 1 entries > # 4 referrals > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Thu Nov 2 04:33:36 2006 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 02 Nov 2006 15:33:36 +1100 Subject: [Fedora-directory-devel] Attribute to determine allowed write attributes? In-Reply-To: <45494FDC.5000509@redhat.com> References: <1162352642.31477.123.camel@localhost.localdomain> <45481D26.2020409@boreham.org> <1162370189.31477.127.camel@localhost.localdomain> <4548A9AD.7090408@redhat.com> <1162422685.31477.155.camel@localhost.localdomain> <45494FDC.5000509@redhat.com> Message-ID: <1162442016.5316.14.camel@amy.samba4.abartlet.net> On Wed, 2006-11-01 at 18:54 -0700, Richard Megginson wrote: > Andrew Bartlett wrote: > > On Wed, 2006-11-01 at 07:05 -0700, Richard Megginson wrote: > > > >> Andrew Bartlett wrote: > >> > >>> On Tue, 2006-10-31 at 21:05 -0700, David Boreham wrote: > >>> > >>> > >>>> Andrew Bartlett wrote: > >>>> > >>>> > >>>> > >>>>> Does anybody have any pointers to an existing feature request like this, > >>>>> or should I file one in Bugzilla? > >>>>> > >>>>> > >>>>> > >>>>> > >>>> This is what is implemented : > >>>> > >>>> http://www.redhat.com/docs/manuals/dir-server/ag/7.1/acl.html#1216899 > >>>> > >>>> > >>> That has: > >>> > >>> > >>> > >>>> Information is not given for attributes in an entry that do not have a > >>>> value; for example, if the userPassword value is removed, then a > >>>> future effective rights search on the entry above would not return any > >>>> effective rights for userPassword, even though self-write and > >>>> self-delete rights could be allowed. Likewise, if the street attribute > >>>> were added with read, compare, and search rights, then street: rsc > >>>> would appear in the attributeLevelRights results. > >>>> > >>>> > >>> I need information on unknown attributes, so that MMC can show them as > >>> valid, writable fields (not greyed out). My preferred format is a list > >>> of writable fields, as permitted by the current schema for that entry. > >>> > >>> > >> This could be useful in any general purpose GUI app, to have the ability > >> to perform one query and get back a list of > >> 1) regular attributes available according to the schema > >> 2) operational attributes - writable vs. read-only > >> 3) virtual attributes - writable vs. read-only > >> > >> I would like to support the openldap "+" special attribute which > >> retrieves all operational attributes, and I would also like to support > >> the Sun DS real and virtual attrs controls. > >> > >> Andrew, I think it would be beneficial to me if you could post an > >> example ldapsearch and an example return entry in LDIF. > >> > > > > Using Samba's ldbsearch: > > > > bin/ldbsearch -H ldap://win2k3dc.win2k3.abartlet.net cn=administrator > > allowedAttributes allowedAttributesEffective allowedClasses > > AllowedClassesEffective -Uadministrator%penguin > > > What do allowedAttributes and allowedAttributesEffective mean? Are they > the writable attributes as allowed by schema and access control? What > does the "Effective" mean? The 'effective' means after ACLs are considered. allowedAttributes is just what the schema will permit. > What are allowedClasses and AllowedClassesEffective? I understand these are the same, but for subclasses. I think I need to try this on a container object to have this show up. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ando at sys-net.it Thu Nov 2 15:07:07 2006 From: ando at sys-net.it (Pierangelo Masarati) Date: Thu, 02 Nov 2006 16:07:07 +0100 Subject: [Fedora-directory-devel] Attribute to determine allowed write attributes? In-Reply-To: <1162422685.31477.155.camel@localhost.localdomain> References: <1162352642.31477.123.camel@localhost.localdomain> <45481D26.2020409@boreham.org> <1162370189.31477.127.camel@localhost.localdomain> <4548A9AD.7090408@redhat.com> <1162422685.31477.155.camel@localhost.localdomain> Message-ID: <454A099B.1070603@sys-net.it> Andrew Bartlett wrote: > On Wed, 2006-11-01 at 07:05 -0700, Richard Megginson wrote: > >> Andrew Bartlett wrote: >> >>> On Tue, 2006-10-31 at 21:05 -0700, David Boreham wrote: >>> >>> >>>> Andrew Bartlett wrote: >>>> >>>> >>>> >>>>> Does anybody have any pointers to an existing feature request like this, >>>>> or should I file one in Bugzilla? >>>>> >>>>> >>>>> >>>>> >>>> This is what is implemented : >>>> >>>> http://www.redhat.com/docs/manuals/dir-server/ag/7.1/acl.html#1216899 >>>> >>>> >>> That has: >>> >>> >>> >>>> Information is not given for attributes in an entry that do not have a >>>> value; for example, if the userPassword value is removed, then a >>>> future effective rights search on the entry above would not return any >>>> effective rights for userPassword, even though self-write and >>>> self-delete rights could be allowed. Likewise, if the street attribute >>>> were added with read, compare, and search rights, then street: rsc >>>> would appear in the attributeLevelRights results. >>>> >>>> >>> I need information on unknown attributes, so that MMC can show them as >>> valid, writable fields (not greyed out). My preferred format is a list >>> of writable fields, as permitted by the current schema for that entry. >>> >>> >> This could be useful in any general purpose GUI app, to have the ability >> to perform one query and get back a list of >> 1) regular attributes available according to the schema >> 2) operational attributes - writable vs. read-only >> 3) virtual attributes - writable vs. read-only >> >> I would like to support the openldap "+" special attribute which >> retrieves all operational attributes, and I would also like to support >> the Sun DS real and virtual attrs controls. >> >> Andrew, I think it would be beneficial to me if you could post an >> example ldapsearch and an example return entry in LDIF. >> > > Using Samba's ldbsearch: > > bin/ldbsearch -H ldap://win2k3dc.win2k3.abartlet.net cn=administrator > allowedAttributes allowedAttributesEffective allowedClasses > AllowedClassesEffective -Uadministrator%penguin > What's the -U for? My guess is -U%, is it correct? > allowedAttributesEffective: adminDisplayName > What identity does the "Effective" refer to? That of the client performing the request? How would this deal with ACL that depend on the value of the data? How would this deal with ACLs that do not just depend on the object and on the client's identity? Moreover, I believe this type of operation should be itself protected by ACLs, i.e. implementations should be able to restrict identities that can get this info. With an ACL model that accounts for attribute values (like any serious implementation should provide), the list itself could be incomplete if access to specific values of allowedAttributes or allowedAttributesEffective is itself restricted. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati at sys-net.it ------------------------------------------ From abartlet at samba.org Thu Nov 2 20:42:02 2006 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 03 Nov 2006 07:42:02 +1100 Subject: [Fedora-directory-devel] Attribute to determine allowed write attributes? In-Reply-To: <454A099B.1070603@sys-net.it> References: <1162352642.31477.123.camel@localhost.localdomain> <45481D26.2020409@boreham.org> <1162370189.31477.127.camel@localhost.localdomain> <4548A9AD.7090408@redhat.com> <1162422685.31477.155.camel@localhost.localdomain> <454A099B.1070603@sys-net.it> Message-ID: <1162500122.31477.173.camel@localhost.localdomain> On Thu, 2006-11-02 at 16:07 +0100, Pierangelo Masarati wrote: > Andrew Bartlett wrote: > > Using Samba's ldbsearch: > > > > bin/ldbsearch -H ldap://win2k3dc.win2k3.abartlet.net cn=administrator > > allowedAttributes allowedAttributesEffective allowedClasses > > AllowedClassesEffective -Uadministrator%penguin > > > What's the -U for? My guess is -U%, is it correct? That's the samba syntax for username and password, for a SASL bind. > > allowedAttributesEffective: adminDisplayName > > > What identity does the "Effective" refer to? That of the client > performing the request? Yes, the access that would be given to this connection, if it were to try write access to these attributes. > How would this deal with ACL that depend on the > value of the data? How would this deal with ACLs that do not just > depend on the object and on the client's identity? It should return the attributes that may be written to. Remember, the purpose is to allow a GUI client to grey out read-only fields, and reduce user frustration. > Moreover, I believe this type of operation should be itself protected by > ACLs, i.e. implementations should be able to restrict identities that > can get this info. This may well be. For my purposes, all users with access to write should be able to know what they may write to. Users with read only access would get a empty list, and the total list of allowed attributes can be calculated by schema introspection. > With an ACL model that accounts for attribute values > (like any serious implementation should provide), the list itself could > be incomplete if access to specific values of allowedAttributes or > allowedAttributesEffective is itself restricted. Sorry, this seems a bit recursive. I'm lost. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ando at sys-net.it Fri Nov 3 00:46:00 2006 From: ando at sys-net.it (Pierangelo Masarati) Date: Fri, 03 Nov 2006 01:46:00 +0100 Subject: [Fedora-directory-devel] Attribute to determine allowed write attributes? In-Reply-To: <1162500122.31477.173.camel@localhost.localdomain> References: <1162352642.31477.123.camel@localhost.localdomain> <45481D26.2020409@boreham.org> <1162370189.31477.127.camel@localhost.localdomain> <4548A9AD.7090408@redhat.com> <1162422685.31477.155.camel@localhost.localdomain> <454A099B.1070603@sys-net.it> <1162500122.31477.173.camel@localhost.localdomain> Message-ID: <454A9148.9010903@sys-net.it> Andrew Bartlett wrote: > Sorry, this seems a bit recursive. I'm lost. > In fact, it is. The point is that what you're asking for may not comply with the ACL model of most DSA implementations, which usually is a desirable model for a number of reasons. What you need is a "cooperative" DSA administrator that agrees to use only a subset of the ACL semantics so that their effect can be computed a priori, without any knowledge of the values that are/will be stored in the attributes. Under this assumption, implementing the feature you desire should be straightforward. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati at sys-net.it ------------------------------------------ From abartlet at samba.org Fri Nov 3 01:16:44 2006 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 03 Nov 2006 12:16:44 +1100 Subject: [Fedora-directory-devel] Attribute to determine allowed write attributes? In-Reply-To: <454A9148.9010903@sys-net.it> References: <1162352642.31477.123.camel@localhost.localdomain> <45481D26.2020409@boreham.org> <1162370189.31477.127.camel@localhost.localdomain> <4548A9AD.7090408@redhat.com> <1162422685.31477.155.camel@localhost.localdomain> <454A099B.1070603@sys-net.it> <1162500122.31477.173.camel@localhost.localdomain> <454A9148.9010903@sys-net.it> Message-ID: <1162516604.5316.27.camel@amy.samba4.abartlet.net> On Fri, 2006-11-03 at 01:46 +0100, Pierangelo Masarati wrote: > Andrew Bartlett wrote: > > Sorry, this seems a bit recursive. I'm lost. > > > In fact, it is. The point is that what you're asking for may not comply > with the ACL model of most DSA implementations, which usually is a > desirable model for a number of reasons. What you need is a > "cooperative" DSA administrator that agrees to use only a subset of the > ACL semantics so that their effect can be computed a priori, without any > knowledge of the values that are/will be stored in the attributes. > Under this assumption, implementing the feature you desire should be > straightforward. Or you simply ignore checks for value when evaluating the ACL, and declare that the attribute may be written to if there is any possible valid value. That should be enough for GUI writers to use for simple user-feedback, with a more detailed error reported to a user on the actual modify failure. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ando at sys-net.it Fri Nov 3 02:42:35 2006 From: ando at sys-net.it (Pierangelo Masarati) Date: Fri, 03 Nov 2006 03:42:35 +0100 Subject: [Fedora-directory-devel] Attribute to determine allowed write attributes? In-Reply-To: <1162516604.5316.27.camel@amy.samba4.abartlet.net> References: <1162352642.31477.123.camel@localhost.localdomain> <45481D26.2020409@boreham.org> <1162370189.31477.127.camel@localhost.localdomain> <4548A9AD.7090408@redhat.com> <1162422685.31477.155.camel@localhost.localdomain> <454A099B.1070603@sys-net.it> <1162500122.31477.173.camel@localhost.localdomain> <454A9148.9010903@sys-net.it> <1162516604.5316.27.camel@amy.samba4.abartlet.net> Message-ID: <454AAC9B.6080204@sys-net.it> Andrew Bartlett wrote: > On Fri, 2006-11-03 at 01:46 +0100, Pierangelo Masarati wrote: > >> Andrew Bartlett wrote: >> >>> Sorry, this seems a bit recursive. I'm lost. >>> >>> >> In fact, it is. The point is that what you're asking for may not comply >> with the ACL model of most DSA implementations, which usually is a >> desirable model for a number of reasons. What you need is a >> "cooperative" DSA administrator that agrees to use only a subset of the >> ACL semantics so that their effect can be computed a priori, without any >> knowledge of the values that are/will be stored in the attributes. >> Under this assumption, implementing the feature you desire should be >> straightforward. >> > > Or you simply ignore checks for value when evaluating the ACL, and > declare that the attribute may be written to if there is any possible > valid value. > > That should be enough for GUI writers to use for simple user-feedback, > with a more detailed error reported to a user on the actual modify > failure. > I've just written a toy module for OpenLDAP (HEAD; haven't checked with earlier versions) that returns the allowedAttributes and allowedAttributesEffective based on the assumption that ACLs do not depend on attribute values. You can download it from . Its transposition to FDS __should__ be straightforward. I plan to submit it as a contrib to OpenLDAP. BTW, can you point me to the schema definition of allowedAttributes and allowedAttributesEffective? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati at sys-net.it ------------------------------------------ From rmeggins at redhat.com Fri Nov 3 16:00:22 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 03 Nov 2006 09:00:22 -0700 Subject: [Fedora-directory-devel] Please review: Bug 213788: Admin Server cannot talk to SSL Config DS Message-ID: <454B6796.5020803@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213788 Bug(s) fixed: 213788 Bug Description: Admin Server cannot talk to SSL Config DS Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The logic in mod_admserv.c expects admldapBuildInfoSSL to return success but with a NULL ldap handle if no password was given or found. This is essentially what admldapBuildInfo does in the same situation. I also found and fixed a few memory leaks with both strings and LDAP handles. Platforms tested: FC5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=140263&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Fri Nov 3 17:40:58 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 03 Nov 2006 10:40:58 -0700 Subject: [Fedora-directory-devel] Please review: Bug 213786: upgrade install of ssl enabled servers changes file/dir permisssions from nobody to root Message-ID: <454B7F2A.8050109@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213786 Bug(s) fixed: 213786 Bug Description: upgrade install of ssl enabled servers changes file/dir permisssions from nobody to root Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The ssloff and sslon operations change several files, by grep/sed to temp files, then moving the temp files over the original ones. When done as root, this changes the file ownership to root from the original nobody. In order to preserve the file/directory ownership, we first figure out the instance, then use the ownership of that dse.ldif file to determine the server user:group. We have to do this before the call to SSLOff because SSLOff needs the user:group to chown the files. Then, every time we create a new file and replace an existing one, we do a chown $user:$group to preserve the existing file ownership. Platforms tested: RHEL4 Flag Day: no Doc impact: no QA impact: should be covered by regular nightly and manual testing New Tests integrated into TET: none https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=140290&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Nov 6 19:41:43 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 06 Nov 2006 12:41:43 -0700 Subject: [Fedora-directory-devel] Please review: Bug 214243: Advanced install loops at install sample entries Message-ID: <454F8FF7.3020202@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214243 Bug(s) fixed: 214243 Bug Description: Advanced install loops at install sample entries Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: There were a couple of problems. The first problem is that askPopulate is not a YesNo dialog, it is just a general Input dialog. The second problem is that askPopulateSetup sets the input buffer size greater than the static buffer used to hold the input in the Dialog class, which is defined as char _buf[MED_BUF]. So the solution is to set the InputLen to be MED_BUF-1, which allows for the trailing null as well. Platforms tested: FC5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=140498&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Nov 7 02:04:10 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 06 Nov 2006 19:04:10 -0700 Subject: [Fedora-directory-devel] Please review: Fedora Core 6 support + version change to 1.0.4 Message-ID: <454FE99A.8090308@redhat.com> FC 6 does not have /usr/include/linux/sys.h. The two files in the diff below include it, but I'm not sure why. If you look at the file on an earlier system, it appears that there is nothing in it. All it seems to do is define NR_syscalls, which is not used anywhere in any include file that I can find, nor in any ds code. So I propose changing the code not to include this file. Also, the version has changed to 1.0.4, so I needed to update ldap/cm/Makefile. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cvsdiffs URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Tue Nov 7 04:13:32 2006 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 06 Nov 2006 20:13:32 -0800 Subject: [Fedora-directory-devel] Please review: Fedora Core 6 support + version change to 1.0.4 In-Reply-To: <454FE99A.8090308@redhat.com> References: <454FE99A.8090308@redhat.com> Message-ID: <455007EC.1060006@redhat.com> Richard Megginson wrote: > FC 6 does not have /usr/include/linux/sys.h. The two files in the > diff below include it, but I'm not sure why. If you look at the file > on an earlier system, it appears that there is nothing in it. All it > seems to do is define NR_syscalls, which is not used anywhere in any > include file that I can find, nor in any ds code. So I propose > changing the code not to include this file. I think these changes are fine. That header file is/was part of the glibc-kernheaders package. My guess is that is may have been necessary when Directory Server was first ported to Linux, but I don't see why it would be needed now. -NGK > Also, the version has changed to 1.0.4, so I needed to update > ldap/cm/Makefile. > > ------------------------------------------------------------------------ > > Index: ldapserver/ldap/cm/Makefile > =================================================================== > RCS file: /cvs/dirsec/ldapserver/ldap/cm/Makefile,v > retrieving revision 1.68 > diff -u -8 -r1.68 Makefile > --- ldapserver/ldap/cm/Makefile 3 Nov 2006 19:49:52 -0000 1.68 > +++ ldapserver/ldap/cm/Makefile 7 Nov 2006 01:54:39 -0000 > @@ -105,19 +105,19 @@ > ifndef BuildDir > HOST=$(shell hostname) > BuildDir=$(shell cd $(RELTOOLSDIR);perl getdefaults -var BuildDir -if $(RELTOOLSDIR)/init/directory/directory5.init -machine $(HOST)) > endif > endif > endif > > ifdef USE_64 > -VERSION=-ver 1.0.3-64bit > +VERSION=-ver 1.0.4-64bit > else > -VERSION=-ver 1.0.3 > +VERSION=-ver 1.0.4 > endif > > ifeq ($(ARCH), HPUX) > RSH=remsh > REMSH=$(RSH) anuurn -l root > else > RSH=rsh > REMSH=$(RSH) anuurn -l root > @@ -271,17 +271,17 @@ > endif > > PACKAGE_SETUP_LIBS_32=$(subst $(NS64TAG),,$(PACKAGE_SETUP_LIBS)) > > # set the values of the macros used by rpmbuild > ifdef BUILD_RPM > # name and version of RPM - must correspond to the spec file - these get branded > RPM_BASE_NAME=fedora > - RPM_VERSION=1.0.3 > + RPM_VERSION=1.0.4 > RPM_FILE_BASE=$(RPM_BASE_NAME)-ds-$(RPM_VERSION) > RPM_ARCH = $(shell uname -i) > # root dir for RPM built and temp files > ABS_TOPDIR = $(shell cd $(INSTDIR)/.. ; pwd) > RPM_TOPDIR = --define "_topdir $(ABS_TOPDIR)" > # location of source tarball > RPM_SOURCEDIR = --define "_sourcedir $(ABS_TOPDIR)" > # location of staging area built into RPM > Index: ldapserver/ldap/servers/slapd/back-ldbm/dblayer.c > =================================================================== > RCS file: /cvs/dirsec/ldapserver/ldap/servers/slapd/back-ldbm/dblayer.c,v > retrieving revision 1.11 > diff -u -8 -r1.11 dblayer.c > --- ldapserver/ldap/servers/slapd/back-ldbm/dblayer.c 18 Apr 2006 18:25:02 -0000 1.11 > +++ ldapserver/ldap/servers/slapd/back-ldbm/dblayer.c 7 Nov 2006 01:54:44 -0000 > @@ -678,17 +678,16 @@ > * Solaris, Linux, Windows > */ > #ifdef OS_solaris > #include > #include > #endif > #ifdef LINUX > #include > -#include > #include /* undocumented (?) */ > #include > #endif > #if defined ( hpux ) > #include > #include > #endif > > Index: ldapserver/ldap/systools/idsktune.c > =================================================================== > RCS file: /cvs/dirsec/ldapserver/ldap/systools/idsktune.c,v > retrieving revision 1.12 > diff -u -8 -r1.12 idsktune.c > --- ldapserver/ldap/systools/idsktune.c 19 Apr 2005 22:07:44 -0000 1.12 > +++ ldapserver/ldap/systools/idsktune.c 7 Nov 2006 01:54:46 -0000 > @@ -103,17 +103,16 @@ > #define IDDS_MNTENT_OPTIONS mnt_mntopts > #define IDDS_MNTENT_MNTTAB "/etc/mnttab" > #endif > > #if defined(IDDS_LINUX_INCLUDE) > #include > #include > #include > -#include > #include > #include > #include > #include > > #define IDDS_MNTENT mntent > #define IDDS_MNTENT_DIRNAME mnt_dir > #define IDDS_MNTENT_OPTIONS mnt_opts > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > From ankur_agwal at yahoo.com Wed Nov 8 12:10:08 2006 From: ankur_agwal at yahoo.com (Ankur Agarwal) Date: Wed, 8 Nov 2006 04:10:08 -0800 (PST) Subject: [Fedora-directory-devel] Questions on Referal/Chaning features Message-ID: <20061108121008.73262.qmail@web54102.mail.yahoo.com> Hi, We have 2 existing directory services set-up with different schemas: 1) Active Directory 2) iPlanet LDAP Now we want to introduce a third one (Fedora LDAP) where we want to use referal/chaining features to send requests to these already existing servers. Would really appreciate your answers on: 1) Can we modify/update active directory data and iPlanet data with application interfacing only with new Fedora LDAP which will dispatch requests to these servers? Or can referal/chaining be used only for querying other LDAP servers? 2) Can Referal/Chaning be set-up across ActiveDirectory and Fedora with them having different schemas? Similarly between iPlanet and Fedora? 3) If we want to migrate data from iPlanet to Fedora (having diff schema on Fedora) then any issues we must be aware of and any best practices? Thanks, Ankur --------------------------------- Sponsored Link Talk more and pay less. Vonage can save you up to $300 a year on your phone bill. Sign up now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Nov 8 14:31:31 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Wed, 08 Nov 2006 07:31:31 -0700 Subject: [Fedora-directory-devel] Re: [Fedora-directory-users] Questions on Referal/Chaning features In-Reply-To: <20061108121008.73262.qmail@web54102.mail.yahoo.com> References: <20061108121008.73262.qmail@web54102.mail.yahoo.com> Message-ID: <4551EA43.80706@redhat.com> Ankur Agarwal wrote: > Hi, > > We have 2 existing directory services set-up with different schemas: > 1) Active Directory > 2) iPlanet LDAP > > Now we want to introduce a third one (Fedora LDAP) where we want to > use referal/chaining features to send requests to these already > existing servers. Would really appreciate your answers on: > > 1) Can we modify/update active directory data and iPlanet data with > application interfacing only with new Fedora LDAP which will dispatch > requests to these servers? Or can referal/chaining be used only for > querying other LDAP servers? A chaining database is read-write - it looks just like a local db to clients. > > 2) Can Referal/Chaning be set-up across ActiveDirectory and Fedora > with them having different schemas? Similarly between iPlanet and Fedora? Not sure about AD. Some other people on the list have been trying to get chaining and pass through auth to work with AD, but I haven't seen any reports of success yet. iPlanet to Fedora should work just fine. > > 3) If we want to migrate data from iPlanet to Fedora (having diff > schema on Fedora) then any issues we must be aware of and any best > practices? Just make sure your customized schema is copied to Fedora. iPlanet and Fedora DS are very compatible. > > Thanks, > Ankur > > ------------------------------------------------------------------------ > Sponsored Link > > Talk more and pay less. Vonage can save you up to $300 a year on your > phone bill. Sign up now. > > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Nov 9 01:58:40 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Wed, 08 Nov 2006 18:58:40 -0700 Subject: [Fedora-directory-devel] Please review: Bug 214733: be able to pass in all configurable paths to ds_newinst Message-ID: <45528B50.8050104@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214733 Bug(s) fixed: 214733 Bug Description: be able to pass in all configurable paths to ds_newinst Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Just add all of the paths that are set-able in create_instance.c to ds_newinst.pl. The paths will be parsed from the input .inf file e.g. config_dir= /path/to/config sysconfdir= /path/to/sysconf etc. in the [slapd] section. Platforms tested: RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=140740&action=diff From ankur_agwal at yahoo.com Thu Nov 9 04:22:16 2006 From: ankur_agwal at yahoo.com (Ankur Agarwal) Date: Wed, 8 Nov 2006 20:22:16 -0800 (PST) Subject: [Fedora-directory-devel] Re: [Fedora-directory-users] Questions on Referal/Chaning features In-Reply-To: <4551EA43.80706@redhat.com> Message-ID: <20061109042216.43383.qmail@web54103.mail.yahoo.com> Thanks Richard! Have a couple of follow-up questions : 1) iPlanet to Fedora chaining should work fine as you have mentioned. Does chaining require both of them to have exactly same schemas or chaining doesnt require that? 2) Client sends request to Fedora (with some authentication info) and then request gets dispatched to iPlanet/ActiveDirectory. How will this request be authenticated at iPlanet/ActiveDirectory. I believe authentication credentials will be different for all these LDAPs. regards, Ankur Richard Megginson wrote: Ankur Agarwal wrote: > Hi, > > We have 2 existing directory services set-up with different schemas: > 1) Active Directory > 2) iPlanet LDAP > > Now we want to introduce a third one (Fedora LDAP) where we want to > use referal/chaining features to send requests to these already > existing servers. Would really appreciate your answers on: > > 1) Can we modify/update active directory data and iPlanet data with > application interfacing only with new Fedora LDAP which will dispatch > requests to these servers? Or can referal/chaining be used only for > querying other LDAP servers? A chaining database is read-write - it looks just like a local db to clients. > > 2) Can Referal/Chaning be set-up across ActiveDirectory and Fedora > with them having different schemas? Similarly between iPlanet and Fedora? Not sure about AD. Some other people on the list have been trying to get chaining and pass through auth to work with AD, but I haven't seen any reports of success yet. iPlanet to Fedora should work just fine. > > 3) If we want to migrate data from iPlanet to Fedora (having diff > schema on Fedora) then any issues we must be aware of and any best > practices? Just make sure your customized schema is copied to Fedora. iPlanet and Fedora DS are very compatible. > > Thanks, > Ankur > > ------------------------------------------------------------------------ > Sponsored Link > > Talk more and pay less. Vonage can save you up to $300 a year on your > phone bill. Sign up now. > > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -- Fedora-directory-users mailing list Fedora-directory-users at redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users --------------------------------- Want to start your own business? Learn how on Yahoo! Small Business. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Nov 9 17:45:06 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 09 Nov 2006 10:45:06 -0700 Subject: [Fedora-directory-devel] Re: [Fedora-directory-users] Questions on Referal/Chaning features In-Reply-To: <20061109042216.43383.qmail@web54103.mail.yahoo.com> References: <20061109042216.43383.qmail@web54103.mail.yahoo.com> Message-ID: <45536922.5010109@redhat.com> Ankur Agarwal wrote: > Thanks Richard! > > Have a couple of follow-up questions : > > 1) iPlanet to Fedora chaining should work fine as you have mentioned. > Does chaining require both of them to have exactly same schemas or > chaining doesnt require that? I don't think it matters. > > 2) Client sends request to Fedora (with some authentication info) and > then request gets dispatched to iPlanet/ActiveDirectory. How will this > request be authenticated at iPlanet/ActiveDirectory. I believe > authentication credentials will be different for all these LDAPs. I don't understand. If you send a simple BIND request with a dn and a password to Fedora acting as the chaining front end, it will simply pass this operation and the credentials to the LDAP server on the backend. The Fedora DS chaning backend can't figure out what sort of authentication to use and change it on the fly. > > regards, > Ankur > > */Richard Megginson /* wrote: > > Ankur Agarwal wrote: > > Hi, > > > > We have 2 existing directory services set-up with different schemas: > > 1) Active Directory > > 2) iPlanet LDAP > > > > Now we want to introduce a third one (Fedora LDAP) where we want to > > use referal/chaining features to send requests to these already > > existing servers. Would really appreciate your answers on: > > > > 1) Can we modify/update active directory data and iPlanet data with > > application interfacing only with new Fedora LDAP which will > dispatch > > requests to these servers? Or can referal/chaining be used only for > > querying other LDAP servers? > A chaining database is read-write - it looks just like a local db to > clients. > > > > 2) Can Referal/Chaning be set-up across ActiveDirectory and Fedora > > with them having different schemas? Similarly between iPlanet > and Fedora? > Not sure about AD. Some other people on the list have been trying to > get chaining and pass through auth to work with AD, but I haven't > seen > any reports of success yet. > > iPlanet to Fedora should work just fine. > > > > 3) If we want to migrate data from iPlanet to Fedora (having diff > > schema on Fedora) then any issues we must be aware of and any best > > practices? > Just make sure your customized schema is copied to Fedora. iPlanet > and > Fedora DS are very compatible. > > > > Thanks, > > Ankur > > > > > ------------------------------------------------------------------------ > > Sponsored Link > > > > Talk more and pay less. Vonage can save you up to $300 a year on > your > > phone bill. Sign up now. > > > > > ------------------------------------------------------------------------ > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > ------------------------------------------------------------------------ > Want to start your own business? Learn how on Yahoo! Small Business. > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Thu Nov 9 18:11:13 2006 From: nhosoi at redhat.com (Noriko Hosoi) Date: Thu, 09 Nov 2006 10:11:13 -0800 Subject: [Fedora-directory-devel] Please review: DS7.2: [Bug 214840] modify sasl_path to accept the string set in the inf file In-Reply-To: <200611091809.kA9I9LHl031961@bugzilla.redhat.com> References: <200611091809.kA9I9LHl031961@bugzilla.redhat.com> Message-ID: <45536F41.10400@redhat.com> Summary: modify sasl_path to accept the string set in the inf file https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214840 Description of problem: Based upon this fix -- 214733: be able to pass in all configurable paths to ds_newinst, ds_newinst side should handle the given sasl_path. File: admin/src/create_instance.c Changes: If sasl_path is set in [slapd] section in the inf file, it's put in dse.ldif like this: dn: cn=config [...] nsslapd-saslpath: /usr/local/lib If the inf file does not have the line, the default path /usr/lib//sasl2 is put in dse.ldif on non-Linux platform. ------- Additional Comments From nhosoi at redhat.com 2006-11-09 13:06 EST ------- Created an attachment (id=140798) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=140798&action=view) cvs diff create_instance.c nhosoi at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- devel_whiteboard| |review.comment#1+ CC| |nkinder at redhat.com, | |rmeggins at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Fri Nov 10 19:45:00 2006 From: nhosoi at redhat.com (Noriko Hosoi) Date: Fri, 10 Nov 2006 11:45:00 -0800 Subject: [Fedora-directory-devel] Please review and comment: [Bug 214533] configure needs to support --with-fhs In-Reply-To: <200611101919.kAAJJNaa009375@bugzilla.redhat.com> References: <200611101919.kAAJJNaa009375@bugzilla.redhat.com> Message-ID: <4554D6BC.7040206@redhat.com> Summary: configure needs to support --with-fhs https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214533 ------- Additional Comments From nhosoi at redhat.com 2006-11-10 14:19 EST ------- Created an attachment (id=140927) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=140927&action=view) cvs diffs (configure.ac Makefile.am), new file m4/fhs.m4 Files: configure.ac Makefile.am m4/fhs.m4 Changes: 1. introduced a new option --with-fhs 2. instead of passing the define macro with -D, generate config.h ------- Additional Comments From nhosoi at redhat.com 2006-11-10 14:28 EST ------- I verified that the changes in Comment #1 generates config.h with the following define: with_fhs/config.h:#define IS_FHS 1 without_fhs:/* #undef IS_FHS */ And the build command line (on RHEL4) looks like this: if gcc -DHAVE_CONFIG_H -I. -I.. -I. -DXP_UNIX -DLinux -DLINUX -DLINUX2_0 -DLINUX2_2 -DLINUX2_4 -DBUILD_NUM=\"2006.314.1857\" -I../ldap/include -I../ldap/servers/slapd -I../include -I. -I../lib/ldaputil -I/usr/include/mozldap6 -I/usr/include/dirsec/nspr4 -I/usr/include/dirsec/nss3 -I/usr/include/dirsec/nss3 -I/usr/include/dirsec/nspr4 -g -O2 -MT lib/ldaputil/libldaputil_a-ldapdb.o -MD -MP -MF "lib/ldaputil/.deps/libldaputil_a-ldapdb.Tpo" -c -o lib/ldaputil/libldaputil_a-ldapdb.o `test -f 'lib/ldaputil/ldapdb.c' || echo '../'`lib/ldaputil/ldapdb.c; Now, each source file can have this include at the top of the code? #ifdef HAVE_CONFIG_H # include #endif ------------------------------------------------------------------------ Note: The changes proposed in comment #1 generate the macro defined in config.h, but does nothing else. The install paths should be updated, as well (in the build). And I'm planning to use the macro IS_FHS in create_instance to notify the instance generator which paths the server instance should use. Thanks, --noriko -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Wed Nov 15 04:17:32 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 14 Nov 2006 21:17:32 -0700 Subject: [Fedora-directory-devel] Please review: Bug 215669: Define LIBDIR, BINDIR, etc. in Makefile Message-ID: <455A94DC.7010504@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215669 Bug(s) fixed: 215669 Bug Description: Define LIBDIR, BINDIR, etc. in Makefile Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The paths LIBDIR, BINDIR, et. al. are #define'd in create_instance.h to hard coded values. We should be able to set these values in configure and override the built in values. We can't simply set them via AC_DEFINE in configure.ac because we are using config.h and this would render the definition like this: #define BINDIR "${exec_prefix}/bin" instead of #define BINDIR "/usr/bin" So we instead define them in Makefile.am and add their definitions to AM_CPPFLAGS, and quote them properly to make sure the value includes the quotation marks when expanded in the C code. I tested this with both an rpmbuild and a regular developer type build. Platforms tested: RHEL4/FC5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=141220&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Wed Nov 15 17:29:44 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Wed, 15 Nov 2006 10:29:44 -0700 Subject: [Fedora-directory-devel] Please review: Bug 214851: integrating db43 into ds70 Message-ID: <455B4E88.8050605@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214851 Bug(s) fixed: 214851 Bug Description: integrating db43 into ds70 Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: I took the original diffs posted by Ulf and merged them in with our code which has changed slightly since the diffs were originally generated. I also put #if directives like the following: #if 1000*DB_VERSION_MAJOR + 100*DB_VERSION_MINOR >= 4300 ... db43 features ... #else ... db42 features ... #endif so that we can use both db42 and db43. Platforms tested: RHEL4/FC5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=141288&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Nov 16 18:47:14 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 16 Nov 2006 11:47:14 -0700 Subject: [Fedora-directory-devel] Please review: Bug 215995: autoconf build needs to link replication plugin with libdb Message-ID: <455CB232.8030807@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215995 Bug(s) fixed: 215995 Bug Description: autoconf build needs to link replication plugin with libdb Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Add $(DB_LINK) to the replication plugin Platforms tested: RHEL4/FC5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=141396&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Nov 21 21:11:54 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 21 Nov 2006 14:11:54 -0700 Subject: [Fedora-directory-devel] Please review: Bug 216758: Use @libdir@ instead of hardcoded /usr/lib in template-script.in files Message-ID: <45636B9A.5000306@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=216758 Bug(s) fixed: 216758 Bug Description: Use @libdir@ instead of hardcoded /usr/lib in template-script.in files Reviewed by: ??? Files: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=141827 Branch: HEAD Fix Description: Just replace /usr/lib with @libdir@ in the script template .in files. Platforms tested: RHEL4 Flag Day: no Doc impact: no QA impact: should be covered by regular nightly and manual testing New Tests integrated into TET: none https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=141828&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Wed Nov 22 02:15:10 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 21 Nov 2006 19:15:10 -0700 Subject: [Fedora-directory-devel] Please review: Bug 210947: parameterizing the hardcoded paths (phase 3. installed binaries, change log, setup) Message-ID: <4563B2AE.8040809@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210947 Bug: 210947 Description: parameterizing the hardcoded paths (phase 3. installed binaries, change log, setup) Fix Description: RHEL4 64 is not able to find ldapsearch because the ldapsdk_bindir is hardcoded to /usr/lib/mozldap6. We should get ldapsdk_bindir from pkg-config or just simply use $libdir/mozldap6. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210947#c31 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From christian.brindley at gmail.com Mon Nov 27 14:14:43 2006 From: christian.brindley at gmail.com (Christian Brindley) Date: Mon, 27 Nov 2006 14:14:43 +0000 Subject: [Fedora-directory-devel] Auto Enrollment Proxy source code Message-ID: I have been looking at the Auto Enrollment Proxy (AEP) wiki pages. This is a very interesting area, and I was wondering if the windows source code is available. Thanks, Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: From sparkins at redhat.com Mon Nov 27 17:57:08 2006 From: sparkins at redhat.com (Steve Parkinson) Date: Mon, 27 Nov 2006 09:57:08 -0800 Subject: [Fedora-directory-devel] Auto Enrollment Proxy source code In-Reply-To: <456AFEFC.7040803@redhat.com> References: <456AFEFC.7040803@redhat.com> Message-ID: <456B26F4.40003@redhat.com> > Subject: [Fedora-directory-devel] Auto Enrollment Proxy source code > Date: Mon, 27 Nov 2006 14:14:43 +0000 > From: Christian Brindley > Reply-To: Fedora Directory server developer discussion. > > To: fedora-directory-devel at redhat.com > > I have been looking at the Auto Enrollment Proxy (AEP) wiki pages. > This is a very interesting area, and I was wondering if the windows > source code is available. > > Thanks, > > Christian Hi Christian, The current source code is here: http://cvs.fedora.redhat.com/lxr/dirsec/source/windowsautoenroll/ The DCOM interface implementation is in proxy.cpp. The source code today will not be building for you. Soon I will publish: - some crucial items that I wasn't able to ship (dcom proxy and stub code) - additional functionality in my local tree that need to get merged, - significant some cleanup Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From christian.brindley at gmail.com Mon Nov 27 18:30:13 2006 From: christian.brindley at gmail.com (Christian Brindley) Date: Mon, 27 Nov 2006 18:30:13 +0000 Subject: [Fedora-directory-devel] Auto Enrollment Proxy source code In-Reply-To: <456B26F4.40003@redhat.com> References: <456AFEFC.7040803@redhat.com> <456B26F4.40003@redhat.com> Message-ID: Hi Steve, Thanks a lot for the link. I'm looking forward to the full source - are you building from an IDL file with AppID {D99E6E74-FC88-11D0-B498-00A0C90312F3} and interface {d99e6e70-fc88-11d0-b498-00a0c90312f3} to emulate the Microsoft ICertRequestD Interface? I see from the wiki that you are planning to implement this as a Windows Service - how is this going? Thanks again, Christian On 27/11/06, Steve Parkinson wrote: > > > > Subject: [Fedora-directory-devel] Auto Enrollment Proxy source code > > Date: Mon, 27 Nov 2006 14:14:43 +0000 > > From: Christian Brindley > > Reply-To: Fedora Directory server developer discussion. > > > > To: fedora-directory-devel at redhat.com > > > > I have been looking at the Auto Enrollment Proxy (AEP) wiki pages. > > This is a very interesting area, and I was wondering if the windows > > source code is available. > > > > Thanks, > > > > Christian > > Hi Christian, > > The current source code is here: > http://cvs.fedora.redhat.com/lxr/dirsec/source/windowsautoenroll/ > > The DCOM interface implementation is in proxy.cpp. > > The source code today will not be building for you. Soon I will publish: > - some crucial items that I wasn't able to ship (dcom proxy and stub code) > - additional functionality in my local tree that need to get merged, > - significant some cleanup > > Steve > > > > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sparkins at redhat.com Mon Nov 27 19:13:00 2006 From: sparkins at redhat.com (Steve Parkinson) Date: Mon, 27 Nov 2006 11:13:00 -0800 Subject: [Fedora-directory-devel] Auto Enrollment Proxy source code In-Reply-To: References: <456AFEFC.7040803@redhat.com> <456B26F4.40003@redhat.com> Message-ID: <456B38BC.4090401@redhat.com> Exactly. Microsoft ships a header file with those definitions (certreqd.h) in the MSDN. So, I made an IDL file with that information and from that, generated the stubs. Windows service work was on hold until I figured out some other problems. Also, there is a bug in the current published code which prevents it from running against anything other than the latest (unreleased) Red Hat Certificate System 7.2. That fix is also in my tree (which I will release soon). Steve Christian Brindley wrote: > Hi Steve, > > Thanks a lot for the link. I'm looking forward to the full source - > are you building from an IDL file with AppID > {D99E6E74-FC88-11D0-B498-00A0C90312F3} and interface > {d99e6e70-fc88-11d0-b498-00a0c90312f3} to emulate the Microsoft > ICertRequestD Interface? I see from the wiki that you are planning to > implement this as a Windows Service - how is this going? > > Thanks again, > > Christian > > > On 27/11/06, *Steve Parkinson* > wrote: > > > > Subject: [Fedora-directory-devel] Auto Enrollment Proxy > source code > > Date: Mon, 27 Nov 2006 14:14:43 +0000 > > From: Christian Brindley > > > Reply-To: Fedora Directory server developer discussion. > > < fedora-directory-devel at redhat.com > > > > To: fedora-directory-devel at redhat.com > > > > > I have been looking at the Auto Enrollment Proxy (AEP) wiki pages. > > This is a very interesting area, and I was wondering if the windows > > source code is available. > > > > Thanks, > > > > Christian > > Hi Christian, > > The current source code is here: > http://cvs.fedora.redhat.com/lxr/dirsec/source/windowsautoenroll/ > > The DCOM interface implementation is in proxy.cpp. > > The source code today will not be building for you. Soon I will > publish: > - some crucial items that I wasn't able to ship (dcom proxy and > stub code) > - additional functionality in my local tree that need to get merged, > - significant some cleanup > > Steve > > > > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > > > > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Mon Nov 27 19:27:11 2006 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 27 Nov 2006 11:27:11 -0800 Subject: [Fedora-directory-devel] Request for reviews and comments: [Bug 216983] New: Make random password generation work with policies In-Reply-To: References: Message-ID: <456B3C0F.9020104@redhat.com> Summary: Make random password generation work with policies https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=216983 Description of problem: passwd_modify_generate_passwd (passwd_extop.c) always generates 8-bytes random characters made by PK11_GenerateRandom and ldif_base64_encode. It needs to generate a password which follows the password policy if it's defined. ------- Additional Comments From nhosoi at redhat.com 2006-11-27 14:18 EST ------- Created an attachment (id=142208) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=142208&action=view) cvs diff (passwd_extop.c) File: ldap/servers/slapd/passwd_extop.c Changes: 1. Renamed passwd_modify_generate_passwd to passwd_modify_generate_basic_passwd, which algorithm is used when no specific password rule or just the minimum length is given. 2. If some other rules are set, passwd_modify_generate_policy_passwd is called and generates a password which fulfills the requirement. Note: this password generator does not support passwordMin8Bit. If it generates a password which includes 8-bit characters, most likely they won't be able to be displayed or input from the users' keyboard. We should note it in the doc... ------- Additional Comments From nhosoi at redhat.com 2006-11-27 14:21 EST ------- Created an attachment (id=142213) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=142213&action=view) generated password sample Attached is the sample output from ldappasswd. Do you think this quality of the randomness satisfies the requirement? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Nov 27 19:33:28 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 27 Nov 2006 12:33:28 -0700 Subject: [Fedora-directory-devel] Please review: Bug 217403: Instance specific schema files should be owned by server uid Message-ID: <456B3D88.1070409@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217403 Bug(s) fixed: 217403 Bug Description: Instance specific schema files should be owned by server uid Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Add a new function - ds_copy_group_files_using_mode_owner() - that allows you to set the file mode and owner when copying directories and files. Use that function when copying the schema files to the new instance directory. Platforms tested: RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=142214&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Tue Nov 28 00:07:01 2006 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 27 Nov 2006 16:07:01 -0800 Subject: [Fedora-directory-devel] Request for reviews and comments: [Bug 216983] New: Make random password generation work with policies In-Reply-To: <456B3C0F.9020104@redhat.com> References: <456B3C0F.9020104@redhat.com> Message-ID: <456B7DA5.50904@redhat.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Tue Nov 28 18:11:40 2006 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 28 Nov 2006 10:11:40 -0800 Subject: [Fedora-directory-devel] Commit: [Bug 216983] New: Make random password generation work with policies In-Reply-To: <456B7DA5.50904@redhat.com> References: <456B3C0F.9020104@redhat.com> <456B7DA5.50904@redhat.com> Message-ID: <456C7BDC.7030303@redhat.com> Summary: Make random password generation work with policies https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=216983 ------- Additional Comments From nhosoi at redhat.com 2006-11-28 13:04 EST ------- Created an attachment (id=142311) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=142311&action=view) cvs diff (passwd_extop.c) Final diff of passwd_extop.c which has been revised based upon the Nathan's review. Reviewed by Nathan (Thank you!!) Checked in into HEAD Commit messsage: Resolves: #216983 Summary: Make random password generation work with policies Changes: 1) Generate a password that meets the current password syntax rules. 2) Report errors when Min8Bit is set or MinCategories > 4 CVS: ---------------------------------------------------------------------- CVS: Modified Files: passwd_extop.c CVS: ---------------------------------------------------------------------- Checking in passwd_extop.c; /cvs/dirsec/ldapserver/ldap/servers/slapd/passwd_extop.c,v <-- passwd_extop.c new revision: 1.14; previous revision: 1.13 done ------- Additional Comments From nhosoi at redhat.com 2006-11-28 12:57 EST ------- Thank you so much, Nathan! passwordMinCategories: 5 Client> ldappasswd: Operations error ldappasswd: additional info: Unable to generate new random password. Please contact the Administrator. Server> [...] - Unable to generate a password that meets the current password syntax rules. A minimum categories setting of 5 is not supported with random password generation. passwordMin8bit: 1 Client> ldappasswd: Operations error ldappasswd: additional info: Unable to generate new random password. Please contact the Administrator. Server> [...] - Unable to generate a password that meets the current password syntax rules. 8-bit syntax restrictions are not supported with random password generation. > > ------- Additional Comments From nhosoi at redhat.com 2006-11-27 18:58 EST ------- > Created an attachment (id=142247) > --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=142247&action=view) > cvs diff (passwd_extop.c) > > Thank you to Nathan for the review and the discussion! > > As you suggested, I changed the code to randomly choose the rest of the specified > characters (characters specified by, e.g., minuppers or mindigits). Also, I added > error messages to log in the errors log as well as to return to the client. Please > take a look at the next attachment for the messages. > > ------- Additional Comments From nhosoi at redhat.com 2006-11-27 19:04 EST ------- > Created an attachment (id=142248) > --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=142248&action=view) > generated password sample + error messages > > Added error messages are for > 1. when passwordMinCategories is 5, which expects the generated password to > include 8-bit character(s). Password Generator does not support such a > password. > 2. when passwordMin8Bit is set. > > Also, fixed the bug pointed out by Nathan in Comment#3. > > Lastly, the generated password sequence looks more randomized! > > > >> Summary: Make random password generation work with policies >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=216983 >> >> Description of problem: >> passwd_modify_generate_passwd (passwd_extop.c) always generates >> 8-bytes random >> characters made by PK11_GenerateRandom and ldif_base64_encode. It >> needs to >> generate a password which follows the password policy if it's defined. >> >> ------- Additional Comments From nhosoi at redhat.com 2006-11-27 14:18 >> EST ------- >> Created an attachment (id=142208) >> --> >> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=142208&action=view) >> >> cvs diff (passwd_extop.c) >> >> File: >> ldap/servers/slapd/passwd_extop.c >> >> Changes: >> 1. Renamed passwd_modify_generate_passwd to >> passwd_modify_generate_basic_passwd, which algorithm is used when no >> specific >> password rule or just the minimum length is given. >> 2. If some other rules are set, passwd_modify_generate_policy_passwd >> is called >> and generates a password which fulfills the requirement. >> >> Note: this password generator does not support passwordMin8Bit. If it >> generates a password which includes 8-bit characters, most likely >> they won't be >> able to be displayed or input from the users' keyboard. We should >> note it in the >> doc... >> >> ------- Additional Comments From nhosoi at redhat.com 2006-11-27 14:21 >> EST ------- >> Created an attachment (id=142213) >> --> >> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=142213&action=view) >> >> generated password sample >> >> Attached is the sample output from ldappasswd. Do you think this >> quality of >> the randomness satisfies the requirement? >> >> ------------------------------------------------------------------------ >> >> -- >> Fedora-directory-devel mailing list >> Fedora-directory-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Thu Nov 30 19:35:34 2006 From: nhosoi at redhat.com (Noriko Hosoi) Date: Thu, 30 Nov 2006 11:35:34 -0800 Subject: [Fedora-directory-devel] Request for reviews and comments: [Bug 183222] Directory Server hangs when running VLV search and update operations simultaneously. In-Reply-To: <200611301914.kAUJE4bC004303@bugzilla.redhat.com> References: <200611301914.kAUJE4bC004303@bugzilla.redhat.com> Message-ID: <456F3286.50208@redhat.com> Summary: Directory Server hangs when running VLV search and update operations simultaneously. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183222 There are at least two hang-up problems in the concurrent vlv search and delete. Please take a look at the attachment (id=142507) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=142507&action=view) for details. And the following attachment is the proposed fix based upon the analysis. ------- Additional Comments From nhosoi at redhat.com 2006-11-30 14:23 EST ------- Created an attachment (id=142508) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=142508&action=view) cvs diffs Files: proto-back-ldbm.h idl.c sort.c vlv.c Changes: 1. promoted idl_delete to global to make it available in vlv_trim_candidates_byvalue. In vlv_trim_candidate_byvalue, if any id's in the idlist is found not having the corresponding entry, delete the id from the idlist and retry the binary search. 2. demoted too noisy error message: [...] - compare_entries db err -30990 [...] - compare_entries db err -30990 [...] 3. eliminated read-lock from vlv_find_index_by_filter to prevent the deadlock with the delete operation. Thank you, --noriko -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: