adam_xu at adagene.com.cn
2018-Mar-28 02:13 UTC
[Samba] random wrong login shell in domain member
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 at 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 at openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com 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 at 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 at openssh.com debug1: Entering interactive session. debug1: pledge: network debug1: client_input_global_request: rtype hostkeys-00 at openssh.com 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 at openssh.com 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
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 at lists.samba.org> 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 at 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 at openssh.com MAC: > <implicit> compression: none > debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com 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 at 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 at openssh.com > debug1: Entering interactive session. > debug1: pledge: network > debug1: client_input_global_request: rtype hostkeys-00 at openssh.com > 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 at openssh.com 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 >
adam_xu at adagene.com.cn
2018-Mar-28 02:46 UTC
[Samba] random wrong login shell in domain member
Thank you, Matt. I finally knew that I was not the only one who encountered this situation! My temporary solution is the same with you. But not all the user are allowed to use login shell "/bin/bash", It is dangerous. let's see if the developers in samba or any other experts can give some advice. yours Adam From: Matt Savin via samba Date: 2018-03-28 10:28 To: adam_xu at adagene.com.cn CC: samba Subject: 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 at lists.samba.org> 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 at 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 at openssh.com MAC: > <implicit> compression: none > debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com 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 at 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 at openssh.com > debug1: Entering interactive session. > debug1: pledge: network > debug1: client_input_global_request: rtype hostkeys-00 at openssh.com > 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 at openssh.com 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