....................................../////.===Shadow-Here===./////................................................ > < > < > < > < > < > < > < > < > < > < > < > < > < > < > < > < > < > < > < > < > < > < > < > < > < > < > < > < > < ------------------------------------------------------------------------------------------------------------------- /////////////////////////////////////////////////////////////////////////////////////////////////////////////////// RIFF¤ WEBPVP8 ˜ ðÑ *ôô>‘HŸK¥¤"§£±¨àð enü¹%½_F‘åè¿2ºQú³íªú`N¿­3ÿƒügµJžaÿ¯ÿ°~¼ÎùnúîÞÖô•òíôÁÉß®Sm¥Ü/ ‡ó˜f£Ùà<˜„xëJ¢Ù€SO3x<ªÔ©4¿+ç¶A`q@Ì“Úñè™ÍÿJÌ´ª-˜ÆtÊÛL]Ïq*‘Ý”ì#ŸÌÏãY]@ê`¿ /ªfkØB4·®£ó z—Üw¥Pxù–ÞLШKÇN¾AkÙTf½è'‰g gÆv›Øuh~ a˜Z— ïj*á¥t d£“uÒ ¨`K˜¹ßþ]b>˜]_ÏÔ6W—è2r4x•íÖ…"ƒÖNîä!¦å Ú}ýxGøÌ —@ ;ÆÚŠ=ɾ1ý8lªË¥ô ^yf®Œ¢u&2©nÙÇ›ñÂñŒ³ aPo['½»øFùà­+4ê“$!lövlüÞ=;N®3ð‚õ›DÉKòÞ>ÄÍ ¥ˆuߤ#ˆ$6ù™¥îŠ‡y’ÍB¼ çxÛ;X"WL£R÷͝*ó-¶Zu}º.s¸sšXqù–DþÿvªhüïwyŸ ¯é³lÀ:KCûÄ£Ëá\…­ ~—ýóî ¼ûûÜTÓüÇy…ŽÆvc»¾×U ñ¸žþоP÷¦ó:Ò¨¨5;Ð#&#ÖúñläÿÁœ GxÉ­/ñ‡áQðìYÉtÒwŽ¼GÔ´zàÒò ð*ëzƒ•4~H]Ø‹f ñÓÈñ`NåWçs'ÆÏW^ø¹!XžµmQ5ÃËoLœÎ: ÞËÍ¥J ù…î èo£ßPÎñ¶ž8.Œ]ʵ~5›ÙË-ù*8ÙÖß±~ ©¹rÓê‚j¶d¸{^Q'˜±Crß ÚH—#¥¥QlÀ×ëã‡DÜ«èî þ&Çæžî;ŽÏºò6ÒLÃXy&ZŒ'j‚¢Ù€IßÚù+–MGi‰*jE€‘JcÜ ÓÌ EÏÚj]o˜ Þr <¾U ûŪæÍ/šÝH¥˜b”¼ ÁñßX GP›ï2›4WŠÏà×£…íÓk†¦H·ÅíMh–*nó÷à]ÁjCº€b7<ب‹¨5車bp2:Á[UªM„QŒçiNMa#<5›áËó¸HýÊ"…×Éw¹¦ì2º–x<›»a±¸3Weü®FÝ⑱ö–î–³|LPÈ~çð~Çå‡|º kD¢µÏàÆAI %1À% ¹Ò – ”ϝS¦‰4&¶£°à Öý”û_Ò Áw°A«Å€?mÇÛgHÉ/8)á¾ÛìáöŽP í¨PŸNÙµº¦‡§Ùš"ÿ«>+ªÕ`Ê÷‡‚ß Õû˜þãÇ-PÍ.¾XV‘€ dÜ"þ4¹ ±Oú‘©t¥¦FªÄÃÄ•b‚znýu½—#cDs˜ÃiÑOˆñ×QO=*IAÊ,¶ŽZƒ;‡wøXè%EÐk:F±Ú” .Ѽ+Áu&Ç`."pÈÉw o&¿dE6‘’EqTuK@Ì¥ã™À(Êk(h‰,H}RÀIXÛš3µ1©_OqÚÒJAñ$ÊÙÜ;D3çŒ[þùœh¬Ã³™ö6ç†NY".Ú‰ï[ªŸŒ '²Ð öø_¨ÂÉ9u鶳ÒŠõTàîMØ#û¯gN‡bÙ놚X„ö …ÉeüÌ^J ‹€.œ$Æ)βÄeæW#óüßĺŸ€ ÀzwV 9oä»f4V*uB «Ë†¹ì¯žR霓æHXa=&“I4K;¯ç‹h×·"UŠ~<•â•ªVêª&ÍSÃÆÅ?ÔqÎ*mTM ˜›µwêd#[C¡©§‘D<©àb†–ÁœøvH/,í:¯( ²£|4-„Æövv„Yͼ™^Á$ˆ„¢Û[6yB.åH*V¨æ?$=˜Ñ€•î¦ñ·­(VlŸ‘ nÀt8W÷´Bûba?q9ú¶Xƒl«ÿ\ù¶’þòUÐj/õ¢Ìµ³g$ƒÎR!¸»|Oߍë’BhîÚÑ¢ñåŒJ„®„£2Ð3•ô02Nt…!£Í]Ïc½Qÿ?ˆ<&ÃA¾Ú,JˆijÌ#5yz„‰Î|ÊŽ5QÏ:‹ÐaóVÔxW—CpeÏzÐïíçôÿÅ_[hãsÐ_/ŽTÝ?BîˆííV$<¿i>²F¬_Eß¿ †bÊŒº­ÿ®Z H“C}”¬,Mp ý/Bá£w>˜YV°aƒúh+cŠ- r/[%|üUMHäQ°X»|û/@|°¥Ð !BÔ Ç¢Ä©š+Õì D«7ìN¶ŽðÔ " ƶ’ÖçtA‰Û×}{tþz­¾GÍ›k¹OEJR$ Â׃ «ëÁ"oÉôž$oUK(Ä)Ãz³Ê-‹êN[Ò3Œñbï8P 4ƒ×q¢bo|?<ÛX¬òÄÍ°L–±›(™ûG?ýË©ÚÄ–ÂDØÐ_Ç¡ô ¾–ÄÏø ×e8Ë©$ÄF¹Å‹ì[©óìl:F¾f´‹‹Xì²ï®\¬ôùƒ ÿat¥óèÒùHß0äe‚;ü×h:ÆWðHž=Ã8骣"kœ'Y?³}Tûè€>?0l›e1Lòñ„aæKÆw…hÖŠùW…ÈÆÄ0ši·›[pcwËþñiêíY/~-Á5˜!¿†A›™Mÿþ(±“t@â“ö2­´TG5yé]çå僳 .·ÍïçÝ7UÚ±Ð/Nè»,_Ï ùdj7\ï Wì4›„»c¸àešg#ÒÊ⥭áØo5‘?ÌdÝô¯ ¹kzsƒ=´#ëÉK›Ø´±-¥eW?‡çßtòTã…$Ý+qÿ±ƒ÷_3Ô¥í÷:æ–ž<·Ö‡‰Å¢ š‡%Ô—utÌÈìðžgÖÀz²À—ï÷Óîäõ{K'´È÷³yaÏÁjƒô}ž§®æÊydÕÈë5¯èˆõvÕ©ã*çD„ “z„Ó‡^^xÂ3M§A´JG‚öï 3W'ˆ.OvXè¡ÊÕª?5º7†˜(˜Ç¶#çê’¶!ÌdZK§æ 0fãaN]òY³RV ™î$®K2R¨`W!1Ôó\;Ý ýB%qæK•&ÓÈe9È0êI±žeŸß -ú@žQr¦ ö4»M¼Áè¹µmw 9 EÆE_°2ó„ŸXKWÁ×Hóì^´²GѝF©óäR†¦‰ç"V»eØ<3ùd3ÿÚ¤Žú“Gi" —‘_ÙËÎ~Üö¯¥½Î»üŸEÚŽåmÞþí ;ÞólËΦMzA"Âf(´òá;Éï(/7½ûñÌ­cïÕçлþÝz¾-ÍvÑ“pH­–ðÓj$¸Äû¤‚‘ãUBË-n“2åPkS5&‹Â|+g^œ®Ì͆d!OïäîU«c;{Û!ÅŽ«ëZ9Ókóˆ]¯ƒ›né `ÇÒ+tÆš (ØKá¾—=3œ®•vuMñg²\ï Ec€ 05±d™‡×iÇ×›UúvÌ¢£Èþ¡ÕØô¶ßÎA"ß±#Ö²ˆÊŸ¦*Ä~ij|àø.-¼'»Ú¥£h ofº¦‡VsR=N½„Î v˜Z*SÌ{=jÑB‹tê…;’HžH¯8–îDù8ñ¢|Q•bÛçš–‹m³“ê¨ åÏ^m¬Žãþ©ïêO‡½6] µÆ„Ooòü ²x}N¦Ë3ïé¿»€›HA˜m%çÞ/¿í7Fø“‹léUk)É°Œµ8Q8›:ÀŠeT*šõ~ôڝG6 ¢}`ùH­–”¡k ‰P1>š†®9z11!X wKfmÁ¦xÑ,N1Q”–æB¶M…ÒÃv6SMˆhU¬ÊPŽï‘öj=·CŒ¯u¹ƒVIЃsx4’ömÛýc塶7ßŠß 57^\wÒÐÆ k§h,Œý î«q^R½3]J¸ÇðN ‚çU¬ôº^Áì} ³f©Õœ§ˆã:FÄÈ‚é(€™?àýÓüè1Gô£¼éj‚OÅñ  #>×—ßtà 0G¥Åa뀐kßhc™À_ÉñÞ#±)GD" YîäË-ÿÙ̪ ¹™a¯´¢E\ÝÒö‚;™„ë]_ p8‰o¡ñ+^÷ 3‘'dT4œŽ ðVë½° :¬víÑ«£tßÚS-3¶“þ2 †üüʨòrš¹M{É_¤`Û¨0ìjœøJ‡:÷ÃáZ˜†@GP&œÑDGÏs¡þ¦þDGú‘1Yá9Ôþ¼ ûø…§÷8&–ÜÑnÄ_m®^üÆ`;ÉVÁJ£?â€-ßê}suÍ2sõA NÌúA磸‘îÿÚ»ƒìö·á¿±tÑÐ"Tÿü˜[@/äj¬€uüªìù¥Ý˜á8Ý´sõj 8@rˆð äþZÇD®ÿUÏ2ùôõrBzÆÏÞž>Ì™xœ“ wiÎ×7_… ¸ \#€MɁV¶¥üÕÿPÔ9Z‡ø§É8#H:ƒ5ÀÝå9ÍIŒ5åKÙŠ÷qÄ>1AÈøžj"µÂд/ªnÀ qªã}"iŸBå˜ÓÛŽ¦…&ݧ;G@—³b¯“•"´4í¨ôM¨åñC‹ïùÉó¯ÓsSH2Ý@ßáM‡ˆKÀªÛUeø/4\gnm¥‹ŸŒ qÄ b9ÞwÒNÏ_4Ég³ú=܆‚´ •â¥õeíþkjz>éÚyU«Íӝ݃6"8/ø{=Ô¢»G¥ äUw°W«,ô—¿ãㆅү¢³xŠUû™yŒ (øSópÐ 9\åTâ»—*oG$/×ÍT†Y¿1¤Þ¢_‡ ¼ „±ÍçèSaÓ 3ÛMÁBkxs‰’R/¡¤ˆÙçª(*õ„üXÌ´ƒ E§´¬EF"Ù”R/ÐNyÆÂ^°?™6¡œïJ·±$§?º>ÖüœcNÌù¯G ‹ñ2ŠBB„^·úìaz¨k:#¨Æ¨8LÎõލ£^§S&cŒÐU€ü(‡F±Š¼&P>8ÙÁ ‰ p5?0ÊƃZl¸aô š¼¡}gÿ¶zÆC²¹¬ÎÖG*HB¡O<º2#ñŒAƒ–¡B˜´É$¥›É:FÀÔx¾u?XÜÏÓvN©RS{2ʈãk9rmP¼Qq̳ è¼ÐFׄ^¡Öì fE“F4A…!ì/…¦Lƒ… … $%´¾yã@CI¬ á—3PþBÏNÿ<ý°4Ü ËÃ#ØÍ~âW«rEñw‹eùMMHß²`¬Öó½íf³:‹k˜¯÷}Z!ã¿<¥,\#öµÀ¯aÒNÆIé,Ћ–lŽ#Àæ9ÀÒS·I’½-Ïp Äz¤Š Â* ­íÄ9­< h>׍3ZkËU¹§˜ŒŠ±f­’¤º³Q ÏB?‹#µíÃ¥®@(Gs«†vI¥Mµ‹Á©e~2ú³ÁP4ìÕi‚²Ê^ö@-DþÓàlÜOÍ]n"µã:žpsŽ¢:! Aõ.ç~ÓBûH÷JCÌ]õVƒd «ú´QÙEA–¯¯Œ!.ˆˆëQ±ù œ·Ì!Õâ )ùL„ÅÀlÚè5@B…o´Æ¸XÓ&Û…O«˜”_#‡ƒ„ûÈt!¤ÁÏ›ÎÝŠ?c9 â\>lÓÁVÄÑ™£eØY]:fÝ–—ù+p{™ðè û³”g±OƒÚSù£áÁÊ„ä,ï7š²G ÕÌBk)~ÑiCµ|h#u¤¶îK¨² #²vݯGãeÖ϶ú…¾múÀ¶þÔñ‚Š9'^($¤§ò “š½{éúp÷J›ušS¹áªCÂubÃH9™D™/ZöØÁ‡¦ÝÙŸ·kð*_”.C‹{áXó€‡c¡c€§/šò/&éš÷,àéJþ‰X›fµ“C¨œ®r¬"kL‰Â_q…Z–.ÉL~O µ›zn‚¹À¦Öª7\àHµšÖ %»ÇníV[¥*Õ;ƒ#½¾HK-ÖIÊdÏEÚ#=o÷Óò³´Š: Ç?{¾+9›–‘OEáU·S€˜j"ÄaÜ ŒÛWt› á–c#a»pÔZÞdŽtWê=9éöÊ¢µ~ ë ;Öe‡Œ®:bî3±ýê¢wà¼îpêñ¹¾4 zc¾ðÖÿzdêŒÑÒŝÀ‰s6¤í³ÎÙB¿OZ”+F¤á‡3@Ñëäg©·Ž ˆèª<ù@É{&S„œÕúÀA)‰h:YÀ5^ÂÓŒ°õäU\ ùËÍû#²?Xe¬tu‰^zÒÔãë¼ÛWtEtû …‚g¶Úüâî*moGè¨7%u!]PhÏd™Ý%Îx: VÒ¦ôÊD3ÀŽKÛËãvÆî…N¯ä>Eró–ð`5 Œ%u5XkñÌ*NU%¶áœÊ:Qÿú»“úzyÏ6å-၇¾ ´ ÒÊ]y žO‘w2Äøæ…H’²f±ÎÇ.ª|¥'gîV•Ü .̘¯€šòü¤U~Ù†*¢!?ò wý,}´°ÔÞnïoKq5µb!áÓ3"vAßH¡³¡·G(ÐÎ0Îò¼MG!/ài®@—¬04*`…«é8ªøøló“ˆÊ”èù¤…ßÊoÿé'ËuÌÖ5×È¡§ˆˆfŽë9}hìâ_!!¯  B&Ëö¶‰ÀAÙNVŸ Wh›¸®XÑJì¨ú“¿÷3uj²˜¨ÍÎìë±aúŠÝå¯ð*Ó¨ôJ“yºØ)m°WýOè68†ŸÏ2—‰Ïüꪫٚ¥‹l1 ø ÏÄFjêµvÌbü¦èÝx:X±¢H=MÐß—,ˆÉÇ´(9ú¾^ÅÚ4¿m‡$âX‘å%(AlZo@½¨UOÌÕ”1ø¸jÎÀÃÃ_ µ‘Ü.œº¦Ut: Æï’!=¯uwû#,“pþÇúŒø(é@?³ü¥‘Mo §—s@Œ#)§ŒùkL}NOÆêA›¸~r½¼ÙA—HJ«eˆÖ´*¡ÓpÌŸö.m<-"³ûÈ$¬_6­åf£ïÚâj1y§ÕJ½@dÞÁr&Í\Z%D£Íñ·AZ Û³øüd/ªAi†/Й~  ‡âĮҮÏh§°b—›Û«mJžòG'[ÈYýŒ¦9psl ýÁ ®±f¦x,‰½tN ‚Xª9 ÙÖH.«Lo0×?͹m¡å†Ѽ+›2ƒF ±Ê8 7Hցϓ²Æ–m9…òŸï]Â1äN†VLâCˆU .ÿ‰Ts +ÅÎx(%¦u]6AF Š ØF鈄‘ |¢¶c±soŒ/t[a¾–û:s·`i햍ê›ËchÈ…8ßÀUÜewŒðNOƒõD%q#éû\9¤x¹&UE×G¥ Í—™$ð E6-‡¼!ýpãÔM˜ Âsìe¯ñµK¢Ç¡ùôléœ4Ö£”À Š®Ðc ^¨À}ÙËŸ§›ºê{ÊuÉC ×Sr€¤’fÉ*j!úÓ’Gsùìoîßîn%ò· àc Wp÷$¨˜)û»H ×8ŽÒ€Zj¤3ÀÙºY'Ql¦py{-6íÔCeiØp‘‡XÊîÆUߢ܂ž£Xé¼Y8þ©ëgñß}é.ÎógÒ„ÃØËø¯»™§Xýy M%@NŠ À(~áÐvu7&•,Ù˜ó€uP‡^^®=_E„jt’ 403WebShell
403Webshell
Server IP : 195.3.193.30  /  Your IP : 216.73.216.125
Web Server : Apache
System : Linux server3 5.10.0-35-amd64 #1 SMP Debian 5.10.237-1 (2025-05-19) x86_64
User : web032 ( 1035)
PHP Version : 7.3.33
Disable Function : show_source, highlight_file, apache_child_terminate, apache_get_modules, apache_note, apache_setenv, virtual, dl, disk_total_space, posix_getpwnam, posix_getpwuid, posix_mkfifo, posix_mknod, posix_setpgid, posix_setsid, posix_setuid, posix_uname, proc_nice, openlog, syslog, pfsockopen
MySQL : OFF  |  cURL : ON  |  WGET : ON  |  Perl : ON  |  Python : OFF  |  Sudo : ON  |  Pkexec : OFF
Directory :  /usr/share/doc/proftpd-doc/contrib/

