Bug #2271
closedCIFS clients fail to authenticate when idmap is using IDMU
100%
Description
I joined my OI box to AD successfully
root@staypuft:~# smbadm list
[*] [AD]
[*] [ad.ismell.org]
[+oracle.ad.ismell.org] [10.0.0.2]
[.] [STAYPUFT] [S-1-5-21-1624921585-1963576407-4047943756]
[*] [AD] [S-1-5-21-3978222023-495330413-1469327242]
I then set my idmap to use IDMU based mapping as described here: http://docs.oracle.com/cd/E19963-01/html/821-1449/manageidmutm.html#enableidmusupporttask
$ svccfg -s svc:/system/idmap setprop \ config/directory_based_mapping = astring: idmu
$ svcadm refresh svc:/system/idmap
Then I created some ZFS shares and tried to connect to them with my windows box. The result was the login prompt kept popping up. This happened from both a computer joined to AD and not.
Doing an idmap dump I got the following
root@staypuft:~/bin# idmap dump -n
winuser:Guest@staypuft uid:2147483649
wingroup:Domain Users@staypuft gid:2147483652
wingroup:Guests@BUILTIN gid:2147483653
wingroup:Domain Admins@ad.ismell.org gid:2147483654
wingroup:Group Policy Creator Owners@ad.ismell.org gid:2147483655
wingroup:Enterprise Admins@ad.ismell.org gid:2147483656
wingroup:Schema Admins@ad.ismell.org gid:2147483657
wingroup:Denied RODC Password Replication Group@ad.ismell.org gid:2147483658
wingroup:Administrators@BUILTIN gid:2147483659
winuser:me@ad.ismell.org uid:10001
wingroup:Backup Admins@ad.ismell.org gid:10003
wingroup:Web Developers@ad.ismell.org gid:10005
wingroup:Domain Users@ad.ismell.org gid:10000
wingroup:Network gid:2147483650
wingroup:Authenticated Users gid:2147483651
winuser:Administrator@ad.ismell.org unixuser:root
gsid:S-1-5-21-1624921585-1963576407-4047943756-2147483648 == unixgroup:root
idmap did correctly lookup my domain user (me@ad.ismell.org)
When looking at the smbd logs I saw the following:
Mar 6 17:55:32 indiana smbd[4229]: [ID 160719 auth.alert] adt_set_user: Invalid argument
Mar 6 17:55:32 indiana smbd[4229]: [ID 160719 auth.alert] adt_set_user: Invalid argument
So my guess is idmap is not passing IDMU mapped users correctly to smbd ?
To add another data point, I have tried the same procedure on NexentaStor and everything works as expected.
Thanks,
Raul
Updated by Ryo Murakawa almost 11 years ago
- Assignee set to Ryo Murakawa
- Tags changed from needs-triage to cifs
Updated by Ryo Murakawa almost 11 years ago
- Assignee changed from Ryo Murakawa to OI PKG
Updated by Bayard Bell over 10 years ago
Have you asked for assistance with this on any of the mailing lists (e.g. openindiana-discuss)?
Updated by Anthony Germano over 10 years ago
I am having the same issue. I'm running oi 151a5. I tested with both Windows XP pro sp3 and Vista ultimate sp2 clients.
Below is some of the testing I did. Idmu had not yet been enabled.
[client able to connect] $ idmap dump -n winuser:testuser@mydomain.com == uid:2147483650 $ svccfg -s svc:/system/idmap setprop \ config/directory_based_mapping = astring: idmu $ svcadm refresh svc:/system/idmap $ idmap flush -a [client still able to connect] $ idmap dump -n winuser:testuser@mydomain.com == uid:10000 [log out and back in to windows] [try to connect from client and get invalid login box] $ tail /var/adm/messeges Aug 6 11:22:45 openindiana smbd[655]: [ID 160719 auth.alert] adt_set_user: Invalid argument $ svccfg -s svc:/system/idmap setprop \ config/directory_based_mapping = astring: none $ svcadm refresh svc:/system/idmap $ idmap flush -a [client able to connect again] $ idmap dump -n winuser:testuser@mydomain.com == uid:2147483651
Like the original poster, I have successfully used idmu with NexentaStor (3.1.3 CE)
Updated by Anthony Germano over 10 years ago
I'm having the same issue with Illumian 1.0.
Updated by Ken Mays about 9 years ago
- Assignee changed from OI PKG to OI illumos
Updated by Kevin Crowe about 8 years ago
Pretty sure I just fixed the same thing in Nexenta src via bug NEX-2842
This appears to be the source of the adt_set_user complaint in /var/adm/messages and the reason why the login fails:
line # 5368 0 -> smbd_user_auth_logon 0xfcdbedf4 0x806074c 0x82a0f0c 0x3 0x1ac 0xfcdbee3c . . . . 6717 0 -> adt_set_user 0x8195320 0x2711 0x80000003 0x2711 0x80000003 0x0 6718 0 -> adt_newuser 0x8195320 0x2711 0x0 0xfcabf2d5 0x3a 0x8190150 6719 0 -> adt_get_unique_id 0x2711 0x84 0x84 0xfcabf1ba 0x8190150 0x0 6720 0 <- adt_get_unique_id 0x40905d09 6721 0 -> adt_get_mask_from_user 0x2711 0x8195338 0x84 0xfcabf1ba 0x8190150 0x0 6722 0 -> calloc 0x1 0x401 0x0 0xfcabe02c 0x0 0x0 6723 0 <- calloc 0x81d4988 6724 0 -> getpwuid_r 0x2711 0xfcdbeaec 0x81d4988 0x401 0x0 0x0 6725 0 <- getpwuid_r 0x0 6726 0 <- adt_get_mask_from_user 0xffffffff 6727 0 <- adt_newuser 0xffffffff 6728 0 <- adt_set_user 0xffffffff
getpwuid_r returns NULL meaning it can't look up the user, that causes adt_get_mask_from_user() to ruturn 0xffffffff (i.e. -1)
adt_get_mask_from_user() shouldn't always assume the ID can be looked up and fail as in this code here if it can't be looked up:
from adt_get_mask_from_user(): 202 if (getpwuid_r(uid, &pwd, pwd_buff, (int)buff_sz) == NULL) { 203 errno = EINVAL; /* user doesn't exist */ 204 free(pwd_buff); 205 return (-1); 206 }
As seen here the NS box can't get the uid:
admin@s1n1:/root# getent passwd 10001 admin@s1n1:/root#
Workarounds that might work for you:
1) Configure NS box as an LDAP client to the WIndows AD Server when using IDMU 2) Configure NS box as a NIS client to the Windows AD Server - you'll need to install the "NIS for Windows" (I forget the official name for it) MS software if you don't have it installed though.
Once you can lookup things through either of these services on the NS box the Windows client logon to the NS box should no longer fail as the NS box can resolve ID's it currently can't resolve.
Here's what I pushed at Nexenta:
kcrowe@earth:/sea/bld/kcrowe/nza-kernel-2842$ git diff HEAD~1 diff --git a/usr/src/lib/libbsm/common/adt.c b/usr/src/lib/libbsm/common/adt.c index 8c7b299..b7fcd62 100644 --- a/usr/src/lib/libbsm/common/adt.c +++ b/usr/src/lib/libbsm/common/adt.c @@ -21,6 +21,7 @@ /* * Copyright (c) 2001, 2010, Oracle and/or its affiliates. All rights reserved. + * Copyright 2014 Nexenta Systems, Inc. All rights reserved. */ #include <bsm/adt.h> @@ -190,7 +191,10 @@ adt_get_mask_from_user(uid_t uid, au_mask_t *mask) /* c2audit excluded */ mask->am_success = 0; mask->am_failure = 0; - } else if (uid <= MAXUID) { + return (0); + } + + if (uid <= MAXUID) { if ((buff_sz = sysconf(_SC_GETPW_R_SIZE_MAX)) == -1) { adt_write_syslog("couldn't determine maximum size of " "password buffer", errno); @@ -199,18 +203,24 @@ adt_get_mask_from_user(uid_t uid, au_mask_t *mask) if ((pwd_buff = calloc(1, (size_t)++buff_sz)) == NULL) { return (-1); } - if (getpwuid_r(uid, &pwd, pwd_buff, (int)buff_sz) == NULL) { - errno = EINVAL; /* user doesn't exist */ - free(pwd_buff); - return (-1); - } - if (au_user_mask(pwd.pw_name, mask)) { + /* + * Ephemeral id's and id's that exist in a name service we + * don't have configured (LDAP, NIS) can't be looked up, + * but either way it's not an error. + */ + if (getpwuid_r(uid, &pwd, pwd_buff, (int)buff_sz) != NULL) { + if (au_user_mask(pwd.pw_name, mask)) { + free(pwd_buff); + errno = EFAULT; /* undetermined failure */ + return (-1); + } free(pwd_buff); - errno = EFAULT; /* undetermined failure */ - return (-1); + return (0); } free(pwd_buff); - } else if (auditon(A_GETKMASK, (caddr_t)mask, sizeof (*mask)) == -1) { + } + + if (auditon(A_GETKMASK, (caddr_t)mask, sizeof (*mask)) == -1) { return (-1); } kcrowe@earth:/sea/bld/kcrowe/nza-kernel-2842$
Updated by Raul Rangel about 8 years ago
Ah, that makes sense. I do have my Nexenta box joined via LDAP because I wanted NFSv3 ids to map correctly. I might give OI a try again. Nice to see Nexenta charging the way on IDMU :)
Updated by serum korea grosir kosmetik over 7 years ago
Karena banyaknya serum korea kw murah dan berdampak buruk pada wajah maka kami membuat perbedaan serum korea ori dan kw. Ciri-ciri Serum Korea ASLI dibawah ini mohon selalu dijadikan acuan dalam membeli Serum Korea karena ada banyak orang yang memalsukan atau membuat Serum Korea oplosan karena serum ini sangat berkhasiat dan laku dipasaran.
semoga dengan adanya artikel perbedaan antara serum korea asli dan palsu ini tidak ada lagi custumer yang tertipu oleh serum korea kw/tiruan. serum korea [[http://www.flickr.com/people/133449474@N04/]]
Updated by Raul Rangel about 7 years ago
Was this patch ever pushed to illumos-gate? If not, is there any plans to?
Updated by Matt Barden 5 months ago
As Kevin noted, the issue here is that adt_get_mask_from_user() requires that any non-ephemeral UID be mappable to a name through getpwuid(), so that it can get any per-user audit flags assigned to that name. However, there are two cases where we may want to audit a UID that isn't present in the passwd database:
1. If the UID came from idmap's IDMU setting (e.g. through ldap commands sent directly to a DC instead of through name services), then nsswitch.conf may not be configured so that the reverse mapping works. This causes authentication to fail.
2. With NFS auditing (#11874), a client who mounts a share using AUTH_SYS may use a UID that's not in any database. We still want to be able to audit access over these shares, even if the UID information isn't reliable.
Tested by verifying that users can log on over SMB and NFS when auditing is enabled (Including with #11873 and #11874) and they get the correct audit mask, even if their UID can't be mapped to a name.
Updated by Joshua M. Clulow 4 months ago
- Project changed from OpenIndiana Distribution to illumos gate
- Category changed from OS/Net (Kernel and Userland) to smb - SMB server and client
- Assignee changed from OI illumos to Toomas Soome
Updated by Joshua M. Clulow 4 months ago
- Assignee changed from Toomas Soome to Matt Barden
Updated by Electric Monk 4 months ago
- Status changed from New to Closed
- % Done changed from 0 to 100
git commit cd918266dec8ae2553f7a0efd53c52aa90d99a39
commit cd918266dec8ae2553f7a0efd53c52aa90d99a39 Author: kcrowenex <kevin.crowe@nexenta.com> Date: 2022-10-06T21:33:48.000Z 2271 CIFS clients fail to authenticate when idmap is using IDMU Reviewed by: Gordon Ross <gordon.w.ross@gmail.com> Approved by: Dan McDonald <danmcd@mnx.io>