Tranquil IT Forum

Hello, I'm having trouble with self-service (WAPT Enterprise).
I created an OU package at the root of my organization, inside which I put a generic self-service package and some groups. Everything is in lowercase in Active Directory and in WAPT: `
app_toto` : all users can see the applications in it (group: everyone in Active Directory);
`app_toto_admin` : all members of the admin group are in the Active Directory group.

So, naturally, admin members have access to the latest rules. However, I have one member of the admin group whose store is empty, while another member has all the apps. Both have the exact same machine configuration, and in Active Directory, they are members of the same groups. I admit I'm stumped.
Have I missed something?

As a follow-up question, one person is getting an "unhandled error" when trying to connect to the console.
Where can I find the console logs? Can't we retrieve a client's logs from the console?

Hello,

the problem varies depending on your configuration.

There are several modes:

the default mode on the agent, the system mode (username/password) is passed to the system, which calculates the groups and verifies the username/password;

the other mode, waptserver-ldap, passes the username/password to the Wapt server, which then makes an LDAP request to verify the user's username/password and the groups they belong to; and

the last mode, waptserver-ldap + Kerberbos.
This mode allows transparent authentication to the Wapt server and does not require a password from the user. (It's still LDAP on the Wapt server side, but this time the connection is made with a service account.)

Can you confirm that you are in the default mode?

https://www.wapt.fr/fr/doc/wapt-advance ... tification

Simon

Thanks for the quick reply, I'm using the default configuration.
However, after digging around, I see that my Wapt clients' configuration (wapt-get.ini) is different. I'm trying to standardize it to see if that makes a difference.
Julien

Okay, I did a clean install, purging the old configuration, but still nothing.
I did the same thing on another machine, and it works there. So there must be a problem with his machine's configuration, but I can't figure out what.
Is there a log file related to the self-service that I can check?

You might find something in C:\Program Files (x86)\wapt\log\waptservice.log

When you're logged into the system account (are you on a Windows machine?), Windows will query Active Directory in real time to check the group access. Is Active Directory available?

To perform the test in pure Python, you can try this

This will return True if the user is indeed a member of the group
If it works here, then the problem is elsewhere

Yes, yes, I am indeed on Windows. However, I just remembered that we migrated to a Windows domain last year and converted the local profiles to domain profiles. If I understand the process correctly:
For self-service authentication, WAPT will use the local account on the machine and then query Active Directory for permissions?
So, on a machine, if I have myuser and myuser.mydomain.lan, 's login myuser is different from the domain account's login?

By default, the domain is set to empty.


The WAPT code manages the domain if you pass your username with "MYDOMAIN\username" or "username@mydomain.lan".

If the domain is set to empty, then Windows handles it. Therefore, in the case of a local account with the same username as the domain account, there's a good chance it will fail.

Windows will first try locally. If the password is identical to the local account, then it works.

However, your local account is not a member of the domain group.

Okay, that's pretty much what I thought.
I had already configured LDAP authentication on the server for the console. If I enable agent authentication, will it bypass the local user and send the request to the server, which will then authenticate itself?
Do I just need to add the lines to the wapt-conf-policy file?

That's it, just ldap_auth_ssl_enabled is not necessary:

This is sufficient:
And if you add Kerberos, authentication will be seamless

Kerberos is the next step; I'll test it this way first. Thanks for the feedback