Upload File :
current_dir [ Writeable ] document_root [ Writeable ]

 

Command :

[ Back ]     

Current File : /usr/share/doc/proftpd-doc/contrib/mod_ldap.html
<!DOCTYPE html>
<html>
<head>
<title>ProFTPD module mod_ldap</title>
</head>

<body bgcolor=white>

<hr><br>
<center>
<h2><b>ProFTPD module <code>mod_ldap</code></b></h2>
</center>
<hr><br>

<p>
This module is contained in the <code>mod_ldap.c</code> file for ProFTPD 1.2.<i>x</i>/1.3.<i>x</i>, and is not compiled by default.  Installation instructions
are discussed <a href="#Installation">here</a>.

<p>
The most current version of <code>mod_ldap</code> is distributed with the
ProFTPD source code.

<h2>Author</h2>
<p>
Please contact John Morrissey &lt;jwm <i>at</i> horde.net&gt; with any
questions, concerns, or suggestions regarding this module.

<h2>Directives</h2>
<ul>
  <li><a href="#LDAPAliasDereference">LDAPAliasDereference</a>
  <li><a href="#LDAPAttr">LDAPAttr</a>
  <li><a href="#LDAPAuthBinds">LDAPAuthBinds</a>
  <li><a href="#LDAPBindDN">LDAPBindDN</a>
  <li><a href="#LDAPDefaultAuthScheme">LDAPDefaultAuthScheme</a>
  <li><a href="#LDAPDefaultGID">LDAPDefaultGID</a>
  <li><a href="#LDAPDefaultQuota">LDAPDefaultQuota</a>
  <li><a href="#LDAPDefaultUID">LDAPDefaultUID</a>
  <li><a href="#LDAPForceDefaultGID">LDAPForceDefaultGID</a>
  <li><a href="#LDAPForceDefaultUID">LDAPForceDefaultUID</a>
  <li><a href="#LDAPForceGeneratedHomedir">LDAPForceGeneratedHomedir</a>
  <li><a href="#LDAPGenerateHomedir">LDAPGenerateHomedir</a>
  <li><a href="#LDAPGenerateHomedirPrefix">LDAPGenerateHomedirPrefix</a>
  <li><a href="#LDAPGenerateHomedirPrefixNoUsername">LDAPGenerateHomedirPrefixNoUsername</a>
  <li><a href="#LDAPGroups">LDAPGroups</a>
  <li><a href="#LDAPLog">LDAPLog</a>
  <li><a href="#LDAPProtocolVersion">LDAPProtocolVersion</a>
  <li><a href="#LDAPQueryTimeout">LDAPQueryTimeout</a>
  <li><a href="#LDAPSearchScope">LDAPSearchScope</a>
  <li><a href="#LDAPServer">LDAPServer</a>
  <li><a href="#LDAPUsers">LDAPUsers</a>
  <li><a href="#LDAPUseSASL">LDAPUseSASL</a>
  <li><a href="#LDAPUseTLS">LDAPUseTLS</a>
