openldap-technical

openldap-technical@openldap.org

12 participants
9794 discussions

Openldap/authconfig authenticating multiple times
by Dave Macias 21 Nov '17

21 Nov '17

Not sure if I sent this right the first time.... I had posted this on centos forum here but no help :( https://www.centos.org/forums/viewtopic.php?f=48&t=65041&hilit=authconfig Basic background: 3 openldap servers with multimaster replication and ppolicy pwdMaxFailure: 6 . When i try to authenticate to the linux box authconfig authenticates to all 3 master servers which return 3 failures, which give you 3 pwdFailureTime attributes for the account. So after typing the password incorrectly twice, the user get's locked out. Trying to understand why this is happening. When configured another clean box i dont see this behavior (one pwdFailureTime per incorrect password attempt). I've also reinstalled related packages but no change. The behavior is seen on all three master ldap servers. Please see the link for details Any input is appreciated. thank you, -dave

1 0

ldap + meta "Proxy operation retry failed" when re-binding as retrieved user for Active Directory account authentication
by Boyd, John K. 20 Nov '17

20 Nov '17

According to my slapd debug logs, after the account is not found locally, the search continues in active directory. I can bind under the admin query only account and successfully retrieve the user account information (I have verified this) from active directory; however, I can't then rebind-as-user with the user password in order to authenticate. I get a "Proxy operation retry failed" error: slapd[22555]: conn=1000 fd=8 ACCEPT from IP=127.0.0.1:35848 (IP=127.0.0.1:389) slapd[22555]: conn=1001 fd=9 ACCEPT from IP=127.0.0.1:35850 (IP=127.0.0.1:389) slapd[22555]: conn=1000 op=0 BIND dn="cn=xxxx,ou=local" method=128 slapd[22555]: conn=1000 op=0 BIND dn="cn=xxxx,ou=local" mech=SIMPLE ssf=0 slapd[22555]: conn=1000 op=0 RESULT tag=97 err=0 text= slapd[22555]: conn=1000 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(uid=xxxx0029)" slapd[22555]: conn=1002 fd=11 ACCEPT from IP=127.0.0.1:35852 (IP=127.0.0.1:389) slapd[22555]: conn=1002 op=0 BIND dn="cn=xxxx,ou=local" method=128 slapd[22555]: conn=1002 op=0 BIND dn="cn=xxxx,ou=local" mech=SIMPLE ssf=0 slapd[22555]: conn=1002 op=0 RESULT tag=97 err=0 text= slapd[22555]: conn=1003 fd=13 ACCEPT from IP=127.0.0.1:35854 (IP=127.0.0.1:389) slapd[22555]: conn=1003 op=0 BIND dn="cn=xxxx,ou=local" method=128 slapd[22555]: conn=1003 op=0 BIND dn="cn=xxxx,ou=local" mech=SIMPLE ssf=0 slapd[22555]: conn=1003 op=0 RESULT tag=97 err=0 text= slapd[22555]: conn=1002 op=1 SRCH base="ou=xxxx,dc=sooner,dc=net,dc=ou,dc=edu" scope=2 deref=0 filter="(uid=xxxx0029)" slapd[22555]: conn=1003 op=1 SRCH base="ou=local" scope=2 deref=0 filter="(uid=xxxx0029)" slapd[22555]: conn=1003 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text= slapd[22555]: conn=1000 op=1 meta_back_search[1] match="" err=32 (No such object) text="". slapd[22555]: conn=1002 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[22555]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[22555]: conn=1001 op=0 BIND dn="cn=11079,ou=xxxx,dc=a,dc=example,dc=com" method=128 slapd[22555]: conn=1004 fd=16 ACCEPT from IP=127.0.0.1:35858 (IP=127.0.0.1:389) slapd[22555]: conn=1004 op=0 BIND dn="cn=11079,ou=General,ou=xxxx,dc=sooner,dc=net,dc=ou,dc=edu" method=128 slapd[22555]: conn=1004 op=0 ldap_back_retry: retrying URI="ldaps://active.directory" DN="" slapd[22555]: conn=1004 op=0 RESULT tag=97 err=52 text=Proxy operation retry failed slapd[22555]: conn=1004 op=1 UNBIND slapd[22555]: conn=1001 op=0 RESULT tag=97 err=52 text= slapd[22555]: conn=1004 fd=16 closed Here is my meta configuration: database meta suffix dc=example,dc=com # The last rwm-map line maps all other attributes to nothing. overlay rwm rwm-map attribute uid sAMAccountname rwm-map attribute * #rwm-map objectclass posixGroup group #rwm-map objectclass posixAccount person #rwm-map objectclass memberUid member ## uri "ldap://127.0.0.1/dc=a,dc=example,dc=com" suffixmassage "dc=a,dc=example,dc=com" "ou=xxxx,dc=sooner,dc=net,dc=ou,dc=edu" rebind-as-user true idassert-bind bindmethod=simple binddn="cn=XXXX,ou=local" credentials=XXXX mode=none idassert-authzFrom "dn.regex:.*" ## uri "ldap://127.0.0.1/dc=b,dc=example,dc=com" suffixmassage "dc=b,dc=example,dc=com" "ou=local" rebind-as-user true idassert-bind bindmethod=simple binddn="cn=XXXX,ou=local" credentials=XXXX mode=none idassert-authzFrom "dn.regex:.*" ## database ldap uri ldaps://active.directory suffix ou=xxxx,dc=sooner,dc=net,dc=ou,dc=edu rebind-as-user true idassert-bind bindmethod=simple binddn="cn=XXXX,ou=it,ou=services,ou=accounts,dc=sooner,dc=net,dc=ou,dc=edu" credentials=XXXX tls_reqcert=allow tls_cacert=/etc/letsencrypt/live/lmamr-lims.rccc.ou.edu/fullchain.pem tls_cert=/etc/letsencrypt/live/lmamr-lims.rccc.ou.edu/cert.pem tls_key=/etc/letsencrypt/live/lmamr-lims.rccc.ou.edu/privkey.pem mode=none idassert-authzFrom "dn.regex:.*"

1 0

One account for modifying directory and wiki
by John Lewis 20 Nov '17

20 Nov '17

I want to have one account for modifying both a LDAP directory and a Mediawiki. What tactic would you you use to do it?

2 4

Re: ssf Security Question
by Howard Chu 20 Nov '17

20 Nov '17

William Brown wrote: > On Fri, 2017-11-17 at 08:34 +0100, Michael Ströder wrote: >> William Brown wrote: >>> Just want to point out there are some security risks with ssf >>> settings. >>> I have documented these here: >>> >>> https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.ht >>> ml >> >> Nice writeup. I always considered SSF values to be naive and somewhat >> overrated. People expect too much when looking at these numbers - >> especially regarding the "strength" of cryptographic algorithms which >> changes over time anyway with new cryptanalysis results coming up. >> >> Personally I always try to implement a TLS-is-must policy and prefer >> LDAPS (with correct protocol and ciphersuites configured) over >> LDAP/StartTLS to avoid this kind of pre-TLS leakage. >> Yes, I deliberately ignore "LDAPS is deprecated". ;-] > > I agree. If only there was a standards working group that could > deprecate startTLS in favour of TLS .... :) I have to agree as well. On my own servers I also use TLS on other "plaintext" ports too (such as pop3 and others) that no one has any business connecting to in plaintext. >> Furthermore some LDAP server implementation (IIRC e.g. MS AD) refuse >> to >> accept SASL/GSSAPI bind requests sent over TLS-secured channel. Which >> is >> IMO also somewhat questionable. > > Yes, I really agree. While a plain text port exists, data leaks are > possible. We should really improve this situation, where we have TLS > for all data to prevent these mistakes. > > I think a big part of the issue is that GSSAPI forces the encryption > layer, and can't work via an already encrypted channel. The people I > know involved in this space are really resistant to changing this due > to the "kerberos centric" nature of the products. Interesting. Our libldap/liblber works fine with GSSAPI's encryption layered over TLS and vice versa. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

