SOLVED Problem with domain join after deployement

  • Hi everybody,

    I’m using fog to deploy images n many PCs and it works fine.

    However, i got a problem with the automatic domain join functionality.

    I attach the log of my last try to this post.

    Thank you for your help.

  • @Sebastian-Roth Great !!! Thank you again.

  • Senior Developer

    @benjamind Yes definitely looking better now. Seems all fine to me. Marking as solved.

  • @Sebastian-Roth The deployment is finished and the PC has correctly joined the domain.

    Here is the logs file : fog.log.

    Does everything seems good to you ?

    Thank you very much for your help.

  • @Sebastian-Roth

    It seems to be better :

    root@fog-dev:~# openssl x509 -noout -modulus -in /var/www/fog/management/other/ssl/srvpublic.crt | openssl md5
    (stdin)= 240adcef143c7ba2a2b4551282f476f9
    root@fog-dev:~# openssl rsa -noout -modulus -in /opt/fog/snapins/ssl/.srvprivate.key | openssl md5
    (stdin)= 240adcef143c7ba2a2b4551282f476f9

    I have started a new deployment i’ll keep you update.

    Thank you.

  • Senior Developer

    @benjamind Ok, here we’ve found it. The certificate (srvpublic.crt) and the private key (.srvprivate.key) don’t match. I have no idea why that might have happened. But we should be able to manually create a new certificate for you and fix this issue. You just need to closely follow the instructions (run as root):

    Make sure you set the variables (first two commands) correctly!! IP address instead of x.x.x.x and the proper full qualified hostname of the FOG server.

    export ipaddress=x.x.x.x
    mv /var/www/fog/management/other/ssl/srvpublic.crt /var/www/fog/management/other/ssl/srvpublic.crt.old
    cd /opt/fog/snapins/ssl/
    cat > req.cnf << EOF
    distinguished_name = req_distinguished_name
    req_extensions = v3_req
    prompt = yes
    CN = $ipaddress
    subjectAltName = @alt_names
    DNS.1 = $ipaddress
    DNS.2 = $hostname
    cat > ca.cnf << EOF
    subjectAltName = @alt_names
    DNS.1 = $ipaddress
    DNS.2 = $hostname
    openssl req -new -sha512 -key .srvprivate.key -out fog.csr -config req.cnf
    openssl x509 -req -in fog.csr -CA CA/.fogCA.pem -CAkey CA/.fogCA.key -CAcreateserial -out /var/www/fog/management/other/ssl/srvpublic.crt -days 3650 -extensions v3_ca -extfile ca.cnf

    After that check to see if the new certificate returns the same md5 hash as the private key file.

    openssl x509 -noout -modulus -in /var/www/fog/management/other/ssl/srvpublic.crt | openssl md5
    openssl rsa -noout -modulus -in /opt/fog/snapins/ssl/.srvprivate.key | openssl md5

  • @Sebastian-Roth

    root@fog-dev:~# openssl x509 -noout -modulus -in /var/www/fog/management/other/ssl/srvpublic.crt | openssl md5
    (stdin)= 6bf7b33e8a206b266560c17350102ffa
    root@fog-dev:~# openssl rsa -noout -modulus -in /opt/fog/snapins/ssl/.srvprivate.key | openssl md5
    (stdin)= 240adcef143c7ba2a2b4551282f476f9

  • Senior Developer

    @benjamind Ohhh, I was on the wrong track again. I expected the error message to be from the fog-client source code but looking at the PCAP file I figured that the FOG server is actually sending this (same) message to the fog-client. I am still not really sure why the FOG server is failing with that error but at least the picture is a little different now. The fog-client encrypts the data and sends it over to the server and the server is unable to decrypt it.

    Please run the following commands on your FOG server just to make sure certificate and private key match:

    openssl x509 -noout -modulus -in /var/www/fog/management/other/ssl/srvpublic.crt | openssl md5
    openssl rsa -noout -modulus -in /opt/fog/snapins/ssl/.srvprivate.key | openssl md5

  • @Sebastian-Roth We have the same error message on other clients. Here is the fog.log fog.log of an other client.

    Here is the pcap file.

    Thnak you for your help.

  • Senior Developer

    @benjamind Sorry for the deplay. Have been on travels over the weekend. The output is showing an empty sectoken field. So we need to look at other possibilites why this is going wrong.

    We have not had much requests from people with the error message “Failed to decrypt data” lately. All the old ones were due to an issue in the FOG server as far as I know but that shouldn’t be the case with FOG version 1.5.5 (which we see you have in the logs).

    Do you see that same error message on several (or all) of your clients?

    Could you please install tcpdump on your FOG server. Then stop the FOGService on your client run tcpdump -w fog-client.pcap host x.x.x.x and port 80 on your FOG server and start the FOGService on the client.

    Put in the client PC’s IP address instead of x.x.x.x and just leave the command for 30 seconds - then stop it with Ctrl+c and upload the resulting fog-client.pcap file to an online drive and post a link here. We should see the HTTP communication between FOG server and your client in that file. Hopefully we can figure out what’s going on.

  • Hi @Sebastian-Roth,

    Is the result of the command indicative ?

  • @Sebastian-Roth

    MariaDB [fog]> SELECT hostID,hostName,hostSecToken FROM hosts WHERE hostName LIKE ‘%PC2409M%’;

    | hostID     | hostName          | hostSecToken            |
    | 61         | PC2409M           |                         |
  • Senior Developer

    @benjamind Try SELECT hostID,hostName,hostSecToken FROM hosts WHERE hostName LIKE '%PC2409M%';

  • @Sebastian-Roth What do you want to verify precisely on the database ?

  • Senior Developer

    @benjamind Sorry, my fault. I went down the wrong road. CA cert should not be renewed (unless you specify so using command line options) but the server cert is renewed on FOG updates.

    We might need to take a look into your database to see if there are tokens pending that you don’t see in the host settings.

  • @Sebastian-Roth Here is is the commands i used to update our server :
    cd /root/fogproject/
    git pull
    cd bin/

  • Senior Developer

    @benjamind Which command line options did you choose when updating?

    @Tom-Elliott Any ideas??

  • @Sebastian-Roth Sorry, i give you the return on the commands form an other FOG server. Here is the return form the concerned server :

    root@fog-dev:~# openssl x509 -dates -noout -in /var/www/fog/management/other/ssl/srvpublic.crt
    notBefore=Mar 14 07:16:32 2019 GMT
    notAfter=Mar 11 07:16:32 2029 GMT
    root@fog-dev:~# openssl x509 -dates -noout -in /var/www/fog/management/other/ca.cert.pem
    notBefore=Apr 5 13:49:36 2018 GMT
    notAfter=Apr 2 13:49:36 2028 GMT

    The srvprublic.crt date corresponds to our last FOG update from 1.5.0 to 1.5.5 and the ca.cert.pem should corresponds to the first installation of the server.

    Is it a normal behaviour ?

  • Senior Developer

    @benjamind I am wondering, why is the server cert roughly two years younger than the CA? Did you update that server cert by intention last September?

  • @Sebastian-Roth I have restarted the FOG service.

    root@fog:~# openssl x509 -dates -noout -in /var/www/fog/management/other/ssl/srvpublic.crt
    notBefore=Sep  3 09:07:28 2018 GMT
    notAfter=Aug 31 09:07:28 2028 GMT
    root@fog:~# openssl x509 -dates -noout -in /var/www/fog/management/other/ca.cert.pem
    notBefore=Nov 24 09:57:37 2016 GMT
    notAfter=Nov 22 09:57:37 2026 GMT