</ul>

<hr>
<h3><a name="LDAPAliasDereference">LDAPAliasDereference</a></h3>
<strong>Syntax:</strong> LDAPAliasDereference <em>never|always|search|find</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.2.7rc1 and later

<p>
The <code>LDAPAliasDereference</code> directive configures how aliases are
handled.  The possible values have the following behaviors:
<ul>
  <li><em>never</em>
    <p>
    Never dereference aliases
  </li>

  <p>
  <li><em>always</em>
    <p>
    Always dereference aliases
  </li>

  <p>
  <li><em>search</em>
    <p>
    Dereference aliases only when searching
  </li>

  <p>
  <li><em>find</em>
    <p>
    Dereference aliases only when locating the base object for the search
  </li>
</ul>

<p>
The default is "never", <i>e.g.</i>:
<pre>
  &lt;IfModule mod_ldap.c&gt;
    LDAPAliasDeference never
  &lt;/IfModule&gt;
</pre>

<p>
<hr>
<h3><a name="LDAPAttr">LDAPAttr</a></h3>
<strong>Syntax:</strong> LDAPAttr <em>old-attr-name new-attr-name</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.2.7rc1 and later

<p>
The <code>LDAPAttr</code> directive is used to map, or to associate, a standard
attribute name to a non-standard attribute name.  If, for example, your
LDAP directory schema used different names for some of the attributes used
by <code>mod_ldap</code>, you would use this directive to tell
<code>mod_ldap</code> what new attribute names to use.