[LMDB] Large transactions
by Jürgen Baier 20 Nov '17

20 Nov '17

Hi, I have a question about LMDB (I hope this is the right mailing list for such a question). I'm running a benchmark (which is similar to my intended use case) which does not behave as I hoped. I store 1 billion key/value pairs in a single LMDB database. _In a single transaction._ The keys are MD5 hash codes from random data (16 bytes) and the value is the string "test". I'm using lmdbjava which currently uses LMDB 0.9.19. The benchmark is executed on Linux (Ubuntu 17.04 with a 4.10 kernel and a ext4 filesystem). In the beginning the data is inserted relatively fast: 1M/1000M took:3317 ms (3s 317ms) Then the insert performance deteriorates gradually. After inserting 642M entries inserting 1M entries takes more than 5 minutes: 642M/1000M took:305734 ms (5m 5s 734ms) At this time the database size (data.mdb) is about 27GiB. The filesystem buffer cache has about the same value, so I assume most pages are cached. Linux still reports 28G free memory. A short analysis with perf seems to indicate that most time is spent in mdb_page_spill Children Self 96,45% 0,00% lmdbjava-native-library.so [.] mdb_cursor_put 96,45% 0,00% lmdbjava-native-library.so [.] mdb_put 96,45% 0,00% jffi8421248145368054745.so (deleted) [.] 0xffff80428d388b3f 60,43% 2,61% lmdbjava-native-library.so [.] mdb_page_spill.isra.16 47,39% 47,39% lmdbjava-native-library.so [.] mdb_midl_sort 26,07% 0,24% lmdbjava-native-library.so [.] mdb_page_touch 26,07% 0,00% lmdbjava-native-library.so [.] mdb_cursor_touch 25,83% 0,00% lmdbjava-native-library.so [.] mdb_page_unspill 23,22% 0,24% lmdbjava-native-library.so [.] mdb_page_dirty 22,99% 22,27% lmdbjava-native-library.so [.] mdb_mid2l_insert 11,14% 0,24% [kernel.kallsyms] [k] entry_SYSCALL_64_fastpath 10,43% 0,47% lmdbjava-native-library.so [.] mdb_page_flush 9,95% 0,00% libpthread-2.24.so [.] __GI___libc_pwrite 9,72% 0,00% [kernel.kallsyms] [k] vfs_write 9,72% 0,00% [kernel.kallsyms] [k] sys_pwrite64 9,48% 0,00% [kernel.kallsyms] [k] generic_perform_write 9,48% 0,00% [kernel.kallsyms] [k] __generic_file_write_iter 9,48% 0,00% [kernel.kallsyms] [k] ext4_file_write_iter 9,48% 0,00% [kernel.kallsyms] [k] new_sync_write 9,48% 0,00% [kernel.kallsyms] [k] __vfs_write 9,24% 0,00% lmdbjava-native-library.so [.] mdb_cursor_set 8,06% 0,47% lmdbjava-native-library.so [.] mdb_page_search 7,35% 0,95% lmdbjava-native-library.so [.] mdb_page_search_root 4,98% 0,24% lmdbjava-native-library.so [.] mdb_page_get.isra.13 The documentation about mdb_page_spill says (as far as I understand) that this function is called to prevent MDB_TXN_FULL situations. Does this mean that my transaction is simply too large to be handled efficiently by LMDB? Note that a similar benchmark with 4 byte integer keys took only 2h34m for 1000M entries (the integer keys were sorted, but I did not use MDB_APPEND). I understand LMDB is not write-optimized and maybe my transactions are simply too large. However, I hope I'm just doing something wrong and I can still use LMDB for my use case. Any ideas? Thank you, Juergen -- Juergen Baier

