FOG Encryption Problem / AD Domain Joins failing

[sgoodman]

I’m on the dev-branch running the most recent updates. CentOS 7.7 (latest 7.X release) MariaDB (10.2.27) and PHP version 7.3.11.

In recent months (I haven’t imaged much lately) my clients stop joining their AD domain (I got a an error in FOG.log [Fog.log says unknown username or bad password, code = 1326]) even though I know this to have not changed. I recreated the client from scratch and it failed, tried this on various PC generations and it also failed.

I went to FOG Settings > Active Directory Defaults and re-entered all information. The AD DEFAULT PASSWORD fails to encrypt and continues to store this in plain text. I can now join the domain, however I am extremely uncomfortable with this.

Am I doing something wrong? Do I need to do something to encrypt this manually? The notes on the UI indicate this should be automatic.

[Tom Elliott]

It was learned that the way we were encrypting the data in the past was not any more (or less) secure than storing the data in plain text. This is because in order to decrypt it we needed the iv used to encrypt that value in the first place. It added complexity and maintaining would have been difficult. So we removed the encrypting of this field. We are working to mask the field however so that the only time the plain text data is passed within the GUI, is when the field is being updated implicitly.

[sgoodman]

Thanks for clarifying - when did this change happen? Spoke with Sebastian weeks ago and he was volunteering to debug (leads me to believe this change was not well known).

I use “technicians” to help me deploy (students) and they are not normally given this credential as it could create a security concern. Masking this would work and this should be reflected in the FOG Settings and the Active Directory Setting for the individual clients/groups.

[Tom Elliott]

@sgoodman I’m pretty sure this was routed out after for 1.5.0.

Here’s the Commit (2017 it seems is when we moved away from encrypting this field.)

https://github.com/FOGProject/fogproject/commit/8dc77cbe3fe6950a2cbe26867cc4b74ff71e5d27

[sgoodman]

@Tom-Elliott
Tom - I have been updating FOG on a regular basis and never changed the encrypted string to clear text and it always worked. Was an encrypted string “semi-supported” for some time after the commit? Did a recent update nullify that? Curious minds want to know.

[Sebastian Roth]

@sgoodman said:

I have been updating FOG on a regular basis and never changed the encrypted string to clear text and it always worked.

There was no change of that code since Feb 1, 2018.

Was an encrypted string “semi-supported” for some time after the commit? Did a recent update nullify that?

From what I understand about the code it seems to try both ways - un-encrypted and encrypted - line 40ff. This has not changed since Feb 1, 2018. Neither hast the fog-client code changed since Apr 10, 2018 (0.11.16 released together with 1.5.1). Is it possible you changed your AD logon credentials in the last weeks and somehow hit some kind of special case with character encoding that we were not aware of? Just guessing here.

I use “technicians” to help me deploy (students) and they are not normally given this credential as it could create a security concern.

We are working on this - see github issue. Tom added it to the working-1.6 branch already and I will adapt this to dev-branch today.