openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

LDAP proxy to AD - fails to bind
by paul.osborne＠canterbury.ac.uk 26 Apr '11

26 Apr '11

Hi, I am going through the hoops of setting up an LDAP proxy (OpenLDAP 2.3 as supplied with Red Hat 5.6) in order to expose parts of our Active Directory to other services which for political and security reasons (that I have no influence in) we do not want talking directly to the AD. In order to achieve this I would like to use ldap-back as the database to act as the proxy to the AD and then a module such as translucent to mask out the bits of the AD that we do not want exposed. So far I am fighting to get ldap-back working as I would expect, at the moment no matter what I do it fails to bind against the AD and a tcp dump demonstrates this failure. Anonymously binding and querying the AD is not an option and so I have to specify a user and get ID assertion working to force a bind against the AD as a specific known user. This does mean that anything (at the moment) could query our proxy and so get at the exposed parts of the AD and for the moment that is intentional. I am also aware that TLS etc are not enabled - this is deliberate as it makes packet sniffing for debugging easier. So for my slapd.conf I have: [slapd.conf] database ldap uri "ldap://myad.canterbury.ac.uk/" suffix "dc=myad,dc=canterbury,dc=ac,dc=uk" acl-bind bindmethod=simple binddn="CN=ldapproxy,OU=AD Administrators,DC=myad,DC=canterbury,DC=ac,DC=uk" credentials="password" access to * by * read idassert-bind bindmethod=simple authzId=dn:CN=ldapproxy,OU=Administrators,DC=myad,DC=canterbury,DC=ac,DC =uk binddn="CN=ldapproxy,OU=Administrators,DC=myad,DC=canterbury,DC=ac,DC=uk " credentials="password" idassert-authzFrom "dn.regex:.*" [end slapd.conf] At the moment I don't really care that anyone can read anything from the AD since I can't even bind, that will be tightened up in due course. I have seen others over the years have had similar issues and I have noted the responses they have received as well as reading the man pages and the Admin Guide, but am now at the point where some community support would be appreciated. Thanks Paul

1 0

Problem about CA Issue Certificate with LDAP
by Nguyen, Quoc Khanh 26 Apr '11

26 Apr '11

Hi all, I'm a new comer, I'm trying to config a CA with LDAP follow this site http://www.openldap.org/pub/ksoper/OpenLDAP_TLS.html#4.2. 4.2 CA Issue Certificate When going to step 4, I have receieved an error messeage. root@ldap:/usr/local/openssl/bin# /usr/local/openssl/ssl/misc/CA.sh -sign Using configuration from /usr/lib/ssl/openssl.cnf Error opening CA private key ./demoCA/private/cakey.pem 665:error:02001002:system library:fopen:No such file or directory:bss_file.c:356:fopen('./demoCA/private/cakey.pem','r') 665:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:358: unable to load CA private key cat: newcert.pem: No such file or directory Signed certificate is in newcert.pem I think it's very simple, but i don't know how to solve it. I have tried to many ways but fail to fix it. Maybe i don't understand about the CA Certificate. I... I am so confusing. Please help, khanhnq -- *********************************** EVERYTHING HAS JUST BEGUN...

1 0

clarifications on cachesize, preferred db, et. al. from admin guide
by Tim Mooney 21 Apr '11

21 Apr '11