1 0

ssf Security Question
by Kaya Saman 20 Nov '17

20 Nov '17

Hi, I am a little confused with this. Basically I have a client connecting to the database, a DECT IP phone base station which doesn't support STARTLS and my slapd config has settings for clients to use certificates to connect. What would be the best way to set this up so that the DECT IP client only accesses the particular place that it needs to, the AddressBook section but then other clients will need to use STARTTLS for everything else?? Currently I am looking at: https://www.openldap.org/doc/admin24/security.html https://www.openldap.org/doc/admin24/access-control.html and have currently put this in my slapd.conf: #Removed the Global? security clause #security ssf=128 #Added generic ACL for all access to require ssf of 128 access to * by ssf=128 self write by ssf=128 anonymous auth by ssf=128 users read #Added ACL for open access to AddressBook in Read and Search only mode access to dn.children="ou=AddressBook,dc=domain,dc=com" by * search by * read Is this correct or do I need to engage the "security" Global section too? Though the documentation suggests otherwise: "For fine-grained control, SSFs may be used in access controls. See theAccess Control <https://www.openldap.org/doc/admin24/access-control.html>section for more information." Thanks. Kaya

3 3

Re: ssf Security Question
by Quanah Gibson-Mount 20 Nov '17

20 Nov '17

--On Friday, November 17, 2017 12:53 PM +1000 William Brown <wibrown(a)redhat.com> wrote: Hi William, > Hey mate, > > Just want to point out there are some security risks with ssf settings. > I have documented these here: > > https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.html > > This is a flaw in the ldap protocol and can never be resolved without > breaking the standard. The issue is that by the time the ssf check is > done, you have already cleartexted sensitive material. I think what you mean is: There is no way with startTLS to prevent possible leakage of credentials when using simple binds. ;) Your blog certainly covers this concept well, but just wanted to be very clear on what the actual issue is. ;) I've been rather unhappy about this for a long time as well, and have had a discussion going on the openldap-devel list about LDAPv4 and breaking backwards compatibility to fix this protocol bug. Another note -- The reason GSSAPI shows up as an SSF of 56 is because it has been hard coded that way in cyrus-sasl. Starting with cyrus-sasl version 2.1.27, which is near release, the actual SASL SSF is finally passed back into the caller. It may be worthwhile noting this in your blog post. ;) Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 2

