samba - Feb 2020 - Unable to get primary group information when using AD authentication with samba-4.10.4

Hi,

When using AD authentication from a rhel8.1 environment with samba-4.10.4
installed, information on the primary group group01 set on
the AD side for any user user01 cannot be obtained.
[root @ rhel8_1 ~] # id user01
uid=2001107(user01) gid=2000513(domain users) groups=2000513(domain
users),2001107(oec0814e),2001103(group01)
If you perform the same operation on the same AD from the samba-3.6.23 rhel6.6
environment, you will get the correct information as
follows:
[root @ rhel6_6 ~] # id user01
uid=2001107(user01) gid=2001103(group01) groups=2000513(domain users),
2001107(oec0814e)

Regarding this, from the support contact of the OS system, "It seems that
there was a problem with samba-4.9.1-8.el8 (RHEL8.0), but
it has been resolved with samba-4.10.0-1.el8" I received information.
"However, it is necessary to log in once with the relevant user using"
wbinfo -a "." After actually executing "whois -a" arbitrary
user% that user's password ", the primary group information set in AD
on the implementation Linux side could be obtained.
root @ rhel8_1 ~] # id user01
uid=2001107(user01) gid=2000513(domain users) groups=2000513(domain users),
2001107(oec0814e),2001103(group01)
[root @ rhel8_1 ~] # wbinfo -i user01
user01:*:2001107:2000513::/home/Domain Users/user01:/bin/bash
[root @ rhel8_1 ~] # wbinfo -a user01% passwd.12
plaintext password authentication succeeded
challenge / response password authentication succeeded
[root @ rhel8_1 ~] # wbinfo -i user01
user01:*:2001107:2001103:user01:/home/group01/user01:/bin/bash
[root @ rhel8_1 ~] # id user01
uid = 2001107 (user01) gid = 2001103 (group01)
groups=2001103(group01),2001107(user01),2000513(domain users)
[root @ rhel8_1 ~] #

However, this is not the solution in my case. Because there are already hundreds
of users registered on the AD server so far, most
of them have set their own passwords, and I can not know those passwords.
In addition, we cannot ask each user to start the interface program to execute
"wbinfo -a" and re-enter the password.

Is there any way to get the primary group of AD registered user on rhel8.1 side
by batch processing without using each user's
password?

Thanks
R.G.

On 19/02/2020 02:16, Goto, Ryoichi via samba wrote:
> Hi,
>
> When using AD authentication from a rhel8.1 environment with samba-4.10.4
installed, information on the primary group group01 set on
> the AD side for any user user01 cannot be obtained.
> [root @ rhel8_1 ~] # id user01
> uid=2001107(user01) gid=2000513(domain users) groups=2000513(domain
users),2001107(oec0814e),2001103(group01)
> If you perform the same operation on the same AD from the samba-3.6.23
rhel6.6 environment, you will get the correct information as
> follows:
> [root @ rhel6_6 ~] # id user01
> uid=2001107(user01) gid=2001103(group01) groups=2000513(domain users),
2001107(oec0814e)
>
> Regarding this, from the support contact of the OS system, "It seems
that there was a problem with samba-4.9.1-8.el8 (RHEL8.0), but
> it has been resolved with samba-4.10.0-1.el8" I received information.
> "However, it is necessary to log in once with the relevant user
using" wbinfo -a "." After actually executing "whois
-a" arbitrary
> user% that user's password ", the primary group information set in
AD on the implementation Linux side could be obtained.
> root @ rhel8_1 ~] # id user01
> uid=2001107(user01) gid=2000513(domain users) groups=2000513(domain users),
2001107(oec0814e),2001103(group01)
> [root @ rhel8_1 ~] # wbinfo -i user01
> user01:*:2001107:2000513::/home/Domain Users/user01:/bin/bash
> [root @ rhel8_1 ~] # wbinfo -a user01% passwd.12
> plaintext password authentication succeeded
> challenge / response password authentication succeeded
> [root @ rhel8_1 ~] # wbinfo -i user01
> user01:*:2001107:2001103:user01:/home/group01/user01:/bin/bash
> [root @ rhel8_1 ~] # id user01
> uid = 2001107 (user01) gid = 2001103 (group01)
groups=2001103(group01),2001107(user01),2000513(domain users)
> [root @ rhel8_1 ~] #
>
> However, this is not the solution in my case. Because there are already
hundreds of users registered on the AD server so far, most
> of them have set their own passwords, and I can not know those passwords.
> In addition, we cannot ask each user to start the interface program to
execute "wbinfo -a" and re-enter the password.
>
> Is there any way to get the primary group of AD registered user on rhel8.1
side by batch processing without using each user's
> password?
>
> Thanks
> R.G.
>
>
Can you please post your smb.conf

