• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

vFrank

Essense of virtualization

  • LinkedIn
  • RSS
  • Twitter

SSO

vCenter er nede, hvad gør du?

November 3, 2017 by FrankBrix Leave a Comment

Hvad ville du gøre hvis dit vCenter blev utilgængeligt i morgen og hvilken indflydelse ville det have på din forretning? Svarene falder typisk i to kategorier:

  • Mit vCenter er ikke kritisk for min produktion og hvis det er nede installere jeg blot et nyt og forbinder det til mine ESXi servere.
  • KRISE! Hvis mit vCenter er nede er der ikke self-service, overvågning og styring af de virtuelle resourser. Jeg er på dybt vand!

Det er er en gammel kendt udfordring i et hvert datacenter. Hvordan beskytter man sin VMware mangement stack og får den hurtigt online igen med en lav RTO. VMware udvider sine management produkter. Hvor man tidligere kunne nøjes med en enkelt vCenter server består de fleste miljøer af adskillige servere til håndtere den daglige drift og rutiner. Den er i dag udbygget til:

  • vCenter (med intern eller ekstern database)
  • vRealize Operations Manager
  • vRealize Automation Center
  • vReaize Log Insight
  • NSX Manager
  • PSC (platform services controllers)
  • SDDC (VMware Cloud Foundation)
  • Management AD og DNS

Udover disse VMware services er der også flere administrative servere som IT afdelingen er afhængige af som kan tilføjes som kritiske komponenter til en disaster plan. Med det Software Defined Data Center er det ikke som tidligere hvor vCenter var “nice-to-have” – er det nu blevet til en kritisk funktion der altid skal være online. Hvis vCenter er nede skaber det problemer for ting som

  • Selv-provisionering af nye virtuelle maskiner
  • Overvågning
  • 3′ parts produkter der kommunikerer med vCenter

I et tilfælde hvor der er nedbrud eller datatab på management stacken er man ilde stedt. Hvordan bringer man stacken online når vCenter og evt. management AD og DNS er nede? Er din platform til beskyttelse 100% uafhængig af dem? Med stor kompleksitet er det muligt at bygge et system med traditional software som kan håndtere dette. Men hvordan tester man det? Hvordan sikrer man at alle windows servere benytter lokale service accounts og ikke AD konti? På hvilken måde kompromittere dette sikkerheden? Hvad med faren for Ransomware når traditional software kører på Windows og i værste tilfælde bliver backup data kryptereret og utilgængelig?

Til at løse dette er der behov for at se på problemet med friske øjne. Der er behov for en løsning der opfylder følgende

  • Baserer sig ikke på Windows og backup data er immutable
  • Har ingen afhængigheder af AD og DNS
  • Kan benyttes selvom vCenter er utilgængelig
  • Kan udføre en Instant-Mass-Restore og bringe ALLE administrative servere online med det samme og som en gruppe.
  • Simpel og alt inkluderet i et system (ikke 4-5 forskellige produkter og producenter)
  • Ingen single point of failures.

Hos Cohesity løser vi dette elegant og din management stack er beskyttet og muligt at lave recovery på få sekunder. De unikke funktioner ved Cohesity:

  • Policy baseret beskyttelse
  • Alt-i-et-system (de-dupe storage, backup software, databaser, always-online, fuld HA for alle komponenter software og hardware.)
  • Instant-Mass-Restore: Recovery af 5 eller 50 maskiner på få sekunder
  • SnapTree: Alle backup punkter er fully hydrated og instant-recoverable. Ingen baggrunds IO operationer for at lave syntetiske fulls
  • Test/Dev: Mulighed for at teste recovery når som helst og validere det virker

Hvis du ønsker at få en demo at dette i dit eget datacenter så tag kontakt.

Hvis du vil læse mere om hvordan Cohesity beskytter den fulde VMware Management Stack inklusive cloud foundation så læs mere her:

http://www.cohesity.com/vmware-cloud-foundation-vcf-cohesity-white-paper/

Video Demonstration:

https://www.youtube.com/watch?v=jtAoCi4HcX4

Filed Under: certification, Cohesity, Network, PernixData, SSO, Uncategorized, vCloud, vcops, View, vMotion, vSphere

How to log in to Single Sign ON SSO in vSphere 5.5

September 23, 2013 by FrankBrix 9 Comments

I just installed vSphere 5.5 in my lab. It was a fresh installation. Not an upgrade. My vCenter server was already in my domain and I expected to be able to log in with my domain administrator account. Unfortunately it was not the case. To solve the issue I wanted to log in with the vSphere Web Client to validate my permissions and that my domain vclass.local was an identity source. In vSphere 5.1 the SSO administrator was called [email protected] this is no longer the case. You need to log in with [email protected] and the password you defined under installation of the SSO server. When I logged in with this user I was able to configure my domain as an identity source and give access to my domain administrator to the vCenter Server.

You can access the vCenter Web Client on the following url: https://WEBCLIENTSERVER:9443/vsphere-client

SSO55

Another thing I noticed was that the [email protected] was administrator on the vcenter. In 5.1 [email protected] did not have any vCenter permissions set.

vpsherelocal

Always remember. The only place to configure the SSO is through the Web Client. Luckily VMware really want to bring the attention out to the administrators. When you log in with your vSphere Client in a 5.5 environment you will be presented with the following warning

loginwarning

 

Filed Under: SSO, vSphere Tagged With: Log in, password, SSO

vCenter: Cannot complete login due to an incorrect user name or password

September 20, 2013 by FrankBrix 5 Comments

After upgrading to vSphere 5.1 or installing from scratch you may be in a situation where you cannot authenticate with your vCenter Server when using a domain user.

When you try to log in from the vSphere client you get the following error: Cannot complete login due to an incorrect user name or password 

When you try to log in from the the vSphere Web Client you get the following error: Provided credentials are not valid

SSO1   

SSO2

 

Prior to vSphere 5.1 and the Single Sign On Server SSO you were able to login directly with your domain user without supplying the domain name. 

There are two solutions to the problem.

Solution 1:

When logging in with your domain account add the domain to the user name. You can do this by either writing: DOMAIN\USERNAME or [email protected] the result will be the same. 

Perhaps you don’t feel this is the right solution for you. You may only have one domain so why should you always write the domain in the log in box. If this is the case see solution 2.

Solution 2:

What you are able to do with SSO and vSphere 5.1 is to add your DOMAIN to the default domain list. you can only accomplish this from the vSphere Web Client. What you need to do is log in to with the user name [email protected] and the password defined for this user during installation. Then you go to “Home” – “Administration” – “Single sign-on and discovery” – Configuration. In the identity source window you select your domain and press the “add to default domains” button. If your domain is not present, then you need to add it. You can also add multiple other domains. After adding the domain to the list you then make sure that it is on top of the list in the “Default domains” window. And at the end you press the “Save” button.

 SSO3

By doing this you should now be able to log in without supplying your domain name in the vSphere Client or vSphere Web Client.

Filed Under: SSO, vSphere Tagged With: cannot, domain, error, SSO, vcenter, vsphere

Primary Sidebar

Blogroll

  • Hazenet
  • Michael Ryom
  • Perfect Cloud
  • vTerkel

Copyright © 2023 · News Pro on Genesis Framework · WordPress · Log in