Web lists-archives.com

Re: [Samba] random wrong login shell in domain member




Hello Adam,

Have the same issue on CentOS 7.4. Ended up hardcording in smb.conf:
   template shell = /bin/bash
   template homedir = /home/%U

Never had such issues on Fedora. Please let me know if you'll find a real
fix.

Thank you,
Matt

On Tue, Mar 27, 2018 at 10:13 PM, adam_xu--- via samba <
samba@xxxxxxxxxxxxxxx> wrote:

> Hello, everybody. I have encountered some strange situations that are
> driving me crazy. I have 2 DCs which using sernet samba, version 4.7.6. and
> I use a samba version 4.6.2 as a domain member for file sharing in
> CentOS7.4. The domain member works well as a file server, but When I login
> to that domain member using AD authtication. Sometimes, It works OK too,
> but sometime , I can't login that domain member. error logs like this:
>  ssh -v alice@192.168.1.100
>
> OpenSSH_7.5p1, LibreSSL 2.5.4
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 52: Applying options for *
> debug1: Connecting to 192.168.1.100 [192.168.1.100] port 22.
> debug1: Connection established.
> debug1: key_load_public: No such file or directory
> debug1: identity file /Users/alice/.ssh/id_rsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /Users/alice/.ssh/id_rsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /Users/alice/.ssh/id_dsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /Users/alice/.ssh/id_dsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /Users/alice/.ssh/id_ecdsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /Users/alice/.ssh/id_ecdsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /Users/alice/.ssh/id_ed25519 type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /Users/alice/.ssh/id_ed25519-cert type -1
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_7.5
> debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
> debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
> debug1: Authenticating to 192.168.1.100:22 as 'alice'
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: algorithm: curve25519-sha256
> debug1: kex: host key algorithm: ecdsa-sha2-nistp256
> debug1: kex: server->client cipher: chacha20-poly1305@xxxxxxxxxxx MAC:
> <implicit> compression: none
> debug1: kex: client->server cipher: chacha20-poly1305@xxxxxxxxxxx MAC:
> <implicit> compression: none
> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> debug1: Server host key: ecdsa-sha2-nistp256 SHA256:pyZM5ige15wicpONpQ2t/
> z7DrzYl2wXS4ZRmG23H3Ks
> debug1: Host '192.168.1.100' is known and matches the ECDSA host key.
> debug1: Found key in /Users/alice/.ssh/known_hosts:31
> debug1: rekey after 134217728 blocks
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: rekey after 134217728 blocks
> debug1: SSH2_MSG_EXT_INFO received
> debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-
> with-mic,password
> debug1: Next authentication method: publickey
> debug1: Trying private key: /Users/alice/.ssh/id_rsa
> debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-
> with-mic,password
> debug1: Trying private key: /Users/alice/.ssh/id_dsa
> debug1: Trying private key: /Users/alice/.ssh/id_ecdsa
> debug1: Trying private key: /Users/alice/.ssh/id_ed25519
> debug1: Next authentication method: password
> alice@192.168.1.100's password:
> debug1: Authentication succeeded (password).
> Authenticated to 192.168.1.100 ([192.168.1.100]:22).
> debug1: channel 0: new [client-session]
> debug1: Requesting no-more-sessions@xxxxxxxxxxx
> debug1: Entering interactive session.
> debug1: pledge: network
> debug1: client_input_global_request: rtype hostkeys-00@xxxxxxxxxxx
> want_reply 0
> debug1: Sending environment.
> debug1: Sending env LANG = en_US.UTF-8
> Last login: Tue Mar 27 00:50:05 2018 from 10.1.1.53
> debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
> debug1: client_input_channel_req: channel 0 rtype eow@xxxxxxxxxxx reply 0
> debug1: channel 0: free: client-session, nchannels 1
> Connection to 192.168.1.100 closed.
> Transferred: sent 2892, received 2564 bytes, in 0.8 seconds
> Bytes per second: sent 3405.9, received 3019.6
> debug1: Exit status 1
>
> here's my domain member's smb.conf
> [global]
>         security = ADS
>         workgroup = EXAMPLE
>         realm = EXAMPLE.COM
>
>         log file = /var/log/samba/%m.log
>         log level = 3 passdb:5 auth:5 winbind:5
>
>         idmap config * : backend = tdb
>         idmap config * : range = 3000-7999
>         idmap config EXAMPLE:backend = ad
>         idmap config EXAMPLE:schema_mode = rfc2307
>         idmap config EXAMPLE:range = 10000-999999
>
>         idmap config EXAMPLE : unix_nss_info = yes
>         winbind use default domain = Yes
>         winbind enum users = Yes
>         winbind enum groups = Yes
>         winbind offline logon = yes
>         winbind refresh tickets = yes
>         access based share enum = yes
>         hide unreadable = yes
>
>         load printers = no
>         vfs objects = acl_xattr full_audit recycle
>         map acl inherit = yes
>         store dos attributes = yes
>
> someone else has reported this kind of error. They got the error all the
> time. but most of time, I can login successfully. Sometime when I got the
> error above, I use "getent passwd | grep alice", It shows that:
>
> alice:*:10016:10001:Li, Yan:/home/EXAMPLE/alice:/bin/false
>
> the defaut login shell which I have set in AD Users and Computers tool is
> "/bin/bash" for this user. and default home dir for this user is
> "/home/alice".
>
> After this error occurs,  I use "getent passwd | grep alice" again. I show
> the right result like:
>
> alice:*:10016:10001:Li, Yan:/home/alice:/bin/bash
>
> this time, I can login the domain member without any problem.
>
> By the way. I have do some testing when I use samba version 4.6.2 in
> CentOS7.4 as a standalone file server. sometimes the default shared
> [homes]  can not be accessed cause the user try to access
> /home/EXAMPLE/alice which is a wrong path. And Maybe serveral minutes later
> , the user "alice" can access the shared [homes]. this time, she got the
> right path "/home/alice". It didn't happend when I use samba 4.4.4 in
> CentOS7.3.
>
> I didn't use any openldap server nor sssd server. this server is a pure
> domain member.
>
> Is it a bug in samba 4.6 or just in RHEL/CentOS?   does anyone have this
> situation in Debian or Ubuntu or any other distributions? Thanks everybody.
>
>
>
>
>
>
>
>
> yours Adam
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba