[SSSD-users] Re: kvon in keytab is getting out of sync

[Grebe, Sebastian]

Hello

It took a while until I was able to get the logs from a failed machine. There 
have been three occasions been logged where the client updated the AD Password. 
Both 2022-5-23 and 2022-05-31 have been fine only 2022-06-07 wasn't and locally 
the kvon was not updated, but on the DC it was. The only difference I can spot 
this.

Working:
* Found computer account for LC015564$ at: 
CN=LC015564,OU=Computer,OU=Minden,OU=Germany,DC=wago,DC=local
* Retrieved kvno '16' for computer account in directory: 
CN=LC015564,OU=Computer,OU=Minden,OU=Germany,DC=wago,DC=local
* Sending NetLogon ping to domain controller: svdc01011.wago.local
* Received NetLogon info from: SVDC01011.wago.local
* Changed computer password
* kvno incremented to 17
* Checking RestrictedKrbHost/lc015564.wago.local

Not working:
* Found computer account for LC015564$ at: 
CN=LC015564,OU=Computer,OU=Minden,OU=Germany,DC=wago,DC=local
* Retrieved kvno '17' for computer account in directory: 
CN=LC015564,OU=Computer,OU=Minden,OU=Germany,DC=wago,DC=local
* Sending NetLogon ping to domain controller: svdc03002.wago.local
* Found old kvno '17'
* Changed computer password
* Retrieved kvno '17' for computer account in directory: 
CN=LC015564,OU=Computer,OU=Minden,OU=Germany,DC=wago,DC=local
* Sending NetLogon ping to domain controller: svdc03002.wago.local
* Received NetLogon info from: SVDC03002.wago.local
* Checking RestrictedKrbHost/lc015564.wago.local


I inclued all log output. To me it looks like the communication is done only in 
TCP allso I do not see any KRB5KRB_AP_ERR_REPEAT errors. So I believe I have a 
different problem then Spike.
I do believe that the problem only occurs if the client is connect over VPN. 
But I have no data to prove this. It may also be related to the side the client 
is connected to. I have no idea what to check next. Maybe I will set one 
specific server to be used for updating the computer password.

Mit freundlichen Grüßen / Best regards

WAGO GmbH & Co. KG
Sebastian Grebe
IT Service Center
phone:  +49 571 887-9000
fax:   +49 571 887-8658

WAGO GmbH & Co. KG
Hansastraße 27
32423 Minden
Deutschland
http://www.wago.com



Public



 

 Diese E-Mail einschließlich ihrer Anhänge ist vertraulich und daher allein für 
den Gebrauch durch den vorgesehenen Empfänger bestimmt. Dritten ist das Lesen, 
Verteilen oder Weiterleiten dieser E-Mail sowie jedwedes Vertrauen auf deren 
Inhalt untersagt. Wir bitten, eine fehlgeleitete E-Mail unverzüglich 
vollständig zu löschen und uns eine Nachricht zukommen zu lassen.
This email may contain material that is confidential and/or privileged for the 
sole use of the intended recipient. Any review, reliance or distribution by 
others or forwarding without express permission is strictly prohibited. If you 
are not the intended recipient, please contact the sender and delete all 
copies. 
 WAGO GmbH & Co. KG - Sitz: Minden - Amtsgericht Bad Oeynhausen HRA 6218
Komplementärin: WAGO Beteiligungs GmbH – Sitz: Brunn am Gebirge (Österreich) - 
Landesgericht Wiener Neustadt, FN 553907w - Niederlassung Minden - Amtsgericht 
Bad Oeynhausen, HRB 17863
Geschäftsführung: Axel Börner, Kathrin Fricke, Dr. Heiner Lang, Christian 
Sallach, Jürgen Schäfer, Dr. Karsten Stoll, Yannick Weber
WAGO ist eine eingetragene Marke der WAGO Verwaltungsgesellschaft mbH  



adcli_update.out.2022-05-31_07-10-18
Description: adcli_update.out.2022-05-31_07-10-18


adcli_update.out.2022-06-07_07-33-23
Description: adcli_update.out.2022-06-07_07-33-23


adcli_update.pcap.2022-05-31_07-10-18
Description: adcli_update.pcap.2022-05-31_07-10-18


adcli_update.pcap.2022-06-07_07-33-23
Description: adcli_update.pcap.2022-06-07_07-33-23


krb5_trace.out.2022-05-31_07-10-18
Description: krb5_trace.out.2022-05-31_07-10-18


krb5_trace.out.2022-06-07_07-33-23
Description: krb5_trace.out.2022-06-07_07-33-23
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: kvon in keytab is getting out of sync

[Sebastian Grebe]

Hello,

I will first push out the debug_level = 0x0100. Hopefully this dose get me 
enough information to solve the problem.
Otherwise, I will look into the adcli update wrapper.

I have forgotten to mention that adcli testjoin is still reporting successfully 
joint despite the error. 

Today I got a new report. In this case the computer was reporting "Cannot find 
key for LC016550$@WAGO.LOCAL kvno 5 in keytab" since 13th of January . And in 
the keytab file there was a ticket with kvno 4 created at  12th of January. 
Unfortunately I didn't checked the reported date on the AD side before 
rejoining the computer. And with the cured log settings a error is only 
reported if the User is authenticating to computer while connected to the 
company network. So it might have been in the error state since 12th of January.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: kvon in keytab is getting out of sync

[Sebastian Grebe]

Hi Grigory

if there is a problem with SELinux shouldn’t the issue be less sporadically. 
Sorry I know, I haven’t included much information about the scope of the 
installation. I have approximately 100 active computers configured this way and 
I have 6 reports about the issue from the last 2 month. Unfortunately, some 
users are working around the issue for multiple days before reporting. Just got 
a new report today but the problem started 7 days ago.
Checked the log anyway but no messages regarding /etc/krb5.keytab.  
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: kvon in keytab is getting out of sync

[Spike White]

Justin,

