কেন আপাচি এলডিএপি লেখক ব্যর্থতা তা বুঝতে পারছেন না


8

হঠাৎ, গতকাল, আমার এক অ্যাপাচি সার্ভার আমার এলডিএপি (AD) সার্ভারের সাথে সংযোগ করতে অক্ষম হয়ে গেল। সেই সার্ভারে আমার দুটি সাইট চলছে, যার মধ্যে উভয়ই আমার AD সার্ভারের বিরুদ্ধে লেখার জন্য LDAP ব্যবহার করে যখন কোনও ব্যবহারকারী কোনও সাইটে লগইন করে। দু'দিন আগে এটি ঠিকঠাক কাজ করেছিল। অজানা কারণে, গতকাল পর্যন্ত, এটি কাজ করা বন্ধ করে দিয়েছে। ত্রুটি লগ কেবল এটি বলে:

auth_ldap authenticate: user foo authentication failed; URI /FrontPage [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server], referer: http://mysite.com/

আমি ভেবেছিলাম সম্ভবত আমার স্বাক্ষরিত এসএসএল শংসাপত্রটির মেয়াদ শেষ হয়ে গেছে, তাই আমি mysite.com এর জন্য একটি নতুন তৈরি করেছি, তবে সার্ভারের হোস্টনামের জন্য নয়, এবং সমস্যাটি অব্যাহত রয়েছে। আমি ডিবাগ-স্তরের লগিং সক্ষম করেছি। এটি এলডিএপি সার্ভারের সাথে সম্পূর্ণ এসএসএল লেনদেন দেখায় এবং আমি যখন "এলডিএপি সার্ভারের সাথে যোগাযোগ করতে পারি না" বার্তাটি পাই তখন এটি শেষ অবধি ত্রুটি ছাড়াই সম্পূর্ণ হয়ে যায়। আমি এই সার্ভারে কমান্ডলাইন থেকে ldapsearch চালাতে পারি, এবং আমি এটিতে লগইন করতে পারি, এটি এলডিএপিও ব্যবহার করে, তাই আমি জানি যে সার্ভারটি এলডিএপি / এডি সার্ভারের সাথে সংযোগ করতে এবং জিজ্ঞাসা করতে পারে। এটি কেবল অ্যাপাচি যা সংযোগ করতে পারে না।

উত্তরের জন্য গুগলিং কিছুই করে নি, তাই আমি এখানে জিজ্ঞাসা করছি। কেউ কি এই সমস্যার অন্তর্দৃষ্টি দিতে পারেন?

এখানে অ্যাপাচি কনফিগারেশন থেকে এলডিএপ বিভাগটি রয়েছে:

<Directory "/web/wiki/">
    Order allow,deny
    Allow from all
    AuthType Basic
    AuthName "Login"
    AuthBasicProvider ldap
    AuthzLDAPAuthoritative off
    #AuthBasicAuthoritative off
    AuthLDAPUrl ldaps://domain.server.ip/dc=full,dc=context,dc=server,dc=name?sAMAccountName?sub
    AuthLDAPBindDN cn=ldapbinduser,cn=Users,dc=full,dc=context,dc=server,dc=name
    AuthLDAPBindPassword password
    require valid-user
</Directory>

যথেষ্ট মজার বিষয় হল, আমার কাছে একটি অ্যাপাচি 2 সার্ভার ছিল যা এলডিএপি এর বিরুদ্ধে প্রমাণিত হয়েছিল যা কয়েক মাস ধরে কাজ করে যাচ্ছিল, তবে ঠিক গত সপ্তাহে এই ঠিক একই সমস্যাটি প্রদর্শন করা শুরু হয়েছিল! আমার জীবনের জন্য আমি এটি কী তা বুঝতে পারি না, আমি সব ধরণের জিনিস চেষ্টা করেছি। এই প্রশ্নটি দেখতে যাচ্ছি।
কামিল কিসিয়েল

উত্তর:


9

Httpd সার্ভার / এলডিএপি ক্লায়েন্টের একটি প্যাকেট ট্রেস সিএ অজানা সম্পর্কে একটি বার্তা প্রকাশ করেছে।

টিএলএসভি 1 সতর্কতা (স্তর: মারাত্মক, বিবরণ: অজানা সিএ)