All- I'm getting back to the project of upgrading our OpenLDAP infrastructure, which I started last summer but was interrupted by email outsourcing... As things currently stand, I'll be deploying 2.4.25 + BDB 4.8.30 on RHEL 5.6. I'm starting with a DB_CONFIG of set_cachesize 0 536870912 1 set_lg_regionmax 262144 set_lg_bsize 2097152 set_flags DB_LOG_AUTOREMOVE though I suspect I will tune further, as the servers are quite beefy and our OpenLDAP databases are pretty modest (60K dn, 80 MB id2entry), so we have horsepower and RAM to spare. I've been carefully reviewing the docs and admin guide and have several questions as points of clarification. - Admin Guide, section 21.4.1.1. The tuning chapter is a godsend and the section on the calculations for Berkeley DB cache sizing is extremely helpful, but I've noted that the docs indicate that each index is a hash structure and proceed to describe how to calculate how much additional cache you will want for each index you have, beyond what you need for the (Btree) id2entry and dn2id. Every single one of my index .bdb files is of type Btree, though, not Hash. Is that section of the docs outdated, and all indexed attributes are now in Btree databases (for back-bdb and presumably back-hdb), or am I fundamentally misunderstanding what the index-related cache calculations are saying? - Admin Guide, section 5. The last note in the intro section of chapter 5 mentions that some backends and overlays do not support slapd-config, without listing what those backends are. Looking through the documentation-related ITS's, it appears that at one point slapo-rwm didn't support slapd-config, but that's apparently changed. I realize it's more work to spell out what backends would prevent someone from using slapd-config, especially since it must be kept up to date as things change, but I think that explicitly listing the backends (and overlays) that don't work with slapd-config will make people more likely to choose slapd-config moving forward. As things stand, most people aren't going to know whether they can use slapd-config or not because they don't know which backends work with it and which don't. If you agree that it would be useful to explicitly list which backends would block the use of slapd-config and someone can provide me with the list of blockers, I would be happy to file an ITS and provide a patch to the current docs to spell things out. I personally think it will help adoption of slapd-config. - man page for slapd.backends(5). The man page entry states that bdb is the preferred backend. I've seen enough hints and comments on the mailing list to suggest that it will eventually be supplanted by hdb. How soon is that going to happen (2.5?), and is it worth mentioning that hdb is as good as bdb now and will be the new preferred backend soon? Again, I'll submit the ITS with the doc patch if it's worth making that assertion in the docs now. - Admin Guide, chapter 21. The tuning chapter doesn't mention the potential benefits of using an alternate memory allocator on Linux, as Quanah clued me in to on the mailing list last month. Should it? If people feel it would be worthwhile to mention, I would be happy to write the first draft and supply the patch in an ITS. - Admin Guide, chapter 21. The tuning chapter doesn't mention the potential benefits of using sysv shared memory vs. mmap'ed files on some platforms. Should it? Same offer for documentation patch applies, though I expect this one will need more feedback from the experts. Thanks, Tim -- Tim Mooney Tim.Mooney(a)ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164

4 7

parsing output from ldap_search_ext_s C API
by sim123 21 Apr '11

21 Apr '11

