ఖాతా సరైన సమూహంలో ఉంది, లాగిన్ విజయవంతమైంది, అయినా కనెక్షన్ తిరస్కరించబడుతుంది లేదా ఉపయోగకరమైన దాన్ని చేరుకోదు. సమూహాలు చేర్చడం టికెట్ అడిగిన దానికంటే ఎక్కువ ఇస్తుంది. సభ్యత్వం ఒక ఇన్’పుట్ మాత్రమే, నిర్ణయం కాదు: గేట్’వే వాస్తవాలను క్రమబద్ధ నీతితో సరిపోల్చి తర్వాత నిర్ణయిస్తుంది. మరో షరతు విఫలమైతే సమూహం మార్పు మీ బహిర్గతతను మాత్రమే మారుస్తుంది.

సమూహ సభ్యత్వం షరతు, అనుమతి కాదు

RADIUS లో సమూహం అనుమతి లక్షణంగా వస్తుంది, లక్షణాలు సెషన్‌ను వివరిస్తాయి, అనుమతి ఇవ్వవు. సర్వర్ Access-Accept లేదా Access-Reject తో సమాధానమిస్తుంది; అంగీకరించినప్పుడు Filter-Id, Class లేదా RFC 2868 టన్నెల్ లక్షణాలను జోడించవచ్చు. ఏదీ సమూహాన్ని పూర్తి ప్రవేశంగా మార్చదు; ఆ మ్యాపింగ్‌ను విధానం పెట్టిన వ్యక్తి రాస్తాడు.

అందుకే ఒకే సమూహ నామం రెండు వ్యవస్థల్లో వేరుగా ప్రవర్తిస్తుంది. Microsoft NPS షరతులు, పరిమితులు, సెట్టింగ్‌ల నుంచి విధానాలు నిర్మించి నిర్దిష్ట క్రమంలో అంచనా వేస్తుంది. OpenVPN Access Server కు సొంత నమూనా ఉంది, కమ్యూనిటీ సర్వర్ తరచుగా అన్నింటినీ client-connect లేదా client-config-dir కు అప్పగిస్తుంది.

సరిపోలిన నియమమే నిర్ణయిస్తుంది, మీరు ఊహించిన సమూహం కాదు

చాలా ఇంజిన్‌లు మొదటి సరిపోలే విధానం వద్ద లేదా అత్యంత నిర్దిష్టమైన దాని వద్ద ఆగుతాయి. విధానం 3 తిరస్కరించి విధానం 7 అనుమతిస్తే, దాటనిచ్చే నియమానికి చేరకముందే సెషన్ విఫలమవచ్చు.

సమూహంతో వచ్చే షరతులు మరో సగం: పరికర స్థితి, ప్రామాణీకరణ పద్ధతి, పూర్తయిన MFA, మూల నెట్‌వర్క్, సర్టిఫికెట్ విషయం లేదా సమయ విండో. ఒకటి తీరకపోతే విధానం సరిపోలదు, ఇంజిన్ పడిపోతుంది, డిఫాల్ట్ తిరస్కరణ వర్తిస్తుంది.

డైరెక్టరీ వివరాలు అదే భ్రమను సృష్టిస్తాయి. Windows సమూహ సభ్యత్వంపై సరిపోలే విధానం టోకెన్‌లోని SID లను చదువుతుంది, అక్కడ భద్రతా సమూహాలు మాత్రమే ఉంటాయి; పంపిణీ సమూహం ఎప్పుడూ కనిపించదు.

సమూహాన్ని తాకే ముందు ఆమోదం లేదా తిరస్కరణ నమోదు చదవండి

మొదట ఒక ప్రశ్న: అభ్యర్థన అనుమతి దశకు చేరిందా? NPS లో 6272 ఇచ్చిన ప్రవేశం, 6273 తిరస్కరణ, 6274 విధాన మూల్యాంకనానికి ముందు పారేయబడిన అభ్యర్థనను నమోదు చేస్తాయి. ఆ మూడు సంఖ్యలు సమస్యను మూడు దర్యాప్తులుగా విభజిస్తాయి, ఒకటి మాత్రమే సమూహాల గురించి.