<p>
The following LDAP attributes can be renamed in this manner:
<ul>
  <li><code>uid</code>
  <li><code>uidNumber</code>
  <li><code>gidNumber</code>
  <li><code>homeDirectory</code>
  <li><code>userPassword</code>
  <li><code>loginShell</code>
  <li><code>cn</code>
  <li><code>memberUid</code>
  <li><code>ftpQuota</code>
</ul>

<p>
<hr>
<h3><a name="LDAPAuthBinds">LDAPAuthBinds</a></h3>
<strong>Syntax:</strong> LDAPAuthBinds <em>on|off</em><br>
<strong>Default:</strong> LDAPAuthBinds on<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.2.7rc1 and later

<p>
By default, the DN specified by the
<a href="#LDAPBindDN"><code>LDAPBindDN</code></a> will be used to bind to the
LDAP server to obtain user information, including the <code>userPassword</code>
attribute.  If <code>LDAPAuthBinds</code> is set to <em>on</em>, the DN
specified by <code>LDAPDNInfo</code> will be used to fetch all user information
<i>except</i> the <code>userPassword</code> attribute.  Then, the
<code>mod_ldap</code> module will bind to the LDAP server as the user who is
logging in via FTP with the user-supplied password.  If this bind succeeds,
the user is considered authenticated and is allowed to log in.  This method of
LDAP authentication has the added benefit of supporting any password encryption
scheme that your LDAP server supports.

<p>
In versions of <code>mod_ldap</code> up to 2.7.6, the default for
<code>LDAPAuthBinds</code> was <em>off</em>.  After <code>mod_ldap</code> 2.8,
the default value for <code>LDAPAuthBinds</code> is <em>on</em>.

<p>
<hr>
<h3><a name="LDAPBindDN">LDAPBindDN</a></h3>
<strong>Syntax:</strong> LDAPBindDN <em>dn password</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.3.5rc1 and later

<p>
The <code>LDAPBindDN</code> directive configures the <em>DN</em> and the
<em>password</em> that <code>mod_ldap</code> will use when binding to the LDAP
directory.  If this configuration directive is missing, then anonymous binds
are used.

<p>
The default is:
<pre>
  &lt;IfModule mod_ldap.c&gt;
    # Use anonymous binds
    LDAPBindDN "" ""
  &lt;/IfModule&gt;
</pre>

<p>
See also: <a href="#LDAPServer"><code>LDAPServer</code></a>, <a href="#LDAPUseSASL"><code>LDAPUseSASL</code></a>

<p>
<hr>
<h3><a name="LDAPDefaultAuthScheme">LDAPDefaultAuthScheme</a></h3>
<strong>Syntax:</strong> LDAPDefaultAuthScheme <em>"crypt"|"clear"</em><br>
<strong>Default:</strong> crypt<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.2.7rc1 and later

<p>
The <code>LDAPDefaultAuthScheme</code> directive specifies the authentication
scheme used for passwords which have no "{hashname}" prefix in the LDAP
directory.  For example, if you have:
<pre>
  userPassword <em>mypass</em>
</pre>
in your directory, you would want to set <code>LDAPDefaultAuthScheme</code>
to <em>"clear"</em>, <i>e.g.</i>:
<pre>
  LDAPDefaultAuthScheme clear
<pre>

<p>
The default value is <em>"crypt"</em>.

<p>
<hr>
<h3><a name="LDAPDefaultGID">LDAPDefaultGID</a></h3>
<strong>Syntax:</strong> LDAPDefaultGID <em>gid</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.2.7rc1 and later

<p>
The <code>LDAPDefaultGID</code> directive sets the default GID to be used
for users when no <code>gidNumber</code> attribute is found for that user.

<p>
This directive is useful primarily in virtual user environments common in
large-scale ISPs and hosting organizations.  If a user does not have an LDAP
<code>gidNumber</code> attribute, the <code>LDAPDefaultGID</code> is used.
This allows one to have a large number of users in an LDAP directory without
<code>gidNumber</code> attributes; setting this configuration directive will
automatically assign those users a single GID.

<p>
See also: <a href="#LDAPDefaultUID"><code>LDAPDefaultUID</code></a>

<p>
<hr>
<h3><a name="LDAPDefaultQuota">LDAPDefaultQuota</a></h3>
<strong>Syntax:</strong> LDAPDefaultQuota <em>default-quota</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.3.5rc1 and later

<p>
The <code>LDAPDefaultQuota</code> directive configures a <em>default-quota</em>
to use if a user does not have an <code>ftpQuota</code> attribute.  This
parameter is formatted the same way as the <code>ftpQuota</code> LDAP attribute.

<p>
<hr>
<h3><a name="LDAPDefaultUID">LDAPDefaultUID</a></h3>
<strong>Syntax:</strong> LDAPDefaultUID <em>uid</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.2.7rc1 and later

