[RESOLVED] Agent not registering in WAPT

[PaulSLA]

Good morning,

Following the implementation of Kerberos authentication on our WAPT server and the configuration of a test workstation with Kerberos enabled, we are encountering an issue when deploying new workstations via WADS. The workstations are visible in the OS deployment section, Windows installs, but then the workstation boots normally but is not registered with WAPT. We have to run the `register` command, which prompts us for the WAPT login/password and then registers the workstation and launches package updates as usual. We tried modifying the `conf` workstation script as follows:

Code: Select all

ping 127.0.0.1 -n 30
net stop waptservice
"C:\Program Files (x86)\wapt\wapt-get.exe" update 
"C:\Program Files (x86)\wapt\wapt-get.exe" install base_software
net start waptservice
"C:\Program Files (x86)\wapt\wapt-get.exe" register --wapt-server-user=XXXXX --wapt-server-passwd=XXXXX

The computer is supposed to register automatically at the end of the Windows installation, but this gets stuck on the "User: Running script postinstall" phase, which never finishes. The computer remains stuck in a loop on the Windows startup screen (the Windows logo with the small dot inside). If we shut down the computer and log back in, we can register it manually.

We have no other issues with WAPT management; the workstations are reachable and updates are performed correctly, whether Kerberos is at 0 or 1.

Has anyone else encountered this problem, and if so, how did they resolve it?



If needed:

waptserver.ini file:

Code: Select all

[options]
server_uuid = 
secret_key = 
wapt_password = 
clients_signing_key = /opt/wapt/conf/ca-srv-wapt.XXXX.dom.pem
clients_signing_certificate = /opt/wapt/conf/ca-srv-wapt.XXXX.dom.crt
ldap_auth_server = XXXX.dom
ldap_auth_base_dn = DC=XXXX,DC=dom
ldap_account_service_login = wapt@XXXX.dom
ldap_account_service_password = 
token_secret_key = 
clients_signing_crl = /var/www/ssl/ca-srv-wapt.XXXX.dom.crl
clients_signing_crl_url = http://srv-wapt.XXXX.dom/wapt/ssl/ca-srv-wapt.XXXX.dom.crl
ssl_additional_crls = /var/www/ssl
waptwua_enable = True
allow_unauthenticated_registration = False
wads_enable = True
login_on_wads = False
use_kerberos = True
ldap_auth_ssl_enabled = False

wat-get.ini from the test station:

See attached file poste1.png

Poste1.png (234.66 KB) Consulted 9238 times

wat-get.ini production workstation:

See attached file poste2.png

Poste2.png (226.96 KB) Viewed 9238 times

Thank you in advance for your answers
Sincerely,

[dcardon]

Hi Paul,

did you restart the postconf after modifying the waptserver.ini file? There are some changes to be reflected in the nginx configuration file.

Regards,

Denis

[PaulSLA]

Hello,

I just tried it again just to be sure (although I'm certain I'd already done it), but it didn't change anything.

Currently, the workstations are stuck on "postinstall script," and I have to shut them down incorrectly, restart them, and finally register them with WAPT.

I modified the postinstall script to add the command: "C:\Program Files (x86)\wapt\wapt-get.exe" register --wapt-server-user=XXXX--wapt-server-passwd=XXXX""
thinking that would make them register, but it didn't. After restoring the script to its normal state, the problem persists (whereas before the modification, the PC completed the Windows installation normally but simply failed to register with wapt).

Here is the current script:
ping 127.0.0.1 -n 30
net stop waptservice
"C:\Program Files (x86)\wapt\wapt-get.exe" update
"C:\Program Files (x86)\wapt\wapt-get.exe" install base_software
net start waptservice

Regards,

[dcardon]

Hello Paul,

Does Kerberos registration work on a WAPT agent outside of WADs?

To test, you can use a clean machine or one that is already integrated. If the machine is integrated, you must remove it from the inventory and delete the client certificate files c:\program files (x86)\wapt\private\*.{crt,p12,pem}

After that, you perform a privilege escalation in LOCAL SYSTEM using psexec

Code: Select all

