[Samba] Help "Could not get unix ID"

Ross S. W. Walker rwalker at medallion.com
Thu Feb 14 17:16:50 GMT 2008


Linux Addict wrote:
> 
> On Thu, Feb 14, 2008 at 11:21 AM, Ross S. W. Walker
> <rwalker at medallion.com> wrote:
> > Linux Addict wrote:
> >  >
> >  > Greetings!!!
> >  >
> >  > I am using samba 3.0.28 clients authenticating AD R2 with SFU 3.5. I
> >  > have setup nss info to template, sfu get the uid, gid, home dir and
> >  > shell from AD.
> >
> >  Whoa, slow down, your getting all ahead of yourself. You seem to need
> >  to pick a user authorization (passwd/group) method and a user
> >  authentication method.
> 
> My nsswitch configuration is passwd files winbind  and group 
> files winbind
> 
> My authentication method(PAM) reads unix local files, krb5 next and
> then winbind.  I want to keep winbind as I will be using a one way
> trust in the future to our corp domain. I had some issues with only
> having krb5 as by default it appended the username with our AD domain
> only.

Hmmm, yes I can see the issue here. Users from foreign domains would
have to know to login as <user>@<domain> otherwise it would use the
domain defined as the default. You could make user education part of
it, because single sign-on is nice.

> >  User authorization can be nss_ldap or samba+winbind or samba+ldap or
> >  samba+ad (samba+ldap and samba+ad are really the same, but samba
> >  uses ad extensions when storing the attributes).
> >
> >  I personnally like samba+winbind because with RID mapping I no
> >  longer have to worry about creating and maintaining UIDs and GIDs for
> >  every Windows user and group, which is a big pain.
> 
> I have around 200 RHEL hosts which will authenticate from AD. I want
> uid/gid consistency across all the hosts. I wasn't sure if RID will
> assign the same IDs on all 200 hosts for a specific user.   Will it be
> same if I use RID?

Yes, RID mapping takes the RID portion of the user's SID and adds it
to the ID range you specify, a very clever feature.

> >  As far as authentication goes, there is pam_ldap, pam_winbind, samba
> >  or kerberos.
> >
> >  If you authenticating against a Windows AD domain I really don't see
> >  any point to not using Kerberos. It is straight forward, easy to
> >  setup, secure and provides single sign-on functionality. The others
> >  require additional setup procedures and don't do single sign-on.
> >
> >
> >  > The problem is it seems to be working for sometime, and then it says
> >  > could not get uid/gid pair. I am assuming some kind of caching is
> >  > causing this.
> >
> >  It may be your initial setup.
> 
>  It wasn't just initial. It worked for first few logins. Then If I try
> again after an hour, you would get that error and the user will not be
> able to login.

Was there anything in the log files during the login?


> >  > My understanding with SFU is that, there wont be any mappings and the
> >  > specific user will pull the uid,gid from AD Unix Attributes.
> >
> >  Managing UIDs and GIDs under SFU is a big PITA. I would only use it
> >  under circumstances where winbind wasn't available, but even there
> >  I would probably setup a Linux VM that would dump winbind RID
> >  mappings into NIS maps and then use NIS to send them out.
> >
> >
> >  > The winbindd-idmap file throws the following error.
> >  >
> >  > nsswitch/idmap_ad.c:idmap_ad_sids_to_unixids(613)
> >  >   Could not get unix ID
> >
> >  Did you join the machine to the domain with a 'net ads join' ?
> >
>
> Yes. The host is part of AD.

Ok, good, so it has a machine SID and password associated with it. 

> >  > This is testparam output.
> >  >
> >  > idmap backend = ad
> >  >         idmap uid = 16777216-33554431
> >  >         idmap gid = 16777216-33554431
> >  >         template shell = /bin/bash
> >  >         winbind separator = +
> >  >         winbind enum users = Yes
> >  >         winbind enum groups = Yes
> >  >         winbind use default domain = Yes
> >  >         winbind nss info = template, sfu
> >  >
> >  >
> >  >
> >  > Please someone help me to all linux clients authenticate
> >  > consistently from AD.
> >
> >  Make sure you have these installed:
> >
> >  samba-common
> >  samba-client
> >  cyrus-sasl-gssapi
> >  libgssapi
> >  cyrus-sasl-md5
> >  cyrus-sasl-lib
> >  cyrus-sasl
> >  cyrus-sasl-gssapi
> >  cyrus-sasl-ntlm
> >  cyrus-sasl-plain
> >  krb5-workstation
> >  pam_krb5
> >  krb5-libs
> >  krb5-auth-dialog
> 
> I dont have all, but have most of them.
> 
> [root at samba1 samba]# rpm -qa |egrep '(samba|cyrus|krb)'
> krb5-libs-1.3.4-27
> cyrus-sasl-md5-2.1.19-5.EL4
> samba-common-3.0.28-1
> cyrus-sasl-2.1.19-5.EL4
> krbafs-1.2.2-6
> pam_krb5-2.1.8-1
> cyrus-sasl-plain-2.1.19-5.EL4
> samba-client-3.0.28-1
> krb5-devel-1.3.4-27
> cyrus-sasl-devel-2.1.19-5.EL4
> krb5-workstation-1.3.4-27
> krbafs-devel-1.2.2-6
> samba-3.0.28-1
> [root at samba1 samba]#

