AD credentials disappears

[kAs1m]

Hello! I’m trying to automate the process of joining into domain for new PC’s, so I’ve created a group in fog web ui, named AD, and added my domain admin credentials in Active Directory section of the group:

After I clicking Update, everything seems fine, and credentials still here, but if I go to, for example, Hosts page and then back to groups, list all groups, and selecting my AD group, the credentials isn’t here anymore…

Fog ver. is 1.5.7

[Sebastian Roth]

@kAs1m Groups work different in FOG than you expect. Search the forums for “persistent groups” to read more on this topics.

[kAs1m]

I think I understands now, but is there a way to quick reg host and auto join domain?

[kAs1m]

I’ve solved it myself.
Now quick reg applies AD settings to host.
Add AD settings in web ui:
Settings - Fog Settings - Active Directory Defaults
Then replace code in /var/www/fog/lib/reg-task/registration.class.php
With this:
https://www.pastiebin.com/5d6c4867436bc

Do not forget to chown www-data:www-data /var/www/fog/lib/reg-task/registration.class.php
after.

PS
And one more thing, maybe someone needs it. If you have multiple admins in your organisation and some of them have just support rights, but not domain admins, you cant hide all ad admin passwords from viewing it in the web ui:
find this code in /var/www/fog/lib/pages/fogconfigurationpage.class.php :
default:
$type .= ‘<input type=“password” name=“${service_id}” value="’
. ‘${service_value}" autocomplete=“off” class=’
. ‘“form-control” id=“${service_name}”/>’;

and replace it with this:
default:
$type .= ‘<input type=“password” name=“${service_id}” value="’
. ‘" autocomplete=“off” class=’
. ‘“form-control” id=“${service_name}”/>’;

also find this code in /var/www/fog/lib/fog/fogpage.class.php :
) => sprintf(
‘<div class=“input-group”>’
. ‘<input id=“adPassword” class=“form-control” type=’
. '“password” ’
. ‘name=“domainpassword” value=“%s” autocomplete=“off”/>’
. ‘</div>’,
$ADPass
),

and replace with this:
) => sprintf(
‘<div class=“input-group”>’
. ‘<input id=“adPassword” class=“form-control” type=’
. '“password” ’
. ‘name=“domainpassword” value=“%s” autocomplete=“off”/>’
. ‘</div>’,
‘#hidden’//$ADPass
),

Also, do
mv /var/www/fog/lib/db/mysqldump.class.php /var/www/fog/lib/db/mysqldump.class.php.bak
to prevent from backing up whole mysql db/

[Sebastian Roth]

@kAs1m Great to see you figured this out yourself so quickly! We might consider adding your code change on lib/reg-task/registration.class.php to the official code. Thanks for sharing this!

We know that passwords displayed in the web UI can be a problem in some organizations where different people need to use it. One pretty active user proposed this same thing and created a plugin for that: https://forums.fogproject.org/topic/9624/control-access-plugin (see if that might be helpful for you as well - maybe in combination with the LDAP plugin too)

[kAs1m]

@Sebastian-Roth Thanks, I think many lazy admins will appreciate full automatic reg process.

PS
Also, I forgot to comment out this section in /var/www/fog/lib/fog/fogpage.class.php:
/sprintf(
‘<label for=“adEnabled”>%s</label>’,
_(‘Join Domain after deploy’)
) => sprintf( //#hidden
‘<input id=“adEnabled” type=“checkbox” name=“domain”%s/>’,
(
$useAD ?
’ checked’ :
‘’
)
),/

This will remove “Join Domain after deploy” checkbox from web ui compleatly(else you’ll notice that you can see AD admin pwd, if you create new host, check this checkbox and click show password button)

[Sebastian Roth]

@kAs1m Have your read about the Access Control Plugin?? I don’t think it’s wise to add those manual adjustments to the web UI code as this will be overwritten every time you update to a new FOG version.

[kAs1m]

@Sebastian-Roth Didn’t has time, sorry. The whole PLUGIN thing was actually new to me, so now after quick navigation in settings, I’ve explored PLUGINSYS checkbox. Thank you, now I’ll sped some time to investigate all of the “mainline” plugins. Thank you for advising me to use this plugin.

PS
Aaan,d I could’t find any functionality that I’ve implemented, also the whole thing seems not working, because I couldn’t restrict Support role from accessing “Access Controls”, where they can revert everything back.
I also reported to this topic about last problem: /topic/10918/access-control-plugin/10