আমি আমার httpd.conf এ নিম্নলিখিত বিকল্পগুলি খুঁজে পেয়েছি এবং যুক্ত করেছি:

  LDAPVerifyServerCert          off

এটি সেন্টোস under এর অধীনে আমার সমস্যাটি সমাধান করেছে The সেন্টোস ৫ টি httpd সার্ভারগুলির কোনও সংশোধন প্রয়োজন হয়নি এবং বিকল্পটি ছাড়াই সব কাজ করেছিল।


এই উত্তর জট আমাকে একটি বিয়ার জিতল। একজন সহকর্মী এই ইস্যুটির দিকে দৌড়ে গেলেন এবং তার নতুন মিন্টেড দেবিয়ান সার্ভার কেন আমাদের এলডিএপি সার্ভারের সাথে সংযোগ স্থাপন করতে পারছে না সে সম্পর্কে অভিযোগ করার বিষয়টি আমি শুনতে পেলাম। আমি এই লিঙ্কটি তাকে চাই এবং তার সমস্যাটি তত্ক্ষণাত্ সমাধান হয়ে গেল।
dmourati

অনেকগুলি। এই উত্তর সত্যিই আমার আড়াল বাঁচিয়েছে।
অ্যানারডেমন

2

উইন্ডোজ 2003 এ এডিয়ের আগে আমার এর আগে এই জাতীয় সমস্যা ছিল: আমি যে সমাধানটি পেয়েছি তা হ'ল সম্পূর্ণ ডিএন ব্যবহার করে বাঁধাই করা নয় বরং তার পরিবর্তে ব্যবহারকারী @ ডোমেন সিনট্যাক্সটি ব্যবহার করুন:

AuthLDAPBindDN user@domain.com

1

আপনার এলডিএপি সার্ভার থেকে লগগুলিতে অ্যাক্সেস আছে কি? তারা এই সমস্যার সমাধানে সহায়ক হতে পারে।


এলডিএপি সার্ভারটি আসলে একটি উইন্ডোজ এডি সার্ভার। আমি ইভেন্টের লগগুলি চেক করেছিলাম, দরকারী কিছু পাই নি। এমনকি অ্যাপাচি সার্ভার এমনকি সংযোগ দেওয়ার চেষ্টা করেছিল এমন কোনও ইঙ্গিতও নয়।
সেথজি

আপনার যাচাই করা উচিত যে অ্যাপাচি সার্ভারটি আসলে এলডিএপ অনুরোধটি AD সার্ভারে প্রেরণ করছে; এটি সম্ভবত কোনও কিছু এলডিএপ অনুরোধটিকে এডি সার্ভারে তৈরি করতে বাধা দিচ্ছে। উইন্ডোজ মেশিনে আপনার যদি যথেষ্ট সুযোগ-সুবিধা থাকে তবে আপনি এলডিএপ অনুরোধটি আসলে এডি তে সঠিকভাবে চলেছে তা যাচাই করতে আপনি ওয়্যারশার্ক চালাতে পারেন। যদি তা না হয় তবে দুটি সার্ভারের মধ্যে নেটওয়ার্ক এবং ফায়ারওয়ালগুলি পরীক্ষা করুন। আপনি কি অ্যাপাচিগুলি সার্ভারে চালাচ্ছেন?
এরিক ডেনিস

1

আমি যখন প্যাকেজ আপডেট ক্লায়েন্ট ldap.conf (সাধারণত /etc/ldap.conf বা /etc/openldap/ldap.conf) পরিবর্তনের কারণ হয়ে থাকে এবং TLS_REQCERT বিকল্পটিকে আরও কড়া সেটিংয়ে পুনরায় সেট করি তখন আমি এটি দেখেছি। এটি এসএসএলকে সঠিকভাবে আলোচনা করতে পারে তবে শেষ পর্যন্ত ব্যর্থ হবে কারণ এটি বিশ্বস্ত রুট থেকে শংসাপত্র চেইনকে বৈধতা দিতে পারে না।


1

আপনি সার্ভারগুলির ঘড়িটি পরীক্ষা করতে চাইতে পারেন। সময়ের পার্থক্য কয়েক মিনিটের বেশি হলে প্রমাণীকরণের টিকিটটি অবৈধ।

