Revolving around the core of technology
Has any headway been made on this?
Dear Joseph,
Implementing AD in Syncrify is very easy in Syncrify. SynaMan (another software published by Synametrics) already does this. However, integrated AD in Syncrify does not make much sense. Let me explain why:
Please let us know if you disagree with this assesement and give us an example on how it should be implemented.
Imran
Hello Imran,
Today a simple account/password authentication is not the best we can do. A strong password would help but some kind of 2 Factor Auth would be better.
To Joseph's point, in a Windows AD environment, many of us would have deployed our own PKI certificate servers (user and machine certs) and use Microsoft Network Policy Server (aka Radius) for additional authentication when using WiFi or VPN access.
Why would this not be important for Syncrify if we expose it directly to the internet for private cloud backup?
Sam
Sam,
I fully understand how important 2-way authentication is. That's not the question. The question is how to implement it? Backups in Syncrify run through a service in the background. The userid/password is saved in the Profile and therefore, before running a backup, these values are sent to the server.
How can we implement a 2-factor authentication for scheduled backup?
Imran
Hi Imran,
I understand your concern: if a user would be required to manually enter anything for each backup attempt it would not be practicle.
If certificates could be added as an optional additional factor that would work without user intervention. You could keep Username+Pwd as the default authentication but add Username+Pwd+Cert as another option. In windows you could use NPS (Radius) to confirm the cert, In Linux/Mac I believe you could use OpenSSL certs (they could be user generated, self-signed), and of course a more expensive option would be global trusted CA's like Digicert, Versign, etc.
For a Google Authenticator approach, perhaps there's a way to enroll a machine once with the Authentication key and then keep a cookie on the machine and/or something on the server side to know that this machine is a trusted client. (I don't know how Google does it but this is how gmail works if you use their authenticator app). In this way, if a new machine attempts to use the same user/pwd credentials it could be refused by default unless the Google Authenticator is used to establish the initial setup (only once).
I don't know what it would take on the server side for you to support this but I think it would be a valuable addition. :Thanks for keeping an open mind about this.
Sam
I have Syncrify in my customers, and we need that when I disable an user in AD, that the Syncryfy user is disabled too.
I have a development that compare MySQL (Sincrify) users (UPN field) with my AD and disable de Syncrify users when the user in AD is disabled, but is a complicated solution.
I appreciate if Syncrify can integrate wirh AD.
Right that could be scripted in a scheduled task. Query AD with something like Search-ADAccount -AccountDisabled or Get-ADUser -Filter {Enabled -eq $false} | FT samAccountName for a list of disabled users then compare them with Sycrify users which is <login>user@somedomain.dom</login> in Syncrify/config/UserMappings.xml (or sql value if you've set that) and set <active>true</active> to false (or change in sql if that's what you're using for Syncrify back end). Sure not ideal (especially having to poll vs be notified or integrated) but it there is minimal overhead if not polled too frequently & would work to auto disable in Syncrify if they've been disabled in AD at least.