Operations Manager – Cannot generate SSPI context

Lately, I was playing with Systems Center Operations Manager (SCOM) 2007 R2 (OpsMgr). I have used MOC environment as a playground, which means that I’ve installed SCOM database on the SQL machine and SCOM RMS on the separate machine myself. Not a big deal to click through with "Next" through the setup.

Now, the things went completelly wrong. Even though initially the console seemed to be working, after some time it just stopped – froze, couldn’t reconnect. I checked the event log and it was full of messages "Cannot generate SSPI context" from various sources including System Center Data Access. What was interesting that restart of the service[s] often resolved problem for certain period of time, but then again – shit was hitting the fan. Of course, one can realize – it just can’t be that plain install could go that wrong, so I’ve started my little investigation.

The error message "Cannot generate SSPI context" immediatelly bings to KB811889. It is comprehensive article that … well, maybe because I was once a manager, I cannot read and then understand if the meaningful content is more than paragraph Smile Anyway, I had to check all the things, because the issue was obviously related to Kerberos and Authentication.

I allowed the SQL service account (I’ve created one in AD) to automatically register SQL SPN (see the KB article on how to do that). After, I verified it, and indeed there was a registration of MSSQLSvc/SQL.OMLab.com:1433 SPN associated with the account. To verify that just lauch ADSI editor, find the account and see if there is a servicePrincipalName attribute on that account. After the SQL SPN registration was there, some of the errors were gone (e.g. Console would connect normally), however – not all of them.

When I tried to create Channel for the notifications – it just plainly refused to that with the same "SSPI context" issue. And that one was "stable". Now two sentences in the KB got my special attention: "For example, the invalid SPNs that the client-side SQL Server driver can form as resolved fully qualified DNS are: MSSQLSvc/SQLSERVER1:1433, …", "If the SSPI interface does not find the SPN, Kerberos authentication is not performed".

Just to check if the "invalid" SPN could be the source of the problem, I went to ADSI Editor, opened properties for the SQL Service account and added MSSQLSvc/SQL:1433 SPN to the servicePrincipalName attribute, restart SQL Server. And indeed, after that I could create channel. Interestingly though, the "SSPI context" error messages with random stack traces were still appearing in the event log.

Why – is the question here. I turned back to the beginning: installation. I’ve checked install logs for the name of the SQL Server that I’ve provided. Well, I wrote simply "SQL" there. Not good for Kerberos though. Quick check on "HKLMSoftwareMicrosoftMicrosoft Operations Manager3.0Setup" for the DatabaseServerName value – it was "SQL". This is again bad for Kerberos, so I’ve changed the value to SQL.OMLab.com (FQDN) and restarted the OpsMgr RMS server.

Verdict: "Cannot generate SSPI context" – gone. I like nice and blue event log and I didn’t had to use tools from sysinternals Winking smile

Stuff to read [3]

  • Often smart things are simple ones or another way for checking for nulls. Check here
  • Calling a service bus HTTP Endpoint with Authentication using WebClient – here
  • Discounted $10 today (09/13/2010) for a book Pro OpenSolaris is available here. Is it still used? According the netcraft.net – not much anymore
  • Checking if remote (HTTP) file exists – here
  • Design-Time friendly ViewModels with MEF – here

Linksys (or Cisco)–how about fixing sites?

Ok, recently I upgraded my home DSL (10Mbit at best) connection to FTTH. Yes, I’ve joined the leading army of Lithuanian FTTH users and I have fiber cable in my room. I must say 100Mbit (40Mbit abroad) – that’s something I love. I have to mention that I’m planning to upgrade to 200Mbit service this year, because 2x increase in speed will increase spending only by 25% and will be something ~29Eur/month, which is fairly reasonable for me.

As I’ve got the FTTH, I needed to change the router. As I’m planning to upgrade later to 200Mbit plan, so I’ve decided not to invest in a heavy-weight router now and decided to buy something of the shelf. I found pretty cheap and already fairly old model Linksys WRT160Nv2 and bought it. As I’m used to Linksys routers – so the setup was fast and initially everything seemed to be ok, except the speed reduction (which was expected, ’cause this particular router can make at best 80Mbit according the tests).

However the bad things started, when connected everything to that router: work laptop, home laptop, netbook, home server and xbox – the router started loosing packets, time-out with DNS requests, etc. – in other words bad things started to happen. It was obvious – a router fault. Looking at the firmware – the obvious thing pops right into eyes – 2 years old firmware, probably crappy one.