Hi All, I am using ldap_search_ext_s C API and having strange results, not sure if I am missing something or its an API bug: My Directory Tree looks like this: | -- dc=example,dc=com | ------ ou=users,dc=example,dc=com | ---------- uid=1,ou=users,dc=example,dc=com | --------------- cn=john | ------ ou=departments,dc=example,dc=com | ---------- uid=11,ou=departments,dc=example,dc=com | --------------- cn=hr | --------------- member=uid=1 | ---------- uid=12,ou=departments,dc=example,dc=com | --------------- cn=sales | --------------- member=uid=1 | ---------- uid=13,ou=departments,dc=example,dc=com | --------------- cn=marketing | --------------- member=uid=1 First I get all the departments for "john" by using *memberof* in sarch attribute. for this query my search filter contains only one criteria ("uid=1") Then I construct another search filter for getting names of all the departments john belongs to : (|(uid=11)(uid=12)(uid=13)) I pass this filter to ldap_search_ext_s, where base is "ou=departments,dc=example,dc=com", scope is one level down, and I want "cn" in the attribute LDAPMessage* output; int retCode = ldap_search_ext_s(ld,base.c_str(), scope,filter.c_str(),attrs,false,NULL,NULL,NULL,0,&output); if(retCode == LDAP_SUCCESS){ //log success //send result to a static method for parsing LDAPUtil::parseResult(ld,output,result); ldap_msgfree(output); }else{ //log error & throw exception } LDAPUtil parse result implementation void LDAPUtil::parseResult(LDAP* ld, LDAPMessage* ldapResponse, LDAPSearchResult* parsedResult){ int numEntries = ldap_count_entries(ld,ldapResponse); cout << "number of entries" << numEntries << endl;* // I get 3 here* if(numEntries > 0){ //parse result LDAPMessage * entry; BerElement * ber; char * attr; BerVarray* vals ; map<string,LDAPAttribute*> attributeValueMap ; int count = 0; * //If I don't use count < numEntries this loop becomes an infinite loop, this loop runs 3 times, however the dn value output is:* *// run 1 :: dn: uid=11,ou=departments,dc=examples,dc=com //run 2 :: dn: uid=12,ou=departments,dc=examples,dc=com // run 3 :: dn: uid=12,ou=departments,dc=examples,dc=com* for ( entry = ldap_first_entry(ld,ldapResponse);entry != NULL && count < numEntries; entry = ldap_next_entry(ld,ldapResponse)){ count++; //create LDAP Attributes LDAPAttribute* attribute = new LDAPAttribute(); //set DN attribute->setDn(ldap_get_dn(ld,entry)); cout << "dn is " << ldap_get_dn(ld,entry) <<endl; for(attr = ldap_first_attribute(ld,entry,&ber); attr != NULL; attr=ldap_next_attribute(ld,entry,ber)) { string temp = attr; cout << "attribute :: " << attr << endl; vals = ldap_get_values_len(ld,entry,attr); if((ldap_count_values_len(vals))> 0 ){ LDAPUtil::processAttribute(attribute,temp,vals); } ldap_value_free_len(vals); } attributeValueMap.insert(pair<string,LDAPAttribute*>(attribute->getDn(),attribute)); } parsedResult->setAttributeValueMap(attributeValueMap); } } Basically above code is working only if I have one entry returned in the output. I would really appreciate if someone can help me with this. As I have hard time beliving its an API bug since I am just doing basic operation. Thanks, - Simon

1 1

Re: Installation openLDAP in Debian
by Jose Ildefonso Camargo Tolosa 21 Apr '11

21 Apr '11

On Thu, Apr 21, 2011 at 11:47 AM, Olivier Guillard <olivier(a)guillard.nom.fr> wrote: >> No, that is not the meaning of "add". > > In that case, how can you change > olcRootPW: MySecretPassword If you forgot your rootdn pass, and have no other user that with write privileges to cn=config, I guess you would need to slapcat your config, edit it, delete old config, and reload with slapadd. Or... take the risk and just edit the file by hand. Ildefonso.

2 5

Re: Installation openLDAP in Debian
by Olivier 21 Apr '11

21 Apr '11

>> No, that is not the meaning of "add". In that case, how can you change olcRootPW: MySecretPassword If it already exists but you want to change it ? --- Olivier

2 1

new entry lost on multi-master setup (two scenarios)
by Jose Ildefonso Camargo Tolosa 21 Apr '11

21 Apr '11

Greetings, At first, I was going to create a bug report, but decided to send to list first. I tried this with both: 2.4.23 (Debian package), and 2.4.25, compiled from source, bdb 4.8. After a couple of entries just disappeared on one multi-master setup I had, I decided to further investigate, and found this (there are two cases, for the same procedure): 1. Configure two LDAP servers in multi-master setup. 2. Make sure they replicate correctly (off course). 3. Shutdown one of the two ldap servers. 4. Create a new entry (say, ou1) on the LDAP server that is left up. 5. Shutdown the last LDAP server. 6. Start the *other* LDAP server, the one where you didn't create the entry. 7. Create another entry, say: ou2, so that both servers has a new entry, that is *not* on the other server. 8. Shutdown the LDAP server (both servers down now). 9. Start both LDAP servers. Result (case 1): one of the two newly created entries is missing on *one* of the servers, and only one of the entries is missing on the other server. Result (case 2): one entry is missing on *both* servers. Both servers has NTP, and has the same timezone (ie, time is synchronized). I'm *not* replicating cn=config (I shouldn't, because I have different SSL certificates on each server). Now, more details: slapd with -d 16384 gives me this on the server that misses both entries, on this server I created the entry dn ou=ou2,dc=st-andes,dc=com (and the server decided to delete it!, and, for some reason, it didn't detected the new ou1 entry created on the other server): http://www.st-andes.com/openldap/case1/log-server2-case1.txt The other server (the one that kept one entry and lost the other), on this server I created the entry ou=ou1,dc=st-andes,dc=com, and it says it was changed by peer.....: http://www.st-andes.com/openldap/case1/log-server1-case1.txt Now, I'm seeing here that it is using 000 server id... but on the cn=config.ldif I have: olcServerID: 1 ldap://ldap.ildetech.com:389/ olcServerID: 2 ldap://ldap2.ildetech.com:389/ And the syncrepl: olcSyncRepl: rid=001 provider=ldap://ldap.ildetech.com:389 binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple credentials="secret" searchbase="dc=st-andes,dc=com" type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical olcSyncRepl: rid=002 provider=ldap://ldap2.ildetech.com:389 binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple credentials="secret" searchbase="dc=st-andes,dc=com" type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical olcMirrorMode: TRUE And, as you can see on the command line, I have the URL specified on the -h parameter, but it seems to be ignoring it!. Or, should I specify the *whole* urls that I put on the -h parameter? (ldap://ldap2.ildetech.com:389 ldap://127.0.0.1:389/ ldaps:/// ldapi:///) So, I decided to change the config: On server 1 (kirara): olcServerID: 1 and olcSyncRepl: rid=002 provider=ldap://ldap2.ildetech.com:389 binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple credentials="secret" searchbase="dc=st-andes,dc=com" type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical olcMirrorMode: TRUE On server 2 (happy): olcServerID: 2 and olcSyncRepl: rid=002 provider=ldap://ldap2.ildetech.com:389 binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple credentials="secret" searchbase="dc=st-andes,dc=com" type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical olcMirrorMode: TRUE With this new setup, and following the same procedure, I get one missing entry on *both* servers (at least servers gets to a consistent state), but I still have a missing entry. The logs for this setup: Server 2 (ID 2, where I created entry: ou2 while the other server was down), this server decided, wrongly, to delete entry ou2: http://www.st-andes.com/openldap/case2/log-server2-case2.txt And the other server (where I created ou1): http://www.st-andes.com/openldap/case2/log-server1-case2.txt This one never saw the other entry, ou2. For both cases, the syncprov module was with default configuration: dn: olcOverlay={0}syncprov objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov structuralObjectClass: olcSyncProvConfig entryUUID: 24354488-e5bf-102f-9e6a-ad3cba95f7f1 creatorsName: cn=config createTimestamp: 20110318152128Z entryCSN: 20110318152128.935227Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20110318152128Z What do you think? Thanks in advance! Ildefonso Camargo

3 5

Re: Installation openLDAP in Debian
by Jose Ildefonso Camargo Tolosa 21 Apr '11

21 Apr '11

Resending on-list. On Wed, Apr 20, 2011 at 1:33 PM, Simone Piccardi <piccardi(a)truelite.it> wrote: > On 20/04/2011 17:42, Jose Ildefonso Camargo Tolosa wrote: >>> >>> Modern OpenLDAP does not use slapd.conf. Please read the OpenLDAP Admin >>> guide. >> >> Quanah: actually, documentation is not yet complete for cn=config, I >> had to actually convert my slapd.conf to cn=config using slaptest in >> order to find out how to do the same I had on slapd.conf on cn=config. >> >> Ildefonso > > That's the way I'm using it. And I suggest to anyone not needing to modify > configurations on the fly to use it that way. > > Because apart the missing documentation, I found difficult having to deal > with the obscure attribute names and the complex directory structure (and > the not so explicative file names used under it) that I found in > /etc/ldap/slapd.d/. Well, I actually got used to cn=config pretty quickly, nevertheless, I still find easier to understand and modify the slapd.conf file than the directory structure under slapd.d... it is definitely more complex (and I don't think it is easier to modify using a LDAP administration tool). The "cn=config" replication suggested on the docs becomes useless when you need to use TLS, because, AFAIK, we don't have a way of having different TLS parameters for each replica (and, on a multi-master setup, you will likely have different servers, with different names, and thus: different SSL certificate). > > I understand the needs for cn=config, but for the moment I don't need it. > Having a file with a simple syntax that I can read and modify instead of a > tree of LDIF files is far more convenient for me. So I hope that slapd.conf > will remain supported. +1, we shouldn't drop slapd.conf file. > > Simone > -- > Simone Piccardi Truelite Srl > piccardi(a)truelite.it (email/jabber) Via Monferrato, 6 > Tel. +39-347-1032433 50142 Firenze > http://www.truelite.it Tel. +39-055-7879597 Fax. +39-055-7333336 >

5 5

Re: Installation openLDAP in Debian
by Howard Chu 21 Apr '11

21 Apr '11

Olivier Guillard wrote: >> On a fresh installation that has not yet been configured: ... > > Thanks howard, it helps. > > For other readers I add this found in the slapadd doc : > >> LIMITATIONS >> Your slapd(8) should not be running when you do this to ensure consis‐ >> tency of the database. > > Something I have to test : > > What happens if you attempt to add an entry or change an attribute > that already exists using "slapadd" (I suspect that the old entry is > replaced). No, that is not the meaning of "add". -- -- 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: Simple LDAP to LDAP Integration
by Alejandro Imass 20 Apr '11

20 Apr '11

On Wed, Apr 20, 2011 at 12:39 PM, Bill MacAllister <whm(a)stanford.edu> wrote: > > > --On Wednesday, April 20, 2011 10:23:20 AM -0400 Alejandro Imass > <ait(a)p2ee.org> wrote: > >> Hello, >> [...] > One way to do this is to configure your OpenLDAP server to generate an > accesslog. They you read the accesslog looking for any changes and > apply the changes to your downstream datastore whatever it is. We do > this using perl and Net::LDAPapi. I can provide an example if you are > interested. > Hi Bill, thank you *very* much for your prompt reply. One question (actually 2) though before I ask for the trouble of providing an example.... do you get the clear text passwd on the accesslog? is the the log an LDIF format? It's not that I really need clear text, but I need to compute the corresponding password hashes for MS-AD. are you guys able to change the password fields as well? or are you just copying the hashes from one to the other? how does this work with the accesslog method? Again many thanks because I really feel that this could be a practical KISS way of integrating this. Thanks!!! Alex > Bill > > -- > > Bill MacAllister > Infrastructure Delivery Group, Stanford University > >

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