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
Előzmény itt: https://hup.hu/node/154635
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;
};
Melyik DNS back-endet használod?
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
SAMBA_INTERNAL
ja, akkor nem is kell benne legyen.
----
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.
Első nekifutásra:
majd
(vagy ahova az SSSD pakolta a keytabját)
(mindkettő rootként persze)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
A javasolt parancshoz hozzácsaptam egy "-e" paramétert is.
https://pastebin.com/xpfGCnkL
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 "
" 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
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é?
Még egy hülye kérdés: ezek szerint az SSSD okozza a problémát?
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
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:
Emlékeim szerint a parancs futtatásának idején futott a Samba, és az
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
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:
(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:
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 "
" 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?
Igen, az csak az sssd-nek mondja, hogy ne csinálja (egyébként nem is kötelező, DC meg úgy rémlik, nem is szokta frissíteni a jelszavát).
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Az éles rendszeren is futtattam a parancsokat, az sssd.conf-ban letiltottam a jelszómódosítást, most úgy tűnik, hogy működik.
Hálás köszönet a segítségedét!
Lehet, hogy az SSSD okozza a problémát?
Szedjem le az SSSD-t és állítsam be a winbind-et, hogy Linuxon is lássam az AD-s felhasználókat? Ez megoldaná a problémát?