You will need the cyrus-sasl-gssapi, cyrus-sasl-lib and libgssapi as
AD uses GSSAPI for single sign-on if using Kerberos.

> >  Try this simple starting smb.conf:
> >
> >  [global]
> >    workgroup = EXAMPLE
> >    realm = EXAMPLE.COM
> >    security = ads
> >    password server = *
> >    use kerberos keytab = yes
> >    passdb backend = tdbsam
> >    allow trusted domains = no
> >    idmap backend = rid
> >    idmap uid = 100000-199999
> >    idmap gid = 100000-199999
> >    template homedir = /home/%U
> >    template shell = /bin/bash
> >    winbind use default domain = true
> >    winbind enum groups = yes
> >    winbind enum users = yes
> >    name resolve order = wins bcast host
> >
> >  [homes]
> >    comment = Home Directories
> >    read only = no
> >    browseable = no
> >
> >  [printers]
> >    comment = All Printers
> >    path = /var/spool/samba
> >    printable = yes
> >    browseable = no

Since you mentioned a multi-domain trust setup let me change this
smb.conf config to:

[global]
   workgroup = MFG
   realm = MFG.PRV
   security = ads
   password server = *
   use kerberos keytab = yes
   passdb backend = tdbsam
   idmap domains = default <DOM1> <DOM2>
   idmap config default:default = yes
   idmap config <DOM1>:backend = rid
   idmap config <DOM1>:range = 100000 - 199999
   idmap config <DOM2>:backend = rid
   idmap config <DOM2>:range = 200000 - 299999
   idmap alloc backend = tdb
   idmap uid = 90000 - 99999
   idmap gid = 90000 - 99999
   template homedir = /home/%U
   template shell = /bin/bash
   winbind use default domain = true
   winbind enum groups = yes
   winbind enum users = yes
   name resolve order = wins bcast host

[homes]
   comment = Home Directories
   read only = no
   browseable = no

[printers]
   comment = All Printers
   path = /var/spool/samba
   printable = yes
   browseable = no

This should allocate <DOM1> to uids and gids to 100000 - 199999 and
<DOM2> uids and gids to 200000 - 299999, it will allocate BUILTIN
and samba mapped ids in the 90000 - 99999 range, all others will
be rejected.

You need different maps for different domains because the RIDs can
be repeated in domains (if they are in different forests).

> >  And this simple krb5.conf:
> >
> >  [logging]
> >   default = FILE:/var/log/krb5libs.log
> >   kdc = FILE:/var/log/krb5kdc.log
> >   admin_server = FILE:/var/log/kadmind.log
> >
> >  [libdefaults]
> >   default_realm = EXAMPLE.COM
> >   dns_lookup_realm = false
> >   dns_lookup_kdc = false
> >   ticket_lifetime = 24h
> >   renew_lifetime = 7d
> >   forwardable = yes
> >
> >  [appdefaults]
> >   pam = {
> >    debug = false
> >    ticket_lifetime = 24h
> >    renew_lifetime = 7d
> >    forwardable = true
> >    krb4_convert = false
> >   }
> >
> >  [realms]
> >   EXAMPLE.COM = {
> >   kdc = example.com
> >   admin_server = example.com
> >   }
> >
> >  [domain_realm]
> >   example.com = EXAMPLE.COM
> >   .example.com = EXAMPLE.COM

Well, you will need to expand this krb5.conf file and add
each trusted domain, IF that is you can deal with entering
<user>@<domain> for foreign domains...

> >  Then make sure your nsswitch.conf has these defined:
> >
> >  passwd:     files winbind
> >  shadow:     files
> >  group:      files winbind
> >
> >  And your /etc/pam.d/system-auth is similar to:
> >
> >  auth        required      pam_env.so
> >  auth        sufficient    pam_unix.so nullok try_first_pass
> >  auth        requisite     pam_succeed_if.so uid >= 500 quiet
> >  auth        sufficient    pam_krb5.so use_first_pass
> >  auth        required      pam_deny.so
> >
> >  account     required      pam_unix.so broken_shadow
> >  account     sufficient    pam_localuser.so
> >  account     sufficient    pam_succeed_if.so uid < 500 quiet
> >  account     [default=bad success=ok user_unknown=ignore] pam_krb5.so
> >  account     required      pam_permit.so
> >
> >  password    requisite     pam_cracklib.so try_first_pass retry=3
> >  password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
> >  password    sufficient    pam_krb5.so use_authtok
> >  password    required      pam_deny.so
> >
> >  session     optional      pam_keyinit.so revoke
> >  session     required      pam_mkhomedir.so skel=/etc/skel umask=0077 silent
> >  session     required      pam_limits.so
> >  session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
> >  session     required      pam_unix.so
> >  session     optional      pam_krb5.so
> 
> I have winbind coming after krb5 as I need it to leverage 
> one-way trust.

That's not bad, have local domain users authenticate via Kerberos and have
foreign domain users authenticate via NTLM, may as well add the foreign
domains to the krb5.conf file to give users the option to single sign-on
if they want it via <user>@<domain>

> >  The modules to pay attention to are, pam_krb5.so and pam_mkhomedir.so.
> >
> >  Then your Windows users should be able to single sign-on to Linux and access
> >  all the Windows shares and resources.

You seem to have a pretty good grasp it's probably a small little typo somewhere...

-Ross

______________________________________________________________________
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.



More information about the samba mailing list