Samba AD hitelesítési probléma ("DNS hiba")

Fórumok

Sziasztok!
Néhány adat a probléma részletezése előtt:

# hostname --fqdn
adsamba.suli.lan


# ip addr ls eno1
2: eno1: mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:1e:c9:xx:yy:zz brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/16 brd 10.1.255.255 scope global eno1
valid_lft forever preferred_lft forever

Egy hónapja Debian 9-en telepítettem a Samba 4.5.8-as verzióját. AD-ként állítottam be a provision parancs ez volt:

# samba-tool domain provision \
--domain=SULI \
--realm=suli.lan \
--server-role=dc \
--use-xattrs=yes \
--use-rfc2307 \
--adminpass=xyz \
--dns-backend=SAMBA_INTERNAL \
--ldapadminpass=zyx

Tegnapig működött is szépen, azonban tegnap reggel óta (a telepítés után pontosan egy hónap elteltével) nem lehet belépni a tartományi felhasználói nevekkel. Vagyis be lehet lépni, de csak ideiglenes felhasználói profillal, és nem csatolja fel a hálózati megosztásokat, home könyvtárat, tehát a csoportházirend sem érvényesül. Kiléptettem a gépet (Win10), de utána azonban már be sem tudtam léptetni a gépet a tartományba, azzal a hibaüzenettel, hogy "Helytelen a felhasználónév vagy a jelszó".

A telepítés után az első parancsok egyike voltak a következők:

# samba-tool user setexpiry --noexpiry administrator
# samba-tool domain passwordsettings set --max-pwd-age=0

A jelszavakra vonatkozó beállítások az alábbiak:

# samba-tool domain passwordsettings show
Password informations for domain 'DC=suli,DC=lan'

Password complexity: off
Store plaintext passwords: off
Password history length: 24
Minimum password length: 7
Minimum password age (days): 1
Maximum password age (days): 0
Account lockout duration (mins): 30
Account lockout threshold (attempts): 0
Reset account lockout after (mins): 30

A samba-tool -lal tudom listázni a felhasználókat, csoportokat, stb, az alábbi parancsok is működnek, igaz még a jelszó bekérése előtt minkét parancs esetén megjelenik a következő "Cannot do GSSAPI to an IP address":

# samba-tool dns zonelist 10.1.1.1 -U Administrator
# samba-tool dns zonelist localhost -U Administrator

Viszont ha ugyanezt a parancsot hostnévvel futtatom, akkor az már nem működik (pedig korábban működött):

# samba-tool dns zonelist adsamba -U Administrator
Password for [SULI\Administrator]:
dcerpc: bind_nak reason 0 - NT_STATUS_UNSUCCESSFUL
dcerpc: bind_nak reason 0 - NT_STATUS_UNSUCCESSFUL
Failed to bind to uuid 50abc2a4-574d-40b3-9d66-ee4fd5fba076 for ncacn_ip_tcp:10.1.1.1[1024,sign,target_hostname=adsamba,abstract_syntax=50abc2a4-574d-40b3-9d66-ee4fd5fba076/0x00000005,localaddress=10.1.1.1] NT_STATUS_UNSUCCESSFUL
ERROR: Connecting to DNS RPC server adsamba failed with (-1073741823, 'Undetermined error')

Úgy látom, hogy ugyanezt a hibát kapom minden olyan esetben, amikor samba-tool parancsban az IP cím helyett a hostnevet használom.
Pedig az alábbi parancsok működnek a szerveren:

# host -t A adsamba
adsamba.suli.lan has address 10.1.1.1

# host -t A adsamba.suli.lan
adsamba.suli.lan has address 10.1.1.1

# host -t SRV _ldap._tcp.suli.lan
_ldap._tcp.suli.lan has SRV record 0 100 389 adsamba.suli.lan.

# host -t SRV _kerberos._tcp.suli.lan
_kerberos._tcp.suli.lan has SRV record 0 100 88 adsamba.suli.lan.

Meglepő módon a Win10-es klienseken is fel tudom oldani az adsamba és adsamba.suli.lan neveket az nslookup-pal, de pl. a megosztást csak IP címmel tudom felcsatolni

A samba log levelt 3-ra állítva az alábbi hibaüzenet keletkezik a /var/log/samba/log.smbd fájlban, ha megpróbálok belépni egy tartományba léptett gépen tartományi felhasználóval:

[2017/08/28 13:46:52.808786, 2] ../lib/util/modules.c:196(do_smb_load_module)
Module 'samba4' loaded
[2017/08/28 13:46:52.824061, 1] ../source4/auth/gensec/gensec_gssapi.c:622(gensec_gssapi_update)
GSS server Update(krb5)(1) Update failed: Miscellaneous failure (see text): Failed to find ADSAMBA$@SULI.LAN(kvno 2) in keytab FILE:/var/lib/samba/private/secrets.keytab (aes256-cts-hmac-sha1-96)
[2017/08/28 13:46:52.824126, 1] ../auth/gensec/spnego.c:545(gensec_spnego_parse_negTokenInit)
SPNEGO(gssapi_krb5) NEG_TOKEN_INIT failed: NT_STATUS_LOGON_FAILURE
[2017/08/28 13:46:52.824163, 2] ../auth/gensec/spnego.c:720(gensec_spnego_server_negTokenTarg)
SPNEGO login failed: NT_STATUS_LOGON_FAILURE

Ez a legbeszédesebb hibaüzenet, de nem tudom, hogy mit kezdjek vele.

Annyi információ még, hogy sssd telepítve van a szerveren, hogy linux alatt is lássam az AD-s felhasználókat. Most már RSAT-tal sem láttam az AD információit, korábban igen.
Továbbá tegnap még ezt láttam névfeloldáskor (nagyon furcsa mert nem tudom, hogy honnan vette a kliens a 1.1.10.in-addr.arpa zónára vonatkozó információkat):

> nslookup adsamba
1.1.10.in-addr.arpa
primary name server = szerver1.sulineve.sulinet.hu
responsible mail addr = hostmaster.sulineve.sulinet.hu
serial = 2017073116
refresh = 28800 (8 hours)
retry = 7200 (2 hours)
expire = 2419200 (28 days)
default TTL = 86400 (1 day)
(root) ??? unknown type 41 ???
Server: UnKnown
Address: 10.1.1.1

Name: adsamba.suli.lan
Address: 10.1.1.1

ma pedig ezt látom névfeloldáskor:

> nslookup adsamba
Server: UnKnown
Address: 10.1.1.1

Name: adsamba.suli.lan
Address: 10.1.1.1

Egy kicsit hosszúra nyúlt, de minél több részletet meg akartam adni. A nagy kérdés, hogy mi történ egyik napról a másikra, amiért most nem működik a hitelesítés, "névfeloldás"??? És hogyan tudom javítani?

Hozzászólások

Volt-e esetleg egy upgrade, ami felülírhatta a bind named.conf-ot és akkor hiányzik belőle a include "/usr/local/samba/private/named.conf";

----
Vágási Ferenc IT-szakember :)
----
Gyűjteménybe keresek feleslegessé vált, kidobásra váró, ingyen elvihető c128, c128d, amiga600 gépeket és c+4-hez billentyűzetet.

Nálam nincs "/usr/local/samba/private/named.conf" fájl a Samba AD szerveren.
Csak "/var/lib/samba/private/named.conf.update" van, az alábbi tartalommal:

# more /var/lib/samba/private/named.conf.update
/* this file is auto-generated - do not edit */
update-policy {
  grant SULI.LAN ms-self * A AAAA;
  grant Administrator@SULI.LAN wildcard * A AAAA SRV CNAME;
  grant ADSAMBA$@suli.lan wildcard * A AAAA SRV CNAME;
};

A javasolt parancshoz hozzácsaptam egy "-e" paramétert is.

# klist -kte /var/lib/samba/private/secrets.keytab

https://pastebin.com/xpfGCnkL

# klist -kt /etc/krb5.keytab

https://pastebin.com/ktm6fyf3

Július 27-én telepítettem a Samba-t, és július 28-án telepítettem és állítottam be az sssd-t (a pontosítás kedvéért mindkettő ugyanazon a szerveren fut).

Mit jelent az, hogy ezek a parancskimenetek eltérnek? Augusztus 28-án (egy hónap elteltével) lejárt valamilyen időkorlát, amit a Samba/Kerberos nem újított meg a "

/var/lib/samba/private/secrets.keytab

" fájlban? Ha igen, akkor hogyan tudom ezt javítani?

Az SSSD renewolhatta a keytab-od (az inkább kliensre való és nem DC-re).

Néhány dolog, amit megpróbálhatsz (ebben a sorrendben):
1. Ráveszed a Sambát, hogy használja a /etc/krb5.keytab fájlt (a kerberos method = system keytab _elvileg_ ezt csinálná, de ha jól rémlik valami nem stimmel vele, kerberos method = dedicated keytab és dedicated keytab file = /etc/krb5.keytab). Ha minden SPN-t megtalál (a kisbetűs host/ miatt gyanús, hogy ezzel még lesznek gondok...), akkor nem kell vele többet foglalkoznod.
2. Megpróbálod lemásolni a frissített keytab fájlt (ezt akkor havonta el kell játszanod). Biztonsági mentsd /var/lib/samba/private/secrets.keytab fájlt, aztán írd felül az /etc/krb5.keytab tartalmával.
3. Ráveszed az SSSD-t, hogy ne piszkálja a keytab-ot (valahogy biztos rá lehet), aztán exportálsz egy újat (úgy rémlik, nem kell futnia a samba-nak, hogy a samba-tool-al tudj keytabot exportálni, de nem esküszöm meg rá - persze amint csináltál új keytabot a samba és az sssd is el fog törni, amíg be nem adod nekik az új keytab fájlokat.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Köszönöm a részletes választ. Nem szeretném, hogy a Samba "eltörjön", mert már vagy 60 gép be van léptetve a tartományba és kb 60 felhasználó is fel van véve.

Nem ragaszkodom én az SSSD-hez, csak ezt tudtam gyorsabban beállítani, ehhez volt leírásom. Ha winbind-et beállítva is láthatóvá tehetem az AD-s felhasználókat Linuxon, és az SSSD eltávolítása megoldja a problémát, akkor azonnal letúrom az SSSD-t.

Vajon megoldja a problémát az SSSD eltávolítása, és a Samba automatikusan elkezdi használni a

/var/lib/samba/private/secrets.keytab

fájlt minden további módosítás nélkül?

Jól értelmeztem a másik szálban írtakat, hogy a Samba beépített winbind-je az AD-ben lévő uid/gid párost fogja használni, abban az esetben ha az fel van véve a felhasználó attribútumai közé?

Egyelőre nem mertem az 1-3. lépéseket végigpróbálni, nehogy végleg odavágjak a Sambanak.

Amit csináltam:
- Leállítottam az SSSD szolgáltatást (elég csak ezt vagy mást is kell)
- A

/etc/nsswitch.conf

fájlból kivettem a "sss" bejegyzéseket
- Újraindítottam a samba-ad-dc szolgáltatást

Ennek ellenére a hiba maradt.
Vagy teljesen el kell távolítani az sssd-t?

Nem pontosan értem a keytab működését, szerepét, kérlek röviden írd már le.

Anno, amikor július 28-án telepítettem, és beállítottam az SSSD-t, akkor futtattam a következő parancsot:


# samba-tool domain exportkeytab /etc/krb5.keytab

Emlékeim szerint a parancs futtatásának idején futott a Samba, és az

/etc/krb5.keytab

fájlt állítottam be az sssd konfigjában. A Samba AD, Windows oldali hitelesítés, stb. során ettől függetlenül nem a

/var/lib/samba/private/secrets.keytab

fájlt használja?

De még most sem értem, miért van az, hogy eddig működött és most már nem?!

Leegyszerűsítve: A keytab gyakorlatilag egy jelszótároló, az abban levő jelszavakkal tudja magát hitelesíteni a gép (ill. egy-egy szolgáltatás). Sima userként is exportálhatsz magadnak keytabot, azt használhatod jelszó helyett.

A Windowsos member PC-k a machine passwordjüket 30 naponta lecserélik (https://blogs.technet.microsoft.com/askds/2009/02/15/machine-account-pa…), az sssd is ezt a működést (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/… - itt van, hogy hogy tudod kikapcsolni) követi.

Lefordítva jelszavakra: a secrets.keytab-ban ott van, hogy a jelszavad "aaaa"; ezt a jelszót az sssd lecserélte "bbbb"-re és elmentette a krb5.keytab-ba, hogy az az új jelszó. A samba pedig továbbra is úgy tudja, hogy "aaaa" a jelszó.

Első lépésként a fenti szerint tiltsd le az sssd keytab megújítást, utána _ments el egy másolatot a secrets.key-tab-ről és a krb5.keytab-ból_. Listáztasd az összes SPN-t, ami szerepel a secrets.keytab-ban, aztán exportáld az összeset:


samba-tool domain exportkeytab --principal=ADSAMBA$ /var/lib/samba/private/secrets.keytab
samba-tool domain exportkeytab --principal=HOST/adsamba.suli.lan /var/lib/samba/private/secrets.keytab

(ha jól rémlik az exportkeytab hozzáfűzi és nem felülírja a fájlt... azt hiszem)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Úgy tűnik, hogy ez lesz a megoldás, itthon van egy virtuális környezetem, ami nagyrészt megegyezik az éles rendszerrel, és mivel a virtuális környezetben sem működött a hitelesítés, így azon próbáltam ki először a javasolt megoldást.

A https://pastebin.com/xpfGCnkL alapján az általad javasolt két parancshoz hasonlóan futtattam a következő parancsot is:


samba-tool domain exportkeytab --principal=HOST/adsamba /var/lib/samba/private/secrets.keytab

Igen, az exportkeytab csak hozzáfűzte az exportált értékeket, 2-es KVNO-val (ez a KVNO =? Key Version NO...).

Jól értelmezem a belinkelt leírásokat, hogy a "

ad_maximum_machine_account_password_age = 0

" paraméter beállításával csak az "adsamba" (vagyis a Samba AD szerver) jelszavának módosítását tiltom le? Ettől az AD-be léptetett Windowsos PC-k továbbra is 30 naponta megváltoztatják a jelszavukat?