Typically only one “auth” method (plugin) should be enabled in DansGuardian.

More than one auth plugin can be enabled and the results will be determinate/replicable.
But the behavior nay not be what you expect;
in fact it might not even be what a human would consider “reasonable”.

There are a few possible uses of multiple auth plugins.
But these are resctricted to rather specific environments,
and even then require rather careful configuration.

When more than one “auth” method is enabled,
DansGuardian tries each one in turn in the order they're listed in dansguardian.conf. (This is sometimes called “stacking”.)
If the current “auth” method returns a match,
that match is accepted and no further “auth” methods are executed.
If on the other hand the current “auth” method does not find a match,
execution continues with the next auth plugin.

If none of the auth methods find a match,
then that request is assigned to the default filter group f1 for the moment.
However on the very next exchange the whole auth process will occur all over again.
This will continue on every exchange until something finally matches.
Once a match is finally found, it will be retained and reused as long as the Browser↔DansGuardian circuit persists.

As some auth plugins “sniff” information elicited by the back end (Squid?)
while others obtain information on their own,
and as some auth plugins never match a partial exchange in a different format,
and as some auth plugins complete on the first exchange
whereas others (Digest and NTLM)
only complete on the second exchange,
the behavior can be quite complex.

These two types of multiple “auth” configurations, although sometimes legitimate, are especially often associated with problems:

Mixing any of the two-stage auth plugins (Digest, NTLM) with any of the one-stage auth plugins (BASIC, Ident, IP) where a one-stage auth plugin may match on the first exchange is especially likely to not behave as expected. The two-stage methods will of course always “fail” temporarily on the first exchange. This can give another method a chance to succeed before the second exchange ever occurs. So the two-stage methods may never match at all, and matches won't occur in the same order as the plugins are listed in dansguardian.conf.

Mixing any of the “person” auth methods (BASIC, Digest, NTLM, Ident) with the “machine” method (IP) will not “combine” the userid and the IP in any rational way. Each of the plugins will simply operate in complete isolation from the others, and the results may not be what you expect. (Such a configuration can be useful in the case where some subnets should be assigned to partcular filter groups, and everybody else should be assigned to different filter groups depending on their userid. But in all other cases such a configuration is probably not useful. )

If your user population is a mix of different operating systems (Linux, Windows, MacOS, etc.)
and a mix of different web browsers (IE, Firefox, Safari, etc.)
multiple auth method may be required to make everything work.

Note though that it's increasingly the case that NTLM (including its optional user display
and its optional fallback to BASIC) can act an a lingua franca. Modern browsers increasingly
provide some sort of support (perhaps manual, but still more than nothing) for NTLM, even on non-Windows operating systems.

If NTLM is used initially in all cases, but you know it will sometimes fail,
you may explicitly configure BASIC as a fallback.
(Even though common, this may not actually be necessary,
as NTLM may provide a sufficient internal fallback.
See Fallback Operation.)

In this case both the NTLM and BASIC DansGuardian auth plugins should be enabled.
(Note though enabling both only makes sense if the proxy (Squid?) configuration really can request
both NTLM and BASIC credentials.)

If you have s separate “admin” or “privileged” subnet that should be treated one way,
while everybody else should be assigned to different filter groups the usual way depending on their userid,
enable both the IP auth plugin and one of the other auth plugins and make sure the IP auth plugin is first.
In …/lists/authplugins/ipgroups list all those computers that should be authorized
simply by their IP address.
Computers whose IP address doesn't match will fall through to the next auth plugin and be assigned by userid.

You must ensure that your proxy (Squid?) configuration exactly matches your DansGuardian configuration.
Specifically, every IP address that the DansGuardian IP auth method recognizes
must be excepted from any credentials requirement of the proxy (Squid?).
Thus the proxy (Squid?) will request credentials only from the clients who will never match DansGuardian IP auth.
This is easier to maintain if either your configuration is generated automatically
(so the DansGuardian portion and the Squid portion are always in sync)
or if the IP addresses to be authed are an entire separately routable network such as a DMZ.