Seriøst, Microsoft?

Jeg liker utfordringer. Det å sette opp tjenester og løsninger som er komplekse, og utfordrende å få til å fungere ordentlig er noe av det beste jeg vet. Sadisme vil kanskje noen kalle det, men nok om det.

SharePoint er en slik utfordring. Dette er et ubeskrivelig monster av en tjeneste, og det å installere, konfigurere og drifte dette er en utfordring av episke dimensjoner.

Jeg har driftet SharePoint en god stund allerede, 2013 utgaven for å være nøyaktig. Dette satte jeg opp for flere år siden, og for å få det til å fungere tok jeg en del skitne snarveier som å bruke en domeneadministratorkonto til å drive så godt som alt av tjenester, og å gi alt for mange kontoer full tilgang i SQL. Dette fungerer jo, men det fører også til at SharePoint konstant minner deg på at dette ikke er særlig god praksis, og ting går ofte i stykker.

Jeg bestemte meg derfor for å skrote hele 2013-installasjonen, og spinne opp en helt ny 2019-farm. Etter å ha laget tre virtuelle maskiner, alle med Windows Server 2019 Datacenter begynte jeg å installere de forskjellige komponentene. Den ene maskinen er en dedikert SQL-server, den andre er en backend for SharePoint, og den tredje er en Web-frontend og distribuert cache-server.

Greit nok, etter timesvis med prøving, feiling og pløying av obskure forum på nettet fikk jeg det hele til å kjøre slik det skulle. Noe av poenget med å lage en ny farm var, i tillegg til å oppgradere til den nyeste utgaven å implementere pålogging via ADFS på en ordentlig måte. Dette skulle vise seg å være litt av et helvete.

Det er i grove trekk to måter å oppnå ADFS-godkjenning for Sharepoint på. En kan bruke «Non-claims aware», eller «Claims-aware». Den tidligere farmen brukte «Non-Claims Aware», og dette er helt klart den enkleste måten å gjøre det på. Det eneste som må til er å sette opp en relaying party trust på ADFS, og deretter aktivere Kerberos-godkjenning for webapplikasjonene i Sharepoint. Bakdelen derimot er at dette gjør at det blir umulig å logge ut uten å slette informasjonskapsler i nettleseren, eller vente til godkjenningen utløper. Derfor valgte jeg «Claims Aware» på den nye farmen.

Dette er teoretisk «fullt støttet» av Microsoft, og det finnes ganske mye dokumentasjon på hvordan dette gjøres. Det involverer en del Powershell, men er i og for seg ganske «enkelt». Det som derimot ikke er enkelt er å bruke Sharepoint etter at dette er satt opp. Gjenkjenning av brukere blir ødelagt, brukervelger blir ødelagt og godkjenner hva som helst, søk slutter å fungere og utlogging fungerer fortsatt ikke. Dette er kjente utfordringer, og det har vært slik helt fra tidenes morgen. Det som er helt forbannet utrolig er at Microsoft ikke har løftet så mye som en finger for å løse utfordringene. Det finnes heller nesten ingen dokumentasjon, annet en diverse Tecnet-artikler som egentlig ikke sier annet enn at «ja, det stemmer. Dette fungerer ikke, vi vet om det, og vi har ingen løsning».

Etter å ha trålet diskusjonsforumer andre steder enn hos Microsoft fant jeg imidlertid løsninger på en del av problemene. En Sharepoint-utvidelse utviklet av en tredjepart finnes for å fikse problemene med brukergjenkjenning og «people picker». Etter å ha installert denne, og konfigurert den fungerte gjenkjenningen av brukere igjen, og det ble mulig å finne frem til brukere for å dele områder, dokumenter og lignende igjen. Neste utfordring er utloggingen. Dette finnes det heller ingen dokumentasjon for hos Microsoft. Det er Microsoft som lager både ADFS og Sharepoint, og dette er elegant integrert i tjenester som for eksempel Exchange Server, men for Sharepoint er historien en helt annen. Det er faenmeg helt utrolig. ADFS-pålogging er så vidt jeg kan forstå den mest vanlige metoden for pålogging, men likevel velger Microsoft å gjøre dette til et ustabilt helvete av tull de ikke støtter fult ut. Dypt nede i et forum var jeg heldig og kom over en Powershellkommando en kan bruke for å sette en variabel for URLen til utloggingslenken i Sharepoint slik at denne pekte til ADFS, og ikke til standardsiden i Sharepoint. Dette krevde også masse prøving og feiling, for URLen som skulle brukes var oppgitt til en helt annet enn den som faktisk endte opp med å fungere til slutt.