<p>
The <code>LDAPDefaultUID</code> directive sets the default UID to be used
for users when no <code>uidNumber</code> attribute is found for that user.

<p>
This directive is useful primarily in virtual user environments common in
large-scale ISPs and hosting organizations.  If a user does not have an LDAP
<code>uidNumber</code> attribute, the <code>LDAPDefaultGID</code> is used.
This allows one to have a large number of users in an LDAP directory without
<code>uidNumber</code> attributes; setting this configuration directive will
automatically assign those users a single UID.

<p>
See also: <a href="#LDAPDefaultGID"><code>LDAPDefaultGID</code></a>

DoAuth
<p>
By default, the search filter template used is:
<pre>
  (&amp;(uid=%v)(objectclass=posixAccount))
</pre>
The <em>uid</em> for the the search filter is taken from the
<code>LDAPAttr</code> directive.  Search filter templates are only supported
in versions of <code>mod_ldap</code> 2.7 and later.

<p>
See also: <a href="#LDAPAttr"><code>LDAPAttr</code></a>

<p>
<hr>
<h3><a name="LDAPForceDefaultGID">LDAPForceDefaultGID</a></h3>
<strong>Syntax:</strong> LDAPForceDefaultGID <em>on|off</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.2.7rc1 and later

<p>
Even when a <a href="#LDAPDefaultGID"><code>LDAPDefaultGID</code></a> is
configured, the <code>mod_ldap</code> module will allow individual users to
have <code>gidNumber</code> attributes that will override this default GID.
With <code>LDAPForceDefaultGID</code> directive configured to be <em>on</em>,
all LDAP-authenticated users are given the default GID; GIDs may not be
overridden by <code>gidNumber</code> attributes.

<p>
<hr>
<h3><a name="LDAPForceDefaultUID">LDAPForceDefaultUID</a></h3>
<strong>Syntax:</strong> LDAPForceDefaultUID <em>on|off</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config<br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.2.7rc1 and later

<p>
Even when a <a href="#LDAPDefaultUID"><code>LDAPDefaultUID</code></a> is
configured, the <code>mod_ldap</code> module will allow individual users to
have <code>uidNumber</code> attributes that will override this default UID.
With <code>LDAPForceDefaultUID</code> directive configured to be <em>on</em>,
all LDAP-authenticated users are given the default UID; UIDs may not be
overridden by <code>uidNumber</code> attributes.

<p>
<hr>
<h3><a name="LDAPForceGeneratedHomedir">LDAPForceGeneratedHomedir</a></h3>
<strong>Syntax:</strong> LDAPForceGeneratedHomedir <em>off|on</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code
>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.2.7rc1 and later

<p>
When no <code>homeDirectory</code> attribute is found, the <code>mod_ldap</code>
module can be configured to <em>generate</em> a home directory using the
<a href="#LDAPGenerateHomedir"><code>LDAPGenerateHomedir</code></a> directive.
If there <i>is</i> a <code>homeDirectory</code> attribute present, however,
the <code>mod_ldap</code> module will use that attribute value as the home
directory.

<p>
However, there may be cases where the administrator wishes to <em>override</em>
the <code>homeDirectory</code> attribute, and thus to <i>always</i> use the
home directory value that <code>mod_ldap</code> would generate.  The
<code>LDAPForceGeneratedHomedir</code> directive is used in such cases.

<p>
For example, assume that the user logging in is named "tj", and has an
LDAP object whose <code>homeDirectory</code> attribute value is "/home/tj".
To <em>force</em> the use of <code>mod_ldap</code>'s generated home directory
instead of that <code>homeDirectory</code> value, the configuration might
look like:
<pre>
  LDAPForceGeneratedHomedir on
  LDAPGenerateHomedir on
  LDAPGenerateHomedirPrefix /var/ftp
</pre>
Using the above configuration, the home directory that the
<code>mod_ldap</code> module would use is <code>/var/ftp/tj</code>, despite
what <code>homeDirectory</code> attribute may be in the LDAP directory.

<p>
<b>Note</b> that if <code>LDAPForceGeneratedHomedir</code> is enabled, then
<code>LDAPGenerateHomedir</code> must <b>also</b> be enabled.  It is an error
to enable <code>LDAPForceGeneratedHomedir</code> without also enabling
<code>LDAPGenerateHomdir</code>.

<p>
See also: <a href="#LDAPGenerateHomedir"><code>LDAPGenerateHomedir</code></a>, <a href="#LDAPGenerateHomedirPrefix"><code>LDAPGenerateHomedirPrefix</code></a>, <a href="#LDAPGenerateHomedirPrefixNoUsername"><code>LDAPGenerateHomedirPrefixNoUsername</code></a>

<p>
<hr>
<h3><a name="LDAPGenerateHomedir">LDAPGenerateHomedir</a></h3>
<strong>Syntax:</strong> LDAPGenerateHomedir <em>on|off</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.2.7rc1 and later

<p>
By default, the <code>mod_ldap</code> module uses the <code>homeDirectory</code>
attribute to determine what home directory to use for the session.  Sometimes,
however, an administrator will want to use a <i>different</i> home directory
for these FTP/SFTP sessions, something other than the path in the
<code>homeDirectory</code> attribute.  The <code>LDAPGenerateHomedir</code>
directive is used for situations like this.

<p>
The <code>LDAPGenerateHomedir</code> directive configures the
<code>mod_ldap</code> module to "generate" a new home directory value,
<em>overriding</em> the value from the <code>homeDirectory</code> attribute.
The generated home directory value <b>requires</b> that a starting point
for the new home directory, a "prefix", also be provided using the
<a href="#LDAPGenerateHomedirPrefix"><code>LDAPGenerateHomedirPrefix</code></a>
directive.

<p>
The <code>LDAPGenerateHomedir</code> directives does <b>not</b> cause the
new home directory to be <em>created on the filesystem</em>.  It only changes
the home directory value that the <code>mod_ldap</code> module provides to
the ProFTPD engine.  The <i>creation</i> of the home directory, if it does
not already exist, is done using the
<a href="../howto/CreateHome.html"><code>CreateHome</code></a> directive.

<p>
See also: <a href="#LDAPGenerateHomedirPrefix"><code>LDAPGenerateHomedirPrefix</code></a>, <a href="#LDAPGenerateHomedirPrefixNoUsername"><code>LDAPGenerateHomedirPrefixNoUsername</code></a>

<p>
<hr>
<h3><a name="LDAPGenerateHomedirPrefix">LDAPGenerateHomedirPrefix</a></h3>
<strong>Syntax:</strong> LDAPGenerateHomedirPrefix <em>prefix</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.2.7rc1 and later

<p>
The <code>LDAPGenerateHomedirPrefix</code> directive is used when
<code>LDAPGenerateHomedir</code> is enabled, causing the <code>mod_ldap</code>
module to <em>generate</em> a <b>default</b> home directory, when the
<code>homeDirectory</code> attribute value is not present.  The generated home
directory value like this:
<pre>
  <i>prefix</i>/<i>username</i>
</pre>
The configured <em>prefix</em> string has the username (from the
<code>uid</code> attribute) appended to generate the home directory value for
the user.

