@john.c Thanks for the suggestion - I'm exploring this option.

@Davidj-0 Thanks for the admonition. I was more concerned about the single point of failure that seems to be inherent with the plugin only allowing a single LDAP/AD server to be specified. As I mentioned to @pdonias , most of our environments (and in my lab) are setup with at least 2 domain controllers, where the Windows systems already leverage them natively.

For the Linux systems we have, which are integrated into AD using SSSD, there's the DNS lookups that happen which essentially protects against the kind of failure I experienced in the lab (where someone accidentally disabled the NIC on the DC that happened to be configured in the LDAP Plugin in XO). Even though the DC was still reachable over it's management interface, authentication into XO was now broken until I discovered it.

@pdonias Essentially, yes.

Every application I've used that authenticates with AD/LDAP seems to allow the specification of at least two servers, so that if the first doesn't respond, the second is tried. In almost all the environments that I work in, there are at least two Domain Controllers. So it stands to reason, at least to me, that XO should give the administrator the choice of deciding whether to leverage all DCs or a single one.

Normally the current implementation hasn't been a problem, until it was. I noticed this when one of my network guys accidentally disabled the NIC on the DC while attempting to add a management interface to the DC. Grant it, this is a lab environment and we're playing around a lot, but I thought this exercise highlighted a single point of failure so wanted to inquire if it were possible to specify more than one server.

Thanks for your response, much appreciated.

Good-day Folks,

Is it possible to specify more than one server when configuring the LDAP plug-in in Xen Orchestra?

I have two Active Directory Domain Controllers that I would like to specify, for redundancy. I've been meeting to ask this question for a while, but it kept escaping my mind.

@ph7 Yep, that's what I've done. Actually, I've powered off the prior XOA instance. Not ideal, but a workable solution.

@Bastien-Nollet Thanks for the update. In my community edition instance at my church, I just updated it to Master, commit 37fbb so I'll test over the weekend and provide an update.

For my XOA (Airgapped) instance at work, I did receive an updated appliance about two weeks ago, so I'll test and see if the problem persists. If it does, then I'll just wait until the official release of XO and then I'll request an updated appliance.

@DustinB Yeah, my thoughts exactly. Would be nice if XO supported logging to a remote syslog server, like XCP-ng does.

I haven't done this yet, but I'm gonna go through /var/log and see if perhaps those logs that are visible in the UI are actually being written to disk. If so, then I could just ship them off and import them into the new appliance.

@DustinB Yep, that's precisely what I did (which went very smoothly, by the way, with the exception of a few plugins which didn't startup automatically so had to start them), then discovered, the config + metadata backup does not include the appliance logs and audit logs - so my security folks are on me about that.

I have a ticket into support now inquiring into what the best approach would be to move these two logs from one appliance to another.

@lawrencesystems Yes sir I agree, as that is my experience with XOCE. But with XOA (Airgapped), in my PoC Lab, I've received my first upgrade and it was a completely new appliance. So I'm now figuring out how to handle that. I did reach out to Vates support about this and got a response that they are looking into perhaps doing the XO updates kinda like how they handle it now for XCP-ng (i.e., allow us to download the entire repo offline and then do the upgrade that way).

I'm sure you've dealt with many customers who are in my kind of environment, where security/compliance requirements are strict.

@lawrencesystems Makes sense.

I always assumed that since XOA was delivered as a service, that one had to leave the settings as-is. Good to know that they allow customization. But for an air-gapped environment, that presents some challenges for when upgrade time comes, and a new appliance is delivered. One has to remember to put the customizations in place on the new appliance before cutting to it. Not a deal breaker, just an annoyance factor I guess...lol.

Thanks again for chiming in.

@lawrencesystems Thanks for the response, I suspected that would be the remedy. I take it that means the entire management network is 10Gbps or faster?

... and make sure it has enough resources to process the backups.

