This is a negative test scenario for samba 3.0.20 and 3.0.21c Used AD at Windows 2003 SP1 server for this scenario. Network configuration: ---- samba client ------ Windows 2003 SP1 server ----- Windows 2003 SP1 server runs a name service The steps to reproduce the problem: 1. create the valid smb.conf and krb5.conf for ADS authentication below 2. configure DC as a name server; # more /etc/resolv.conf search eng.test.com nameserver 2.9.192.20 3. register (with ADS option) the samba client in AD’s Computers section with successful result # net ads join -U Administrator%password Using short domain name -- ENG Joined 'CLIENT-11' to realm 'ENG.TEST.COM' 4. samba client leaves/unregister (with ADS option) AD’s Computers section successfully # net ads leave -U Administrator%password Removed 'CLIENT-11' from realm 'ENG.TEST.COM' 5. modify the name server configuration, where the primary name server is unreachable (bogus) ip address. The secondary name server is valid ip address of DC where DNS is running # more /etc/resolv.conf search eng.test.com nameserver 1.1.1.1 <----- bogus the primary nameserver nameserver 2.9.192.20 6. register (with ADS option) the samba client in AD’s Computers section # net ads join -U Administrator%password samba client registration hangs forever until Ctrl+C is executed to terminate the command 7. register (with RPC option) the samba client in AD’s Computers section with successful result # net rpc join -U Administrator%password Joined domain ENG. #testparm Load smb config files from /etc/samba/smb.conf WARNING: The "printer admin" option is deprecated Processing section "[print$]" Processing section "[printers]" Loaded services file OK. Server role: ROLE_DOMAIN_MEMBER Press enter to see a dump of your service definitions [global] workgroup = ENG realm = ENG.TEST.COM security = ADS client schannel = No password server = 2.9.192.20, * log level = 5 log file = /local/local1/errorlog/samba.log max log size = 1000 smb ports = 50139 lpq cache time = 10 socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 printcap cache time = 60 printcap name = cups preferred master = No local master = No domain master = No dns proxy = No wins server = 2.9.192.20 ldap ssl = start tls idmap uid = 70000-200000 idmap gid = 70000-200000 template homedir = /local/local1/ template shell = /admin-shell winbind cache time = 900 winbind enum users = No winbind enum groups = No winbind use default domain = Yes comment = test printing printer admin = @cupsAdmin cups options = "raw" default devmode = Yes force printername = Yes [print$] path = /state/samba/printers write list = @cupsAdmin force user = root force group = root guest ok = Yes [printers] path = /local/local1/spool/samba guest ok = Yes printable = Yes browseable = No # more /etc/krb5.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] ticket_lifetime = 24000 default_realm = ENG.TEST.COM dns_lookup_realm = false dns_lookup_kdc = false [realms] ENG.TEST.COM = { kdc = server-2003-ent1.eng.test.com:88 admin_server = server-2003-ent1.eng.test.com:749 default_domain = ENG.TEST.COM } [domain_realm] .eng.test.com = ENG.TEST.COM eng.test.com = ENG.TEST.COM [kdc] profile = /var/kerberos/krb5kdc/kdc.conf [pam] debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false
this works fine for me, using heimdal kerberos. I'm suspecting you're using MIT? If their libs don't properly handle a DNS server being down, then there's nothign we can do. If you can get a sniffer trace and level 10 debug and attach them here, i'll look at it.
This is correct. The client uses MIT Kerberos library. tcpdump on port 53 (DNS) indicates the bogus name server 1.1.1.1 is contacted only.
I'm looking for more than just what nameserver was contacted. I'm trying to figure out what stage it's at. If it's the krb5 libs doing it, there's not much we can do about it. A level 10 debug log would help...
Yep, this appears to be a bug in krb5_get_init_creds_password(). It never returns if the dns server is bad. Looking at a sniffer trace, we manage to get a TGT, but then no further krb5 traffic occurs. Stepping through with gdb, the call in kerberos_kinit_password_ext() to krb5_get_init_creds_password() never returns. So this is a bug in MIT libs, not samba. Sorry, we can't do anything about the samba piece. *** This bug has been marked as a duplicate of 3672 ***