<p>
For example:
<pre>
  LDAPGenerateHomedir on
  LDAPGenerateHomedirPrefix /var/ftp
</pre>
Using the above configuration, and assuming a user name of "tj", the home
directory that the <code>mod_ldap</code> module would use is
<code>/var/ftp/tj</code>, no matter what the <code>homeDirectory</code>
attribute may be in the LDAP directory.

<p>
See also: <a href="#LDAPForceGeneratedHomedir"><code>LDAPForceGeneratedHomedir</code></a>, <a href="#LDAPGenerateHomedir"><code>LDAPGenerateHomedir</code></a>, <a href="#LDAPGenerateHomedirPrefixNoUsername"><code>LDAPGenerateHomedirPrefixNoUsername</code></a>

<p>
<hr>
<h3><a name="LDAPGenerateHomedirPrefixNoUsername">LDAPGenerateHomedirPrefixNoUsername</a></h3>
<strong>Syntax:</strong> LDAPGenerateHomedirPrefixNoUsername <em>on|off</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.2.7rc1 and later

<p>
When the <a href="#LDAPGenerateHomedir"><code>LDAPGenerateHomedir</code></a>
and <a href="#LDAPGenerateHomedirPrefix"><code>LDAPGenerateHomedirPrefix</code></a> directives are used, the <em>generated</em> home directory value for
the session is:
<pre>
  <i>prefix</i>/<i>username</i>
</pre>
However, there may be cases where the administrator does <b>not</b> want
the username automatically appended to the generated value, and instead wishes
to use <i>just</i> the prefix as the home directory.  For these use cases,
use the <code>LDAPGenerateHomedirPrefixNoUsername</code> directive.

<p>
For example:
<pre>
  LDAPGenerateHomedir on
  LDAPGenerateHomedirPrefix /var/ftp
  LDAPGenerateHomedirPrefixNoUsername on
</pre>
Using the above configuration, and assuming a user name of "tj", the home
directory that the <code>mod_ldap</code> module would use is
<code>/var/ftp</code>, no matter what the <code>homeDirectory</code> attribute
may be in the LDAP directory.

<p>
See also: <a href="#LDAPGenerateHomedir"><code>LDAPGenerateHomedir</code></a>, <a href="#LDAPGenerateHomedirPrefix"><code>LDAPGenerateHomedirPrefix</code></a>

<p>
<hr>
<h3><a name="LDAPGroups">LDAPGroups</a></h3>
<strong>Syntax:</strong> LDAPGroups <em>base-dn cn-filter-template gid-number-filter-template member-uid-filter-template</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.3.5rc1 and later

<p>
The <code>LDAPGroups</code> directive activates LDAP GID-to-name lookups for
directory listings.  The first parameter to this directive is the LDAP
<em>base DN</em> to use for GID-to-name lookups.  The second through fourth
optional parameters are templates to be used for the search filter;
<code>%v</code> will be replaced with the GID that is being looked up.

<p>
By default, the CN filter template look like this:
<pre>
  (&amp;(LDAPAttr_cn=%v)(objectclass=posixGroup))
</pre>
The <code>gidNumber</code> filter template is:
<pre>
  (&amp;(LDAPAttr_gidNumber=%v)(objectclass=posixGroup))
</pre>
and the <code>memberUid</code> filter template used is:
<pre>
  (&amp;(LDAPAttr_memberUid=%v)(objectclass=posixGroup))
</pre>
Note that filter templates are only supported in <code>mod_ldap</code>
version 2.8.3 and later.

<p>
The attribute names used in the default search filters are taken from the
<a href="#LDAPAttr"><code>LDAPAttr</code></a> directive.

<p>
<hr>
<h3><a name="LDAPLog">LDAPLog</a></h3>
<strong>Syntax:</strong> LDAPLog <em>file|"none"</em><br>
<strong>Default:</strong> <em>None</em><br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.3.5rc4 and later

<p>
The <code>LDAPLog</code> directive is used to specify a log file for
<code>mod_ldap</code>'s reporting on a per-server basis.  The <em>file</em>
parameter given must be the full path to the file to use for logging.

<p>
Note that this path must <b>not</b> be to a world-writable directory and,
unless <code>AllowLogSymlinks</code> is explicitly set to <em>on</em>
(generally a bad idea), the path must <b>not</b> be a symbolic link.

<p>
<hr>
<h3><a name="LDAPProtocolVersion">LDAPProtocolVersion</a></h3>
<strong>Syntax:</strong> LDAPProtocolVersion <em>2|3</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.2.7rc1 and later

<p>
The <code>LDAPProtocolVersion</code> directive configures the version of
the LDAP protocol that <code>mod_ldap</code> will use when talking to the
LDAP servers.  The default protocol version used is <em>3</em>.

<p>
<hr>
<h3><a name="LDAPQueryTimeout">LDAPQueryTimeout</a></h3>
<strong>Syntax:</strong> LDAPQueryTimeout <em>secs</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.2.7rc1 and later

<p>
The <code>LDAPQueryTimeout</code> directive configures the timeout value,
in seconds, that will be used for LDAP directory queries.  The default timeout
value is determined by your LDAP API.

<p>
<hr>
<h3><a name="LDAPSearchScope">LDAPSearchScope</a></h3>
<strong>Syntax:</strong> LDAPSearchScope <em>base|onelevel|subtree</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.2.7rc1 and later

<p>
The <code>LDAPSearchScope</code> directive is used to set the scope used for
LDAP searches.  The default setting, <em>subtree</em>, searches for all entries
in the tree from the current level down.  Setting this directive to
<em>onelevel</em> searches only one level deep in the LDAP tree.

<p>
<b>Note</b> that the <code>LDAPSearchScope</code> directive <b>cannot</b> be
used when the LDAP URL syntax, rather than hostname/port, is used for your
<a href="#LDAPServer"><code>LDAPServer</code></a> configuration.  Why not?
The search scope can be specified as part of the URL itself.  This, combined
with the fact that the <code>LDAPServer</code> directive can take
<i>multiple</i> hosts/URLs, makes it clear to include the search scope in the
URLs as needed.

<p>
If you are <b>not</b> using the LDAP URL syntax, then the following will
use the <em>subtree</em> search scope:
<pre>
  LDAPServer ldap.example.com
</pre>
or, to make it explicit in your configuration:
<pre>
  LDAPServer ldap.example.com
  LDAPSearchScope subtree
</pre>
On the other hand, if you <b>are</b> using LDAP URLs, then you specify the
search scope as part of the URL:
<pre>
  LDAPServer ldap://ldap.example.com/??sub
</pre>
It is <b>important</b> that the "/" after the hostname/port be part of your
LDAP URL when specifying the search scope.  That is, using:
<pre>
  LDAPServer ldap://ldap.example.com??sub
</pre>
<b>will not work as expected</b>; see
<a href="https://tools.ietf.org/html/rfc2255">RFC 2255</a>, Section 3.  LDAP
URL parameters are <b>not</b> like HTTP URL query parameters; LDAP URL
parameters <b>are</b> order-specific.  And the "/" before any of the
optional parameters <b>is required</b>.

