Bug 9592 - "net ads join -k" fails due to absence of LOGNAME env. on FreeBSD
Summary: "net ads join -k" fails due to absence of LOGNAME env. on FreeBSD
Status: RESOLVED WONTFIX
Alias: None
Product: Samba 3.6
Classification: Unclassified
Component: Client Tools (show other bugs)
Version: 3.6.9
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Volker Lendecke
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-24 13:00 UTC by d.y.kazarov
Modified: 2016-07-27 11:17 UTC (History)
0 users

See Also:


Attachments
Warning about missing LOGNAME env. (539 bytes, application/octet-stream)
2013-01-24 13:00 UTC, d.y.kazarov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description d.y.kazarov 2013-01-24 13:00:24 UTC
Created attachment 8476 [details]
Warning about missing LOGNAME env.

On FreeBSD su command with full login simulation ("-l" or "-" option) clears LOGNAME environment. The absence of LOGNAME environment makes "net ads join -k" to use 'anonymous' connections to domain controller and the joining fails.

# kinit domadmin
domadmin@DOMAIN.LOC's Password:
# unset LOGNAME
# net ads join -k
Failed to join domain: failed to join domain 'DOMAIN.LOC' over rpc: Access denied
# export LOGNAME=root
# net ads join -k
Using short domain name -- DOMAIN
Joined 'HOSTNAME' to realm 'domain.loc'

It's really not a problem to set the LOGNAME environment, but importance of this environment is not documented and 'net' issues no warning so it's very hard to find a source of a problem.

Attached patch adds such warning.
Comment 1 Jared Sutton 2016-07-26 16:36:46 UTC
I've run into this issue when running "net ads join -k" from /etc/rc.local on a RHEL 6.7 system.  This issue is 3+ years old and has a proposed patch which at least informs the user of the problem.  Any chance someone could commit the proposed patch?
Comment 2 Björn Jacke 2016-07-27 11:17:18 UTC
I really think that this is not worth changing and putting additional checks and verbose output in the code. I would never recommend anyone not to give a username for a "net join". Doing it without krb5 also shows the user name that is being used by the "net" command. Those people who don't do that and in addition to that also blindly use kerberos (which usually is not working before we join a machine by the way) should really know what they do.