if it's https://krbdev.mit.edu/rt/Ticket/Display.html?id=9037 , then it's
even more evil to positively prove than dialing up the sssd debug level.
The min debug level to get verbose adcli update output is debug level 7.
Even running at this debug level for just a few days swamps the /var/log or
other filesystem housing /var/log/sssd/*.

You can fine-tune this in sssd.conf with debug_level = 0x0100 , which gives
just the desired 'adcli update' verbosity with not much else.  And you can
tune the default logrotate.d setting to rotate logs more frequently.

However, this bug is quite infrequent and the adcli update verbosity is
insufficient to determine exactly what's going on.

Ultimately, we have to disable the 30-day  'adcli update' from sssd.conf
and write our own crontab file to fire off every 3-4 days.   In this cron
job that called adcli update, we wrapped this manual adcli update with
tcpdump to get the raw packet capture.  In that way, we were finally able
to get a full packet capture and see this race condition.  We also call
adcli update with KRB5_TRACE enabled, so that we get the full krb5 verbose
output.

Attached is the simple wrapped adcli update shell script that this cron job
calls.

We had to push this cron job out to thousands of servers and update the
machine accounts passwords every 3-4 days to obtain 2-3 failed client
packet captures.  That race condition is that infrequent.
It occurs on 0.3 - 0.4% of all adcli update invocations.

Most all of these ideas we obtained from this sssd mailing list (such as
disabling automatic password renewal and running adcli update as a cron
job).

I'm not convinced that Sebastian's situation is this bug,  so Sebastian
might be able to get away with debug_level = 0x0100 to see what his bug
is.

Spike





On Wed, Jan 19, 2022 at 9:15 AM Justin Stephenson 
wrote:

> Hi,
>
> It sounds like a problem occurs when SSSD executes 'adcli update' to
> renew the machine account password, if successful the AD DC computer
> object password is updated and the new keys are written to the keytab.
> If a failure occurs however it may have caused these two things to go
> out of sync.
>
> You may need to set a high enough 'debug_level' in your
> [domain/$domain] section of sssd.conf then check the adcli output
> written into the domain logs when the issue happens.
>
> -Justin
>
> On Wed, Jan 19, 2022 at 5:40 AM Sebastian Grebe
>  wrote:
> >
> > Hello,
> >
> > we are getting report from users where they suddenly can‘t authenticate
> to their Linux computers anymore. These computers are joint to ore MS
> Domain using adcli und sssd. Checking the log reveals that the kerberos
> tickets stored in  /etc/krb5.keytab do not have the expected KVON. At the
> moment we can’t tell what’s causing the issue. It happens only
> sporadically. I’m under the impression only computer without permanent
> network connection (Laptops) are affected.
> >
> > The log shows:
> >
> > Jan 11 09:30:52 lc015564 systemd[1]: Starting System Security Services
> Daemon...
> > Jan 11 09:30:52 lc015564 sssd[1376]: Starting up
> > Jan 11 09:30:52 lc015564 sssd_be[1609]: Starting up
> > Jan 11 09:30:52 lc015564 sssd_ifp[1633]: Starting up
> > Jan 11 09:30:52 lc015564 systemd[1]: Started System Security Services
> Daemon.
> > Jan 11 09:30:55 lc015564 sssd_be[1609]: Backend is offline
> > Jan 11 09:49:32 lc015564 sssd_be[1609]: Backend is online
> > Jan 11 09:49:41 lc015564 krb5_child[6111]: Cannot find key for
> LC015564$@WAGO.LOCAL kvno 11 in keytab
> > Jan 11 09:49:41 lc015564 krb5_child[6111]: Cannot find key for
> LC015564$@WAGO.LOCAL kvno 11 in keytab
> > Jan 11 09:49:49 lc015564 adcli[6102]: GSSAPI client step 1
> > Jan 11 09:49:49 lc015564 adcli[6102]: GSSAPI client step 1
> > Jan 11 09:49:50 lc015564 adcli[6102]: GSSAPI client step 1
> > Jan 11 10:00:57 lc015564 krb5_child[6838]: Cannot find key for
> LC015564$@WAGO.LOCAL kvno 11 in keytab
> > Jan 11 10:00:57 lc015564 krb5_child[6838]: Cannot find key for
> LC015564$@WAGO.LOCAL kvno 11 in keytab
> >
> > And klist -k shows:
> >
> > Keytab name: FILE:/etc/krb5.keytab
> > KVNO Principal
> > 
> --
> >   10 LC015564$@WAGO.LOCAL
> >   10 LC015564$@WAGO.LOCAL
> >   10 LC015564$@WAGO.LOCAL
> >   10 host/LC015564@WAGO.LOCAL
> >   10 host/LC015564@WAGO.LOCAL
> >   10 host/LC015564@WAGO.LOCAL
> >   10 host/lc015564.wago.local@WAGO.LOCAL
> >   10 host/lc015564.wago.local@WAGO.LOCAL
> >   10 host/lc015564.wago.local@WAGO.LOCAL
> >   10 RestrictedKrbHost/LC015564@WAGO.LOCAL
> >   10 RestrictedKrbHost/LC015564@WAGO.LOCAL
> >   10 RestrictedKrbHost/LC015564@WAGO.LOCAL
> >   10 RestrictedKrbHost/lc015564.wago.local@WAGO.LOCAL
> >   10 RestrictedKrbHost/lc015564.wago.local@WAGO.LOCAL
> >   10 RestrictedKrbHost/lc015564.wago.local@WAGO.LOCAL
> >9 LC015564$@WAGO.LOCAL
> >9 LC015564$@WAGO.LOCAL
> >9 LC015564$@WAGO.LOCAL
> >9 host/LC015564@WAGO.LOCAL
> >9 

[SSSD-users] Re: kvon in keytab is getting out of sync

[Grigory Trenin]

Hi Sebastian,

Please check if SELinux context of /etc/krb5.keytab file is correct.
I have seen this issue a couple of times when SELinux prevented adcli from
writing to this file when it was invoked from SSSD. Thus, the password
adcli changed the password in AD, but was unable to write it to
/etc/krb5.keytab.
You have the last password change timestamp in AD - this timestamp can help
with investigation. You can examine the system logs for this date for any
errors. In my case, there were SELinux denied events for /etc/krb5.keytab
in the audit log.


Kind regards,
Grigory Trenin

ср, 19 янв. 2022 г. в 13:39, Sebastian Grebe :

> Hello,
>
> we are getting report from users where they suddenly can‘t authenticate to
> their Linux computers anymore. These computers are joint to ore MS Domain
> using adcli und sssd. Checking the log reveals that the kerberos tickets
> stored in  /etc/krb5.keytab do not have the expected KVON. At the moment we
> can’t tell what’s causing the issue. It happens only sporadically. I’m
> under the impression only computer without permanent network connection
> (Laptops) are affected.
>
> The log shows:
>
> Jan 11 09:30:52 lc015564 systemd[1]: Starting System Security Services
> Daemon...
> Jan 11 09:30:52 lc015564 sssd[1376]: Starting up
> Jan 11 09:30:52 lc015564 sssd_be[1609]: Starting up
> Jan 11 09:30:52 lc015564 sssd_ifp[1633]: Starting up
> Jan 11 09:30:52 lc015564 systemd[1]: Started System Security Services
> Daemon.
> Jan 11 09:30:55 lc015564 sssd_be[1609]: Backend is offline
> Jan 11 09:49:32 lc015564 sssd_be[1609]: Backend is online
> Jan 11 09:49:41 lc015564 krb5_child[6111]: Cannot find key for
> LC015564$@WAGO.LOCAL kvno 11 in keytab
> Jan 11 09:49:41 lc015564 krb5_child[6111]: Cannot find key for
> LC015564$@WAGO.LOCAL kvno 11 in keytab
> Jan 11 09:49:49 lc015564 adcli[6102]: GSSAPI client step 1
> Jan 11 09:49:49 lc015564 adcli[6102]: GSSAPI client step 1
> Jan 11 09:49:50 lc015564 adcli[6102]: GSSAPI client step 1
> Jan 11 10:00:57 lc015564 krb5_child[6838]: Cannot find key for
> LC015564$@WAGO.LOCAL kvno 11 in keytab
> Jan 11 10:00:57 lc015564 krb5_child[6838]: Cannot find key for
> LC015564$@WAGO.LOCAL kvno 11 in keytab
>
> And klist -k shows:
>
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> 
> --
>   10 LC015564$@WAGO.LOCAL
>   10 LC015564$@WAGO.LOCAL
>   10 LC015564$@WAGO.LOCAL
>   10 host/LC015564@WAGO.LOCAL
>   10 host/LC015564@WAGO.LOCAL
>   10 host/LC015564@WAGO.LOCAL
>   10 host/lc015564.wago.local@WAGO.LOCAL
>   10 host/lc015564.wago.local@WAGO.LOCAL
>   10 host/lc015564.wago.local@WAGO.LOCAL
>   10 RestrictedKrbHost/LC015564@WAGO.LOCAL
>   10 RestrictedKrbHost/LC015564@WAGO.LOCAL
>   10 RestrictedKrbHost/LC015564@WAGO.LOCAL
>   10 RestrictedKrbHost/lc015564.wago.local@WAGO.LOCAL
>   10 RestrictedKrbHost/lc015564.wago.local@WAGO.LOCAL
>   10 RestrictedKrbHost/lc015564.wago.local@WAGO.LOCAL
>9 LC015564$@WAGO.LOCAL
>9 LC015564$@WAGO.LOCAL
>9 LC015564$@WAGO.LOCAL
>9 host/LC015564@WAGO.LOCAL
>9 host/LC015564@WAGO.LOCAL
>9 host/LC015564@WAGO.LOCAL
>9 host/lc015564.wago.local@WAGO.LOCAL
>9 host/lc015564.wago.local@WAGO.LOCAL
>9 host/lc015564.wago.local@WAGO.LOCAL
>9 RestrictedKrbHost/LC015564@WAGO.LOCAL
>9 RestrictedKrbHost/LC015564@WAGO.LOCAL
>9 RestrictedKrbHost/LC015564@WAGO.LOCAL
>9 RestrictedKrbHost/lc015564.wago.local@WAGO.LOCAL
>9 RestrictedKrbHost/lc015564.wago.local@WAGO.LOCAL
>9 RestrictedKrbHost/lc015564.wago.local@WAGO.LOCAL
>
> This is a our sssd.conf (it's from o different computer):
>
> [sssd]
> domains = wago.local
> config_file_version = 2
> services = ifp
>
> [domain/wago.local]
> default_shell = /bin/bash
> fallback_homedir = /home/%d/%u
> cache_credentials = true
> krb5_store_password_if_offline = true
> krb5_realm = WAGO.LOCAL
> krb5_ccname_template = /tmp/krb5cc_%U
> realmd_tags = manages-system joined-with-adcli
> id_provider = ad
> access_provider = ad
> ad_domain = wago.local
> ad_enabled_domains = wago.local
> ad_hostname = lc017547.wago.local
> use_fully_qualified_names = false
> ldap_id_mapping = true
> ldap_user_gecos = displayName
> ldap_use_tokengroups = false
> ldap_search_base = dc=wago,dc=local?subtree?
> ldap_user_search_base =
> ou=User,ou=Minden,ou=Germany,dc=wago,dc=local?subtree??ou=User,ou=Administration,dc=wago,dc=local?onelevel?(&(objectClass=user)(cn=a2*))?ou=Service,dc=wago,dc=local?subtree?
> ldap_group_search_base =
> cn=Users,dc=wago,dc=local?onelevel?(&(objectClass=group)(cn=Domain
> Users))?ou=Groups,ou=Minden,ou=Germany,dc=wago,dc=local?onelevel?(&(objectClass=group)(cn=&01-PC-Support))
> ldap_netgroup_search_base = cn=Users,dc=wago,dc=local?onelevel?
> ignore_group_members = true
> enumerate = false
> dyndns_update = true
> dyndns_refresh_interval = 7200
> dyndns_update_ptr = true
> dyndns_server = 10.1.100.2
> case_sensitive = Preserving
>
> [nss]
> filter_users = root

[SSSD-users] Re: kvon in keytab is getting out of sync

[Justin Stephenson]

Hi,

It sounds like a problem occurs when SSSD executes 'adcli update' to
renew the machine account password, if successful the AD DC computer
object password is updated and the new keys are written to the keytab.
If a failure occurs however it may have caused these two things to go
out of sync.

You may need to set a high enough 'debug_level' in your
[domain/$domain] section of sssd.conf then check the adcli output
written into the domain logs when the issue happens.

-Justin

On Wed, Jan 19, 2022 at 5:40 AM Sebastian Grebe
 wrote:
>
> Hello,
>
> we are getting report from users where they suddenly can‘t authenticate to 
> their Linux computers anymore. These computers are joint to ore MS Domain 
> using adcli und sssd. Checking the log reveals that the kerberos tickets 
> stored in  /etc/krb5.keytab do not have the expected KVON. At the moment we 
> can’t tell what’s causing the issue. It happens only sporadically. I’m under 
> the impression only computer without permanent network connection (Laptops) 
> are affected.
>
> The log shows:
>
> Jan 11 09:30:52 lc015564 systemd[1]: Starting System Security Services 
> Daemon...
> Jan 11 09:30:52 lc015564 sssd[1376]: Starting up
> Jan 11 09:30:52 lc015564 sssd_be[1609]: Starting up
> Jan 11 09:30:52 lc015564 sssd_ifp[1633]: Starting up
> Jan 11 09:30:52 lc015564 systemd[1]: Started System Security Services Daemon.
> Jan 11 09:30:55 lc015564 sssd_be[1609]: Backend is offline
> Jan 11 09:49:32 lc015564 sssd_be[1609]: Backend is online
> Jan 11 09:49:41 lc015564 krb5_child[6111]: Cannot find key for 
> LC015564$@WAGO.LOCAL kvno 11 in keytab
> Jan 11 09:49:41 lc015564 krb5_child[6111]: Cannot find key for 
> LC015564$@WAGO.LOCAL kvno 11 in keytab
> Jan 11 09:49:49 lc015564 adcli[6102]: GSSAPI client step 1
> Jan 11 09:49:49 lc015564 adcli[6102]: GSSAPI client step 1
> Jan 11 09:49:50 lc015564 adcli[6102]: GSSAPI client step 1
> Jan 11 10:00:57 lc015564 krb5_child[6838]: Cannot find key for 
> LC015564$@WAGO.LOCAL kvno 11 in keytab
> Jan 11 10:00:57 lc015564 krb5_child[6838]: Cannot find key for 
> LC015564$@WAGO.LOCAL kvno 11 in keytab
>
> And klist -k shows:
>
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
>  
> --
>   10 LC015564$@WAGO.LOCAL
>   10 LC015564$@WAGO.LOCAL
>   10 LC015564$@WAGO.LOCAL
>   10 host/LC015564@WAGO.LOCAL
>   10 host/LC015564@WAGO.LOCAL
>   10 host/LC015564@WAGO.LOCAL
>   10 host/lc015564.wago.local@WAGO.LOCAL
>   10 host/lc015564.wago.local@WAGO.LOCAL
>   10 host/lc015564.wago.local@WAGO.LOCAL
>   10 RestrictedKrbHost/LC015564@WAGO.LOCAL
>   10 RestrictedKrbHost/LC015564@WAGO.LOCAL
>   10 RestrictedKrbHost/LC015564@WAGO.LOCAL
>   10 RestrictedKrbHost/lc015564.wago.local@WAGO.LOCAL
>   10 RestrictedKrbHost/lc015564.wago.local@WAGO.LOCAL
>   10 RestrictedKrbHost/lc015564.wago.local@WAGO.LOCAL
>9 LC015564$@WAGO.LOCAL
>9 LC015564$@WAGO.LOCAL
>9 LC015564$@WAGO.LOCAL
>9 host/LC015564@WAGO.LOCAL
>9 host/LC015564@WAGO.LOCAL
>9 host/LC015564@WAGO.LOCAL
>9 host/lc015564.wago.local@WAGO.LOCAL
>9 host/lc015564.wago.local@WAGO.LOCAL
>9 host/lc015564.wago.local@WAGO.LOCAL
>9 RestrictedKrbHost/LC015564@WAGO.LOCAL
>9 RestrictedKrbHost/LC015564@WAGO.LOCAL
>9 RestrictedKrbHost/LC015564@WAGO.LOCAL
>9 RestrictedKrbHost/lc015564.wago.local@WAGO.LOCAL
>9 RestrictedKrbHost/lc015564.wago.local@WAGO.LOCAL
>9 RestrictedKrbHost/lc015564.wago.local@WAGO.LOCAL
>
> This is a our sssd.conf (it's from o different computer):
>
> [sssd]
> domains = wago.local
> config_file_version = 2
> services = ifp
>
> [domain/wago.local]
> default_shell = /bin/bash
> fallback_homedir = /home/%d/%u
> cache_credentials = true
> krb5_store_password_if_offline = true
> krb5_realm = WAGO.LOCAL
> krb5_ccname_template = /tmp/krb5cc_%U
> realmd_tags = manages-system joined-with-adcli
> id_provider = ad
> access_provider = ad
> ad_domain = wago.local
> ad_enabled_domains = wago.local
> ad_hostname = lc017547.wago.local
> use_fully_qualified_names = false
> ldap_id_mapping = true
> ldap_user_gecos = displayName
> ldap_use_tokengroups = false
> ldap_search_base = dc=wago,dc=local?subtree?
> ldap_user_search_base = 
> ou=User,ou=Minden,ou=Germany,dc=wago,dc=local?subtree??ou=User,ou=Administration,dc=wago,dc=local?onelevel?(&(objectClass=user)(cn=a2*))?ou=Service,dc=wago,dc=local?subtree?
> ldap_group_search_base = 
> cn=Users,dc=wago,dc=local?onelevel?(&(objectClass=group)(cn=Domain 
> Users))?ou=Groups,ou=Minden,ou=Germany,dc=wago,dc=local?onelevel?(&(objectClass=group)(cn=&01-PC-Support))
> ldap_netgroup_search_base = cn=Users,dc=wago,dc=local?onelevel?
> ignore_group_members = true
> enumerate = false
> dyndns_update = true
> dyndns_refresh_interval = 7200
> dyndns_update_ptr = true
> dyndns_server = 10.1.100.2
> case_sensitive = Preserving
>
> [nss]
> filter_users = root
> filter_groups = root
>
> [pam]
> offline_credentials_expiration = 0
>