OpenVPN-ի LDAP նույնականացումն աշխատում է, բայց խմբի ստուգումը ձախողվում է. որտեղ նայել

Մուտքի տվյալներն անցնում են, թունելը սկսում է բարձրանալ, և հետո սեանսը ձախողվում է խմբի, այլ ոչ թե գաղտնաբառի մասին հաղորդագրությամբ։ Այդ համակցությունը ձախողումը տեղադրում է LDAP փլագինի աշխատանքի երկրորդ կեսում՝ կապակցումը և գաղտնաբառի ստուգումը հաջողվեցին, իսկ դրան հաջորդող անդամության որոշումը՝ ոչ։ Երկու կեսերն էլ կարդում են նույն կոնֆիգուրացիայի բլոկից, դրա համար էլ մի տեղում ուղղումը կարող է անթերի թողնել մյուսը։ Սկսեք այն մատյանի տողից, որը նշում է քայլը, ոչ այն հաշվից, որով պատահաբար փորձարկում եք։

Մերժումը դիտարկեք որպես լիազորման պատասխան

Փլագինը կատարում է ծառայության կապակցում, փնտրում է հաշիվը, ստուգում է տրված գաղտնաբառը, ապա հարցնում՝ արդյոք այդ հաշիվը պատկանում է թույլատրված խմբի։ Դրանք չորս առանձին գործողություններ են, և միայն վերջինն է խմբերի մասին։ Ուստի հաջող կապակցումից հետո եկող մերժումը ոչինչ չի ասում գաղտնաբառի մասին, նույնիսկ երբ հաճախորդը ցուցադրում է նույնականացման ընդհանուր սխալ։ Փլագինի մատյանի մակարդակը կոնֆիգուրացիան փոխելուց առաջ բարձրացնելն է այն, ինչը ելքի մեջ բաժանում է չորսը։

Փնտրեք հենց խմբի գնահատումը։ Երբ խմբի հարցում ընդհանրապես չի հայտնվում, լիազորման բլոկին չի հասնում, ինչը սովորաբար նշանակում է, որ հրահանգը գտնվում է այն բլոկից դուրս, որին պատկանում է, կամ բացակայում է պարտադիր ընտրանք։ Երբ հարցումը հայտնվում է և ոչինչ չի վերադարձնում, վերջնակետը կամ զտիչը պատասխանում է ձեր մտքում եղածից տարբեր հարցի։

Որոշեք՝ անդամությունը զտիչի մե՞ջ է, թե՞ խմբի բլոկում

Գոյություն ունի աջակցվող երկու ձև, և դրանք խառնելն այն է, ինչի պատճառով աշխատող կոնֆիգուրացիան դադարում է աշխատել։ Առաջինը անդամությունը մղում է օգտվողի որոնման մեջ՝ օգտվողի օբյեկտից հատկանիշ պահանջելով՝ երկրորդը թողնում է օգտվողի որոնումը անփոփոխ և ստիպում փլագինին հետո փնտրել խմբի օբյեկտը։ Յուրաքանչյուր տեղակայման համար ընտրեք մեկը և գրեք, թե որն եք ընտրել։

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
    RequireGroup false
</Authorization>

Այդ ձևով զտիչն է ամեն ինչ որոշում, ուստի RequireGroup պետք է լինի false, հակառակ դեպքում փլագինը գնում է փնտրելու խմբի օբյեկտ, որը զտիչը երբեք չի հիշատակել։ Զտիչի հատկանիշը պետք է գոյություն ունենա օգտվողի օբյեկտում և լցված լինի, ինչը երաշխավորված չէ, երբ խմբերը ներդրված են։

Մյուս ձևը որոնումը պահում է պարզ և դրանից հետո ավելացնում խմբի որոնում։ Խմբի օբյեկտը հստակ անվանվում է, և փլագինը համեմատում է օգտվողին այն անդամների հետ, որոնք գրացուցակը վերադարձնում է դրա համար։ Օգտվողի զտիչում ոչինչ չի փոխվում, ինչը այս ձևը դարձնում է ավելի հեշտ աուդիտի ենթարկելու, երբ խումբը կառավարում է մեկ այլ թիմ։

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(sAMAccountName=%u)"
    RequireGroup true
    Group        "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>

Կույր կետը ընդհանուր է՝ անդամության պարզ համեմատությունը չի բացում ներդրված խմբերը, ուստի այն հաշիվը, որի հասանելիությունը գալիս է ծնող խմբի միջոցով, ձախողվում է, մինչ կոնսոլը դեռ ցույց է տալիս անդամությունը։ Active Directory-ն խմբի վրա բացահայտում է member-ը, այլ սխեմաներ օգտագործում են uniqueMember-ը, և սխալ հատկանիշին մատնանշելը սխալի փոխարեն դատարկ արդյունք է վերադարձնում։

Ընտրեք վերջնակետ, որը պարունակում է խմբի օբյեկտը