যদিও এটি ঠিক ত্রুটি বার্তা নয়, 'অন্যান্য সার্ভার হঠাৎ একই সমস্যা হয়ে যায়' অংশটি এই জাতীয় সমস্যাটিকে নির্দেশ করতে পারে।


1

এলডিএপিএসের সাথে কাজ করতে আপনাকে এলডিএপি সিএ শংসাপত্র জারি করতে হবে


1

আমার একটি অনুরূপ সমস্যা রয়েছে, যা আমি এই আদেশটি চালিয়ে সনাক্ত করেছি:

openssl s_client -connect $ldap_host:636 -state -nbio 2>&1। আমি মনে করি Mod_ldap নীচে ওপেনসেল ব্যবহার করে, তাই এটি ডিবাগিংয়ের জন্য মোটামুটি সুসংগত হওয়া উচিত।

আমি এটিকে অন্য কোনও এসএসএল এনক্রিপ্ট করা সার্ভারের সাথে তুলনা করেছি যা আমি জানতাম যে কাজ করছে। সঠিকভাবে যাচাই করা এসএসএল সংযোগটি একটি শিকড় সিএতে ফিরে যাবে এবং ফিরে যাবে 0. কী ভুল হচ্ছে তা নির্ধারণ করতে আপনি আউটপুটটি ব্যবহার করতে পারেন।

আমার ক্ষেত্রে, এলডিএপি সার্ভার শংসাপত্রগুলি ভেরিজাইন দ্বারা স্বাক্ষরিত, যা ইন্টারমিডিয়েট সিএ শংসাপত্রগুলি ব্যবহার করে । ওপেনএসএসএল শংসাপত্রটি যাচাই করতে অক্ষম এবং সংযোগটি অস্বীকার করা হয়েছে ("সার্ভারের দ্বারা সংযোগ প্রত্যাখ্যান করা" সহায়তামূলক নয়)।


1

আমারও একই সমস্যা ছিল। আমি ওপেনসেল সহ সার্টিফিকেট পেতে পারি, আমি একই পোর্টগুলিতে ldapsearch সহ SSL এর মাধ্যমে অ্যাক্টিভ ডিরেক্টরিটি জিজ্ঞাসা করতে পারি। অবশেষে আমি মাইক্রোসফ্ট গ্লোবাল ক্যাটালগ বন্দরগুলি 3268 বা 3269 এ পরিবর্তন করেছি এবং তারা উভয়েই কাজ করেছিল। মাইক্রোসফ্ট উইন্ডোজ 2003 সার্ভারগুলি প্যাচ করা হয়েছিল, তবে সমস্যাটি শুরু হওয়ার কয়েক দিন আগে এটি হয়েছিল।


0

আমি আমাদের সমস্ত সার্ভার জুড়ে এলডিএপিএস বাস্তবায়ন করছিলাম এবং এই সমস্যাটির মধ্যেও এসেছি। আপনি কি সরল পঠন এলডিএপি (আদর্শ নয়, তবে সমস্যার উত্সটি জানার জন্য দরকারী) এ ফিরে গেলে কী তা দূরে যায়? যদি তা হয় তবে আমার এখনও কোনও সমাধান খুঁজে পাওয়া যায় নি তবে সম্ভবত আমরা একসাথে authnz_ldap এ একটি বাগ আলাদা করতে পারি।


0

আমি ধরে নিচ্ছি যে আপনার কমান্ড-লাইন পরীক্ষাগুলি আপনার অ্যাপাচি কনফিগারেশনের মতো একই "বাইন্ড ব্যবহারকারী" ব্যবহার করছে using যদি তা না হয় তবে আপনার সঠিক বর্তমান পাসওয়ার্ড আছে কিনা তা পরীক্ষা করা উচিত।

অতীতে, আমাকে একবার AD ডোমেনের জন্য মানক LDAP পোর্টের পরিবর্তে বৈশ্বিক ক্যাটালগ বন্দরটি ব্যবহার করতে হয়েছিল। এর কারণ মনে করতে পারছি না। উপরের আপনার ইউআরএল হিসাবে ldaps জন্য, এটি পোর্ট 3269 হবে।