Rowland

On 19/02/2020 09:18, Goto, Ryoichi wrote:
>> Can you please post your smb.conf
> Thank you for your reply.
> It is like this.
>
> [global]
>          kerberos method = secrets and keytab
>          realm = TESTDOM.LOCAL
>          workgroup = TESTDOM
>          password server = adsv.testdom.local
>          security = ads
>          winbind enum groups = Yes
>          winbind enum users = Yes
>          winbind separator = +
>          winbind use default domain = true
>          winbind offline logon = false
>          template homedir = /home/%g/%u
>          template shell = /bin/bash
>          idmap uid = 16777216-33554431
>          idmap gid = 16777216-33554431
>
>
>
One of two things is going on here, either you are using sssd or your 
smb.conf is badly configured, which is it ?

Rowland

'wbinfo -a' is basically the same as logging in, but you should be able 
to get a users primary group without the user logging in, this will 
depend on what you mean by 'primary group'. On Windows, every users 
primary group is 'Domain Users' and when you make a Unix computer a 
domain member, Unix users get the same primary group by default. Before 
Samba 4.6.0 there was no way of changing this, but from 4.6.0, you can 
give your users a gidNumber attribute containing the ID number of a 
group (don't user the ID for Domain Users, there is no point), then, 
provided smb.conf is configured correctly, your users will get a 
different primary group.

Try this smb.conf:

[global]
 ??? kerberos method = secrets and keytab
 ??? realm = TESTDOM.LOCAL
 ??? workgroup = TESTDOM
 ??? security = ads
 ??? winbind use default domain = true
 ??? winbind expand groups = 2
 ??? winbind refresh tickets = Yes

 ??? idmap config * : backend = tdb
 ??? idmap config * : range = 3000-7999
 ??? idmap config TESTDOM : backend = ad
 ??? idmap config TESTDOM : range = 16777216-33554431
 ??? idmap config TESTDOM : schema_mode = rfc2307
 ??? idmap config TESTDOM : unix_nss_info = yes
 ??? idmap config TESTDOM : unix_primary_group = yes

 ??? # If you do not have the relevant rfc2307 attributes in AD
 ??? # uncomment the next two lines.
 ??? #template homedir = /home/%g/%u
 ??? #template shell = /bin/bash

 ??? vfs objects = acl_xattr
 ??? map acl inherit = Yes

 ??? username map = /etc/samba/user.map

Run this in a terminal:

echo '!root = TESTDOM\Administrator' > /etc/samba/user.map

Restart Samba

The reason I mentioned sssd was this: idmap uid = 16777216-33554431

 From memory, that range is synonymous with sssd and will mean that your 
users & groups will need to have uidNumber & gidNumber attributes 
containing numbers inside that range.

If your users & groups do not have uidNumber & gidNumber attributes 
containing numbers inside that range, you must find your lowest & 
highest Unix IDs and base the range around those.

On 21/02/2020 04:54, Goto, Ryoichi wrote:
> Thank you for very easy-to-understand and courteous advice.
I reread your initial post and noticed something that I missed earlier, 
you had in smb.conf:

 ??????? idmap uid = 16777216-33554431
 ??????? idmap gid = 16777216-33554431

Yet, you were getting results like this:

id user01
uid=2001107(user01) gid=2000513(domain users) groups=2000513(domain 
users),2001107(oec0814e),2001103(group01)

'2000513' is less than '16777216'

Are you sure that you do not have sssd installed ?

On top of the Samba packages you have installed, I would also expect:

samba.x86_64
samba-client-libs
samba-common
samba-common-tools
samba-winbind-clients

/etc/krb5 should just be this:

[libdefaults]
 ???????? default_realm = TESTDOM.LOCAL
 ???????? dns_lookup_realm = false
 ???????? dns_lookup_kdc = true

Also, remove the link:

rm -rf /etc/krb5.conf.d/crypto-policies

On a Centos 8 Unix domain member using the winbind 'rid' backend:

getent passwd rowland
rowland:*:11107:10513::/home/rowland:/bin/bash

Change to using the 'ad' backend, restart Samba and run 'net cache
flush' :

getent passwd rowland
rowland:*:10000:10010:Rowland Penny:/home/rowland:/bin/bash

id rowland
uid=10000(rowland) gid=10010(group12) groups=10010(group12),10000(domain 
users),

I hope you can see that before the change 'rowland' had 'Domain
Admins'
as the primary group, but now has 'group12'

Rowland

On 26/02/2020 09:50, Goto, Ryoichi wrote:
> Mr. Roland
> I'm sorry I couldn't respond for a while for my convenience, even
though I had answered my answer immediately.
> And sssd was installed on my server as you pointed out.
> Immediately, remove all sssd related packages, remove the link of
/etc/krb5.conf.d/crypto-policies, modify /etc/krb5.conf, and
> install only samba.x86_64 for samba. Since it did not exist, I put it in
and restarted with automatic start of smb.service.
> However, the symptom that the user displayed by "wbinfo -u" does
not accept "id", "wbinfo -i", or "getent passwd"
does not go away.
> In the smb.conf
> If I comment out "idmap config OITA-NHS: backend = ad", I will
not be able to get the collect primary group, but I will be able to
> recognize users with commands such as id.
>
>
> [root at ms ~]# wbinfo -u
> administrator
> guest
> defaultaccount
> krbtgt
> oec0814e
> oec1364e
> oec_user01
> oec_user02
> [root at ms ~]# id oec_user01
> id: `oec_faculty01': no such user
> [root at ms ~]# getent passwd oec_user01
> [root at ms ~]#
>
Can you post the contents of the following files:

/etc/resolv.conf

/etc/hostname

/etc/hosts

/etc/krb5.conf

/etc/samba/smb.conf

/etc/nsswitch.conf

I have a Samba Unix domain member running on Centos 8 and it works, but 
I did have to turn Selinux off.

Comparing your files with mine, may point to an error.

Rowland

On 28/02/2020 06:51, Goto, Ryoichi wrote:
> Mr. Roland,
> I missed the instruction email from you. sorry.
>
OK, I just installed:

samba samba-winbind samba-winbind-clients krb5-workstation

I removed these:

sssd sssd* realmd

Now for your files:

Your /etc/hostname is wrong, it should contain only your computers short 
hostname: ms2

/etc/hosts should look like this (if using dhcp):

127.0.0.1?? localhost
::1???????? localhost

However, if the computer has a fixed IP, then you also need a line like 
this:

ComputerIP ms2.tesstdom.local ms2

Run this: rm -f /etc/krb5.conf.d/crypto-policies

Then make /etc/krb5.conf look like this:

[libdefaults]
 ??? default_realm = TESTDOM.LOCAL
 ??? dns_lookup_realm = false
 ??? dns_lookup_kdc = true

Change /etc/nsswitch.conf to this:

#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Valid entries include:
#
#??? nisplus??? ??? ??? Use NIS+ (NIS version 3)
#??? nis??? ??? ??? Use NIS (NIS version 2), also called YP
#??? dns??? ??? ??? Use DNS (Domain Name Service)
#??? files??? ??? ??? Use the local files in /etc
#??? db??? ??? ??? Use the pre-processed /var/db files
#??? compat??? ??? ??? Use /etc files plus *_compat pseudo-databases
#??? hesiod??? ??? ??? Use Hesiod (DNS) for user lookups
#??? [NOTFOUND=return]??? Stop searching if not found so far
#

passwd:????? files winbind systemd
shadow:????? files systemd
group:?????? files winbind systemd

hosts:????? files dns myhostname

bootparams: files

ethers:???? files
netmasks:?? files
networks:?? files
protocols:? files
rpc:??????? files
services:?? files

netgroup:?? nis

publickey:? files

automount:? files
aliases:??? files

/etc/resolv.conf looks okay, provided that 172.16.84.5 is the IP of a DC.

Try this /etc/samba/smb.conf

[global]
 ??????? workgroup = TESTDOM
 ??????? security = ADS
 ??????? realm = TESTDOM.LOCAL

 ??????? dedicated keytab file = /etc/krb5.keytab
 ??????? kerberos method = secrets and keytab

 ??????? winbind use default domain = yes
 ??????? winbind expand groups = 2
 ??????? winbind refresh tickets = Yes

 ??????? log file = /var/log/samba/%m.log
 ??????? log level = 3

 ??????? idmap config * : backend = tdb
 ??????? idmap config * : range = 3000-7999
 ??????? idmap config TESTDOM : backend = ad
 ??????? idmap config TESTDOM : range = 10000-999999
 ??????? idmap config TESTDOM : schema_mode = rfc2307
 ??????? idmap config TESTDOM : unix_nss_info = yes
 ??????? template shell = /bin/bash
 ??????? template homedir = /home/%U

 ??????? domain master = no
 ??????? local master = no
 ??????? preferred master = no

 ??????? # user Administrator workaround, without it you are unable to 
set privileges
 ??????? username map = /etc/samba/user.map

 ??????? # For ACL support on domain member
 ??????? vfs objects = acl_xattr
 ??????? map acl inherit = Yes

 ??????? log file = /var/log/samba/log.%m
 ??????? max log size = 50
 ??????? log level = 4

The only other thing I would comment on is, you shouldn't use
'.local'
as your TLD, it is reserved for Bonjour and Avahi.

Rowland

On 28/02/2020 10:15, Goto, Ryoichi wrote:
> Hi, Rowland.
> Thank you for your answer.
>
>> I removed these:
>>
>> sssd sssd * realmd
> Did this:
> [root @ ms2 ~] # rpm -qa | grep realmd
> [root @ ms2 ~] # rpm -qa | grep sss
> libsss_certmap-2.2.0-19.el8.x86_64
> sssd-common-2.2.0-19.el8.x86_64
> libsss_sudo-2.2.0-19.el8.x86_64
> sssd-client-2.2.0-19.el8.x86_64
> sssd-nfs-idmap-2.2.0-19.el8.x86_64
> sssd-kcm-2.2.0-19.el8.x86_64
> libsss_idmap-2.2.0-19.el8.x86_64
> libsss_nss_idmap-2.2.0-19.el8.x86_64
> libsss_autofs-2.2.0-19.el8.x86_64
> [root @ ms2 ~] # dnf remove sssd-common-2.2.0-19.el8.x86_64
sssd-client-2.2.0-19.el8.x86_64 sssd-nfs-idmap-2.2.0-19.el8.x86_64
> sssd-kcm-2.2.0-19.el8.x86_64
>
>> Your / etc / hostname is wrong, it should contain only your computers
short
>> hostname: ms2
> It has changed.
>   
>> / etc / hosts should look like this (if using dhcp):
>>
>> 127.0.0.1 localhost
>> :: 1 localhost
> Added the following:
> 172.16.0.72 ms2.testdom.local ms2
>
>> Run this: rm -f /etc/krb5.conf.d/crypto-policies
> I ran it.
>
>> Change /etc/nsswitch.conf to this:
> I ran it.
>
>> Try this /etc/samba/smb.conf
> I did that.
>
> Deleted the contents of / var / log / samba / log * and restarted nmd,
winbind and smbd.
>
>
>
> As a result, you cannot get the user information correctly.
> [root @ ms2 ~] # wbinfo -i oec0814e
> failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
> Could not get info for user oec0814e
> [root @ ms2 ~] # wbinfo -i oec_faculty01
> failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
> Could not get info for user oec_faculty01
> [root @ ms2 ~] # id oec_faculty01
> id: `oec_faculty01 ': no ??such user
> [root @ ms2 ~] #
>
>
> For me, "idmap backend ad not found" in
/var/log/samba/log.winbindd-idmap
> [2020/02/28 04: 40: 06.613958, 4]
../../source3/winbindd/winbindd_dual.c:1597(child_handler)
>    child daemon request 56
> [2020/02/28 04: 40: 06.614260, 3]
../../source3/winbindd/idmap.c:397(idmap_init_domain)
>    idmap backend ad not found
> [2020/02/28 04: 40: 06.620853, 3]
../../lib/util/modules.c:167(load_module_absolute_path)
>    load_module_absolute_path: Module '/usr/lib64/samba/idmap/ad.so'
loaded
Yes, but it then goes on to load the module.

Try running this:

authconfig --enablewinbind --enablewinbindauth --enablemkhomedir --update

Run: net ads info

It should produce something like this:

LDAP server: 192.168.0.8
LDAP server name: dc8.samdom.example.com
Realm: SAMDOM.EXAMPLE.COM
Bind Path: dc=SAMDOM,dc=EXAMPLE,dc=COM
LDAP port: 389
Server time: Fri, 07 Feb 2020 14:24:49 GMT
KDC server: 192.168.0.8
Server time offset: 1
Last machine account password change: Fri, 07 Feb 2020 14:20:09 GMT

Does 'wbinfo -u' display your AD users ?

Do your users have a uidNumber attribute inside '10000-999999' and 
Domain Users a gidNumber inside the same range ?

If not, change this:

 ??????? idmap config TESTDOM : backend = ad
 ??????? idmap config TESTDOM : range = 10000-999999
 ??????? idmap config TESTDOM : schema_mode = rfc2307
 ??????? idmap config TESTDOM : unix_nss_info = yes

To this:

 ??????? idmap config TESTDOM : backend = rid
 ??????? idmap config TESTDOM : range = 10000-999999

Rowland

On 02/03/2020 00:45, Goto, Ryoichi wrote:
> [root @ ms2 ~] # wbinfo -i oec_faculty02
> oec_faculty02: *: 11110: 10513 :: / home / Domain Users / oec_faculty02: /
bin / bash
> [root @ ms2 ~] # id oec_faculty02
> uid = 11110 (oec_faculty02) gid = 10513 (domain users) groups = 10513
(domain users), 11110 (oec_faculty02), 11105 (faculty),
> 1000001 (BUILTIN \ users)
If it doesn't work on a Unix domain member using the 'ad' backend,
but
does with the 'rid' backend, then this probably means that you do not 
have the required uidNumber & gidNumber attributes in AD. They are not 
added automatically and xidNumber attributes found on a DC are not the 
same as uidNumber & gidNumber attributes.

Rowland

On 02/03/2020 09:21, Goto, Ryoichi wrote:
> Hi, Rowland.
>
> As stated in the first query on February 29, why does the samba-3.6.23
rhel6.6 environment produce the expected results?
I have no idea, I can only go off the info provided. If the 'ad' backend
produces no output, this usually means that the users do not have a 
uidNumber containing a number inside the 'DOMAIN' range and/or Domain 
Users does not have a gidNumber containing a number inside the same range.

Switching to the 'rid' backend usually proves this, if you get users 
with 'getent passwd' or 'id', then this proves there is
connection to AD
and that there is either a problem with the uidNumber & gidNumber 
attributes, or there are none.
> Or why run 'wbinfo -a username% password' even if it is 'rid
backend', and log in once and get the information successfully?
>
The problem is that Samba cannot get the full list of a users groups 
unless the user has logged in, which is what 'wbinfo -a' does. However, 
does it really matter if you do not get a full list of a users groups 
without running 'wbinfo -a', the user will get a full list when they log
in.

Rowland

On 03/03/2020 01:19, Goto, Ryoichi wrote:
> In conjunction with the former, if I interpret it as "I first recorded
'idmap backend ad not found', but eventually loaded and
> resolved as '/usr/lib64/samba/idmap/ad.so'" Is it good?
Yes
>
> One more thing I want to check is that I mentioned in the previous mail,
but there was a specification change between "samba-3.6.23
> rhel6.6" and "samba-4.10.4-101 rhel8.1". Is it? " If
you have any information about this, please let me know.
There are too many to list, not least is that you can now use Samba as 
an AD DC, but see here for the release notes:

https://wiki.samba.org/index.php/Samba_Features_added/changed_(by_release)#Samba_4.6_Features_added.2Fchanged

Rowland

On 03/03/2020 02:47, Goto, Ryoichi wrote:
> Users who run 'wbinfo -a USERNAME% PASSWORD' will get the expected
results even after rebooting the machine.
> Being the user who ran 'wbinfo -a' and where will the resulting
information be stored?
I don't really see why a user needs to run 'wbinfo -a' in the first
place ?

There were changes made to winbind that made it so users couldn't get a 
reliable list of groups for another user, but a user will always get a 
reliable list of their groups from AD. A user running 'wbinfo -a 
another_user' is basically logging in as that user.

Rowland

On 03/03/2020 11:07, Goto, Ryoichi wrote:
>> I don't really see why a user needs to run 'wbinfo -a' in
the first place ?
> It's not my purpose to look at the meaning of the wbinfo commands while
being rude.
I wasn't aiming my comments at you ;-)
> My goal was to see if the administrator of a mail server using AD
authentication could just use the "wbinfo -a" as a means to find
> out the group name of the recipients of mail arriving at that server.
> Unfortunately, my goal doesn't seem to be achieved with "wbinfo
-a", so I'll look at alternatives.
Ah, I understand your problem a bit better now, it sounds like you want 
to check if a user is member of a specific group before delivering mail. 
If so, this is probably possible with a script or modification of your 
email servers configuration.

Rowland

Am 03.03.20 um 12:22 schrieb Rowland penny via samba:
>> My goal was to see if the administrator of a mail server using AD
>> authentication could just use the "wbinfo -a" as a means to
find
>> out the group name of the recipients of mail arriving at that server.
>> Unfortunately, my goal doesn't seem to be achieved with
"wbinfo -a",
>> so I'll look at alternatives.
For this we are using Postfix LDAP alias maps:

http://www.postfix.org/LDAP_README.html#example_alias

Works great for us.


Regards


Christian

-- 
Dr. Christian Naumer
Unit Head Bioprocess Development
B.R.A.I.N Aktiengesellschaft
Darmstaedter Str. 34-36, D-64673 Zwingenberg
e-mail cn at brain-biotech.com, homepage www.brain-biotech.com
fon +49-6251-9331-30  /   fax +49-6251-9331-11

Sitz der Gesellschaft: Zwingenberg/Bergstrasse
Registergericht AG Darmstadt, HRB 24758
Vorstand: Adriaan Moelker (Vorstandsvorsitzender), 
Manfred Bender, Ludger Roedder
Aufsichtsratsvorsitzender: Dr. Georg Kellinghusen

On 11/03/2020 23:53, Goto, Ryoichi wrote:
> Hi, Rowland.
>
> Two days ago I sent the following email:
> So far you have given the answer that day, but this time it has not.
> Would you please reply to my email if you like?
> I used the property / attribute editor on the AD side and set the values
??of gidNumber and uidNumber of the user within the range.
> The "wbinfo -i" command gives the error "unknown user".
Is there any other reason why the "ad" backend doesn't work? For
example, it
> uses Redhat's samba package.
>
> Running "wbinfo -i" or "id":
> [root @ ms2 ~] # net ads join -U administrator
> Enter administrator's password:
> Using short domain name-TESTDOM
> Joined 'MS2' to dns domain 'oita-nhs.local'
> [root @ ms2 ~] # wbinfo -i oec0814e
> failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
> Could not get info for user oec0814e
> [root @ ms2 ~] # id oec0814e
> id: `oec0814e ': no ??such user
> [root @ ms2 ~] # wbinfo -u
> oec0814e
As far as I am aware, you should be able use any OS Samba packages as a 
Unix domain member, it is just certain OS's that do not provide packages 
that can be used as a DC.

What is worrying is that 'wbinfo -i' doesn't work. 'wbinfo'
should go
direct to AD (via winbind), so is there a firewall blocking any of the 
required ports ? see here: 
https://wiki.samba.org/index.php/Samba_AD_DC_Port_Usage

Is Selinux or Apparmor running ?

Is sssd installed ?

This should work and when it doesn't, it is usually down to a 
misconfiguration or missing uidNumber or gidNumber attributes. At a 
minimum, any user you wish to be visible on a Unix domain member must 
have a uidNumber and the Domain Users group must be have a gidNumber.

Try running 'net cache flush'

Rowland