Re: Using back-meta or back-relay plus slapo-rwm as a proxy to a local database
masar...@aero.polimi.it wrote: Ok, fair warning - this is a little long-winded, but I'd rather give too much detail than not enough. Also, all examples are in slapd.conf format, since there is no documentation for cn=config, and I'm using slapd with -f and -F to make the conversion. Anyways, I'm working on implementing some rewrite rules with slapo-rwm, using back-relay (or possibly back-meta if that doesn't work out) as the backend on top of which slapo-rwm will sit, to make available some features that would be otherwise not be present with back-ldap, or in the absence of a proxy backend altogether. In its most basic form, the slapo-rwm overlay can be used without a proxy or relay backend, but the feature I'm after appears to require either the slapd-meta backend or the slapd-relay backend. For now, I've chosen to try with slapd-relay, as my research has indicated it supports the feature I'm after. For reference, this feature I desire is the 'searchResult' rewriteContext, as I'm interested in rewriting dynamic group membership DN's (i.e., the 'member' attribute, as defined in rfc2307bis) as plain uid's, so clients that only know about rfc2307 (and thus, look only for entries of the same format as memberUid and fail to perform any mappings to translate membership DN's to UID's) can make use of the dynamic groups I've created in my directory. Since my slapd-hdb database's rootDSE is dc=example,dc=com, I really couldn't find any way to get around using a virtual naming context; creating a back-meta database on the same host with the same suffix as the back-hdb database seemed ambiguous at best (in terms of how to ensure that clients would always speak to the back-meta db first), and using the suffix dc=com seemed inappropriate, as did creating several relay databases, one for each of the entries below the slapd-hdb database's rootDSE (e.g., ou=Users,dc=example,dc=com, ou=Groups,dc=example,dc=com, etc.). Creating several relay databases in that fashion presents other problems as well, and wouldn't do me any good for clients which query for entries using dc=example,dc=com as their search base. Given that, and the fact that I'm only looking to remap/rewrite data going to and from a single local database with a single naming context, I decided it was a better idea to create a single back-relay database with a bogus proxy naming context and use a suffixmassage to rewrite it, e.g.: database relay suffix dc=example-proxy,dc=com relay dc=example,dc=com overlayrwm rwm-rewriteEngine on rwm-suffixmassage dc=example-proxy,dc=com dc=example,dc=com rwm-rewriteContext searchResult rwm-rewriteRule^uid=([^,]+?),ou=Users,dc=example,dc=com$ $1 The result of this mapping does not yield a valid DN; as such, this rewriting is incorrect. Also, I don't see how it could be useful, as LDAP clients usually expect DNs to be DN-valued. In this case, dscl (Mac OS X's directory services client) expects a UID, not a DN, as is the POSIX standard for group members, and doesn't know how to parse usernames in groups that use DN's to identify their members. Instead, they expect UID's, and since there appears to be no way to do this client side with dscl (believe me, I did try to find one before resorting to this), I have constructed the above rewriteRule to do this for them. This should not impact my Linux clients either, as nslcd (a daemon created in a fork of nss_ldap by Arthur de Jong) only performs DN-to-UID translations if the group members are represented as DN-valued attribute values. My question wasn't whether or not the result is a valid DN - it's whether or not it would actually work, functionally speaking. Is that the case, regardless of how ugly or undesirable it might be? For reference, here is the back-meta database configuration I was going to use before I discovered that back-relay supported the searchResult rewriteContext: database meta suffix dc=example-proxy,dc=com overlayrwm rwm-rewriteEngine on urildap://localhost/dc=example-proxy,dc=com; rwm-suffixmassage dc=example-proxy,dc=com dc=example,dc=com rwm-rewriteContext searchResult rwm-rewriteRule^uid=([^,]+?),ou=Users,dc=example,dc=com$ $1 In either case, I have a few questions going forward from this point: 1. Is it legal to rewrite the search result DN's as described in the example above? I'm hoping that since the data being manipulated is going from server - client and is not being stored in the directory, the attributes I'm rewriting would not be subjected to the syntax requirements of the entry that holds them. 2. Are there any benefits or drawbacks to using a rewriteMap to accomplish this task? In my mind, it just seems like another means to the same end, at least based on the following configuration I came up with: rwm-rewriteMap ldap
Re: Using back-meta or back-relay plus slapo-rwm as a proxy to a local database
masar...@aero.polimi.it wrote: masar...@aero.polimi.it wrote: In this case, dscl (Mac OS X's directory services client) expects a UID, not a DN, as is the POSIX standard for group members, and doesn't know how to parse usernames in groups that use DN's to identify their members. Instead, they expect UID's, and since there appears to be no way to do this client side with dscl (believe me, I did try to find one before resorting to this), I have constructed the above rewriteRule to do this for them. This should not impact my Linux clients either, as nslcd (a daemon created in a fork of nss_ldap by Arthur de Jong) only performs DN-to-UID translations if the group members are represented as DN-valued attribute values. My question wasn't whether or not the result is a valid DN - it's whether or not it would actually work, functionally speaking. Is that the case, regardless of how ugly or undesirable it might be? You seem to be confusing LDAP groups (groupOfNames objectClass, member attribute) with POSIX groups (posixGroup objectClass, memberUid attribute). This has been sorted out long ago. Use the right object for each application. The rest of the discussion, at this point, seems moot. p. No, I know the difference. What I'm saying is that the OS X clients aren't translating DN-valued LDAP group membership attributes to UID-valued POSIX group memberships. On Linux, this is done with nss_ldap/nss_ldapd/nslcd by either: a) parsing the group membership attributes, which are listed as DN's, and returning just the portion between the 'uid=' and the next comma (e.g., if the DN was 'uid=jdoe,ou=Users,dc=example,dc=org', nslcd would translate that to 'jdoe', for use as a POSIX group member), or b) issuing a second lookup to map the UID corresponding to that particular DN (kind of the way slapo-rwm can if configured to). In other words, I'm what I'm proposing to do is exactly what nss_ldapd/nslcd does, only in a proxy database on the server side in the server's response to the client, instead of on the client side of that response. The *only* reason I'm doing this is because it's not being done on OS X machines by Directory Service's LDAPv3 plugin (the equivalent to Linux's nss_ldap plugin for NSS), and I cannot change the way the LDAPv3 plugin works by hacking its code, as doing so could void the warranty and support and all that other proprietary nonsense. So my only choice is to do it in the response on the server side, instead of in the response on the client side. And, since this is going to be done by means of a virtual naming context with slapd-meta and slapo-rwm, only the OS X clients will be using that virtual naming context. Everybody else, who does it properly on the client side, will use the real naming context. The main reason for the OP was to verify whether or not the implementation I proposed would actually *work*, regardless of whether or not it was advisable from a policy standpoint. If by invalid, you mean will not work (and not it is not advisable to do so), then that is fine and I'll find some other way around this problem (somehow...) - so if you wouldn't mind clarifying your response, I would be appreciative. Respectfully, Ryan
Re: Using back-meta or back-relay plus slapo-rwm as a proxy to a local database
masar...@aero.polimi.it wrote: masar...@aero.polimi.it wrote: masar...@aero.polimi.it wrote: No, I know the difference. What I'm saying is that the OS X clients aren't translating DN-valued LDAP group membership attributes to UID-valued POSIX group memberships. On Linux, this is done with nss_ldap/nss_ldapd/nslcd by either: a) parsing the group membership attributes, which are listed as DN's, and returning just the portion between the 'uid=' and the next comma (e.g., if the DN was 'uid=jdoe,ou=Users,dc=example,dc=org', nslcd would translate that to 'jdoe', for use as a POSIX group member), or b) issuing a second lookup to map the UID corresponding to that particular DN (kind of the way slapo-rwm can if configured to). In other words, I'm what I'm proposing to do is exactly what nss_ldapd/nslcd does, only in a proxy database on the server side in the server's response to the client, instead of on the client side of that response. The *only* reason I'm doing this is because it's not being done on OS X machines by Directory Service's LDAPv3 plugin (the equivalent to Linux's nss_ldap plugin for NSS), and I cannot change the way the LDAPv3 plugin works by hacking its code, as doing so could void the warranty and support and all that other proprietary nonsense. So my only choice is to do it in the response on the server side, instead of in the response on the client side. And, since this is going to be done by means of a virtual naming context with slapd-meta and slapo-rwm, only the OS X clients will be using that virtual naming context. Everybody else, who does it properly on the client side, will use the real naming context. The main reason for the OP was to verify whether or not the implementation I proposed would actually *work*, regardless of whether or not it was advisable from a policy standpoint. If by invalid, you mean will not work (and not it is not advisable to do so), then that is fine and I'll find some other way around this problem (somehow...) - so if you wouldn't mind clarifying your response, I would be appreciative. Well, perhaps you should then have a look at slapo-nssov (contrib/slapd-modules/nssov/); someone else on this list may give you better support than I could in setting it up appropriately. p. No; nssov is irrelevant here - that would only work for Linux clients, and they're the ones who perform the DN-to-UID translations appropriately. I know that this isn't just an issue for me; O'Reilly have even made passing references in their books about the fact that Apple's LDAPv3 Directory Services plugin does not handle DN-valued group memberships appropriately (third paragraph from the bottom): http://macdevcenter.com/pub/a/mac/2003/08/26/active_directory.html?page=2 That was 7 years ago, and they still haven't fixed it. Wonder what the odds are that they'll have a change of heart? :P Thanks anyways, though, for taking a gander at this. I'm going to try and implement the workaround I mentioned above for those OS X hosts, as a stopgap (hopefully a stopgap and not permanent, anyways...) until and if Apple updates the plugin to allow DN-valued group memberships, as they do for Active Directory. Hopefully it works. I wish I could say that I find it ironic that they would get it right with AD and not with *nix, but I digress... Respectfully, Ryan
Using back-meta or back-relay plus slapo-rwm as a proxy to a local database
=config attributes and objectclasses for those backend and overlays that's better or more efficient than creating a standard slapd.conf configuration and converting it with slapd using -f and -F? Perhaps an official or unofficial bit of documentation floating around out there other than a few miscellaneous postings on the mailing lists and some ITS contents? On a similar note in the same vein, as far as I can tell, none of the man pages, admin guide sections, or FAQ-O-Matic entries on slapd-relay mention which rewrite contexts are available with it, and I didn't realize that slapd-relay accepted the searchResult rewrite context until I read the servers/slapd/back-relay/README file (while searching for code that might reveal slapo-rwm's cn=config attribute equivalents). Would it be objectionable to update these reference points with said information? I'd be happy to file an ITS and submit patches and/or content for updating the documentation, if Gavin is too busy, unavailable, or would like some help. Thanks for any and all advice, musings, criticisms, and opinions! -Ryan -- Ryan Steele Systems Administrator AWeber Communications
Re: syncrepl's retry option
Quanah Gibson-Mount wrote: --On Tuesday, April 20, 2010 5:34 PM -0400 Ryan Steele ry...@aweber.com wrote: The FAQ indicates that the 'retry' option should be a comma-separated list: http://www.openldap.org/faq/data/cache/1118.html However, all of the examples from the section on replication in the Admin Guide seem to show them as being space-delimited values: http://www.openldap.org/doc/admin24/replication.html#Syncrepl Which is correct? Both. If you examine the source, you find: slap_str2clist( retry_list, val, ,\t ); i.e., it accepts a space, a comma, or a tab, as delimiters. --Quanah Ah, thanks for clearing that up, Quanah. Gavin, should the documentation be updated to reflect this? I checked several sources, but none seemed to definitively identify all of the acceptable delimiters. I'm happy to submit a patch for the Admin Guide, if you like? Thanks, Ryan
syncrepl's retry option
The FAQ indicates that the 'retry' option should be a comma-separated list: http://www.openldap.org/faq/data/cache/1118.html However, all of the examples from the section on replication in the Admin Guide seem to show them as being space-delimited values: http://www.openldap.org/doc/admin24/replication.html#Syncrepl Which is correct? Thanks, Ryan
Multi-Master, referrals, and chaining
Hey folks, As it stands, I've got an environment with six slapd servers (2.4.18) in an N-Way Multi-Master configuration. At any given moment, only one of these six nodes is receiving client requests (reads, writes, etc.). We use Pacemaker to provide some basic high-availability services, such that if the current 'master' (a term I'll use in this thread to refer to the one node receiving all reads/writes from clients) croaks, a shared IP/hostname resource is migrated to the next available server. I would like to modify this setup such that ALL of these six nodes can receive client requests, but in the interest of preserving data consistency, I'd like to refer writes to just one of them (that one being the current 'master'), such that the rest receive the update(s) via syncrepl. From my own research and reading, it seems as though I'll need a combination of referrals (specifically, the 'updateref' directive) and chaining, with the latter being introduced so that the job of chasing the referrals is handled server-side instead of being offloaded to the clients. I have two questions about this setup, though: 1. In order to prevent an endless loop of referrals, I'm assuming that the terminal node (the 'master') should NOT have an updateref option that points to the 'master' shared IP/hostname (i.e., itself), like the rest of the nodes do. Is this correct, or will slapd realize that the referral target is itself, and answer authoritatively? 2. If the assumption in #1 is correct, what is the most advisable way to handle referrals in the situation where the identity of the terminal node is subject to change? My thought was to trigger an ldapmodify operation which effectively removes the olcUpdateRef option during the failover, but I'm open to better ideas if they exist. Thanks! -Ryan
Re: Multi-Master, referrals, and chaining
I actually realized that my logic was slightly faulty - since each of the six masters is capable of performing the write operation, the referral will never be chased. Given that, is it impossible to have an N-Way MultiMaster configuration in which writes are possible on any node, but the writes at any given time are performed on only one of them to ensure consistency? That is, short of doing what I'm doing now (sending ALL traffic to only one master), which doesn't scale very well. Ryan Steele wrote: Hey folks, As it stands, I've got an environment with six slapd servers (2.4.18) in an N-Way Multi-Master configuration. At any given moment, only one of these six nodes is receiving client requests (reads, writes, etc.). We use Pacemaker to provide some basic high-availability services, such that if the current 'master' (a term I'll use in this thread to refer to the one node receiving all reads/writes from clients) croaks, a shared IP/hostname resource is migrated to the next available server. I would like to modify this setup such that ALL of these six nodes can receive client requests, but in the interest of preserving data consistency, I'd like to refer writes to just one of them (that one being the current 'master'), such that the rest receive the update(s) via syncrepl. From my own research and reading, it seems as though I'll need a combination of referrals (specifically, the 'updateref' directive) and chaining, with the latter being introduced so that the job of chasing the referrals is handled server-side instead of being offloaded to the clients. I have two questions about this setup, though: 1. In order to prevent an endless loop of referrals, I'm assuming that the terminal node (the 'master') should NOT have an updateref option that points to the 'master' shared IP/hostname (i.e., itself), like the rest of the nodes do. Is this correct, or will slapd realize that the referral target is itself, and answer authoritatively? 2. If the assumption in #1 is correct, what is the most advisable way to handle referrals in the situation where the identity of the terminal node is subject to change? My thought was to trigger an ldapmodify operation which effectively removes the olcUpdateRef option during the failover, but I'm open to better ideas if they exist. Thanks! -Ryan
Re: Using back-ldap as a client-side proxy/cache
Howard Chu wrote: Ryan Steele wrote: Hey folks, In order to provide stability to my OpenLDAP clients in the event of a network outage, I would like to implement some client-side caching. I've done some research, and have concluded that nscd is evil and should be avoided at all costs, It's not necesarily evil, it just doesn't work... Well, to me it's one and the same if it affects my service availability. :) and thus eventually settled on using back-ldap as a proxy and caching mechanism on the clients. And just to be clear, back-ldap is only a proxy. For caching support you must add the pcache overlay. Ideally, clients would query a local cache first, and if the information was not available, back-ldap would then forward the connection on to my root OpenLDAP server(s). That's exactly what back-ldap+pcache will do. Yeah, I think I've settled on using libnss-ldapd/nslcd + back-ldap + pcache. I would like to get nssov involved too, but it's not clear to me from the available documentation whether nssov is to be used in conjunction with pcache or instead of pcache. It almost seemed like nssov would be most suitable on the server side of things, whereas pcache was geared more towards client-side back-ldap setups. Am I misinterpreting anything there? If not, would anybody care to expound on that subject a little to provide some framing context? However, I didn't see much information in the admin guide with respect to such configurations other than a reference to the back-ldap man page, and given that I've got no real experience with setting up back-ldap, I was wondering if somebody who did/does would have some recommendations, advice, or knew of a good documentation source describing this sort of setup? Generally there's not much to set up. back-ldap needs whatever information any client would need to communicate successfully with the remote LDAP server. That's what I was starting to gather, but I'm still trying to figure out exactly what's supported since it's only a proxy. In particular, there doesn't seem to be many examples of folks using ACL's in their back-ldap configs, so I still want to make sure that the contents of the client-side cache are subject to the same visibility restrictions imposed on the server. To that end, if someone could confirm that the ACL syntax available in fully-fleshed out back-hdb slapd installations is available (in its entirety) in back-ldap configurations, I would be most appreciative. The other question I have is that it seems most people use back-ldap with a slapd.conf-style configuration, versus a cn=config type of setup. In this sort of circumstance, where one is not configuring a full-on OpenLDAP server/replica, that seems like it might be a good thing in the interest of keeping the client configurations simple. Nonetheless, I wanted to verify that it was the recommended way, since slapd.conf (in the context of a fully fleshed-out OpenLDAP server) is deprecated. It only seems that most are using slapd.conf because cn=config is new and most sites with existing slapd.conf deployments haven't migrated to cn=config yet. For new installs, just use cn=config. Gotcha, thanks for clarifying, Howard. Respectfully, Ryan
Using back-ldap as a client-side proxy/cache
Hey folks, In order to provide stability to my OpenLDAP clients in the event of a network outage, I would like to implement some client-side caching. I've done some research, and have concluded that nscd is evil and should be avoided at all costs, and thus eventually settled on using back-ldap as a proxy and caching mechanism on the clients. Ideally, clients would query a local cache first, and if the information was not available, back-ldap would then forward the connection on to my root OpenLDAP server(s). However, I didn't see much information in the admin guide with respect to such configurations other than a reference to the back-ldap man page, and given that I've got no real experience with setting up back-ldap, I was wondering if somebody who did/does would have some recommendations, advice, or knew of a good documentation source describing this sort of setup? The other question I have is that it seems most people use back-ldap with a slapd.conf-style configuration, versus a cn=config type of setup. In this sort of circumstance, where one is not configuring a full-on OpenLDAP server/replica, that seems like it might be a good thing in the interest of keeping the client configurations simple. Nonetheless, I wanted to verify that it was the recommended way, since slapd.conf (in the context of a fully fleshed-out OpenLDAP server) is deprecated. Thanks as always for insights, advice, and criticisms. Respectfully, Ryan
Replicated cluster reindexing and log level
I actually have two separate questions, both aimed at performance tuning my database. The first is about running slapindex on individual cluster members to preserve high availability. Namely, if each cluster member is brought offline individually for reindexing (as opposed to putting them all in read-only mode) and no new indices are added while any of the nodes are offline, are there any risks posed (if the nodes not currently being indexed are left in read/write mode) to the reindexed node when is brought back into the cluster? Or is this a relatively safe plan? The second revolves around log size. In my current environment, using the 'stats' loglevel, I get about 600-700 lines per second, and the cumulative size of the logs rotated throughout the day can reach in the area of 25G or more. Even though disk space is cheap, I'd love to rotate logs less frequently and consume fewer CPU cycles when gzipping and rotating said logs, while still having good visibility if I need to troubleshoot a problem. Is there any other loglevel folks can recommend that will still give me adequate information if I need to go back and glean information from the logs, while perhaps being a bit less verbose? Thanks as always. Respectfully, Ryan
Re: Question about contextCSN's
Ryan Steele wrote: I'm not quite sure how to interpret that though, given the results I'm seeing in my master-master pair. Should the contextCSN's in the backend database for both SID 001 and SID 002 match? E.g.: contextCSN: 20100126210305.876171Z#00#001#00 contextCSN: 20100126210305.876171Z#00#002#00 Or should both nodes agree about the timestamps for each SID independently? E.g.: ### ldap1 contextCSN: 20100126210305.876171Z#00#001#00 contextCSN: 20091018205321.288716Z#00#002#00 ### ldap2 contextCSN: 20100126210305.876171Z#00#001#00 contextCSN: 20091018205321.288716Z#00#002#00 Ah, I think I understand, and if my understanding is correct, the second case is the true statement. That is, the backend database on each node should agree about the most recent timestamp made by SID 001, indicating that they all received the same (most current) write from SID 001. I guess the question that remains in my mind, then, is why keep more than one contextCSN per database? Aren't we only concerned with the last write made to it (in this case, SID 001's write)? Thanks again for the insight. Respectfully, Ryan
Re: Question about contextCSN's
Rein Tollevik wrote: Ryan Steele wrote: I'm replicating both the config and backend databases between two boxes. Everything seems fine, but for some reason when I query them both for the contextCSN, the config database returns only one while the backend database returns two, as seen below: The contextCSN attribute with any given sid is added to a database only after the server with that serverID modifies the database. The count of contextCSN values in a database does not need to reflect the number of master servers that could modify it, and it have no relation to the values in other databases. In your example, all modifications to cn=config was probably made on the first server (assuming it have serverID 1 that is). The example db have been modified by both. Rein Thanks a lot for clarifying; I didn't realize that the contextCSN for each SID was added to a given database only after being modified by that SID. And yes, I do understand that the different databases (e.g., backend and config) will have different contextCSN's reflecting the last time they were written to, but my question was mostly about the same database on different nodes. Namely, I thought that verifying whether replication was complete was done by comparing the contextCSN's for the same database on each node (SID) in the replication group. That is, if replication is working, each server to whom the given database is being replicated should have the same contextCSN for that database, to verify that each received the same last write operation. I'm not quite sure how to interpret that though, given the results I'm seeing in my master-master pair. Should the contextCSN's in the backend database for both SID 001 and SID 002 match? E.g.: contextCSN: 20100126210305.876171Z#00#001#00 contextCSN: 20100126210305.876171Z#00#002#00 Or should both nodes agree about the timestamps for each SID independently? E.g.: ### ldap1 contextCSN: 20100126210305.876171Z#00#001#00 contextCSN: 20091018205321.288716Z#00#002#00 ### ldap2 contextCSN: 20100126210305.876171Z#00#001#00 contextCSN: 20091018205321.288716Z#00#002#00 It would intuitively seem to me that each node (SID) to whom the database is being replicated should have the same contextCSN, so that one could verify the replication status by looking at the attribute values for each SID on one node, instead of querying each node to see if the timestamp for each individual SID matched on every node. But, which is correct? Thanks again for the insight. Respectfully, Ryan
Re: Syncrepl Problem after repeatedly reboot
HRZ Konten wrote:
Hallo all,
we have 2 OpenLDAP 2.4.17 with N-Way Replication on Debian Lenny.
Config
dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootPW:: x
structuralObjectClass: olcDatabaseConfig
entryUUID: 446a8178-95f7-102e-8e9a-95c863b9a1ce
creatorsName: cn=config
createTimestamp: 20100115075644Z
olcSyncrepl: {0}rid=001 provider=ldaps://:636/ bindd
n=cn=config bindmethod=simple credentials=xxx
searchbase=cn=confi
g type=refreshAndPersist retry=5 5 300 + schemachecking=on timeout=3
olcSyncrepl: {1}rid=002 provider=xxx:636/ bindd
n=cn=config bindmethod=simple credentials=
searchbase=cn=confi
g type=refreshAndPersist retry=5 5 300 + schemachecking=on timeout=3
olcMirrorMode: TRUE
entryCSN: 20100115075655.626787Z#00#000#00
modifiersName: cn=config
modifyTimestamp: 20100115075655Z
We reboot one of the nodes a couple of times at the time as the other
node made ~ 60 000 adds.
After 12 hours there is still some difference between both nodes:
r...@ldap1:~# ldapsearch -D cn=manager,dc=xxx -W -x -b dc=xxx
courseOfStudy=* | grep courseOfStudy | wc -l
Enter LDAP Password:
61125
r...@ldap2:~# ldapsearch -D cn=manager,dc=xxx -W -x -b dc=xxx
courseOfStudy=* | grep courseOfStudy | wc -l
Enter LDAP Password:
47366
The contextCSN is equal on both nodes:
ldap1:
ldapsearch -xLLLH ldaps://ldap1:636 -s base -b dc=xxx contextCSN -W -D
cn=manager,xxx
Result:
contextCSN: 20100121183644.034011Z#00#000#00
ldap2:
ldapsearch -xLLLH ldaps://ldap2:636 -s base -b dc=uxxx contextCSN -W -D
cn=manager,xxx
Result:
contextCSN: 20100121183644.034011Z#00#000#00
Is there an easy way to force a new replication on the second node?
I will really appreciate your help...
There is a thread in the mailing list in which Pierangelo Masarati stated that
SID 000 is special and refers to
synchronization that was done prior to the cluster being N-Way replicated. Are
you sure that multi-master replication
is really working at all?
Respectfully,
Ryan
Question about contextCSN's
I'm replicating both the config and backend databases between two boxes.
Everything seems fine, but for some reason
when I query them both for the contextCSN, the config database returns only one
while the backend database returns two,
as seen below:
## ldap1 replication config
olcDatabase={0}config.ldif:olcSyncrepl: {0}rid=001
provider=ldap://ldap1.example.com binddn=cn=admin,cn=co
olcDatabase={0}config.ldif- nfig bindmethod=simple credentials=SECRET
searchbase=cn=config type
olcDatabase={0}config.ldif- =refreshAndPersist retry=5 10 300 15 timeout=1
olcDatabase={0}config.ldif:olcSyncrepl: {1}rid=002
provider=ldap://ldap2.example.com binddn=cn=admin,cn=co
olcDatabase={0}config.ldif- nfig bindmethod=simple credentials=SECRET
searchbase=cn=config type
olcDatabase={0}config.ldif- =refreshAndPersist retry=5 10 300 15 timeout=1
olcDatabase={1}hdb.ldif:olcSyncrepl: {0}rid=003
provider=ldap://ldap1.example.com binddn=cn=admin,dc=exa
olcDatabase={1}hdb.ldif- mple,dc=com bindmethod=simple credentials=SECRET
searchbase=dc=example,
olcDatabase={1}hdb.ldif- dc=com type=refreshAndPersist retry=5 10 300 15
timeout=1
olcDatabase={1}hdb.ldif:olcSyncrepl: {1}rid=004
provider=ldap://ldap2.example.com binddn=cn=admin,dc=exa
olcDatabase={1}hdb.ldif- mple,dc=com bindmethod=simple credentials=SECRET
searchbase=dc=example,
olcDatabase={1}hdb.ldif- dc=com type=refreshAndPersist retry=5 10 300 15
timeout=1
## ldap2 replication config
olcDatabase={0}config.ldif:olcSyncrepl: {0}rid=001
provider=ldap://ldap1.example.com binddn=cn=admin,cn=co
olcDatabase={0}config.ldif- nfig bindmethod=simple credentials=SECRET
searchbase=cn=config type
olcDatabase={0}config.ldif- =refreshAndPersist retry=5 10 300 15 timeout=1
olcDatabase={0}config.ldif:olcSyncrepl: {1}rid=002
provider=ldap://ldap2.example.com binddn=cn=admin,cn=co
olcDatabase={0}config.ldif- nfig bindmethod=simple credentials=SECRET
searchbase=cn=config type
olcDatabase={0}config.ldif- =refreshAndPersist retry=5 10 300 15 timeout=1
olcDatabase={1}hdb.ldif:olcSyncrepl: {0}rid=003
provider=ldap://ldap1.example.com binddn=cn=admin,dc=exa
olcDatabase={1}hdb.ldif- mple,dc=com bindmethod=simple credentials=SECRET
searchbase=dc=example,
olcDatabase={1}hdb.ldif- dc=com type=refreshAndPersist retry=5 10 300 15
timeout=1
olcDatabase={1}hdb.ldif:olcSyncrepl: {1}rid=004
provider=ldap://ldap2.example.com binddn=cn=admin,dc=exa
olcDatabase={1}hdb.ldif- mple,dc=com bindmethod=simple credentials=SECRET
searchbase=dc=example,
olcDatabase={1}hdb.ldif- dc=com type=refreshAndPersist retry=5 10 300 15
timeout=1
## Query
r...@ldap1:~# ldapsearch -x -H ldap://localhost -D 'cn=admin,cn=config' -y
/etc/ldap.secret -b 'cn=config' -s base -LL
contextCSN; ldapsearch -x -H ldap://localhost -D 'cn=admin,dc=example,dc=com'
-y /etc/ldap.secret -b 'dc=example,dc=com'
-s base -LL contextCSN
version: 1
dn: cn=config
contextCSN: 20091012205437.323661Z#00#001#00
version: 1
dn: dc=example,dc=com
contextCSN: 20100126210305.876171Z#00#001#00
contextCSN: 20091018205321.288716Z#00#002#00
I checked the documentation, but didn't see anything that clarified this
behavior. I've also checked the logs, and
there are no replication failures in them. So what is the reason for this?
The only difference I can see between the
config and backend is that the backend database has two overlays (autogroup and
syncprov) and the config db has only one
(syncprov), but that may just be an irrelevant coincidence. I would be most
appreciative if somebody could shed some
light on this for me. Thanks!
Respectfully,
Ryan
Re: MirrorMode/N-Way Multi-Master Replication Clarification
Gavin Henry wrote: - Howard Chu h...@symas.com wrote: The key element of MirrorMode is that there is an external frontend that ensures that all writes are directed to a single server. Otherwise, there is no difference. Should I change the docs for MM? We do writes to a single server to guarantee writes correct? If they are both the same, should we rename MirrorMode to a different key word? We don't use the server URI in the MM example, maybe that section should be totally re-written as it seems to be confusing users. Thoughts? Well, at least maybe some clarification, if a total re-write is too time consuming. If the difference between the two has nothing to do with the number of nodes involved, and only whether or not there's an external frontend, perhaps they would be more aptly titled N-Way Multi-Master and Proxied N-Way Multi-Master. And, perhaps any emphasis on the number of nodes involved should be removed to avoid ambiguity? Just my thoughts, hope it helps Gavin. Let me know if there's anything I can do to help. Respectfully, Ryan
Re: MirrorMode and chaining - are slaves needed?
Gavin Henry wrote: - Ryan Steele ry...@aweber.com wrote: Hi folks, I'm in the process of setting up about six nodes, and tossing around the idea of having either 2 masters in MirrorMode (traffic to the active master is managed externally) with 4 slaves (each of whom will refer their writes to the active master). I'm automating some of the setup, and in an effort to simplify the configuration, was wondering if I might be better served by simply having 6 masters with an identical configuration, each of which refer their writes to the active master (a separate IP/hostname on a virtual interface on one of the masters). So, the question becomes, 'are there any downsides I'm not aware of?' It seems to me that the advantage with the 6 masters is that, aside from the consolidation of configs for the automated setup, I now have 6 write-capable nodes instead of 2. And, provided I chain the writes to the active master, I shouldn't have to worry about incompatible writes/partitioning. Any thoughts, advice, recommendations? Thanks! If you have 6 masters you don't need to chain anything as that is Multi Master. I'm confused as to why you are chaining from a master to an active master. You should have either two MirrorMode nodes (with management) and chaining slaves or full Multi Master. I want to use MirrorMode, but between six nodes instead of two (the example in the Admin Guide uses three, so I figured using more than just two nodes was fine). As such, I need an active master to ensure that two masters don't write to the same entry or entries at (or near) the same time and cause a conflict/partition. I figured that having six masters in MirrorMode, instead of two masters and four slaves, would allow me to cut down on configuration while boosting my redundancy. I would use chaining on all of them to both keep the configs identical (less management overhead) and ensure that I don't run in to the aforementioned conflict scenarios. Is there anything I've failed to consider in deciding that using six masters in MirrorMode is more desirable than having two masters in MirrorMode with four slaves? The way you've described above isn't very clear and sounds messy. What your clients/apps need from the slaves? What is the usage pattern etc. I thought it sounded more simple - six masters with identical configurations (both cn=config and backend database replicated via identical syncprov/syncrepl configurations on each node), with all writes being directed to the active master; the chaining just guarantees that any writes erroneously sent to an inactive master would be forwarded on to the active master. In contrast, with the two masters and four slaves, the two masters must share syncprov/syncrepl configs and replicate cn=config and backend data to and from each other, while replicating the backend to the slaves; the six slaves would in turn need entirely separate syncprov/syncrepl configs since their cn=config wouldn't be in MirrorMode, to ensure that they replicate backend data to nobody and from the active master, and because they'd still need to chain/refer writes to the masters. Does the above logic seem sound or flawed to you? Anything I've glossed over or perhaps misunderstood? Thanks again for all the advice and insight - I truly appreciate it! Respectfully, Ryan
Re: MirrorMode and chaining - are slaves needed?
Gavin Henry wrote: - Ryan Steele ry...@aweber.com wrote: I want to use MirrorMode, but between six nodes instead of two (the example in the Admin Guide uses three, so I figured using more than just two nodes was fine). As such, I need an active master to ensure that two masters don't write to the same entry or entries at (or near) the same time and cause a conflict/partition. Sorry Ryan, but I think you misunderstand MirrorMode. MirrorMode is Active-Active Hot-standby. It's designed for just *two* nodes. The example in the admin guide is for full Multi-Master, but only showing three masters. Anything more that two is Multi-Master. Hm, but the N-Way MultiMaster documentation has MirrorMode directives... perhaps that's the source of my confusion. Does each master in an N-Way MultiMaster setup, in likeness with the documentation, have an olcMirrorMode directive? I figured that having six masters in MirrorMode, instead of two masters and four slaves, would allow me to cut down on configuration while boosting my redundancy. I would use chaining on all of them to both keep the configs identical (less management overhead) and ensure that I don't run in to the aforementioned conflict scenarios. Is there anything I've failed to consider in deciding that using six masters in MirrorMode is more desirable than having two masters in MirrorMode with four slaves? See above. If you have 6 Multi-Master and replicate cn=config and the rest of the data, you will have your desired outcome. Well, my desired outcome is to have a multi-master setup that guarantees the consistency of single-master setup, so I'm fine with any configuration that adheres to those paradigms. I thought it sounded more simple - six masters with identical configurations (both cn=config and backend database replicated via identical syncprov/syncrepl configurations on each node), with all writes being directed to the active master; the chaining just guarantees that any writes erroneously sent to an inactive master would be forwarded on to the active master. They handle this all themselves via SyncRepl when in Multimaster mode. As all writes have to go to all masters. Correct, but if I allow the initial writes to be made on more than one node, I could end up with a situation where two or more masters perform writes on the same entry or dependent entries, which could result in failed writes and/or partitioning of the data between nodes. So, I'll still need my external traffic shaper to direct the initial writes to only one node to ensure consistency, but as you mentioned I do not need to refer the writes to the active master (which could be done with carefully crafted ACLs, but would add unnecessary complication). That being said, do I simply need to keep the MirrorMode directives and external traffic shaper, and eliminate any chaining/referrals to achieve my desired setup? Thanks! -Ryan
MirrorMode and chaining - are slaves needed?
Hi folks, I'm in the process of setting up about six nodes, and tossing around the idea of having either 2 masters in MirrorMode (traffic to the active master is managed externally) with 4 slaves (each of whom will refer their writes to the active master). I'm automating some of the setup, and in an effort to simplify the configuration, was wondering if I might be better served by simply having 6 masters with an identical configuration, each of which refer their writes to the active master (a separate IP/hostname on a virtual interface on one of the masters). So, the question becomes, 'are there any downsides I'm not aware of?' It seems to me that the advantage with the 6 masters is that, aside from the consolidation of configs for the automated setup, I now have 6 write-capable nodes instead of 2. And, provided I chain the writes to the active master, I shouldn't have to worry about incompatible writes/partitioning. Any thoughts, advice, recommendations? Thanks! -Ryan
Re: Debugging a module
Hi Quanah, Quanah Gibson-Mount wrote: This is how filters work in LDAP. It sounds to me like things are working correctly. I.e., if I search for objectClass=joe objectClass, it will return every entry that has an objectClass value of joe, and all the values for objectClass. If I search for (member=uid=user1,ou=users,dc=example,dc=com), it will return to me every group that has a member attribute matching that value. I see nothing wrong in the behavior here, just in the understanding of how filters work. Let me know if you have further questions. To expand on this a little bit more: LDAP filters are used to limit the number of entries returned. They do not limit attr=value pairs. Generally, with groups, the most common operation is the ldapcompare operation. It lets you ask whether or not a given value is assigned to an attribute in a specific entry. I.e., I can ask Is uid=user1,ou=users,dc=example,dc=com a value for the member attribute in the group cn=testgroup ou=Groups,dc=example,dc=com using the ldapcompare operation. It will answer one of three ways: TRUE, FALSE, or UNDEFINED. http://www.openldap.org/software/man.cgi?query=ldapcompareapropos=0sektion=0manpath=OpenLDAP+2.4-Releaseformat=html Ah, your responses have been most helpful, thank you! The ldapcompare operation might actually satisfy the end-goals I was hoping to achieve by returning the dn or uid explicitly. Cheers! Respectfully, Ryan
Re: Can't start slapd with slapd.d
Hi Akihiro,
Akihiro Moriguchi wrote:
cn={3}inetorgperson,cn=schema,cn=config: olcAttributeTypes: Duplicate
attributeType: 2.16.840.1.113730.3.1.1
Sounds to me like you have two schema files which each define the same
attribute (in this case, carLicense). Try
identifying them with something like: grep -r 2.16.840.1.113730.3.1.1
/etc/ldap/slapd.d
Respectfully,
Ryan
Re: 2.3.43, and a variety of problems.
Brandon Hume wrote: On Fri, 2009-09-18 at 07:33 -0400, Francis Swasey wrote: This is getting ridiculous from my perspective. We've had a rash of people reporting problems against older releases and being effectively told to go to hell (which is what we hear when the development team or some proxy for them tells us to upgrade to 2.4). The fix is in 2.4 but can't be backported is certainly a valid answer, and one I can live with. I'm not married to 2.3, and I think syncrepl is the best thing since copulation. Agreed - syncrepl is fantastic. However, part of the reason I'm so slow moving to 2.4 is because I'm pretty much the only person here running this large LDAP directory. And part of the reason I'm the only person running the show, in addition to my other tasks, is because my coworkers and technical friends look at the openldap-software mailing list and say I don't want to deal with those people. (Some of these people have worked with Theo de Raat...) It is unfortunate that such reports are not isolated amongst a few individuals. I realize that users ask stupid questions and run ancient versions, but I also realize that sometimes those users are experiencing a catastrophe and have eighty thousand users banging on the door demanding explanation (ie: me). In that kind of situation people miss parts as they review docs and conflate symptoms and frequently make things worse before they make it better... and, yes, ask stupid questions. Part of the reason I'm slow moving to 2.4 is because I actually had to work myself up to asking my syncrepl-client question. I braced myself for one-word answers, RTFM-type answers, and variations on why in the world are you doing something like that? I got lucky, my question was apparently worthwhile, and I got useful information along with tangible relief. But what does that say about the environment? Regrettably, this has become the accepted nature of the list and IRC channel. You either say nothing, accept it, and hope to get some useful morsels peppered in between the chastising, or you complain about it and risk alienation by those in the know. I have been more vocal than most on the topic (although, more in IRC than the mailing lists), and it's certainly reflected in some of the answers I've received in my recent mailing list postings. I'm not saying that anybody is deserving of a response because clearly the list is volunteer-only, but in my case (http://www.mail-archive.com/openldap-software@openldap.org/msg15769.html) a request for clarification of a technical statement got twisted in to an accusation claiming I'd misrepresented another individual's response, instead of an answer to an earnest question - a side effect of being vocal about the tone you describe. But, things aren't likely to change unless more people are willing to sacrifice help in return for questioning the aforementioned resentful nature. When I come across technical posts, when someone decides to share their knowledge, it's a delight. But there's never any doubt when some of those people think you're wasting their time. I can handle being told that my version is too old and is unsupported. I just wish we could scale back a bit on the contempt while being told. Yes, it's less than an uncommon request... Respectfully, Ryan
Re: Debugging a module
Hey Andreas, Andreas Hasenack wrote: On Wed, Sep 16, 2009 at 17:42, Ryan Steele ry...@aweber.com wrote: query returns nothing: ldapsearch -x -w SECRET -D cn=admin,dc=example,dc=com -b cn=testgroup,ou=Groups,dc=example,dc=com -LLL '(uid=user1)' This filter doesn't look right. Try (member=uid=user1,ou=Users,dc=example,dc=com) ldapsearch -x -w SECRET -D cn=admin,dc=example,dc=com -b cn=testgroup ou=Groups,dc=example,dc=com -LLL dn: cn=testgroup,ou=Groups,dc=example,dc=com ou: Groups cn: testgroup objectClass: groupOfURLs memberURL: ldap:///ou=Users,dc=example,dc=com?uid?sub?((employeeType=Developer )(objectClass=exampleEmployee)) member: uid=user1,ou=Users,dc=example,dc=com member: uid=user2,ou=Users,dc=example,dc=com member: uid=user3,ou=Users,dc=example,dc=com Thanks for the advice - I think you're right about filtering on the 'member' attribute. However, doing so still returns the entire list, not the individual member I'm filtering for. E.g., the same results as: ldapsearch -x -w SECRET -D cn=admin,dc=example,dc=com -b cn=testgroup,ou=Groups,dc=example,dc=com -LLL '(member=*)' At an even more basic level, something like this should work too, but it returns nothing: ldapsearch -x -w SECRET -D cn=admin,dc=example,dc=com -b cn=testgroup,ou=Groups,dc=example,dc=com -LLL member I'm not quite sure how to explain this behavior, given the implications made in the following two posts which indicate that I should be able to use dynamically generated attributes as filter expressions: http://www.openldap.org/lists/openldap-software/200802/msg00211.html http://www.openldap.org/lists/openldap-software/200812/msg00038.html Also, in the earlier ITS filed for the autogroup contrib overlay, it states that for searches and compares, it should behave like a static group, bolstering that supposition: http://www.openldap.org/lists/openldap-bugs/200709/msg00128.html So, should I be searching for a bug (which was the premise for the OP), or has the behavior of autogroup changed since its inception? As always, many thanks for any and all advice! Respectfully, Ryan
Re: Debugging a module
Howard Chu wrote: autogroup isn't supposed to perform any expansion during searches. That's not what it does. So, you're saying that dynlist should perform the expansion, and autogroup just allows you to filter it? The autogroup man page makes no mention of needing the dynlist module (only the dynlist schema), which to me seems to imply that it's intended to supersede, not complement, dynlist. However, I could certainly have subjectively misinterpreted the documentation, or it might just not be documented at all (in which case I'm happy to submit a patch after having inquired with the two major developers of the module as to the patch's accuracy. Several previous on-list postings about this aren't clear as to whether or not they use autogroup instead of or in addition to dynlist. And, when I tested the use of both together, the results aren't what I expect; e.g., the following query returns nothing: ldapsearch -x -w SECRET -D cn=admin,dc=example,dc=com -b cn=testgroup,ou=Groups,dc=example,dc=com -LLL '(uid=user1)' ... whereas the same query without the trailing '(uid=user1)' returns a group full of member uid's: ldapsearch -x -w SECRET -D cn=admin,dc=example,dc=com -b cn=testgroup ou=Groups,dc=example,dc=com -LLL dn: cn=testgroup,ou=Groups,dc=example,dc=com ou: Groups cn: testgroup objectClass: groupOfURLs memberURL: ldap:///ou=Users,dc=example,dc=com?uid?sub?((employeeType=Developer )(objectClass=exampleEmployee)) member: uid=user1,ou=Users,dc=example,dc=com member: uid=user2,ou=Users,dc=example,dc=com member: uid=user3,ou=Users,dc=example,dc=com If I use autogroup alone, it does not work either. So, I assumed this to be a problem in the module with whatever is supposed to trigger the expansion and was hoping to try and ferret it out with gdb instead of bothering the list with several posts full of output without having tried to debug it myself first. But, if I've interpreted it incorrectly and the premise for my investigation is invalid, I'm happy to be told exactly how to achieve the ability to filter dynamically created groups using one or both of those overlays before assuming and investigating a bug! For reference, the following posts are examples of what I'm referring to: http://www.openldap.org/lists/openldap-software/200802/msg00211.html http://www.openldap.org/lists/openldap-software/200812/msg00030.html As always, I appreciate any and all advice! Regards, Ryan
Re: Debugging a module
Howard Chu wrote: Ryan Steele wrote: Howard Chu wrote: autogroup isn't supposed to perform any expansion during searches. That's not what it does. So, you're saying that dynlist should perform the expansion, and autogroup just allows you to filter it? I'm quite certain I never said any such thing. That wasn't a statement, it was a question, denoted by the question mark punctuation. And, if the answer is no, can you elaborate on what you did mean? Or, perhaps answer the question I asked at the end of the post, which was regarding how to achieve the desired affect, as you alluded to in http://www.openldap.org/lists/openldap-software/200802/msg00211.html, which reads: Pierangelo Masarati wrote: Guy Deleeuw wrote: All work fine, I can retrieve the two group entries. Now, I try to retrieve the group which have a particular member (ExoMemberShipMember): ldapsearch -x -LLL -b ou=groups,ou=portal,ou=www,ou=Exo,o=Eurofer,c=be -s sub (((objectClass=ExoMemberShip)(ExoMemberShipURL=*))(ExoMemberShipMember=cn=De Leeuw Guy,br=Internal,o=Eurofer,c=be)) And I receive an empty respond. Could you give me your advice about the feasibility of this kind of query ? This occurs because you can't filter for dynamically created members, as they get added to the entry while it's being returned. So the dynamic members are not present in the entry during search, when the filter is evaluated. You can only filter for static data. You might want to look at the autogroup overlay http://www.openldap.org/its/index.cgi/Contrib?id=5145 which will be included in OpenLDAP 2.4.8. -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ The autogroup Readme clearly states: I have read the README. I'm interested in the behavior mentioned in that post, if you could be so kind to elaborate on the statement you made in it? Thanks, Ryan
Debugging a module
Hey folks, I'm trying to debug the cause of faulty module behavior (autogroup) which has eluded both strace and 'slapd -d 16383' (and, just as a point of reference, it's slapd 2.4.18 and autogroup 1.8 on Ubuntu 8.04). So, I'd like to use gdb to figure out what's going on, but I'm not quite sure how to attack the problem. I've tried several different approaches to debug what's going wrong during the ldapsearch with gdb, but I can't seem to capture what I'm looking for. Rather than paste what I've tried, since it's ineffective, I'd instead like to ask how you all would approach it. So again, the scenario is: - slapd is running without any errors in the logs (about slapd or the failed autogroup expansions) - dynlist works, so I know that modules as a whole and dynamic searches work - autogroup doesn't generate any errors, but fails to perform any expansions during ldapsearches How can I attack this problem with gdb such that I'll be able to step through what's going on from the moment slapd begins parsing the entry requested by the ldapsearch in which there's supposed to be an expansion occurring? Many thanks in advance for your insight. Regards, Ryan
Stability of autogroup overlay with OpenLDAP 2.4.18
Is the autogroup overlay considered stable for use with versions of OpenLDAP earlier than 2.4.18? I know it's being used on earlier versions (as 2.4.18 is not considered stable yet), but I've also seen some reports of basic search functionality getting clobbered after doing so. According to ITS#6227, that bug was fixed, but I'd like to confirm that the overlay does at least work before investing the time (however short it may be) to compile it and package it in with OpenLDAP locally for internal use. I appreciate any feedback. Regards, Ryan
Re: No Results from Ldapsearch
The Hwyman wrote: I'm running Red Hat Enterprise 5 (x86_64) and Openldap version 2.3.27 from official rpms. I have installed openldap, openldap-devel, openldap-clients, and openldap-servers. The following command: ldapsearch -x -b dc=example,dc=com '(uid=jsmith)' produces the following results: -- # extended LDIF # # LDAPv3 # base dc=example,dc=com with scope subtree # filter: (uid=jsmith) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 -- If I specify the jsmith user (or any other user) using -D -W, I get the same results. If I specify the rootdn user: ldapsearch -x -D cn=manager,dc=example,dc=com -W -b dc=example,dc=com '(uid=jsmith)' I get the following results: -- # extended LDIF # # LDAPv3 # base dc=example,dc=com with scope subtree # filter: (uid=jsmith) # requesting: ALL # # jsmith, users, example.com dn: uid=jsmith,ou=users,dc=example,dc=com uid: jsmith cn: jsmith homeDirectory: /home/jsmith uidNumber: xxx objectClass: posixAccount objectClass: shadowAccount objectClass: person gidNumber: xxx gecos: John Smith sn: Smith shadowLastChange: xxx userPassword:: xxx loginShell: /sbin/nologin # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 -- The problem is that I have not disabled annonymous or user access other than to set ACLs for the userPassword field. The user jsmith can't even do a search on himself. I've tried slapacl and confirmed that annonymous as well as the jsmith user can read the uid field. I even tried reindexing using slapindex, but that didn't work either. Here is my slapd.conf: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba3.schema include /etc/openldap/schema/qmail.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile/var/run/openldap/slapd.args databasebdb suffix dc=example,dc=com rootdn cn=manager,dc=example,dc=com rootpw xxx access to attrs=userPassword by anonymous auth by self write by * none access to attrs=uid by * read directory /var/lib/ldap index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShelleq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntryeq,pres,sub Am I missing something?? Thanks What do see if you run slapd in debug mode (slapd -d level)? It should tell you exactly what it's balking at. Respectfully, Ryan
Re: A question about log messages
Pierangelo Masarati wrote: Ryan Steele wrote: Hey folks, While researching another problem, I noticed that even on successful searches (e.g., entries returned that match the filters I set), I see the following in the logs: Apr 23 12:45:11 ldapmaster slapd[30294]: send_ldap_result: err=0 matched= text= It almost looks to me like it's saying didn't match anything, when in fact it does return entries. I tried looking through the man pages for an explanation, but didn't find one. If anyone could point me to said documentation, or explain how the above message is supposed to be interpreted given the context of the situation, I'd be much obliged. matched is a field of the LDAP result message as specified in RFC4511, section 4.1.9. That log indicates that the matched field is empty. p. I see no matched field defined in that RFC, only matchedDN. For that matter, I don't see text either, but I do see diagnosticMessage. Are these each respectively equivalent? The RFC also says For certain result codes (typically, but not restricted to noSuchObject, aliasProblem, invalidDNSyntax, and aliasDereferencingProblem), the matchedDN field is set (subject to access controls) to the name of the last entry (object or alias) used in finding the target (or base) object..., so I'm guessing since it's empty for me on a successful search, result code 0 is not among those? Thanks! Ryan
A question about log messages
Hey folks, While researching another problem, I noticed that even on successful searches (e.g., entries returned that match the filters I set), I see the following in the logs: Apr 23 12:45:11 ldapmaster slapd[30294]: send_ldap_result: err=0 matched= text= It almost looks to me like it's saying didn't match anything, when in fact it does return entries. I tried looking through the man pages for an explanation, but didn't find one. If anyone could point me to said documentation, or explain how the above message is supposed to be interpreted given the context of the situation, I'd be much obliged. Thanks, Ryan
Re: A question about pwdMinAge
Howard Chu wrote: Chris G. Sellers wrote: pwdMinAge is part of the password policy, not part of the user's record. The scheme defines pwdMinAge as being part of the objectClass pwdPolicy, so unless you have that in your users record, it will not be there. I believe you assume correct that it uses math to determine when the password was last changed, and when the current time is. If that does not exceed the value of the password policy entry for pwdMinAge, then the change will fail. You could change the user's passwordPolicy to be Zero Day password change,but you would have to change it back. RTFM already. slapo-ppolicy(5), pwdReset. I set pwdReset to TRUE after setting a reasonable pwdMinAge, and reset the user's password with ldappasswd, binding as the rootdn to make the change. Then, I adjusted the sambaPwdCanChange and sambaPwdLastSet values to something earlier than the current time. Alas, I still get Password is too young to change from LDAP. My only recourse at this point is to only enforce the 'min password age' in Samba via pdbedit, but I'd really like to enforce this in LDAP as well as an extra precaution against shell users circumventing the policies laid forth in Samba. Any and all advice and/or clue-stick beatings welcome. I look forward to the day when the interaction between the two is more seamless/native, which hopefully is in the not-too-distant future; I've been made aware of a new RFC proposal to make Samba play nice with ppolicy: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-passwords-00.txt
Re: A question about pwdMinAge
Tony Earnshaw wrote: My site uses ppolicy with great success. Ryan Steele skrev, on 08-04-2008 23:35: I wanted to test the scenario where a user had forgotten his password, and needed to have it reset. I wanted to give this user the ability change this temporary password if they wanted. To do this, I: 1. Executed ldappasswd, binding as the rootdn, to change the user's password 2. Used ldapvi to reset the sambaPwdCanChange and sambaPwdLastSet attributes Fie. That's part of what 'overlay smbk5pwd' is for. Does it automatically. I'm using smbk5pwd, but I think you're missing the point here. Users can change their passwords just fine thanks to the overlay, but not if I reset the password, because then the sambaPwdCanChange, sambaPwdLastSet, and pwdChangedTime (or pwdMinAge) gets updated. The first two I can fix easily, the third is where I run in to trouble. 3. Logged in to the domain as the user 4. Hit Ctrl+Alt+Delete and selected Change Password However, because my ppolicy pwdMinAge hadn't expired yet, the user was unable to change the password. So, it seems necessary to be able to change that value for the user so he/she can change their password. I couldn't find an attribute called pwdMinAge, but I'm assuming that's because it just looks at pwdChangedTime. The pwdMinAge attribute exists. Perhaps a GUI such as gq could help here. I shouldn't need a GUI to administer the directory, but nevertheless I installed phpldapadmin, and it doesn't see a pwdMinAge attribute in the user's entry. Neither slapcat nor ldapvi can find this attribute on the user either. I 'assume' because I couldn't find explicit documentation stating this, though the man page definition for pwdChangedTime says [pwdChangedTime] is used by the password expiration policy to determine whether the password is too old to be allowed to be used for user authentication. Is this why I see a NT_STATUS_WRONG_PASSWORD returned from LDAP when a user tries to change a password that is being protected by pwdMinAge? No, pwdMinAge has nothing to do with Samba, Samba doesn't use it - see pdbedit -P. It _does_ affect being able to change your password when logged into a Samba controlled domain. Adding a pwdMinAge attribute to my password policy prevents the user from being able to change his/her password after it's been reset by an administrator. I'm familiar with pdbedit, but I fail to see how that will help me solve this problem. I'm happy to be convinced otherwise, though. And, is executing an ldapmodify the proper thing to do in this situation to change the pwdChangedTime and allow the user to change his/her password? E.g.: ldapmodify -D cn=admin,dc=example,dc=com -W dn: uid=someuser,ou=Users,dc=example,dc=com changetype: modify replace: pwdChangedTime pwdChangedTime: 1207690188Z pwdChangedTime is an operational attribute and cannot be changed by *any* user, it is the directory that has to change it. Well then, how does one accomplish what I'm trying to do? If a user forgets his/her password, and an admin resets it, I want the user to be able to change it to something they're comfortable with (which adheres to the restrictions), but short of removing the pwdMinAge attribute from my password policy, I can't seem to figure out how that is possible. Thanks as always, Ryan
Re: smbk5pwd and ppolicy working together
Adam, Howard, and list, Upon Howard's suggestion, I went and re-read the docs on ACL's for slapd.conf. What I came up with is the following (I'll change the first asterisk to the specific attributes once I've actually got it working...): # ACL's access to * by dn.exact=cn=pwdchanger,dc=example,dc=com write by * break access to attrs=userPassword,sambaNTPassword,sambaLMPassword,shadowLastChange,shadowMax,sambaPwdLastSet,sambaPwdMustChange by selfwrite by * auth access to * by * read I also set the 'ldap admin dn' to be cn=pwdchanger,dc=example,dc=com in my smb.conf, and added him to the smbpasswd database. I'm happy to report that my initial testing shows that ppolicy indeed is being adhered to now. A big thank you to Howard, Adam, Pat, and others who assisted me. I have noticed, as Thierry Lacoste pointed out, that Windows reports a successful password change when the password fails ppolicy restrictions - but ONLY if I have logging set to 0. I have no idea why the two are related. If I have logging turned on (even to 1), Windows reports The system cannot change your password now because the domain DOMAINNAME is unavailable, but at least it's confirmation on the user end that the change didn't take. However, this is a Samba issue, not an LDAP issue, so I'll take my findings to their mailing list. Again, thanks to those who helped me. Best Regards, Ryan
Re: smbk5pwd and ppolicy working together
Hey Howard, Adam, and List: I'm not even sure this is the path I ought to be going down. If smbk5pwd has no knowledge of ppolicy, and password changes from Windows clients won't adhere to those restrictions with any combination of configuration options in any currently known universe, perhaps what I really need is an alternate strategy. I'm open to suggestion; my only requirements are that password changes from a Windows workstation be subjected to the ppolicy constraints, and that the LDAP and Samba passwords all be in sync. However, here are the logs entries and relevant slapd configuration options - pastings inline below: Howard Chu wrote: Ryan Steele wrote: I realize that 'only' is what I want and that's what I'm using, however I think smbk5pwd is working. The two snippets below are show the differences after a Windows user changes his password (from the ctrl+alt+delete menu): Don't guess. Turn up the slapd debug level and show what it logs when you perform the actual password change. Note that although the logs seem to indicate (at least to my untrained eyes) that access to userPassword, sambaLMPassword, and sambaNTPassword is denied, Windows tells me it's been updated, and I can in fact log out and log back in with the new password. Apr 3 07:27:00 ldapmaster slapd[1012]: = access_allowed: read access to uid=tester,ou=Users,dc=example,dc=com userPassword requested Apr 3 07:27:00 ldapmaster slapd[1012]: = acl_get: [1] attr userPassword Apr 3 07:27:00 ldapmaster slapd[1012]: access_allowed: no res from state (userPassword) Apr 3 07:27:00 ldapmaster slapd[1012]: = acl_mask: access to entry uid=tester,ou=Users,dc=example,dc=com, attr userPassword requested Apr 3 07:27:00 ldapmaster slapd[1012]: = acl_mask: to value by , (=0) Apr 3 07:27:00 ldapmaster slapd[1012]: = check a_dn_pat: self Apr 3 07:27:00 ldapmaster slapd[1012]: = check a_dn_pat: * Apr 3 07:27:00 ldapmaster slapd[1012]: = acl_mask: [2] applying auth(=xd) (stop) Apr 3 07:27:00 ldapmaster slapd[1012]: = acl_mask: [2] mask: auth(=xd) Apr 3 07:27:00 ldapmaster slapd[1012]: = access_allowed: read access denied by auth(=xd) Apr 3 07:27:00 ldapmaster slapd[1012]: send_search_entry: conn 5 access to attribute userPassword, value #0 not allowed Apr 3 07:27:00 ldapmaster slapd[1012]: = access_allowed: read access to uid=tester,ou=Users,dc=example,dc=com sambaLMPassword requested Apr 3 07:27:00 ldapmaster slapd[1012]: = acl_get: [1] attr sambaLMPassword Apr 3 07:27:00 ldapmaster slapd[1012]: access_allowed: no res from state (sambaLMPassword) Apr 3 07:27:00 ldapmaster slapd[1012]: = acl_mask: access to entry uid=tester,ou=Users,dc=example,dc=com, attr sambaLMPassword requested Apr 3 07:27:00 ldapmaster slapd[1012]: = acl_mask: to value by , (=0) Apr 3 07:27:00 ldapmaster slapd[1012]: = check a_dn_pat: self Apr 3 07:27:00 ldapmaster slapd[1012]: = check a_dn_pat: * Apr 3 07:27:00 ldapmaster slapd[1012]: = acl_mask: [2] applying auth(=xd) (stop) Apr 3 07:27:00 ldapmaster slapd[1012]: = acl_mask: [2] mask: auth(=xd) Apr 3 07:27:00 ldapmaster slapd[1012]: = access_allowed: read access denied by auth(=xd) Apr 3 07:27:00 ldapmaster slapd[1012]: send_search_entry: conn 5 access to attribute sambaLMPassword, value #0 not allowed Apr 3 07:27:00 ldapmaster slapd[1012]: = access_allowed: read access to uid=tester,ou=Users,dc=example,dc=com sambaNTPassword requested Apr 3 07:27:00 ldapmaster slapd[1012]: = acl_get: [1] attr sambaNTPassword Apr 3 07:27:00 ldapmaster slapd[1012]: access_allowed: no res from state (sambaNTPassword) Apr 3 07:27:00 ldapmaster slapd[1012]: = acl_mask: access to entry uid=tester,ou=Users,dc=example,dc=com, attr sambaNTPassword requested Apr 3 07:27:00 ldapmaster slapd[1012]: = acl_mask: to value by , (=0) Apr 3 07:27:00 ldapmaster slapd[1012]: = check a_dn_pat: self Apr 3 07:27:00 ldapmaster slapd[1012]: = check a_dn_pat: * Apr 3 07:27:00 ldapmaster slapd[1012]: = acl_mask: [2] applying auth(=xd) (stop) Apr 3 07:27:00 ldapmaster slapd[1012]: = acl_mask: [2] mask: auth(=xd) Apr 3 07:27:00 ldapmaster slapd[1012]: = access_allowed: read access denied by auth(=xd) Apr 3 07:27:00 ldapmaster slapd[1012]: send_search_entry: conn 5 access to attribute sambaNTPassword, value #0 not allowed The only other references I found to these attributes in the logs (which are at loglevel 128) are: Apr 3 07:27:00 ldapmaster slapd[1012]: = root access granted Apr 3 07:27:00 ldapmaster slapd[1012]: = access_allowed: read access to uid=tester,ou=Users,dc=example,dc=com sambaLMPassword requested Apr 3 07:27:00 ldapmaster slapd[1012]: = root access granted Apr 3 07:27:00 ldapmaster slapd[1012]: = access_allowed: read access to uid=tester,ou=Users,dc=example,dc=com sambaNTPassword requested Also, don't make us guess - post the relevant portion of your slapd configuration. include /etc/openldap/schema/ppolicy.schema # Dynamic modules moduleload smbk5pwd.la rootdn cn=admin,dc
Re: smbk5pwd and ppolicy working together
Howard and others, Let me ask two theoretical questions, before I submit my comments below. Windows XP/2000/et. al. send their passwords via SMB hashed. So, without configuring those workstations to send the passwords plaintext over the wire, is there any way for ppolicy to act on the ldapmodify initiated by Samba from Windows clients attempting to change their passwords? Furthermore, if the above change is made so that ppolicy can evaluate the plaintext password, what exactly will the interaction between LDAP and the clients be if it fails to clear ppolicy constraints? Additional comments below Howard Chu wrote: Ryan Steele wrote: Hey Howard, Adam, and List: I'm not even sure this is the path I ought to be going down. If smbk5pwd has no knowledge of ppolicy, and password changes from Windows clients won't adhere to those restrictions with any combination of configuration options in any currently known universe, perhaps what I really need is an alternate strategy. I'm open to suggestion; my only requirements are that password changes from a Windows workstation be subjected to the ppolicy constraints, and that the LDAP and Samba passwords all be in sync. However, here are the logs entries and relevant slapd configuration options - pastings inline below: snip This is syslog output, not debug output. I said to bump up the debug level. Maybe I'm misunderstanding. From the slapd.conf manpage: loglevel integer [...] Specify the level at which debugging statements and operation statistics should be syslogged (currently logged to the syslogd(8) LOG_LOCAL4 facility). I thought debugging statements is what you wanted? When I start slapd with the -d option, I seem to get the same output as when I specify 'loglevel N' in the slapd.conf. snip As already mentioned, ppolicy doesn't restrict the rootDN. If you want your policy constraints to work, you have to bind with some other DN to make the changes. That will of course mean that you have to give that DN write access to the selected attributes in your ACL. Ok - I'll create an LDAP user specifically for changing passwords, and set that as my ldap admin dn in the smb.conf, so the change won't be done by the rootdn, as recommended by Adam and yourself. I'll then create an entry in the slapd.conf like the one below and give that a shot. # ACL's access to attrs=userPassword,sambaNTPassword,sambaLMPassword,shadowLastChange,shadowMax,sambaPwdLastSet,sambaPwdMustChange by selfwrite by * auth access to attrs=userPassword,sambaNTPassword,sambaLMPassword,shadowLastChange,shadowMax,sambaPwdLastSet,sambaPwdMustChange,pwdChangedTime,pwdHistory by dn=cn=pwchanger,dc=example,dc=com write access to * by * read
Re: smbk5pwd and ppolicy working together
Adam Tauno Williams wrote: I say this because clients joined to the domain (run by a Samba PDC with an OpenLDAP backend) can change their passwords and it updates the NT/LM passwords in LDAP, thus verifying the functionality of smk5pwd, but it does not appear to enforce ppolicy restrictions. On the flip side of the coin, the user can change their LDAP password by invoking ldappasswd from a shell on the server, and are bound by the restrictions set forth by ppolicy (password length, strength, historical passwords, etc.). The ppolicy overlay is adding extra functionality to the password extended operation. ldappasswd uses this. The restriction is not present if you update the password hash via the ldapmodify command. The key is in the extended operation. As an added tidbit only userPassword is monitored not any other attribute. Samba does password changes via an ldapmodify rather than an ldappasswd (unless you have ldap passwd sync = Only which I have never personally used so I have no tests to back this up). This would explain why LDAP has the policy enforcing and Samba does not. My 'passwd program' in my smb.conf is passwd program = /usr/bin/ldappasswd -x -W -S -D uid=%u,ou=Users,dc=example,dc=com - so it should be using ldappasswd, which is bound by ppolicy, correct? You shouldn't need a passwd program when using an LDAP SAM. You're right. In reading the Samba documentation, I see that's only for updating Unix passwords, not LDAP passwords (though I suppose it's relevant if PAM is using LDAP and you set 'unix passwd sync = yes'; however, this is not my situation). I've tried 'ldap passwd sync = only', after my failures with 'ldap passwd sync = yes' lead me back to the documentation, however this yielded no success. I'm pretty sure if you have ldap passwd sync = yes that your passwd program directive is irrelevant since this means Samba is doing an ldapmodify to set the NT, LM, and userPassword attributes - your passwd program isn't doing anything. If only doesn't work then I strongly suspect that your smk5pwd module is *not* working, otherwise only would be the only mode to make any sense. By setting ldap passwd sync = yes your, at best, doing the work of smbk5pwd twice. I realize that 'only' is what I want and that's what I'm using, however I think smbk5pwd is working. The two snippets below are show the differences after a Windows user changes his password (from the ctrl+alt+delete menu): sambaPwdCanChange: 1207134133 sambaPwdMustChange: 2147483647 userPassword:: e1NTSEF9UkxaOUdIZnVhNkV2ejBzS0JKNVVWQ2pVOHNnR29Ma1Q= sambaPwdLastSet: 1207134133 sambaLMPassword: d85774cf671a9947aad3b435b51404ee sambaNTPassword: baac3929fabc9e6dcd32421ba94a84d4 pwdChangedTime: 20080402110213Z entryCSN: 20080402110213Z#01#00#00 modifiersName: cn=admin,dc=example,dc=com modifyTimestamp: 20080402110213Z sambaPwdMustChange: 2147483647 sambaPwdCanChange: 1207137250 userPassword:: e1NTSEF9NWMveHkxSkVtZDcvcnZuWFZ4a3dtMVJsUnAzUGdEQW4= sambaPwdLastSet: 1207137250 sambaLMPassword: 614a6376feed376daad3b435b51404ee sambaNTPassword: d01b4a346f59e594f299a41a48126188 pwdChangedTime: 20080402115410Z entryCSN: 20080402115410Z#01#00#00 modifiersName: cn=admin,dc=example,dc=com modifyTimestamp: 20080402115410Z Unless my test or logic (or both) are fundamentally flawed, it seems like the NT and LM passwords are being changed, along with the other attributes listed above. Interestingly enough, however, the modifiersName is admin (who isn't bound by the ppolicy restrictions) - perhaps that is what's causing the circumvention of ppolicy? Should I be investigating a way to force the modifier to be the user themselves? Thanks as always for advice and constructive criticisms. Ryan
smbk5pwd and ppolicy working together
Hello, I've got the smbk5pwd and ppolicy modules working, but I'm not entirely sure I've got them working together. I say this because clients joined to the domain (run by a Samba PDC with an OpenLDAP backend) can change their passwords and it updates the NT/LM passwords in LDAP, thus verifying the functionality of smk5pwd, but it does not appear to enforce ppolicy restrictions. On the flip side of the coin, the user can change their LDAP password by invoking ldappasswd from a shell on the server, and are bound by the restrictions set forth by ppolicy (password length, strength, historical passwords, etc.). But, I cannot seem to get ppolicy and smbk5pwd to operate in conjunction with one another - when changed from a Windows client, only smbk5pwd seems to work. I was initially thinking this was maybe because Windows was sending the passwords already hashed to OpenLDAP, but if I send a password such as 'a', I get this message: Your password must be at least 5 characters, cannot repeat any of your previous 0 passwords and must be at least 0 days old. Please type a different password. Type a password that meets these requirements in both text boxes. However, I have no idea where it's getting those requirements or that text from, though I'm wondering it's a Windows policy. In any case, it's certainly not what ppolicy requires, as is the case from a shell on the server. I also see this in the sambaPasswordHistory attribute, which (possibly?) indicates that ppolicy isn't working properly in conjunction with smbk5pwd, and possibly explains why isn't not triggering on the historical passwords: sambaPasswordHistory: That doesn't explain, though, why the strength and length checks aren't working. I've ramped up the debugging on the back end, but all I see is Samba happily updating with weak passwords and no mention of password lengths (even when that dialog pops up on the Windows client side). I'd appreciate any insight anybody might have. Thanks, Ryan
Re: smbk5pwd and ppolicy working together
Hi Pat, I didn't actually receive the copy of my message from the list hopefully there hasn't been any other correspondence on this that I've missed. My replies are inline as well. Pat Riehecky wrote: Here is what I know on this, wiser minds may feel free to correct everything I have to say. replies are inline. On Tue, 2008-04-01 at 15:46 -0400, Ryan Steele wrote: Hello, I've got the smbk5pwd and ppolicy modules working, but I'm not entirely sure I've got them working together. I say this because clients joined to the domain (run by a Samba PDC with an OpenLDAP backend) can change their passwords and it updates the NT/LM passwords in LDAP, thus verifying the functionality of smk5pwd, but it does not appear to enforce ppolicy restrictions. On the flip side of the coin, the user can change their LDAP password by invoking ldappasswd from a shell on the server, and are bound by the restrictions set forth by ppolicy (password length, strength, historical passwords, etc.). The ppolicy overlay is adding extra functionality to the password extended operation. ldappasswd uses this. The restriction is not present if you update the password hash via the ldapmodify command. The key is in the extended operation. As an added tidbit only userPassword is monitored not any other attribute. Samba does password changes via an ldapmodify rather than an ldappasswd (unless you have ldap passwd sync = Only which I have never personally used so I have no tests to back this up). This would explain why LDAP has the policy enforcing and Samba does not. My 'passwd program' in my smb.conf is passwd program = /usr/bin/ldappasswd -x -W -S -D uid=%u,ou=Users,dc=example,dc=com - so it should be using ldappasswd, which is bound by ppolicy, correct? I've tried 'ldap passwd sync = only', after my failures with 'ldap passwd sync = yes' lead me back to the documentation, however this yielded no success. But, I cannot seem to get ppolicy and smbk5pwd to operate in conjunction with one another - when changed from a Windows client, only smbk5pwd seems to work. I was initially thinking this was maybe because Windows was sending the passwords already hashed to OpenLDAP, but if I send a password such as 'a', I get this message: Your password must be at least 5 characters, cannot repeat any of your previous 0 passwords and must be at least 0 days old. Please type a different password. Type a password that meets these requirements in both text boxes. I would recommend reading the information at http://www.linuxtopia.org/online_books/network_administration_guides/samba_reference_guide/18_passdb_15.html for an answer to this. It should, by inference explain the questions you have below as well. Questions on this should be aimed at the samba list. Dually noted. However, I have no idea where it's getting those requirements or that text from, though I'm wondering it's a Windows policy. In any case, it's certainly not what ppolicy requires, as is the case from a shell on the server. I also see this in the sambaPasswordHistory attribute, which (possibly?) indicates that ppolicy isn't working properly in conjunction with smbk5pwd, and possibly explains why isn't not triggering on the historical passwords: sambaPasswordHistory: That doesn't explain, though, why the strength and length checks aren't working. I've ramped up the debugging on the back end, but all I see is Samba happily updating with weak passwords and no mention of password lengths (even when that dialog pops up on the Windows client side). I'd appreciate any insight anybody might have. Thanks, Ryan
Struggling with ppolicy
Hey folks,
If this is the wrong list, please let me know and I'd be happy to send
it to the right one.
As I've mentioned in a previous post (which hasn't been posted yet, so I
apologize if you've seen any of this information already) I've got a FC6
box, with OpenLDAP 2.3.30. I'm attempting to get ppolicy to work, and I
can now successfully start OpenLDAP with the ppolicy directive in it:
### abridged slapd.conf ###
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/ppolicy.schema
modulepath /usr/lib/openldap
overlay ppolicy
ppolicy_default cn=Password Policy,ou=policies,ou=example,ou=com
access to
attrs=userPassword,sambaNTPassword,sambaLMPassword,shadowLastChange,shadowMax,sambaPwdLastSet,sambaPwdMustChange
by self write
by * auth
access to *
by * read
database bdb
suffix dc=example,dc=com
rootdn cn=admin,dc=example,dc=com
rootpw {SSHA}X
directory /var/lib/ldap
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
sasl-secprops none
### Password Policy entry via slapcat ###
dn: cn=Password Policy,ou=policies,dc=example,dc=com
objectClass: top
objectClass: device
objectClass: pwdPolicy
cn: Password Policy
pwdAttribute: 2.5.4.35
pwdMaxAge: 3888000
pwdInHistory: 2
pwdCheckQuality: 1
pwdMinLength: 6
pwdExpireWarning: 432000
pwdGraceAuthNLimit: 5
pwdMaxFailure: 10
pwdFailureCountInterval: 0
pwdMustChange: FALSE
pwdAllowUserChange: TRUE
pwdSafeModify: TRUE
pwdLockoutDuration: 7776000
pwdLockout: TRUE
structuralObjectClass: device
entryUUID: 2e1eee98-83ea-102c-9736-1d2794f3677b
creatorsName: cn=admin,dc=example,dc=com
createTimestamp: 20080311190746Z
entryCSN: 20080311190746Z#00#00#00
modifiersName: cn=admin,dc=example,dc=com
modifyTimestamp: 20080311190746Z
[EMAIL PROTECTED] openldap]# /etc/init.d/ldap start
Checking configuration files for slapd: WARNING: No dynamic config
support for overlay ppolicy.
config file testing succeeded
[ OK ]
Starting slapd: [ OK ]
From what I gather, since I'm using a slapd.conf and not a back-bdb,
that warning does not apply to me.
However, when I add users, I see no special attributes that show they're
being regulated by ppolicy (Googling turned up some ldif's that had
pwdPolicySubentry attributes - should I have that?) Additionally, I can
enter passwords such as 'a' - single characters, and it doesn't complain
at all. In fact, none of the restrictions are being enforced, and I'm
really scratching my head. The options I compiled with were:
--enable-plugins \
--enable-ppolicy=yes \
--enable-slapd \
--enable-slurpd \
--enable-multimaster \
--enable-bdb \
--enable-hdb \
--enable-ldap \
--enable-ldbm \
--with-ldbm-api=%{ldbm_backend} \
--enable-meta \
--enable-monitor \
--enable-null \
--enable-shell \
--enable-sql=mod \
--disable-perl \
--disable-shared \
--disable-dynamic \
--enable-static \
--with-kerberos=k5only
Thanks in advance for any help...
Best Regards,
Ryan
Operational attribute pwdFailureTime not being added to entries
Hello,
First let me thank the gracious folks on this list who have lent their
advice to me on my path towards implementing ppolicy. I'm making
progress; I can reject new passwords based on password history, and
reject weak passwords. However, I'm having a bit of a time trying to
get the lockouts to work. My policy is defined as:
56 cn=Password Policy,ou=Policies,dc=example,dc=com
objectClass: top
objectClass: device
objectClass: pwdPolicy
cn: Password Policy
pwdAttribute: userPassword
pwdMaxAge: 3888000
pwdMinLength: 6
pwdExpireWarning: 432000
pwdFailureCountInterval: 0
pwdMustChange: FALSE
pwdAllowUserChange: TRUE
pwdSafeModify: TRUE
pwdLockout: TRUE
pwdCheckQuality: 1
pwdGraceAuthNLimit: 0
pwdInHistory: 6
pwdLockoutDuration: 60
pwdMaxFailure: 3
However, even after many failure attempts, I see no pwdFailureTime attributes
in the offending user's entry:
dn: uid=testuser,ou=Users,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: sambaSamAccount
cn: testuser
sn: testuser
givenName: testuser
uid: testuser
uidNumber: 1009
gidNumber: 513
homeDirectory: /home/testuser
loginShell: /bin/bash
gecos: System User
structuralObjectClass: inetOrgPerson
entryUUID: 42d5971e-7b49-102c-8aae-af676a6dbed9
creatorsName: cn=admin,dc=example,dc=com
createTimestamp: 20080229193543Z
sambaLogonTime: 0
sambaLogoffTime: 2147483647
sambaKickoffTime: 2147483647
sambaPwdCanChange: 0
displayName: System User
sambaSID: S-1-5-21-1484159386-3942804292-94657008-3018
sambaPrimaryGroupSID: S-1-5-21-1484159386-3942804292-94657008-513
sambaLogonScript: logon.bat
sambaProfilePath: \\masterldap.example.com\profiles\testuser
sambaHomePath: \\masterldap.example.com\testuser
sambaHomeDrive: H:
pwdHistory: 20080313194326Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}C2DOwhgHFTc
XmGxRdqlpBUz12eZpRXI4
pwdHistory: 20080313194602Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}AboL9Sp7678
X2KsPv8sMPE5CC2i6c6LY
pwdHistory: 20080313194626Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}7hUqCecYGvd
g5bx1ybw71YQcZShicmFk
pwdHistory: 20080313194852Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}E920Fe1PlYV
Bwjn+rpiOFO8UaiRzZnB6
pwdHistory: 20080313200637Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}hFfD2xFwG/T
s5PVg3CAIf4i6rkpaZnNM
pwdHistory: 20080313200941Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}/GpzR2wV7dy
XITeU+5nBpFyTKdgxQzk4
sambaLMPassword: X
sambaAcctFlags: [U]
sambaNTPassword: X
sambaPwdLastSet: 1205438797
sambaPwdMustChange: 1209326797
userPassword:: X
pwdChangedTime: 20080313200941Z
entryCSN: 20080313200941Z#00#00#00
modifiersName: cn=admin,dc=example,dc=com
modifyTimestamp: 20080313200941Z
Is the shadowAccount attribute killing me? I'm not really sure. Just for
completeness, the slapd.conf (abridged) looks like:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/ppolicy.schema
pidfile /var/run/openldap/slapd.pid
argsfile/var/run/openldap/slapd.args
modulepath /usr/lib/openldap
databasebdb
suffix dc=example,dc=com
directory /var/lib/ldap
rootdn cn=admin,dc=example,dc=com
rootpw {SSHA}tFEA391Y3ZLHXkQDDk6f0t1ZkJEuMwIj
overlay ppolicy
ppolicy_default cn=Password Policy,ou=Policies,dc=example,dc=com
ppolicy_use_lockout
access to
attrs=userPassword,sambaNTPassword,sambaLMPassword,shadowLastChange,shadowMax,sambaPwdLastSet,sambaPwdMustChange
by selfwrite
by * auth
access to *
by * read
moduleload smbk5pwd.la
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShelleq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntryeq,pres,sub
loglevel -1
sasl-secprops none
As always, thank you for your help.
Best Regards,
Ryan