Re: Is existing documentation kind of vague?
by Howard Chu 19 Nov '17

19 Nov '17

MJ J wrote: > Certainly, I will make a better list tomorrow or so and send them to > you. Generally, it relates to the areas of cn=config which are not > runtime configurable and the lack of inline ACLs being first-class > citizens. > > Basically, I feel that anything which is exposed via cn=config should > not require an offline slapadd in order to take effect. These are not > really huge problems for LDAP experts, but quite challenging when > trying to train a bit less skilled people to handle operations. A > detailed list of cn=config params which can and cannot be modified > during runtime would help matters greatly, instead of the current > situation of knowledge via trial and error ;-) The intention has always been 100% runtime modifiable. Any that aren't should be considered as bugs in 2.5. > On Sun, Nov 19, 2017 at 8:28 PM, Howard Chu <hyc(a)symas.com> wrote: >> MJ J wrote: >>> >>> I actually like 389 a lot and I have used Netscape DS extensively in >>> managing international telecom networks about 15 years ago. There are >>> quite many management features that are superior to OpenLDAP still to >>> this day, but I simply cannot use it anymore because of the lack of >>> scalability. I know the original Netscape DS devs quite extensively... >> >> >> There are certainly some obvious deficiences remaining in cn=config, and >> we're working on addressing as many as possible for 2.5. But I'd be curious >> to see your list of issues. >> >> >>> >>> -mike >>> >>> On Fri, Nov 17, 2017 at 8:34 AM, William Brown <wibrown(a)redhat.com> wrote: >>>> >>>> On Fri, 2017-11-17 at 08:27 +0200, MJ J wrote: >>>>> >>>>> No matter how you wrap poll() and select(), they will always be >>>>> poll() >>>>> and select() - you will always run loops around an ever increasing >>>>> stack of file descriptors while doing I/O. BDB is always going to >>>>> have >>>>> the same old problems... That's what I'm talking about - sacrificing >>>>> performance for platform portability (NSPR). >>>>> >>>>> FreeIPA could be multi-tenant i.e.support top-level and subordinate >>>>> kerberos realms if it supported a more sensible DIT layout. I know >>>>> because I have built such a system (based on OpenLDAP) and deployed >>>>> it >>>>> internationally. Probably the best piece of code to come out of the >>>>> project is bind-dyndb-ldap. >>>> >>>> >>>> Whoa mate - I'm not here to claim that 389 is a better ldap server - we >>>> just do some different things. We acknowledge our limitations and are >>>> really working on them and paying down our tech debt. We want to remove >>>> parts of nspr, replace bdb and more. :) >>>> >>>> I'm here to follow the progress of the openldap project, who have a >>>> team of people I respect greatly and want to learn from, and here to >>>> help discussions and provide input from a different perspective. >>>> >>>> There are things that today openldap does much better than us for >>>> certain - and there are also some things that we do differently too >>>> like DNA plugin uid allocation, replication etc, >>>> >>>> There are also project focusses and decisions made to improve >>>> supportability in systems like FreeIPA - we can discuss them forever, >>>> but reality is today, FreeIPA is not targeting multi-tennant >>>> environments because the majority of our consumers don't want that >>>> functionality. We made a design decision and have to live with it. I'm >>>> providing this information to help give the ability for people to >>>> construct an informed opinion. >>>> >>>> >>>> As mentioned, I'm not here to throw insults and criticisms, I'm here to >>>> have positive, respectful discussions about technology, to provide >>>> different ideas, and to learn from others :) >>>> >>>> Thanks, >>>> >>>>> >>>>> On Fri, Nov 17, 2017 at 4:49 AM, William Brown <wibrown(a)redhat.com> >>>>> wrote: >>>>>> >>>>>> On Thu, 2017-11-16 at 05:54 +0200, MJ J wrote: >>>>>>> >>>>>>> Sure, it can be improved to become invulnerable to the >>>>>>> academically >>>>>>> imaginative race conditions that are not going to happen in real >>>>>>> life. >>>>>>> That will go to the very bottom of my list of things to do now, >>>>>>> thanks. >>>>>>> >>>>>>> FreeIPA is a cool concept, too bad it's not scalable or multi- >>>>>>> tenant >>>>>>> capable. >>>>>> >>>>>> >>>>>> It's a lot more scalable depending on which features you >>>>>> enable/disable. It won't even be multi-tenant due to the design >>>>>> with >>>>>> gssapi/krb. >>>>>> >>>>>> At the end of the day, the atomic UID/GID alloc in FreeIPA is from >>>>>> the >>>>>> DNA plugin from 389-ds-base (which you can multi-instance on a >>>>>> server >>>>>> or multi-tentant with many backends). We use a similar method to AD >>>>>> in >>>>>> that each master has a pool of ids to alloc from, and they can >>>>>> atomically request pools. This prevents the race issues you are >>>>>> describing here with openldap. >>>>>> >>>>>> So that's an option for you, because those race conditions *do* and >>>>>> *will* happen, and it will be a bad day for you when they do. >>>>>> >>>>>> >>>>>> Another option is an external IDM system that allocs the uid's and >>>>>> feeds them to your LDAP environment instead, >>>>>> >>>>>> Full disclosure: I'm a core dev of 389 directory server, so that's >>>>>> why >>>>>> I'm speaking in this context. Not here to say bad about openldap or >>>>>> try >>>>>> to poach you, they are a great project, just want to offer >>>>>> objective >>>>>> insight from "the other (dark?) side". :) >>>>>> >>>>>>> >>>>>>> On Wed, Nov 15, 2017 at 11:09 PM, Michael Ströder <michael@stroed >>>>>>> er.c >>>>>>> om> wrote: >>>>>>>> >>>>>>>> MJ J wrote: >>>>>>>>> >>>>>>>>> TLDR; in a split-brain situation, you could run into trouble. >>>>>>>>> But >>>>>>>>> this >>>>>>>>> isn't the only place. Efffective systems monitoring is the >>>>>>>>> key >>>>>>>>> here. >>>>>>>>> >>>>>>>>> Long answer; >>>>>>>>> [..] >>>>>>>>> The solution I posted has been in production in a large, >>>>>>>>> dynamic >>>>>>>>> company for several years and never encountered a problem. >>>>>>>> >>>>>>>> >>>>>>>> Maybe it works for you. But I still don't understand why you >>>>>>>> post >>>>>>>> such a >>>>>>>> lengthy justification insisting on your MOD_INCREMENT / read- >>>>>>>> after- >>>>>>>> write >>>>>>>> approach with possible race condition even in a single master >>>>>>>> deployment >>>>>>>> while there are two proper solutions with just a few lines code >>>>>>>> more: >>>>>>>> >>>>>>>> 1. delete-by-value to provoke a conflict like the original >>>>>>>> poster >>>>>>>> mentioned by pointing to >>>>>>>> http://www.rexconsulting.net/ldap-protocol-uidNumber.html >>>>>>>> >>>>>>>> 2. MOD_INCREMENT with pre-read control >>>>>>>> >>>>>>>> Of course none of the solutions work when hitting multiple >>>>>>>> providers >>>>>>>> hard in a MMR setup or in a split-brain situation. One has to >>>>>>>> choose a >>>>>>>> "primary" provider then. >>>>>>>> BTW: AFAIK with FreeIPA each provider has its own ID range to >>>>>>>> prevent that. >>>>>>>> >>>>>>>> Ciao, Michael. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Sincerely, >>>>>> >>>>>> William Brown >>>>>> Software Engineer >>>>>> Red Hat, Australia/Brisbane >>>>>> >>>>> >>>>> >>>> -- >>>> Sincerely, >>>> >>>> William Brown >>>> Software Engineer >>>> Red Hat, Australia/Brisbane >>>> >>> >>> >> >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Is existing documentation kind of vague?
by Howard Chu 19 Nov '17