<p>
<hr>
<h3><a name="LDAPServer">LDAPServer</a></h3>
<strong>Syntax:</strong> LDAPServer <em>url1|host1:port1 url2|host2:port2 [ssl-ca:&lt;path&gt;] [ssl-cert:&lt;path&gt;] [ssl-key:&lt;path&gt;] [ssl-ciphers:&lt;list&gt;] [ssl-verify:boolean]</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.2.7rc1 and later

<p>
The <code>LDAPServer</code> directive allows you to to specify the hostname(s)
and port(s) of the LDAP server(s) to use for LDAP authentication. If no
<code>LDAPServer</code> configuration directive is present, the default LDAP
servers specified by your LDAP library will be used.  Note that the LDAP
URL syntax may also be used.

<p>
To specify multiple LDAP servers, you can configure the entire list of servers
on one line:
<pre>
  # Using just hostname/port
  LDAPServer host1:port1 host2:port2
</pre>
or:
<pre>
  # Using the URL syntax
  LDAPServer url1 url2
</pre>
In ProFTPD 1.3.7rc4 and later, you can also use multiple <code>LDAPServer</code>
directives as well, <i>e.g.</i>:
<pre>
  LDAPServer host1:port1
  LDAPServer url1
  LDAPServer host2
  LDAPServer url2
</pre>

<p>
The default search scope for LDAP URLs is "base" (unless a scope is explicitly
provided in the URL). This behavior differs from the
<a href="#LDAPSearchScope"><code>LDAPSearchScope</code></a> directive, which
defaults to "subtree".

<p>
<b>Note</b> that to use LDAPS (LDAP over SSL), you <b>must</b> use the
<em>URL</em> format, <i>e.g.</i>:
<pre>
  LDAPServer ldaps://host1:port1 ldaps://host2:port2
</pre>

<p>
However, LDAPS is deprecated.  Instead, LDAP prefers the
<a href="https://en.wikipedia.org/wiki/STARTTLS">STARTTLS</a> mechanism. To
enable use of STARTTLS for your LDAP connections, use the
<a href="#LDAPUseTLS"><code>LDAPUseTLS</code></a> directive, <i>e.g.</i>:
<pre>
  LDAPServer ldap://host1:port1 ldap://host2:port2
  LDAPUseTLS on
</pre>

<p>
In ProFTPD 1.3.7rc4 and later, it is possible to configure SSL/TLS parameters
for a given connection.  Most of the time, all that is needed for the SSL
session is the CA (Certificate Authority) to use, for verifying the
certificate presented by the LDAP server, using the <em>ssl-ca:</em> parameter.
Thus:
<pre>
  LDAPServer ... ssl-ca:/path/to/cacert.pem
</pre>
If your LDAP server is configured to require SSL/TLS mutual authentication
(also called "client auth"), you may need the <em>ssl-cert:</em> and
<em>ssl-key:</em> parameters as well:
<pre>
  LDAPServer ... ssl-ca:/path/to/cacert.pem \
    ssl-cert:/path/to/client-cert.pem \
    ssl-key:/path/to/client-key.pem
</pre>
Finally, you may want to configure the specific SSL/TLS ciphersuites that
should be used; the <em>ssl-ciphers:</em> parameter can be used for this:
<pre>
  LDAPServer ... ssl-ca:/path/to/cacert.pem \
    ssl-cert:/path/to/client-cert.pem \
    ssl-key:/path/to/client-key.pem \
    ssl-ciphers:DEFAULT:!EXPORT:!DES
</pre>

<p>
If there is an issue with the server certificate presented by your LDAP
server, <b>but</b> you need to create the SSL/TLS session anyway, you can
relax the certificate verification requirements using the <em>ssl-verify:</em>
parameter, <i>e.g.</i>:
<pre>
  LDAPServer ... ssl-ca:/path/to/cacert.pem \
    ssl-verify:off
</pre>

<p>
<hr>
<h3><a name="LDAPUsers">LDAPUsers</a></h3>
<strong>Syntax:</strong> LDAPUsers <em>base-dn [name-filter-template [uid-filter-template]]</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.3.5rc1 and later

<p>
The <code>LDAPUsers</code> directive activates LDAP UID-to-name lookups
for directory listings.  The first parameter to this directive is the LDAP
<em>base DN</em> to use for UID-to-name lookups.  The optional second parameter
is a template to be used for the search filter for the username; <code>%v</code>
will be replaced with the UID that is being looked up.  Similarly, an optional
third parameter is also a template, to be used for the search filter for
the UID.

<p>
By default, the name search filter template looks like this:
<pre>
  (&amp;(uid=%v)(objectclass=posixAccount))
</pre>
and the UID search filter template looks like this:
<pre>
  (&amp;(LDAPAttr_uidNumber=%v)(objectclass=posixGroup))
</pre>
The <em>uidNumber</em> attribute name used in the search filter comes from
the <a href="#LDAPAttr"><code>LDAPAttr</code></a> directive.
Note that filter templates are only supported in <code>mod_ldap</code>
version 2.7 and later.

<p>
<hr>
<h3><a name="LDAPUseSASL">LDAPUseSASL</a></h3>
<strong>Syntax:</strong> LDAPUseSASL <em>mech1 ...</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.3.7rc4 and later

<p>
The <code>LDAPUseSASL</code> directive tells the <code>mod_ldap</code> module
to use the configured space-separated list of
<a href="https://ldapwiki.com/wiki/SASL">SASL</a> (Simple Authentication and
Security Layer) mechanisms, when using the
<a href="#LDAPBindDN"><code>LDAPBindDN</code></a> to talk to the LDAP server.
By default, <em>simple</em> binds are done to the LDAP server.

<p>
The currently supported mechanisms are:
<ul>
  <li>ANONYMOUS
  <li>CRAM-MD5
  <li>DIGEST-MD5
  <li>LOGIN
  <li>PLAIN
  <li>SCRAM-SHA-1
</ul>
The order in which the mechanisms are configured matters; the first one
selected by the LDAP server wins.

<p>
<b>Note</b> that a SASL mechanism configured here may still be rejected by
the LDAP server, if the server-side policies for authentication are not met.
Indeed, some SASL mechanisms may only be allowed by the server <i>if</i> used
in conjunction with SSL/TLS; this is a common requirement for using the
<code>LOGIN</code> and <code>PLAIN</code> mechanisms.

<p>
Thus a good default configuration, using TLS <i>and</i> SASL, might be:
<pre>
  &lt;IfModule mod_ldap.c&gt;
    LDAPServer ldap.example.com
    LDAPBindDN CN=readonly,DC=example,DC=com ...
    LDAPUseSASL SCRAM-SHA-1 DIGEST-MD5
    LDAPUseTLS on
  &lt;/IfModule&gt;
</pre>