0

যেভাবে এটি কাজ করে তা হ'ল আপনার ওয়েবসাইটটিকে প্রথমে আপনার বাইন্ড ব্যবহারকারীর শংসাপত্রগুলি ব্যবহার করে AD এর সাথে সংযোগ স্থাপন করা দরকার এবং তারপরে, একবার এই সংযোগটি তৈরি হয়ে গেলে এটি ব্যবহারকারীর শংসাপত্রগুলি আপনার ওয়েবসাইট অ্যাক্সেস করার জন্য এই অ্যাক্সেসটিকে ব্যবহার করে।

আপনার ত্রুটির বার্তা অনুসারে, মনে হচ্ছে প্রক্রিয়াটি আপনার বাইন্ড ব্যবহারকারী (AuthLDAPBindDN) হিসাবে AD এর সাথে সংযোগ করতে অক্ষম ।

নিশ্চিত করুন যে বেঁধে ব্যবহারকারীর অ্যাকাউন্ট অক্ষম নেই সক্রিয় ডিরেক্টরি, এবং যে আপনি যে পাসওয়ার্ডটি হিসাবে (AuthLDAPBindPassword) নির্দিষ্ট করেছেন সঠিক । এছাড়াও, আপনার বাইন্ড ব্যবহারকারীর অন্যান্য ব্যবহারকারীদের অনুসন্ধানের প্রয়োজনীয় অনুমতি রয়েছে তা নিশ্চিত করুন (আমাদের ক্ষেত্রে ডোমেন ব্যবহারকারীদের সদস্য হতে হবে)


0

আরএইচইএল 6 এ আমার এই সমস্যাটি ("ldap সার্ভারের সাথে যোগাযোগ করতে পারে না") ছিল এবং এটি ওপেনড্যাপের পরিবর্তনের ফলাফল। yum কনফিগারেশন ফাইলটি আপডেট করেছে /etc/openldap/ldap.conf তবে এটি ওভাররাইটিংয়ের পরিবর্তে (এটি কাস্টমাইজ করা হয়েছে; আমার ক্ষেত্রে এটি ছিল না) এটি একটি ldap.conf.rpmnew ফাইল তৈরি করেছে।

.Dpm নতুন সংস্করণটি ldap.conf এর সাথে অনুলিপি করা সমস্যার সমাধান করেছে।

(আমি একমত হতে পারি না যে শংসাপত্র যাচাইকরণ বন্ধ করে দেওয়া এটির একটি উত্তর It এটি সম্ভাব্য বিপজ্জনক উপায়ে সমস্যা এড়ায়))


0

আমি এখানে পাওয়া প্যাকেজগুলি berkelydbএবং openldapপ্যাকেজগুলি ইনস্টল করে এই সমস্যাটি সমাধান করতে সক্ষম হয়েছি ।

পার্থক্যটি হ'ল রেডহ্যাট এসএসএল সমর্থনের nssপরিবর্তে জিনিসগুলি লিঙ্ক করা শুরু করেছে openssl। এই ক্ষেত্রে, এটি সমস্ত জিনিসকে ভেঙে দেয়। এই প্যাকেজগুলি ইনস্টল করা (যা ওপেনসেলের সাথে যুক্ত রয়েছে) সমস্যার সমাধান করে। কেবল প্যাকেজগুলি পান এবং চালান:

yum install berkeleydb-ltb* openldap-ltb*

তারপরে অ্যাপাচি পুনরায় চালু করুন, এবং আপনার ব্যবসায়ের উচিত।


0

রেল .6..6 থেকে রেল .5.৫ এ আপগ্রেড করার পরে আমার অভিন্ন সমস্যা ছিল। আমি যখন ধারণার বাইরে ছিলাম তখন অ্যাপাচি ২.২.৩২-তে Mod_ssl এ সিদ্ধান্ত নিয়েছি যে rhel7.4 এ 100% উপযুক্ত হতে পারে না। আমি অ্যাপাচি ২.২.৩২ থেকে অ্যাপাচি ২.৪ এ আপগ্রেড করেছি, এসএসএল সক্ষম করেছি এবং এসএলডিপ কাজ করেছে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.