veg: I tried a dist upgrade in one of the bookworm images and a lot of things broke. Something in systemd (IIRC) wanted a feature that is not being emulated and just dies very early on in the init process.

I didn'treally dig deep though

As I'm ok on bookworm for now

I'm seeing strange behavior in kclient when used against AD with IPv6 enabled. pastebin.com/5ZJDV1RC

any ideas? Is this a bug or am I just holding it wrong?

At first glance, it's a bug/missing-feature. Do you know what *process* is failing?

I see some $CMD/krb5 that has AF_INET6/AF_INET duality, but not ALL of it. WOuld be interesting to know what process is only using IPv4.

"Failed to set account password." seems to be a difference.

Ahh, I think I found the problem. Pardon the multi-line:

kebe(lib/krb5)[0]% git grep -lw AF_INET

kadm5/clnt/changepw.c

kadm5/srv/chgpwd.c

kebe(lib/krb5)[0]% git grep -lw AF_INET6

kebe(lib/krb5)[1]%

A fix in $LIB/krb5 is probably your first step.

danmcd, I wish I knew which process was failing. <sigh>

so should I be reporting this as an illumos bug?

I actually don't need to know that now. I missed the output.

Assuming it isn't already filed, yes.

illumos.org/issues/17577 is the catch-all "Update our krb5, dammit."

→ BUG 17577: Kerberos code needs update (New)

Your problem COULD MAYBE be fixed by whacking those two lib/krb5 files a bit.

No bugs mention IPv6 by name.

I bumped into this problem while trying to solve another (more important) one.

should I add it to 17577 or create a new one?

The `ksetpw` command is what's failing in your kclient (a shell script) invocation. That binary in $CMD calls one or both of the stuck-in-v4-only routines in $LIB.

17577 states that Oracle open-sourced their formerly-in-ON krb5 bits, or at least the patches?

Maybe a v6 patch is in there somewhere?!? I have no idea...

I can work around this temporarily but it's going to bite us ($job[1]) fairly badly if we ignore it for too long.

workaround being to add the DCs to /etc/hosts on the impacted servers.

oracle moved kerberos into solaris-userland

that would be the best source of knowing what the hell, because the diffs of kerberos v. upstream are a mess

and the XXX comments left behind are also not easy to under

stand

new ticket time?

Yes.

I'm assuming that if you can get what we have to Just Speak IPv6 we're all good?

That alone is worth a distinct ticket IMHO.

yeah, that's probably fixable

the krb5 upgrade probably needs someone like racktop with big AD stuff to deal with

at least if they want it to still work afterward

illumos.org/issues/17809 submitted

→ BUG 17809: kclient + AD + IPv6 = "Setup FAILED" (New)

Please put your pastebin output in there. I'll update with how I got to the lib/krb5 bits.

the pastebin output is already in there. That's 90% of the content. :)

Now to go back to trying to figure out why ldap bind is failing <sigh>

darnit. I was really hoping the computer account was the issue but nope, nscd is still failing to proxy bind to the AD servers.

anyone using LDAP? Can you tell me the ownership and perms of /var/ldap/ldap_client_* please?

I find it hard to believe it needs to be world readable but:

Jan 6 13:08:01 testfs1 svc.startd[36]: [ID 293258 daemon.warning] libsldap: Status: 2 Mesg: Unable to load configuration '/var/ldap/ldap_client_file' ('').

(FTR, making it world readable and rebooting did not get that error logged.)

it shouldn't -- ldap_cachemgr should be the only thing that needs to read it

the ldapclient command should create all of that for you

I assumed it should be 0400 root:root but that generated the above error.

jbk, it did generate it and gave it the 0400 perms.

the big one is the creds file -- that holds the password for binding

(and the DN of the account to bind to)

there's no error with ldap_client_cred being 0400 root:root.

I'm going to put 0400 back on ldap_client_file and restart and see if the error comes back.

I take it back. I'm still getting that can't load error even with world-read perms on the file.

so something ldapclient is writing is upsetting it, I guess.

I think that error was a red herring.

i think you can run ldap_cachemgr with the -g flag (I think that's it) that'll tell you the status of the configured servers

thanks. I'm currently rebuilding testfs1 but I'll give that a try when I'm back to that stage.

I *think* it is actually working... partly. getent passwd returns some users but not all.

are you trying to allow AD accounts to login to the system?

login? no.

This is a fileserver, I need smb to work.

our current system is causing $boss upset because it uses NTMLv2 and he doesn't like that.

why not just use smbadm join ?

(it uses a simple smbadm join)

jbk: that's the thing that's causing the NTMLv2 propblem.

at least recent versions should setup all of the kerberos bits

it does, but for whatever reason we're still getting alerts logged on the DC.

IIUC, that's a client thing -- you have to connect using the FQDN to get the client to use kerberos

fqdn for the client or the server? ... I swear I tried that but maybe I'm just an idiot.

you might want to set the minimum smb verson to 2.1 if you haven't done that

I presume that's different from setting lmauth_level=5?

(I have this vague memory or setting smb version to 2.1 years ago but I don't see anything in my notes about it.)

check sharectl get smb

yeah -- if you send an email to illumos-discuss, I might be able to prod Gordon to answer with more detail since he knows all the details..

if he doesn't see it himself

min_protocol=2.1

but I do recall if you connect to the share using something like \\IPADDR\SHARE, that _does_ use NTLM, and you have to use \\SERVER.FQDN\SHARE (while required, that might not be sufficient)

looks like we're not specifying the name of the DC in our join command. just -u admin_username doma.in.name

oh yeah, that's... unlikely :)

our users love their go to the DNS CNAME \\fs then browse.

yeah -- smbadm join should do DNS SRV lookups on the domain name to locate the DCs

(I think the bits to make it site aware are also upstreamed if you're using sites)

smbadm doesn't have an option to specify DC for the join command and given the \\IPADDR comment I'm guessing that's not relevant anyway.

I mean, clients going to \\IPADDR are going to use NTML

when you do smbadm join

it's going to do the DNS SRV lookups

create the keytab

etc

sadly, I have no way to force the clients to use the long name.

FQDN

I wonder if that's still going to be a problem if I get this new configuration working. :(

I'd still ask -- ISTR that it's the SMB _client_ (i.e your desktops) that decide to use NTLM or kerberos -- I'm not sure that the server can force the behavior

I'll try to write a concise question to post ... tomorrow.

I've been busting my head against this LDAP stuff for several days and I'm not sure what's what anymore.

or just clean up everything and try smbadm join

(the host join bug didn't help.)

it'll also configure idmap to talk to AD using LDAP using SASL/gssapi

the thing is, the DC is logging the complaint against the file server, not the client.

(for historical reasons, for smb sharing idmap is the thing that actually does all the LDAP lookups)

yeah, when an smb client connects, the server has to basically forward the request to the DC to validate it

I tripped over that idmap setting at some point but figured I'd get there after I got rid of the binding error being logged in /var/adm/messages first.

if you're doing smb, you don't need ldap/client or any of that...

I'll need to go back through the documentation and find that setting again.

for now I'm trying to follow omnios.org/setup/ad-connect but it's for non-SSL connections so I'm ... adapting.

if you're trying to share a given share via both SMB and NFS, you'll need to configure idmap to lookup the correct attributes in AD

nope, I refuse to share via both.

they get one or the other, not both.

yeah, for smb, it doesn't use SSL or TLS

To the point where I have separate servers for NFS & SMB.

it uses gssapi

I don't suppose there's a simple cookbook document about this :)

svcadm enable smb/server idmap; smbadm join -u <User with creds> domain.name

that really should be all you need as long as DNS is configured

that's what I have been doing for the past several years.

well and ntp (because kerberos)

but, like I said, $boss wants the NTML alerts to stop.

previous setup: svcadm refresh ntp; svcadm enable -r smb/server ; sharectl set -p max_workser=2048 smb, sharectl set -p lmauth_level=5 smb ; sharectl set -p ipv6_enable=true smb ; smbadm join -u ... ; and then a bunch of idmap

oh, and cp /etc/nsswitch.ad /etc/nsswitch.conf

ad shouldn't be needed for the most part (nss_ad.so really needs to be rewritten, but that's a _long_ story)

silly question... but have you tried to block client(s) to use NTLM?

you mostly need it if you have RFC2307 attributes in AD (or equivalent) and want to have people login to a system using their AD creds

except that it duplicates (poorly) a lot of logic in idmap (so it doesn't handle down DCs nearly as well as idmap)

tsoome_, I have not done that. Until a few minutes ago I thought this was a server problem.

tsoome_, If you want to save me a bunch of googling and know the command(s) to try for that I'd appreciate it :)

I mean, first for debugging, because the client fall back to NTLM if kerberos fails....

hmm... thinking about this... the test host doesn't have any clients talking to it yet so why would it be generating those errors?

do not know the commands without google:D

right now I'm trying to google how to set idmap to sasl/gssapi and ... end of day brain isn't helping.

you shouldn't need to do that -- smbadm join takes care of that for you

it doesn't use ldap_cachemgr or ldap/client

then the existing server (which uses smbadm join) should already have done that.

idmap creates its own ldap connections

and has it's own config stored in smf

you should see things like info about the machine account, etc if you do a listprop on the idmap service

basically there's a lot of discovery via DNS SRV records that are used to locate AD DCs

idmap does all of that, and will handle locating a new DC if the one it's currently usign dies

listprop doesn't have anything with 'sasl' in it (grep -i)

svccfg -s svc:/system/idmap listprop - right?

it's basically baked in

you should see things lik config/machine_uuid, config/machine_sid, and config/domain_name populated

yep, I'm seeing those

and you should already have /etc/krb5/krb5.keytab populated with principals for the FQDN of the machine

yep, with DES, ArcFour, AES-128, and AES-256 options.

for host, cifs, HOSTNAME$, nfs, HTTP, and root

I just checked the logs, we're seeing these alrts for fs2 and hvfs2 - both of which have no clients (they're test hosts).

I think I'm going to stop with this for the day and pick up 'fresh and clean' tomorrow.

smbadm list-sessions

make sure of that

: || lvd@fs2 ~ [502] ; sudo smbadm list-sessions

Password:

: || lvd@fs2 ~ [503] ;

same for hvfs2. If they'd had sessions I'd have been very surprised.

specifically, $boss is auditing for" LogName = 'Microsoft-Windows-NTLM/Operational' Id = 4023"

"Check for Missing SPNs: Often, NTLM fallback occurs due to missing or incorrect Service Principal Names (SPNs). Ensure SPNs are correctly registered for the services in Active Directory."

any suggestions on how to do that?

spn is basically service/host.domain format name (or service/host)

so you would need to fetch all ldap entries for host:)

but, I'm not quite sure why is your test server generating those NTLM audit records. Thats something one should dig from source and NTLM related docs - maybe some sort of session setup or whatever like that....

to disable NTLM from illumos server side... I'd check with gwr as suggested:)

setspn -L hostname returns a lot of things but I'm ignorant of their meaning. More reading.

I'll start drafting that email but suspect it won't go out until I've had time to review it in the morning.

some years ago I had to set up AD auth for solaris, but that was just for user access (ldap + kerberos) and havent touched AD later:)

in my ideal world I wouldn't be touching AD ...