And here it comes – I went to the linksys.com support site to look for the newer firmware, selected model (WRT160N version 2), etc. and what I’ve got? The same old firmware. That can’t be true. I’ve started binging the internet and landed into bunch of forums (including the ones from Cisco), which just confirmed what I’ve seen – a faulty firmware and that linksys/cisco were not very much helpful about solving the issue for whatever reasons. What else I’ve seen on those that there were other versions of firmware, but the links were pointing to some "not very trustworth sites" until I’ve found a link to a cisco site for home users. Yes, that one contained updated version of firmware, which seems to be working ok for now.

You may ask, so what’s the problem? Well, the problem is that after the cisco bought linksys – they kept the site dead (content not updated), but alive (still there and even has Cisco logo). In many cases for the product support I type <manufacturer><.com> and in this case it just plainly #fail.

Dear Cisco, please either kill the linksys.com and redirect it to the appropriate cisco site or update the content accordingly.

Security: smartphone as a credit card replacement

I’ve been reading lately in local and international (also here) press about replacing credit and debit cards with the smartphones. On one hand idea seems to be very attractive, however this means that the security on the mobile devices will have to be tightened much more than it is today.

Today many people do not care much about the features, software and settings on the mobile phones, which leaves them vulnerable in one or another way.

As the mobile smartphones become more and more popular, they will definitelly gain attention from malicious and criminal space and with the intentions of banks to handle payments using smartphones – the attraction will be even higher.

In case of bank cards, responsibilities in case of the incidents is pretty much clear, because banks must take responsibility for all infrastructure from card to the bank back-end system. If mobile phone is used, I’m pretty sure that banks will try to get rid of some responsibilities and move those to the user space as they have done with e-banking. While there is a lot of effort and resources devoted in order to fight back digital crime in PC space: antivirus, automated OS security updates, automated application updates, phishing prevention in browsers – there is only a little effort in the security area of mobile devices.

So, will mobile devices be accepted as tools for making payments? Probably will because of the pricing and convenience, as the e-banking does now.

Should we pay more attention to the security of the smartphones and the respective payment related infrastructure? Sure yes.

Live vs. Google for small businesses

Yes, "I am trying to be a good Microsoft citizen" and you can say that I’m biased and this is yet another marketing campaign, however it is not. If you ask me, my personal opinion in the area of e-mail, documents and sharing information will be simple: Live rocks & Google … lets say is not that good Smile.

This started, when one of my friends (he’s an IT guy, who supports small businesses) said that he moved someone’s mail to google, because: it is available, free and is accessible via web. Hey, c’mon, have you considered all options and pros/cons of those options?

First things first: you can move your domain to live as well and have e-mail there (yeah, the hotmail one). Comparing just the e-mail options, I’d say they are either comparable or (to my experience) Live is even better:

  • Both are catching SPAM good, however the Live SPAM box is either empty or with just few message to check for – I like this approach.
  • Both are providing vast space for your e-mail. While at this moment gmail claims that I have some 7+GB of storage, Live mail gives you more than enough storage to keep your e-mails as long as you play nicely
  • Both have flagging, quick views, contacts, calendars, etc.

Now there comes another part into the play: creating & sharing information – yes, documents. And this point I’d say today Microsoft is beating Goo very hard.

  • First you can use Live Skydrive to create & store office documents, pictures (well, whatever legal) and it is 25GB of storage separate from e-mail. Nice. Far more than additional 2GB in total from Google
  • And yes, office web apps available for personal use for free in skydrive, which is almost too good to be true, but it is
  • Why office web apps are better than Gdocs? Well, take a look and there are more things. I mean creating, editing, sharing – works and it works both on your desktop and on the web pretty much the same way. You can check my old presentation online.
  • Look and feel is the same – I love it. Microsoft is keeping its promise to provide the same services for businesses and consumers, multiple device types.

To summarize, if I would start small business now in Lithuania, I’d probably go for Live services, because I think it is better option at the moment.

Kindle Wireles 3G in Lithuania

I bought Kindle DX and Kindle 2 February this year (2010). The only way I could purchase and download the books, was to do it through computer. Though it was OK, still it was suboptimal. Last week I’ve requested some information from our local GSM operators regarding the situation with Amazon.com & Kindle 3G (see special blog post).

This week some strange things started to happen:

  • First, a friend of mine reported that @AmazonKindle claims that 3G is working in Lithuania
  • In fact, if you go now (2010.08.03 00:00+0300 Smile) and view country specific information for Lithuania – it sais:

image

However, on the GSM map – the situation is following:

image

As you can see – Lithuania is purely white, which means – no coverage. At the same time my Kindle DX doesn’t find any network.

So, dear Amazon, please verify the information before publishing it and please – work with AT&T and local operators (it seems that Bite will be the one providing service) to make the service available.

Customer service: Bite vs. Omnitel

[Translation of the previous blog post]

Because I’m an owner of Amazon Kindle, actually I have both – Kindle 2 and Kindle DX, I was curious why we don’t have 3G on Kindle. The same question was raised by my colleagues, friends, which have or plan to buy Kindle. Strange indeed, when mobile penetration in Lithuania is ~150%, which means ~1.5 mobile phone per person, and we are FTTH leaders worldwide – cannot receive simple service. According the numbers it seems that we are gadget/geek country, and when one person has ~1,5 mobile phone – selling voice plans is most probably a hard business. It seems that one should think about delivering additional data services. Kindle data services could be one of those, but it isn’t.

On this occasion I’ve sent an e-mail to info@ addresses indicated on Bite and Omnitel respective pages, and pointed out, that I am planning to disclose the answers on my blog (which I’m doing right now). Questions were simple:

  • Why it is impossible to use 3G on Kindle devices?
  • Do you plan to agree with Amazon and provide the ability to use all device benefits?
  • When it will happen?

It didn’t take a while to receive the response.

Omnitel "admin" responded with the message of the following content: "We do not plan selling these devices, therefore we do not plan providing any support". Talking about customer service it is to put it mildly double rubbish:

  • The response itself is nonsense. How device sales are related? I can buy it from Amazon without help from Omnitel. Aren’t they interested in potential revenue for data services, especially when the logistics here is minimal. After such answer you feel like hit with the soppy cloth straight into the face. Maybe they didn’t understand? They could clarify. Maybe they are planning to sell iPad’s, but I’m not asking about those. And by the way, I’m not planning to read books on a computer screen. And also, there are rumors, that one of the popular programs on the iPad is – Kindle Reader Smile
  • The answer from "admin" also isn’t promising a lot. First of all – source is almost anonymous, i.e. you never learn who is he and what is his role in the company. And of course no chances to discuss the question in more detail. All internet is buzzing that the communication with customers must be more interactive and personal, then this case is total opposite of that.

The response from Bite was a double surprise. First of all, I’ve received a phone call from Raminta, company’s representative for public relations (PR Smile). I think, it was right, because I wrote in my e-mail that it will go public. During the call she was interested how urgent is my query. Just few hours later I got e-mail with the response (approximate translation follows):

"We are negotiating with Amazon.com service provider AT&T regarding Kindle service already for a long while, but because a small customer number and market potential all negotiation attempts were vain.

We continue to persist and hope that this service will be accessible to our clients"

Immediately you can see several differences:

  • Communication is personal and immediate
  • PR representative sorted out situation and responded adequately
  • Response was comprehensive and adequate. It doesn’t mean that I’m happy with the situation, but knowing the fact that Kindle users are not forgotten – is at least not disappointing

Summarizing:

  • Omnitel #FAIL (somehow nothing new)
  • AT&T #FAIL (again, as always)

Lietuvos e-valdžios … (ne)”sėkmės” arba kaip lengva susimauti [LT]

Pastaba: žemiau išdėstytos mintys yra mano asmeninės ir niekaip neatspindi mano darbdavio nuomonės ar pozicijos.

Paprastai rašau mintis angliškai ir paprastai į valstybines nesąmones daug dėmesio nekreipiu, bet šį kartą perskaitęs straipsnius delfi.lt ir critical.lt apie mūsų e-valdžios portalo savybes – negaliu susilaikyti, nes tokių nesąmonių jau senokai nesu matęs. Susidaro įspūdis, kad grupelė mėgėjų susirinko ir padarė kažką …

Pradžiai – ačiū critical.lt žmonėms, už jų skirtą laiką ir pastangas, nes priešingu atveju šitas reikalas galėjo baigtis kur kas blogiau, o IVPK teiginiai, kad “norint pasinaudoti šia spraga būtina aukšta kompetencija” neatitinka tikrovės, nes paleisti fiddler ar kokią kitą priemonę tikrai nereikia didelių sugebėjimų.

Toliau tiesiog noriu surašyti keletą savo pastebėjimų, kurie mane stebina tiek, kad nesuprantu kaip į Lietuvą atėjo Barclays, taigi – apie viską iš eilės. Savo pastebėjimus paremsiu tik viešai prieinama informacija, kuriai peržiūrėti skyriau 15-20 minučių, o potencialios rizikos vertinimą – “Defense in Depth” principais ir STRIDE (Spoofing, Tampering, Repudiation, Denial of Service, Elevation of Privilege) klasifikavimu.

  • Pačių išduotas sertifikatas duomenų autentiškumui nustatyti

Pasižiūrime į nuorodą esančią šalia “VAIISIS sertifikatas perduodamų autentifikavimo duomenų parašo tikrinimui” ir kaip teisingai pastebėjo critical.lt komentatorius – ten yra įdėtas sertifikatas (viešas raktas), pagal kurį autentifikavimo paslaugos naudotojai turėtų tikrinti ar duomenys autentiški (VAIISIS). Jeigu atkreipti dėmesį į jo turinį, buvo nueita kvailiausiu pigiausiu keliu. Tiekėjas pats sugeneravo sertifikatą (privataus viešo rakto porą) ir viskas, tačiau neįdėjo jokių priemonių kaip apsisaugoti nuo to atvejo, jei privatus raktas turėtų būti paskelbtas negaliojantis (tapo viešas, buvo pavogtas, ir t.t.). Be to, 1K raktas šiais laikais artėja prie ribos, o galiojimas – penkiems metams.

Normaliu atveju, PKI (viešo rakto infrastruktūra) aplinkoje CA (sertifikavimo tarnyba) ne tik išduoda sertifikatą, bet ir užtikrina papildomas paslaugas, bent jau CRL (sertifikatų atšaukimo sąrašų) publikavimą (dar gali būti OCSP – Online Certificate Status Protocol realizacija). Negaliu komentuoti dėl Java ar kitų bibliotekų/platformų, bet bent jau .Net Framework/Windows platformos atveju sertifikato galiojimas yra “auto-magiškai” Smile tikrinamas pagal jame (CRL distribution points papildyme) įrašytą informaciją.

Dabar gi, paslaugos tiekėjas turės matyt telefonu informuoti visus autentifikavimo paslaugos naudotojus, kad pateiktas viešas raktas nebūtų naudojamas tikrinimui, tačiau tai nebus užtikrinama techninėmis priemonėmis. O ten jau kaip gausis – programuotojas pakeis arba ne.

Prielaida

Įtariu, kad privatus raktas tiesiog “padėtas” failinėje sistemoje ar panašiai – apsaugant slaptažodžiais ir programinėmis priemonėmis (kaip buvo kūrimo metu, taip ir liko), o tai jau rimta problema, nes šis raktas autentifikavimo/pasitikėjimo procese yra kritinis, o minėtos priemonės tikrai nėra pakankamos.

Tokio sprendimo pasekmė – ypatingai didelė spoofing, repudiation, information disclosure, tampering, elevation of privilege rizika.

  • (Ne)standartai prieš suderinamumą

Skaitome išorinio komponento prijungimo prie VAISIS rekomendacijas ir randame štai tokį parašymą: “Metodų gražinamų pranešimų formate turi atsirasti vieningi laukai, skirti klaidų informacijai gražinti (laukų pavadinimai: error_code, error_id, error_message);”, nors dar prieš tai parašyta, kad viskas turi atitikti WS-I, bei SOAP 1.1. Gaunasi, kad jei aš noriu prijungti savo paslaugas prie VAIISIS – tai dėl kažkieno sugalvoto pseudo-standarto aš esu priverstas keisti savo paslaugų logiką? Nors truputį daugiau susidūrę su web servisais žmonės žino, kad SOAP turi numatytą mechanizmą klaidų informacijos perdavimui – SOAP fault, kuriame tokie dalykai kaip faultcode, faultactor, details, faultstring. Tai kam reikėjo “išradinėti” tuos error…? Nejaugi universitete žmonių nemokė apie esybių/logikos/etc. atskyrimą? Mano nuomone – pasiūlytas sprendimas yra blogiau nei studento lygyje. Gerai, kad čia tik rekomendacija ir kaip taisyklė – jų galima nesilaikyti Smile

Tame pačiame dokumente minimas ir WS-S arba WS-Security ir šioje vietoje iškart užkliūva tai, jog anksčiau critical.lt minėtas autentifikavimo mechanizmas pagal aprašymą yra visiškai nestandartinis sprendimas. IT industrijoje jau kuris laikas taikomi standartai būtent šiems paskirstyto autentifikavimo scenarijams:

  • WS-Federation
  • WS-Trust
  • SAML ir netgi specialiai valstybiniam scenarijui taikomas eGov profilis

WS-Federation, bei WS-Trust protokolai paremti tuo pačiu WS-Security. Tuo pat metu tiek komercinės programinės įrangos gamintojai tokie kaip Microsoft (ADFS v2), BEA/Oracle, IBM, ir t.t., tiek nemokamos programinės įrangos kūrėjai (pvz.: Shibboleth) kuria programinę įrangą palaikančią minėtus standartus. Savo ruožtu tai reiškia šiokį-tokį tarpusavio suderinamumą ir galimybę integruoti įvairias sistemas ir aplinkas tarpusavyje atliekant konfigūracijos pakeitimus.

Duotu atveju tiekėjo pasirinkto sprendimo rezultatai akivaizdūs:

  • Dokumente numatytas tik vienas autentifikavimo scenarijus, tačiau visiškai nenumatytas išsijungimo scenarijus, nekalbant apie scenarijus, kai klientas naudojasi ne web programa.
  • Kiekvienai organizacijai reikės realizuoti nestandartinį sprendimą arba plėsti atitinkamų produktų galimybes. Na, tam tikra prasme man tai patinka – be darbo neliksiu, tačiau iš įmonių ir organizacijų pozicijos – tai jau vertimas realizuoti skirtingus sprendimus tam pačiam poreikiui patenkinti.
  • Na ir pabaigai – priemonės apsaugo nuo elementarių programavimo (susijusio su saugumu) klaidų. WS-Security pagal nutylėjimą įtraukia time stamp’ą į pranešimą (pastebėjimas – tai vyksta WS-S protokolo lygyje), nustatant autentifikavimą sertifikatu – pranešimas bus tinkamai pasirašomas atitinkamai ir bent jau kai kurių produktų/paketų atveju reikalaujama, kad pasirašymui naudojamas sertifikatas turėtų įrašytą CRL nuorodą. Kitaip tariant šiuo atveju tiekėjas bandė išrasti dviratį ir išrado jį labai blogai.

Reikia pabrėžti, kad standartinių produktų/bibliotekų naudojimas neapsaugo nuo saugumo klaidų arba potencialių problemų (žr. pavyzdį toliau), tačiau bent jau neleistų daryti visiškų nesąmonių.

  • “Vidiniai niuansėliai”

Žiūrime į architektūros dokumento 31-ą puslapį ir matome autentifikavimo faktų lentelės aprašymą. Iš pirmo žvilgsnio gali pasirodyti, kad viskas gerai – yra duomenų bazėje lentelė, kurioje įrašoma audito informacija, tačiau yra viena nedidelė problema: lentelėje akivaizdžiai nėra jokios apsaugos nuo Tampering ir Repudiation. Kitaip tariant, gavus prieigą prie minėtos DB lentelės (pasinaudojant programinės įrangos, OS arba DB klaidomis, socialine inžinerija ir t.t.) galima pridėti arba panaikinti reikiamus įrašus praktiškai nepaliekant jokios galimybės tai aptikti. Aišku, aš labai tikiuosi, kad bent jau “SQL injection” skylių ten nėra ir teisės į lenteles sudėtos atitinkamai, kas sumažina riziką, tačiau kaip tokiam valstybiniam sprendimui – nepakanka.

Kaip minėjau – aš informacijos peržiūrai skyriau 15 minučių, o straipsnio parašymui – truputį daugiau Smile. Įdomu, kiek dar niuansų galima būtų rasti sprendime atlikus paprastą rizikų modeliavimą.

Apibendrinant galima pasakyti tiek – paskirstytas autentifikavimas, valstybės paslaugų portalai yra ne juokas ir “studentiškai”/“ant snarglių” neturėtų būti daromi. Reikia suprasti ir probleminę sritį, jos niuansus, galimus scenarijus, pasauliniu mastu taikomus sprendimus ir tik tada kurti pagrįstą sprendimą.

Kad išvengti komentarų šiukšlių dienoraštyje – jų lauksiu elektroniniu paštu: vardas et karštas paštas taškas kom. Rimtus komentarus (jei tokių bus) planuoju apibendrinti ir įdėti atskiroje žinutėje.