Although, I'm curious about what you meant by the last part of your response. Does this mean I ought not accept the default CPU, RAM, and Disk sizes of XOA? I suppose one could customize these parameters when building XOCE (from sources), but aren't we supposed to be using the official XOA as-is?

Good-day everyone,

Just looking for some advice here. I've been playing around with backups in my lab, as part of my Proof-of-Concept in an Air-Gapped environment. I have a 10Gbps Storage Network between the hosts and the NAS, but the Management network is at 1Gbps. To that end, I am noticing that XOA seems to be the bottleneck during any backup job.

As I'm sure there's a perfectly valid reason for why Vates went with this architecture of running all backup jobs through XO, I'm not questioning that. However, I want to ask how others are managing to achieve higher transfer speeds on their backup jobs. Is it as simple as putting the Management Network on a 10Gbps link?

Looking forward to your responses, thanks.

Good-day Folks,

I'm attempting to leverage the Self Service functionality of XO to build a lab environment, whereby the lab users can have limited ability to build VMs, Create & Attach VDIs, Create & Attach NICs to VMs, etc. I also want to grant these users the ability to learn how to import VMs and ISOs.

So yesterday I attempted to play around with Self Service and ACLs a bit, and I discovered that the only way to get the Import menu to show up is to grant the Group Operator permissions to the entire pool. This seems to be too much privilege.

If anyone know of a way to accomplish what I'm trying to do, please do share. Thank you.

@olivierlambert Awesome! Can't wait.

@olivierlambert Aah, you got me there. Thanks for all the support thus far, really appreciate it.

@olivierlambert Thanks for the response, that's good to know that you guys have this on the roadmap. I didn't raise a support ticket because I'm not a paying customer yet, so don't want to come off as exploiting resources that could be dedicated to your paying customers.

That said, I will send this in via a support ticket. Thanks again.

Good-day Folks,

Happy Friday; I trust we're all in good health!

BLUF: I believe the current XOA upgrade option for those of us whose environments fall under the Physical air gap only section of the Airgap support and deployment documentation, leaves us with a new appliance and no way to preserve the historical logs and/or artifacts of the existing AND approved XOA instance.

In my environment, all hardware changes (i.e., new additions, modifications, removal, etc.) MUST go through a formal approval process - which almost always includes going through a Change Control Board (CCB) - yes, this includes any updates/upgrades to virtual machines. This process can often times take several days to weeks to complete. With the only upgrade option available, at this time, the imported VM is essentially a "new" virtual machine, thus, triggers the aforementioned CCB approval process. Additionally, I observed yesterday - after receiving an updated XOA image from support and importing it using the deploy script you provide - that although I was able to very easily export the XO-Config from the existing appliance and import it into the new appliance and essentially get back to the same configuration state (exception being some plugins had to be re-enabled), I was missing historical artifacts - most notably was the logs of the XOA appliance.

Given the above explanation, is there any chance that Vates will consider providing a patching mechanism similar to how you handle XCP--ng (i.e., with an offline repo)? This way, we can download the relevant files, setup a repo on the air-gapped network, then patch the appliance - thus preserving it's historical artifacts AND identity, and most importantly, not triggering an approval process.

@anthonyper said in Imported VM Starts but Does Not Initialize the Display:

yum update --enablerepo=xcp-ng-aperard1 edk2

YES - you fixed it! Thank you!!!
I tried the package and it worked - the VM started and was able to initialize the display and finish booting up. Glad you found the issue and I'm even more glad that it was my report that prompted you to look into this. This is a true testament to the power of this community.

@olivierlambert I have just submitted a Github issue for this - https://github.com/vatesfr/xen-orchestra/issues/8351

Thanks again for indulging me.

kismetgerald-ngc created this issue in vatesfr/xen-orchestra

open LDAP/Active Directory Authentication Fails if User is Member of More than 6 Groups #8351

@olivierlambert Awesome, glad I could convince ya . I will submit a Github issue shortly, thanks again.