What the record showsWhat it meansWhere to look next
6272, access grantedAuthentication and authorization both succeededRoutes, split tunnel, DNS, per-resource rules
6273, access deniedA policy matched and denied, or nothing matched and the default deniedThe conditions of the policy that fired, in order
6274, request discardedThe request never reached authorizationShared secret, NAS client entry, proxy chain, malformed attributes

నమోదు అందుబాటులో లేకపోతే సర్వర్‌ను నేరుగా అడిగి సమాధానం చదవండి. Filter-Id మరియు టన్నెల్ లక్షణాలు లేని సమాధానం అంటే సర్వర్ సెషన్‌ను సాధారణంగా భావిస్తుంది, గేట్’వే తన నియమాలను వాడుతుంది.

radtest alice 'password' 10.0.0.5 0 testing123

తిరిగి వచ్చిన లక్షణాలను గేట్’వే నమోదు చేసిన వాటితో పోల్చండి, సమూహ నామం సూచించే దానితో కాదు. అది విధాన సమస్యను అమలు సమస్య నుంచి వేరు చేస్తుంది.

సమూహ మార్పు వెనుకకు వర్తించదు

అనుమతి లక్షణాలు సెషన్ ధృవీకరణ సమయంలో ఒకసారి తిరిగి వస్తాయి. గేట్’వే వాటిని సెషన్‌పై ఉంచి ప్రతి ప్యాకెట్‌కు డైరెక్టరీని మళ్లీ చదవదు, అందుకే ఎవరినైనా సమూహం నుంచి తీసిన తర్వాత కూడా స్థాపిత సెషన్ కొనసాగుతుంది.

మార్పు అమలు కావడానికి కొత్త అనుమతి నిర్ణయం కావాలి, కొత్త కీలు మాత్రమే కాదు. సర్వర్ RFC 5176 కు మద్దతిస్తే UDP 3799 కు Disconnect-Request లేదా CoA-Request మళ్లీ మూల్యాంకనానికి బలవంతం చేస్తుంది; లేకపోతే క్లయింట్‌ను తెంచి మళ్లీ కనెక్ట్ కావడానికి అనుమతించండి.

షరతును సరిచేయండి, సమూహాన్ని కాదు

ఏ విధానం పనిచేసిందో తెలిస్తే మరమ్మతు సాధారణంగా చిన్నది: లక్ష్య అనుమతిని కప్పే తిరస్కరణను తిరిగి క్రమబద్ధీకరించండి, మిస్ అయిన పరికర లేదా MFA షరతును జోడించండి, లేదా ఒక వనరు కోసం సన్నని నియమం రాయండి.

చిన్న చక్రం మార్పును నిజాయితీగా ఉంచుతుంది:

  • అసలు ఖాతాతో తిరస్కరణను తిరిగి సృష్టించి, ఏదైనా మార్చే ముందు ఈవెంట్ ID రాయండి.
  • ఒకే వస్తువు మార్చండి: విధాన క్రమం, ఒక షరతు లేదా ఒక సమూహం; ఏదో రాయండి.
  • కొత్త సెషన్ తెరిచి, నమోదులో అనుమతి కనిపిస్తుందని, వనరు నిజంగా తెరుచుకుంటుందని నిర్ధారించండి.
  • ఇంకా తిరస్కరించాల్సిన వినియోగదారుని పరీక్షించండి, మరమ్మతు విధానాన్ని విస్తరించలేదని.

అనుమతి సరైనా వనరు తెరచుకోకపోతే, అనుమతి దాటిన క్షణంలోనే సమస్య రూటింగ్ లేదా నామ పరిష్కారానికి మారింది. ఆ రెండు లోపాలను వేరుగా ఉంచండి.

సంబంధిత వ్యాసాలు