samba - May 2015 - [Solved] A working CUPS authentication now fails without change anything...

2015-05-08 21:24 GMT+02:00 Daniel Carrasco Mar?n <danielmadrid19 at
gmail.com>:
>
>
> 2015-05-04 19:25 GMT+02:00 Daniel Carrasco Mar?n <danielmadrid19 at
gmail.com
> >:
>
>>
>>
>> 2015-05-04 18:50 GMT+02:00 Andrey Repin <anrdaemon at yandex.ru>:
>>
>>> Greetings, Daniel Carrasco Mar?n!
>>>
>>> >>> Just a moments ago i've sent a message to other
user saying that
>>> I've a
>>> >>> working server with CUPS authentication using AD
groups. Well, that
>>> >>> authentication is not working anymore and i've not
changed
>>> anything...
>>> >>>
>>> >>> The thursday I was configuring the server to allow the
management of
>>> cups
>>> >>> with AD groups and was working perfect. After that
i've added some
>>> printer
>>> >>> alias to samba configuration and I've disabled the
"load printers"
>>> option
>>> >>> to hide the real name.
>>> >>> Today i've tried to enter to CUPS to change the
default paper size on
>>> >>> printers but it failed (local account works). I've
not changed any
>>> >>> configuration in domain or member smb.cfg files (at
least in
>>> general),
>>> >>> then
>>> >>> I don't know where is the problem...
>>> >>>
>>> >>> My smb.conf looks:
>>> >>> [global]
>>> >>>          workgroup = Domain
>>> >>>          security = ADS
>>> >>>          realm = DOMAIN.RED
>>> >>>          dedicated keytab file = /etc/krb5.keytab
>>> >>>          kerberos method = secrets and keytab
>>> >>>          encrypt passwords = yes
>>> >>>
>>> >>>          idmap config *:backend = tdb
>>> >>>          idmap config *:range = 10000-20000000
>>> >>>          idmap config DOMAIN:backend = ad
>>> >>>          idmap config DOMAIN:schema_mode = rfc2307
>>> >>>          idmap config DOMAIN:range = 10000-20000000
>>> >>>
>>> >>
>>> >> It might help if you didn't use the same range for
'*' and 'DOMAIN'
>>>
>>> > Changed to:
>>> >         idmap config *:backend = tdb
>>> >         idmap config *:range = 40000-70000
>>> >         idmap config ND:backend = ad
>>> >         idmap config ND:schema_mode = rfc2307
>>> >         idmap config ND:range = 10000-30000
>>>
>>> > rebooted and same problem. I've to clear any cache or
something?
>>>
>>> Check the actual syslog. And show CUPS configuration too.
>>> May be CUPS is blocked by apparmor and unable to read necessary
files
>>> (i.e.
>>> KDC tickets).
>>>
>>>
>>> --
>>> With best regards,
>>> Andrey Repin
>>> Monday, May 4, 2015 19:49:20
>>>
>>> Sorry for my terrible english...
>>
>>
>> I don't have apparmor and on cups I've added the group to
SystemGroup:
>> SystemGroup printadmin lpadmin
>>
>> and the other in cupsd.conf
>> LogLevel warn
>> MaxLogSize 0
>> # Allow remote access
>> Port 80
>> Listen /var/run/cups/cups.sock
>> # Share local printers on the local network.
>> Browsing On
>> BrowseOrder allow,deny
>> BrowseRemoteProtocols
>> BrowseAddress @LOCAL
>> BrowseLocalProtocols CUPS dnssd
>> DefaultAuthType Basic
>> WebInterface Yes
>> DefaultLanguage es
>>
>> <Location />
>>   # Allow shared printing...
>>   Order allow,deny
>>   Allow @LOCAL
>> </Location>
>> <Location /admin>
>>   Order allow,deny
>>   Allow From *
>> </Location>
>> <Location /admin/conf>
>>   AuthType Default
>>   Require user @SYSTEM
>>   Order allow,deny
>> </Location>
>> <Policy default>
>>   JobPrivateAccess all
>>   JobPrivateValues none
>>   SubscriptionPrivateAccess default
>>   SubscriptionPrivateValues default
>>   <Limit Create-Job Print-Job Print-URI Validate-Job>
>>     Order deny,allow
>>   </Limit>
>>   <Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job
>> Purge-Jobs Set-Job-Attributes Create-Job-Subscription
Renew-Subscription
>> Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job
>> Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job
>> CUPS-Get-Document>
>>     Require user @OWNER @SYSTEM printersjobsmanagers
>>     Order deny,allow
>>   </Limit>
>>   <Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer
>> CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default
CUPS-Get-Devices>
>>     AuthType Default
>>     Require user @SYSTEM
>>     Order deny,allow
>>   </Limit>
>>   <Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer
>> Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs
>> Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer
>> Startup-Printer Promote-Job Schedule-Job-After Cancel-Jobs
CUPS-Accept-Jobs
>> CUPS-Reject-Jobs>
>>     AuthType Default
>>     Require user @SYSTEM
>>     Order deny,allow
>>   </Limit>
>>   <Limit Cancel-Job CUPS-Authenticate-Job>
>>     Require user @OWNER @SYSTEM
>>     Order deny,allow
>>   </Limit>
>>   <Limit All>
>>     Order deny,allow
>>   </Limit>
>> </Policy>
>> <Policy authenticated>
>>   JobPrivateAccess all
>>   JobPrivateValues none
>>   SubscriptionPrivateAccess default
>>   SubscriptionPrivateValues default
>>   <Limit Create-Job Print-Job Print-URI Validate-Job>
>>     AuthType Default
>>     Order deny,allow
>>   </Limit>
>>   <Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job
>> Purge-Jobs Set-Job-Attributes Create-Job-Subscription
Renew-Subscription
>> Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job
>> Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job
>> CUPS-Get-Document>
>>     AuthType Default
>>     Require user @OWNER @SYSTEM
>>     Order deny,allow
>>   </Limit>
>>   <Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer
>> CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default>
>>     AuthType Default
>>     Require user @SYSTEM
>>     Order deny,allow
>>   </Limit>
>>   <Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer
>> Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs
>> Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer
>> Startup-Printer Promote-Job Schedule-Job-After Cancel-Jobs
CUPS-Accept-Jobs
>> CUPS-Reject-Jobs>
>>     AuthType Default
>>     Require user @SYSTEM
>>     Order deny,allow
>>   </Limit>
>>   <Limit Cancel-Job CUPS-Authenticate-Job>
>>     AuthType Default
>>     Require user @OWNER @SYSTEM
>>     Order deny,allow
>>   </Limit>
>>   <Limit All>
>>     Order deny,allow
>>   </Limit>
>> </Policy>
>>
>> and syslog don't have any new info:
>> May  4 18:47:12 print winbindd[2491]: [2015/05/04 18:47:12.659066,  0]
>> ../lib/util/fault.c:72(fault_report)
>> May  4 18:47:12 print winbindd[2491]:
>> ==============================================================>>
May  4 18:47:12 print winbindd[2491]: [2015/05/04 18:47:12.659695,  0]
>> ../lib/util/fault.c:73(fault_report)
>> May  4 18:47:12 print winbindd[2491]:   INTERNAL ERROR: Signal 11 in
pid
>> 2491 (4.1.17-Debian)
>> May  4 18:47:12 print winbindd[2491]:   Please read the
Trouble-Shooting
>> section of the Samba HOWTO
>> May  4 18:47:12 print winbindd[2491]: [2015/05/04 18:47:12.660320,  0]
>> ../lib/util/fault.c:75(fault_report)
>> May  4 18:47:12 print winbindd[2491]:
>> ==============================================================>>
May  4 18:47:12 print winbindd[2491]: [2015/05/04 18:47:12.660754,  0]
>> ../source3/lib/util.c:785(smb_panic_s3)
>> May  4 18:47:12 print winbindd[2491]:   PANIC (pid 2491): internal
error
>> May  4 18:47:12 print winbindd[2491]: [2015/05/04 18:47:12.662065,  0]
>> ../source3/lib/util.c:896(log_stack_trace)
>> May  4 18:47:12 print winbindd[2491]:   BACKTRACE: 27 stack frames:
>> May  4 18:47:12 print winbindd[2491]:    #0
>> /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(log_stack_trace+0x1a)
>> [0x7f926398be1a]
>> May  4 18:47:12 print winbindd[2491]:    #1
>> /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(smb_panic_s3+0x20)
>> [0x7f926398bef0]
>> May  4 18:47:12 print winbindd[2491]:    #2
>> /usr/lib/x86_64-linux-gnu/libsamba-util.so.0(smb_panic+0x2f)
>> [0x7f9267cc270f]
>> May  4 18:47:12 print winbindd[2491]:    #3
>> /usr/lib/x86_64-linux-gnu/libsamba-util.so.0(+0x1e906) [0x7f9267cc2906]
>> May  4 18:47:12 print winbindd[2491]:    #4
>> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0) [0x7f92680ef0a0]
>> May  4 18:47:12 print winbindd[2491]:    #5
>> /usr/lib/x86_64-linux-gnu/libkrb5.so.26(krb5_storage_free+0x1)
>> [0x7f92624cc9e1]
>> May  4 18:47:12 print winbindd[2491]:    #6
>> /usr/lib/x86_64-linux-gnu/libkrb5.so.26(+0x482ad) [0x7f92624b22ad]
>> May  4 18:47:12 print winbindd[2491]:    #7
>> /usr/lib/x86_64-linux-gnu/samba/libgse.so.0(+0x97bf) [0x7f92645277bf]
>> May  4 18:47:12 print winbindd[2491]:    #8
>>
/usr/lib/x86_64-linux-gnu/samba/libgse.so.0(gse_krb5_get_server_keytab+0x18b)
>> [0x7f9264527d8b]
>> May  4 18:47:12 print winbindd[2491]:    #9
>> /usr/lib/x86_64-linux-gnu/samba/libgse.so.0(+0xbb48) [0x7f9264529b48]
>> May  4 18:47:12 print winbindd[2491]:    #10
>> /usr/lib/x86_64-linux-gnu/libgensec.so.0(gensec_start_mech+0x42)
>> [0x7f92649ba7e2]
>> May  4 18:47:12 print winbindd[2491]:    #11
>> /usr/lib/x86_64-linux-gnu/libgensec.so.0(gensec_start_mech_by_oid+0x2e)
>> [0x7f92649bab3e]
>> May  4 18:47:12 print winbindd[2491]:    #12
>> /usr/sbin/winbindd(kerberos_return_pac+0x491) [0x7f9268546d61]
>> May  4 18:47:12 print winbindd[2491]:    #13
>> /usr/sbin/winbindd(winbindd_dual_pam_auth+0xab8) [0x7f926856e558]
>> May  4 18:47:12 print winbindd[2491]:    #14
/usr/sbin/winbindd(+0x663bc)
>> [0x7f92685843bc]
>> May  4 18:47:12 print winbindd[2491]:    #15
>> /usr/lib/x86_64-linux-gnu/libtevent.so.0(+0x986b) [0x7f92619ee86b]
>> May  4 18:47:12 print winbindd[2491]:    #16
>> /usr/lib/x86_64-linux-gnu/libtevent.so.0(+0x7d56) [0x7f92619ecd56]
>> May  4 18:47:12 print winbindd[2491]:    #17
>> /usr/lib/x86_64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x9d)
>> [0x7f92619e93ed]
>> May  4 18:47:12 print winbindd[2491]:    #18
/usr/sbin/winbindd(+0x688c0)
>> [0x7f92685868c0]
>> May  4 18:47:12 print winbindd[2491]:    #19
/usr/sbin/winbindd(+0x68fd5)
>> [0x7f9268586fd5]
>> May  4 18:47:12 print winbindd[2491]:    #20
>>
/usr/lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_immediate+0xe2)
>> [0x7f92619e9ca2]
>> May  4 18:47:12 print winbindd[2491]:    #21
>> /usr/lib/x86_64-linux-gnu/libtevent.so.0(+0x9601) [0x7f92619ee601]
>> May  4 18:47:12 print winbindd[2491]:    #22
>> /usr/lib/x86_64-linux-gnu/libtevent.so.0(+0x7d56) [0x7f92619ecd56]
>> May  4 18:47:12 print winbindd[2491]:    #23
>> /usr/lib/x86_64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x9d)
>> [0x7f92619e93ed]
>> May  4 18:47:12 print winbindd[2491]:    #24
>> /usr/sbin/winbindd(main+0xaeb) [0x7f926854604b]
>> May  4 18:47:12 print winbindd[2491]:    #25
>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)
[0x7f9261678ead]
>> May  4 18:47:12 print winbindd[2491]:    #26
/usr/sbin/winbindd(+0x286bd)
>> [0x7f92685466bd]
>> May  4 18:47:12 print winbindd[2491]: [2015/05/04 18:47:12.667553,  0]
>> ../source3/lib/dumpcore.c:312(dump_core)
>> May  4 18:47:12 print winbindd[2491]:   unable to change to
>> /var/log/samba/cores/winbindd
>> May  4 18:47:12 print winbindd[2491]:   refusing to dump core
>>
>>
>> Greetings!!
>>
>
>
> I cannot make it work. I've tried with Samba 4.1.17 level 2003, Sernet
> Samba 4.2.1 level 2008_R2, both versions on client too... but I always get
> the same Winbind error.
> It only fail with internal authentication because Windows clients and
> samba authentication works perfect, and the error is only showed on memeber
> server (the AD don't show any error on log).
>
> Is necessary any custom configuration for internal authentication?.
> Kerberos authentication works, because I've tried to kinit with an
admin
> account and with a test account and both are working.
>
>
> I've followed this steps to add the client to AD domain:
>
>    1. I've Installed samba, winbind, libnss-winbind and libpam-winbind
>    2. I've used the wiki example to configure the smb.conf
>    3. I've edited the nsswitch.conf to add "winbind" to group
and passwd
>    (getent works perfect)
>    4. I've executed the join command of the wiki: net ads join -U
>    administrator
>
> The configuration file is:
>
> [global]
>         workgroup = CASA
>         security = ADS
>         realm = CASA.RED
>         dedicated keytab file = /etc/krb5.keytab
>         kerberos method = secrets and keytab
>
>         idmap config *:backend = tdb
>         idmap config *:range = 2000-9999
>         idmap config CASA:backend = ad
>         idmap config CASA:schema_mode = rfc2307
>         idmap config CASA:range = 10000-99999
>
>         winbind nss info = rfc2307
>         winbind trusted domains only = no
>         winbind use default domain = yes
>         winbind enum users  = yes
>         winbind enum groups = yes
>         winbind refresh tickets = Yes
>         winbind expand groups = 4
>         winbind normalize names = Yes
>         domain master = no
>         local master = no
>         vfs objects = acl_xattr
>         map acl inherit = Yes
>         store dos attributes = Yes
>
>
> Samba shares permissions are working, but all the local authentication
> like ssh or cups webinterface fails.
>
>
> I've forgotten something?
>
>
> Thanks!!
>
Hi again!!, this time is not for help request as always :P finally i've
found the solution and I want to share it.
The problem was just permissions. If you change the keytab permission to
644 it works perfect: chmod 644 /etc/krb5.keytab
Anyway I don't understand why the daemons can't read that file when are
running as root.

Greetings!!

Greetings, Daniel Carrasco Mar?n!
> Hi again!!, this time is not for help request as always :P finally i've
> found the solution and I want to share it.
> The problem was just permissions. If you change the keytab permission to
> 644 it works perfect: chmod 644 /etc/krb5.keytab
> Anyway I don't understand why the daemons can't read that file when
are
> running as root.
Not all daemons are run as root, far from that.
Most of single-purpose daemons, such as cups, run as their own users.


-- 
With best regards,
Andrey Repin
Tuesday, May 12, 2015 20:14:19

Sorry for my terrible english...

On Tue, 12 May 2015, Andrey Repin wrote:
> Greetings, Daniel Carrasco Mar?n!
>
>> Hi again!!, this time is not for help request as always :P finally
i've
>> found the solution and I want to share it.
>> The problem was just permissions. If you change the keytab permission
to
>> 644 it works perfect: chmod 644 /etc/krb5.keytab
>> Anyway I don't understand why the daemons can't read that file
when are
>> running as root.
>
> Not all daemons are run as root, far from that.
> Most of single-purpose daemons, such as cups, run as their own users.
Yep, this is done for security purposes so that if one process is 
compromised, it doesn't have administrative access to the rest of the 
system.

In a similar vein, you don't generally want any process on the machine to 
have access to some things.  The system kerberos keytab is probably one of 
those.  If cups is running as it's own user, a better solution would be to 
either generate a new keytab just for cups, or copy the existing keytab 
and make it only readable by the cups user.