psexec -i -s cmd.exe

Then you run a wapt-get register without username/password to verify that the machine is able to register correctly in kerberos.

Sincerely,

Denis

[PaulSLA]

Hello,

I've tested it. After setting `use kerberos` to 1 on the agent side and rebooting the WAPT service, authentication works directly without a password. If `use kerberos` is set to 0, then a login and password are required.

Kerberos registration therefore seems to be working. I then tried the self-service option, and I get an "incorrect password" error message. I enter my Windows password, and everything works. But with Kerberos, shouldn't this be automatic?

This still raises the issue of new PCs registering. How can I view the default deployed configuration and verify that it's using Kerberos? If it's not using it, can I simply generate a new agent that uses Kerberos to resolve the issue?

If so, what about the currently deployed agents? Will they all re-register?

Sincerely,

[dcardon]

Hello again Paul,

Test done: after setting `use kerberos` to 1 on the agent side and rebooting the WAPT service, authentication works directly without a password. If `use kerberos` is set to 0, then a login and password are required.

Okay, that means the Kerberos part is properly configured.

Kerberos registration seems to be working. I tried the self-service option, but I got an "incorrect password" error message. I entered my Windows password and everything worked. But with Kerberos, shouldn't that be automatic?

Yes, it should work automatically. You do have `service_auth_type=waptserver-ldap` on the test machine, but not on the other one. Was the test performed on the test machine?

This always causes problems with new PCs registering. How can I view the default deployment configuration and verify that it's using Kerberos? If it's not, can I simply generate a new agent that uses Kerberos to resolve the issue?

Are the newly deployed workstations displaying the correct time? Kerberos is somewhat sensitive to time. It's worth noting that WinPE records its BIOS time in UTC, while a locally installed Windows system records its BIOS time in the local time zone. This is rather inconsistent. There's no time zone in the BIOS, and Windows isn't consistent in its use of time within the BIOS... (Linux also records time in UTC).

If so, what about the agents currently deployed? Will they all re-register?

If an agent is registered, it has its client certificate (.pem / .p12) and uses it to authenticate to the server. It will only use Kerberos authentication if it doesn't have a client certificate or if it's not working (i.e., it has been revoked). Therefore, no, there will be no re-registration of already deployed/registered workstations.

Sincerely,

Denis

[PaulSLA]

Hello,

thank you for these replies. I do have the line "service_auth_type=waptserver-ldap" in [global] on the machine where I'm doing my test. I'm not putting it on the production machines yet because I'm not sure I fully understand all the ins and outs of this configuration.
I also have the line, found on the forum, which solved a similar problem at the time: "ldap_auth_ssl_enabled=False".

I was able to fix the problem on the new PCs. For some reason I don't know, the post-install script gets stuck and the installation never continues. Since this script no longer does much useful work, I was able to delete it, and the installation continues. Once the installation is finished, the PC registers correctly with Kerberos (after generating a new agent that supports it, of course).


Thank you for the information regarding the existing machines. So, I can change `use_kerberos` from 0 to 1 on my machines; this won't have any impact on production? But if I understand correctly, this is of little use, only for re-registering them if needed someday.

So the only remaining issue is the self-service feature not working with SSO despite the presence of the lines mentioned above and the server configuration already posted.
If the line "service_auth_type=waptserver-ldap" is present, then the self-service starts with a red error message saying the password is incorrect. If I remove it, no message appears, and I'm simply asked for the password. I don't have many other ideas to fix this problem, unfortunately.

Sincerely,

[dcardon]

Hi Paul,

I'm a bit stuck on the self-service configuration issue. Your organization has subscribed to phone support. The best thing to do is open a ticket and have someone look at the configuration with you live; it shouldn't be too difficult.

Regards,

Denis

[PaulSLA]

Hello,

I continued looking into it, and method 2 from the documentation works.

"ldap_auth_ssl_enabled = True
verify_cert_ldap = False"

The third method, however, doesn't work, but since we also plan to enable certificate verification, we'll open a ticket for both issues at the same time, as they both seem related to a certificate problem.

Thank you for your help!

Best regards,