URL-ը որոշում է, թե որ գրացուցակից է հարցնում փլագինը, և 389 պորտի դոմենի կարգավորիչը պատասխանում է միայն իր անվանատարածքի համար։ 3268 պորտի գլոբալ կատալոգը պատասխանում է ամբողջ անտառի համար՝ միայն ընթերցման և մասնակի հատկանիշների հավաքածուով։ Երբ հաշիվները մի դոմենում են, իսկ VPN խումբը՝ մյուսում, միադոմեն հարցումը կարող է գտնել օգտվողին և այնուամենայնիվ բաց թողնել անդամությունը։ Սա այն դեպքն է, երբ URL-ը կատալոգի պորտ տեղափոխելը լուծում է մերժումը, և սա նաև այն դեպքն է, երբ մարդիկ չափից շատ են ընդհանրացնում։

Մասնակի հատկանիշների հավաքածուն սահմանն է՝ այն հատկանիշի վրա, որը կատալոգը չի պարունակում, հնարավոր չէ զտել, ուստի նույն փոփոխությունը կարող է մեկ տեղակայում աշխատեցնել, իսկ մյուսը դատարկ վերադարձնել։ Բլոկը վերաշարադրելուց առաջ հաստատեք, թե վերջնակետն իրականում ինչ է վերադարձնում իրական օգտվողի և խմբի համար։ Փոխանցումները և TLS-ը կրկին առանձին հարցեր են, քանի որ փոխանցմանը պետք է հետևել, և TLS պահանջող վերջնակետին անհրաժեշտ են համապատասխան վստահության ֆայլեր։

Հաշվի վիճակը և որոնման շրջանակը պահեք իրենց դաշտերում

Անջատման դրոշը պատկանում է զտիչին, ոչ թե խմբի ստուգմանը։ Active Directory-ում դա userAccountControl-ի երկրորդ բիթն է, և առանց այդ պայմանի վավեր գաղտնաբառով անջատված հաշիվը նույնականացվում է, ապա ձախողվում խմբի քայլում, ինչը լիազորման սխալի տպավորություն է թողնում։ Որոնման շրջանակը պատկանում է բազային DN-ին, քանի որ դոմենի արմատից սկսելը դանդաղ է և կարող է համընկնել այն կազմակերպչական միավորից դուրս գտնվող օբյեկտների հետ, որը ցանկանում էիք ծածկել։

Կապակցման հաշվի իրավունքները նույնպես նեղ պահեք։ Գրացուցակի լայն իրավունքները սխալ կարգավորված զտիչը դարձնում են հաջող հարցում և թաքցնում սխալը, մինչև ինչ-որ մեկը աուդիտի ենթարկի հաշիվը։ Անդամությունը փոխեք հենց գրացուցակում, երբեք՝ տեղական բացառությունների ցանկում, որպեսզի հաշիվն անջատելը բավարար լինի հասանելիությունը հեռացնելու համար։ Եթե խումբը կառավարում է մեկ այլ թիմ, նախապես պայմանավորվեք այն հատկանիշի շուրջ, որը նրանք լցնում են, մինչ դրա վրա զտիչ գրելը։

Ապացուցեք արդյունքը երեք հաշիվներով

Գործարկեք կոնֆիգուրացիան երեք ինքնության դեմ՝ թույլատրված անդամ, խմբից դուրս վավեր հաշիվ և անջատված հաշիվ։ Եթե բոլոր երեքը մերժվեն, կապակցումը կամ խմբի հարցումը կոտրված է՝ եթե բոլոր երեքը ընդունվեն, ընդհանրապես խմբի պայման չի կիրառվում։ Խառը արդյունքը միակն է, որն ապացուցում է, որ կոնֆիգուրացիան տարբերում է ձեզ համար կարևոր դեպքերը։

Նույն երեք պատասխանները կարդացեք անմիջապես գրացուցակից, նախքան փլագինին մեղադրելը։ Առաջին հարցումը ցույց է տալիս այն խմբի հատկանիշը, որից կախված է զտիչը, իսկ երկրորդը՝ հաշվի կառավարման արժեքը։ Փոխարինեք ձեր սեփական բազային DN-ով, հաշվով և վերջնակետով:

ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=alice)" memberOf
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=bob)" userAccountControl

Այն օգտվողը, ում memberOf-ը դատարկ է վերադառնում, գրացուցակի փաստ է, ոչ թե փլագինի սխալ, և այն հաշիվը, որը անջատվելուց հետո դեռ նույնականացվում է, նշանակում է, որ զտիչին պակասում է հաշվի կառավարման պայմանը։ Նախ ուղղեք այդ ապացույցը, ապա նորից գործարկեք երեք հաշվի թեստը։ Ձախողված քայլը նշող մատյանի տողը պահեք կոնֆիգուրացիայի փոփոխության կողքին, որպեսզի հաջորդ մարդը կարողանա լիազորումն անջատել նույնականացումից՝ առանց որոնումը կրկնելու։