Neste utfordring, dette kanskje den største av alle var kravlesøkene. Disse er et helvete å få til å fungere i utgangspunktet, og det blir ikke bedre av at søkeroboten i Sharepoint ikke (!) har støtte for ADFS-pålogging. Løsningen på dette fra Microsoft var å utvide webapplikasjonen man ønsket å kravlesøke, og aktivere NTLM-godkjenning for denne. Ok, kravlesøket fungerer igjen, men det gjør ikke lenkene i resultatene søket leverer. Dokumenter, bilder og andre ting søket finner lenker nå til innhold på den utvidede webapplikasjonen, og ikke på den primære. Det vil si at hvis du søker på Hei.docx fra den primære webapplikasjonen er dette dokumentet blitt indeksert av den utvidede. Primær og utvidet har forskjellige URLer, f.eks sp2, og sp1. Dette betyr at når du klikker på et resultat, blir du sendt til feil URL, og denne har ikke ADFS-godkjenning, antageligvis er den ikke tilgjengelig eksternt, og ingenting fungerer. Dette er Microsoft klare over, det har nemlig gjort brukere forbannet helt siden Sharepoint 2010. En løsning en supportmedarbeider hadde foreslått i et forum på Technet var å aktivere både kravbasert (ADFS) og NTLM-godkjenning på den primære webapplikasjonen. Dette fungerer, men det fører også til at en må velge påloggingsmetode etter at en har logget på med ADFS. Velger en feil her, hvilket er ekstremt enkelt å gjøre, aner ikke Sharepoint hvilken bruker som har logget på, og ting går i stykker enda en gang. Heller ikke dette har Microsoft noen løsning for. Etter å ha gjort enda et dypdykk i søkeresultatene hos min gode venn Google fant jeg til slutt en kommentar under et blogginnlegg om problemet. En bruker hadde skrevet en egen DLL som omgikk godkjenningsvelgeren etter pålogging, og sendte brukeren direkte til den korrekte siden akkurat som om det kun skulle være kravbasert godkjenning som var aktivert. Jeg kjente at piffen gikk ut av meg, å skrive en egen DLL er langt utenfor mitt kompetanseområde, og jeg var i ferd med å gi opp.

Dagen etter bestemte jeg meg for å gjøre et nytt forsøk. Jeg trålet nettet i timevis, og plutselig fant jeg 3 linjer med tekst i et forum som så lovende ut. Dette gikk ut på å gjøre som Microsoft hadde foreslått, nemlig å aktivere påde NTLM og kravbasert(ADFS)-godkjenning på webapplikasjonen. I tillegg til dette skulle en i IIS legge inn en redirect fra den virtuelle mappen /_login/ og direkte til /_Trust/Default.aspx. Dette skulle gjøre at godkjenningsvelgeren ble omgått, og sender brukerne rett til riktig side akkurat som den egenskrevede DLL-en som ble foreslått i et annet innlegg. Vill av forventning prøvde jeg dette, og etter en del prøving og feiling fikk jeg det til å fungere. Løsningen tok (etter prøving og feiling) ca 2 minutter å implementere, og den fungerte utmerket. Hvorfor i helvete kan ikke Microsoft dokumentere og opplyse om slikt som dette? Hvorfor er integreringen mellom de forskjellige produktene så elendig?

Skjerp dere Microsoft, dette er for faen for dårlig.

Skribent: SnurreSprett

29 år gammel elektriker som har en lidenskap for serverdrift, nettverk, IoT, dingser, smarthus og alt mulig annet nerdeopplegg.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *