Project

General

Profile

Bug #2271

CIFS clients fail to authenticate when idmap is using IDMU

Added by Raul Rangel over 7 years ago. Updated almost 4 years ago.

Status:
New
Priority:
Normal
Assignee:
Category:
OS/Net (Kernel and Userland)
Target version:
-
Start date:
2012-03-10
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
cifs

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 gid:2147483655
wingroup:Enterprise Admins@ad.ismell.org gid:2147483656
wingroup:Schema 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 gid:10003
wingroup:Web Developers@ad.ismell.org gid:10005
wingroup:Domain 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 ()

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

History

#1

Updated by Ryo Murakawa over 7 years ago

  • Assignee set to Ryo Murakawa
  • Tags changed from needs-triage to cifs
#2

Updated by Ryo Murakawa over 7 years ago

  • Assignee changed from Ryo Murakawa to OI PKG
#3

Updated by Bayard Bell about 7 years ago

Have you asked for assistance with this on any of the mailing lists (e.g. openindiana-discuss)?

#4

Updated by Anthony Germano about 7 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)

#5

Updated by Anthony Germano about 7 years ago

I'm having the same issue with Illumian 1.0.

#6

Updated by Ken Mays over 5 years ago

  • Assignee changed from OI PKG to OI illumos
#7

Updated by Kevin Crowe over 4 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$

#8

Updated by Raul Rangel over 4 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 :)

#9

Updated by serum korea grosir kosmetik about 4 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/]]

#10

Updated by Raul Rangel almost 4 years ago

Was this patch ever pushed to illumos-gate? If not, is there any plans to?

Also available in: Atom PDF