<p>
<hr>
<h3><a name="LDAPUseTLS">LDAPUseTLS</a></h3>
<strong>Syntax:</strong> LDAPUseTLS <em>on|off</em><br>
<strong>Default:</strong> off<br>
<strong>Context:</strong> server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code><br>
<strong>Module:</strong> mod_ldap<br>
<strong>Compatibility:</strong> 1.2.7rc1 and later

<p>
The <code>LDAPUseTLS</code> directive configures whether <code>mod_ldap</code>
will use SSL/TLS via <a href="https://en.wikipedia.org/wiki/STARTTLS">STARTTLS</a> to protect the connections made to the configured LDAP servers.

<p>
By default, the <code>mod_ldap</code> module connects to the LDAP server via 
non-encrypted connections.  Enabling this option causes <code>mod_ldap</code>
to use an encrypted (TLS/SSL) connection to the LDAP server. If a secure
connection to the LDAP server fails, <code>mod_ldap</code> will not
authenticate users; <code>mod_ldap</code> will <b>not</b> fall back to an
unsecure connection.

<p>
<hr>
<h2><a name="Installation">Installation</a></h2>
Follow the normal steps for using third-party modules in ProFTPD:
<pre>
  $ ./configure --with-modules=mod_ldap
  $ make
  $ make install
</pre>
You may need to specify the location of the OpenLDAP header and library files
in your <code>configure</code> command, <i>e.g.</i>:
<pre>
 $ ./configure --with-modules=mod_ldap \
    --with-includes=/usr/local/openldap/include \
    --with-libraries=/usr/local/openldap/lib
</pre>

<p>
<hr>
<h2><a name="Usage">Usage</a></h2>

<p>
One <code>mod_ldap</code> user submitted the following configuration for
allowing <code>mod_ldap</code> to communicate to a Windows Active Directory
server.  Note that this configuration has not been tested; if it works for
you (or not), please let us know:
<pre>
  &lt;IfModule mod_ldap.c&gt;
    LDAPServer ldaps://dc.example.org:3268
    LDAPUseTLS on
    LDAPAuthBinds on
    LDAPBindDN "cn=SRV_ACC_SVN_AUTH,ou=special accounts,ou=Sales,dc=example,dc=org" ******************

    LDAPUsers ou=Users,ou=Sales,dc=example,dc=org "(&amp;(sAMAccountName=%u)(objectclass=user)(memberOf=cn=Linux Admins,ou=Groups,ou=Sales,dc=example,dc=com))"
    LDAPSearchScope subtree

    # Assign default IDs
    LDAPDefaultUID 106
    LDAPDefaultGID 65534

    # Create the home directory
    LDAPGenerateHomedir on
    LDAPGenerateHomedirPrefix /home

    # Use different attribute names where necessary
    LDAPAttr uid sAMAccountName
    LDAPAttr gidNumber primaryGroupID
  &lt;/IfModule&gt;
</pre>

<p>
<b>Logging</b><br>
The <code>mod_ldap</code> module supports <a href="../howto/Tracing.html">trace logging</a>, via the module-specific log channels:
<ul>
  <li>ldap
  <li>ldap.library
</ul>
Thus for trace logging, to aid in debugging, you would use the following in
your <code>proftpd.conf</code>:
<pre>
  TraceLog /path/to/ftpd/trace.log
  Trace ldap:20
</pre>
This trace logging can generate large files; it is intended for debugging use
only, and should be removed from any production configuration.

<p><a name="FAQ">
<b>Frequently Asked Questions</b><br>

<p><a name="ScopesFAQ">
<font color=red>Question</font>: Why is <code>mod_ldap</code> using a "base"
scope by default, rather than "subtree"?  I configured:
<pre>
  LDAPSearchScope subtree
</pre>
but it is not working; I see the following in my LDAP server logs:
<pre>
  slapd[31709]: conn=20239 op=1 SRCH <b>base</b>="ou=people,dc=example,dc=com" scope=0 deref=0 filter="(&amp;(uid=tj)(objectClass=posixAccount))"
</pre>
<font color=blue>Answer</font>: The use of the "base" scope for searches, in
spite of any <code>LDAPSearchScope</code> directive, happens when a URL, rather
than hostname/port, are used in the <code>LDAPServer</code> directive. <a href="https://tools.ietf.org/html/rfc2255">RFC 2255</a>, Section 3 specifies that the default scope is "base".

<p>
Thus instead of:
<pre>
  LDAPServer ldap://ldap.example.com
</pre>
you will need to use:
<pre>
  LDAPServer ldap://ldap.example.com/??sub
</pre>
See the <a href="#LDAPSearchScope"><code>LDAPSearchScope</code></a>
documentation for more details.

<p><a name="HomedirsFAQ">
<font color=red>Question</font>: How do I use <code>LDAPGenerateHomedir</code>
and <code>CreateHome</code> together successfully?  Can I use <i>just</i>
<code>LDAPGenerateHomedir</code>?<br>
<font color=blue>Answer</font>: If you want to have home directories for your
LDAP users automatically <b>created</b>, you <b>do</b> need to use the
<a href="../howto/CreateHome.html"><code>CreateHome</code></a> directive.
Whether you <em>need</em> to use the <a href="#LDAPGenerateHomedir"><code>LDAPGenerateHomedir</code></a> directive is a different (but related) question.

<p>
The <code>LDAPGenerateHomedir</code> directive (and its relative <a href="#LDAPForceGeneratedHomedir"><code>LDAPForceGeneratedHomedir</code></a>) should be
used <i>when you want to users to have a different home directory than is
configured for them in LDAP</i>.  They are <b>not</b> used for creating these
directories, just generating the paths to use.

<p>
Thus to <i>generate</i> a different home directory for your LDAP-defined users,
<i>and</i> to have these different home directories <em>created</em>, you
might use something like this:
<pre>
  &lt;IfModule mod_ldap.c&gt;
    ...
    LDAPGenerateHomedir on
    LDAPGenerateHomedirPrefix /data
    LDAPForceGeneratedHomedir on

    # And make sure these home directories are created
    CreateHome on 0770 skel /opt/ProFTPD/etc/skel
    ...
  &lt;/IfModule&gt;
</pre>

<p><a name="MultipleBindsFAQ">
<font color=red>Question</font>: In my LDAP server logs, I see ProFTPD make
<i>multiple</i> binds for the same client logging in:
<pre>
  slapd[31709]: conn=20239 op=0 BIND dn="cn=admin,dc=example,dc=com" method=128
  slapd[31709]: conn=20239 op=0 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0
</pre>
I was expecting just <i>one</i> bind.  Is this a bug, or is it expected
behavior?<br>
<font color=blue>Answer</font>: Yes, this <em>is</em> the expected behavior.
See the <a href="#LDAPAuthBinds"><code>LDAPAuthBinds</code></a> directive
for details.

<p>
<b>Note</b> that you may see <i>additional</i> binds when other modules, such
as <code>mod_ifsession</code>, are present in your <code>proftpd</code> build.

<p>
<hr>
<font size=2><b><i>
&copy; Copyright 2013-2020 TJ Saunders<br>
 All Rights Reserved<br>
</i></b></font>
<hr>

</body>
</html>

Youez - 2016 - github.com/yon3zu
LinuXploit