19 Nov '17

MJ J wrote: > I actually like 389 a lot and I have used Netscape DS extensively in > managing international telecom networks about 15 years ago. There are > quite many management features that are superior to OpenLDAP still to > this day, but I simply cannot use it anymore because of the lack of > scalability. I know the original Netscape DS devs quite extensively... There are certainly some obvious deficiences remaining in cn=config, and we're working on addressing as many as possible for 2.5. But I'd be curious to see your list of issues. > > -mike > > On Fri, Nov 17, 2017 at 8:34 AM, William Brown <wibrown(a)redhat.com> wrote: >> On Fri, 2017-11-17 at 08:27 +0200, MJ J wrote: >>> No matter how you wrap poll() and select(), they will always be >>> poll() >>> and select() - you will always run loops around an ever increasing >>> stack of file descriptors while doing I/O. BDB is always going to >>> have >>> the same old problems... That's what I'm talking about - sacrificing >>> performance for platform portability (NSPR). >>> >>> FreeIPA could be multi-tenant i.e.support top-level and subordinate >>> kerberos realms if it supported a more sensible DIT layout. I know >>> because I have built such a system (based on OpenLDAP) and deployed >>> it >>> internationally. Probably the best piece of code to come out of the >>> project is bind-dyndb-ldap. >> >> Whoa mate - I'm not here to claim that 389 is a better ldap server - we >> just do some different things. We acknowledge our limitations and are >> really working on them and paying down our tech debt. We want to remove >> parts of nspr, replace bdb and more. :) >> >> I'm here to follow the progress of the openldap project, who have a >> team of people I respect greatly and want to learn from, and here to >> help discussions and provide input from a different perspective. >> >> There are things that today openldap does much better than us for >> certain - and there are also some things that we do differently too >> like DNA plugin uid allocation, replication etc, >> >> There are also project focusses and decisions made to improve >> supportability in systems like FreeIPA - we can discuss them forever, >> but reality is today, FreeIPA is not targeting multi-tennant >> environments because the majority of our consumers don't want that >> functionality. We made a design decision and have to live with it. I'm >> providing this information to help give the ability for people to >> construct an informed opinion. >> >> >> As mentioned, I'm not here to throw insults and criticisms, I'm here to >> have positive, respectful discussions about technology, to provide >> different ideas, and to learn from others :) >> >> Thanks, >> >>> >>> On Fri, Nov 17, 2017 at 4:49 AM, William Brown <wibrown(a)redhat.com> >>> wrote: >>>> On Thu, 2017-11-16 at 05:54 +0200, MJ J wrote: >>>>> Sure, it can be improved to become invulnerable to the >>>>> academically >>>>> imaginative race conditions that are not going to happen in real >>>>> life. >>>>> That will go to the very bottom of my list of things to do now, >>>>> thanks. >>>>> >>>>> FreeIPA is a cool concept, too bad it's not scalable or multi- >>>>> tenant >>>>> capable. >>>> >>>> It's a lot more scalable depending on which features you >>>> enable/disable. It won't even be multi-tenant due to the design >>>> with >>>> gssapi/krb. >>>> >>>> At the end of the day, the atomic UID/GID alloc in FreeIPA is from >>>> the >>>> DNA plugin from 389-ds-base (which you can multi-instance on a >>>> server >>>> or multi-tentant with many backends). We use a similar method to AD >>>> in >>>> that each master has a pool of ids to alloc from, and they can >>>> atomically request pools. This prevents the race issues you are >>>> describing here with openldap. >>>> >>>> So that's an option for you, because those race conditions *do* and >>>> *will* happen, and it will be a bad day for you when they do. >>>> >>>> >>>> Another option is an external IDM system that allocs the uid's and >>>> feeds them to your LDAP environment instead, >>>> >>>> Full disclosure: I'm a core dev of 389 directory server, so that's >>>> why >>>> I'm speaking in this context. Not here to say bad about openldap or >>>> try >>>> to poach you, they are a great project, just want to offer >>>> objective >>>> insight from "the other (dark?) side". :) >>>> >>>>> >>>>> On Wed, Nov 15, 2017 at 11:09 PM, Michael Ströder <michael@stroed >>>>> er.c >>>>> om> wrote: >>>>>> MJ J wrote: >>>>>>> TLDR; in a split-brain situation, you could run into trouble. >>>>>>> But >>>>>>> this >>>>>>> isn't the only place. Efffective systems monitoring is the >>>>>>> key >>>>>>> here. >>>>>>> >>>>>>> Long answer; >>>>>>> [..] >>>>>>> The solution I posted has been in production in a large, >>>>>>> dynamic >>>>>>> company for several years and never encountered a problem. >>>>>> >>>>>> Maybe it works for you. But I still don't understand why you >>>>>> post >>>>>> such a >>>>>> lengthy justification insisting on your MOD_INCREMENT / read- >>>>>> after- >>>>>> write >>>>>> approach with possible race condition even in a single master >>>>>> deployment >>>>>> while there are two proper solutions with just a few lines code >>>>>> more: >>>>>> >>>>>> 1. delete-by-value to provoke a conflict like the original >>>>>> poster >>>>>> mentioned by pointing to >>>>>> http://www.rexconsulting.net/ldap-protocol-uidNumber.html >>>>>> >>>>>> 2. MOD_INCREMENT with pre-read control >>>>>> >>>>>> Of course none of the solutions work when hitting multiple >>>>>> providers >>>>>> hard in a MMR setup or in a split-brain situation. One has to >>>>>> choose a >>>>>> "primary" provider then. >>>>>> BTW: AFAIK with FreeIPA each provider has its own ID range to >>>>>> prevent that. >>>>>> >>>>>> Ciao, Michael. >>>>> >>>>> >>>> >>>> -- >>>> Sincerely, >>>> >>>> William Brown >>>> Software Engineer >>>> Red Hat, Australia/Brisbane >>>> >>> >>> >> -- >> Sincerely, >> >> William Brown >> Software Engineer >> Red Hat, Australia/Brisbane >> > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: Is existing documentation kind of vague?
by Howard Chu 19 Nov '17

19 Nov '17

MJ J wrote: > I had a requirement to build a centrally managed SSO system that > replicated subordinate subtrees (kerberos, identities, roles, > permissions, resources, dns, etc) to the respective sites and handle > tens of thousands of concurrent requests per second. I determined that > FreeIPA was unable to perform this mission due to 1) inflexible DIT, > 2) inflexible management tooling, and 3) lack of scalability. So, I > built a system to achieve those goals. And it really wasn't rocket > science. Perhaps I will write a book about it and ask for competent > reviewers from the OL community. Would be happy to review it. > On Fri, Nov 17, 2017 at 4:21 PM, Michael Ströder <michael(a)stroeder.com> wrote: >> MJ J wrote: >>> I know because I have built such a system (based on OpenLDAP) and >>> deployed it internationally. >> So what makes your system special, which goals does it reach and how? >> >> Ciao, Michael. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical