Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

switch -new_console:u:"other_user:password" lock the account of other_user #1557

Open
Maximus5 opened this issue Jul 31, 2015 · 9 comments
Open

Comments

@Maximus5
Copy link
Owner

Originally reported on Google Code with ID 1557

Required information!
OS version: Win7 SP1   x64
ConEmu version: ConEmuPack.140412.7z
Far version (if you are using Far Manager): No Far

*Bug description*
Launching a task with the switch -new_console:u (with login and password giben on the
command line) to run as another user will lock this user account.
Our active directory run on Windows 2008R2. The forest is at 2008R2 fonctionnal level.
Note that launching a command as another user using the "New console dialog..." does
not trigger the bug.

ConEmuPack.140304.7z is NOT affected.
All preview version since are affected.

*Steps to reproduction*
1. Log on Windows as DOMAIN\user
2. Create a new task cmd -new_console:u:"DOMAIN\other_user:password"
3. Launch task
4. Constat that
  - the task is launched
  - but the account DOMAIN\other_user is now locked
  - if the same task in launched again before unlocking the account, it fail with the
attached message "Can't create new console, command execution failed (code 1909). The
account is loccked... Choose your shell?"


Reported by syloiseau35 on 2014-04-17 07:36:23


- _Attachment: snap-2014-04-17_09-35-36.png
![snap-2014-04-17_09-35-36.png](https://storage.googleapis.com/google-code-attachments/conemu-maximus5/issue-1557/comment-0/snap-2014-04-17_09-35-36.png)_
@Maximus5
Copy link
Owner Author

Are you sure dialog is working properly? They must be using one brunch of code and your
issue is very strange... Please recheck.

Reported by ConEmu.Maximus5 on 2014-04-17 07:58:29

@Maximus5
Copy link
Owner Author

Yes. I just rechecked ConEmuPack.140412.7z and the dialog does not lock the account.

Attached:
 - The task definition (which lock the account, while launching the task correctly)
 - The "new dialog" (which works and do not lock the account)

One difference between those 2 ways is that the task start "cmd" in %USERPROFILE%,
while the new dialog start "C:\Windows\System32\cmd" in the directory containing conemu64.exe.
Beside the impact on the tab title, the two cmd are the same (as shown by the task
explorer). Anyway, cmd is an example, but the same happen with powershell.exe.

Best regards,
Sylvain

Reported by syloiseau35 on 2014-04-17 11:44:37


- _Attachment: snap-2014-04-17_13-17-59.png
![snap-2014-04-17_13-17-59.png](https://storage.googleapis.com/google-code-attachments/conemu-maximus5/issue-1557/comment-2/snap-2014-04-17_13-17-59.png)_ - _Attachment: snap-2014-04-17_13-21-43.png
![snap-2014-04-17_13-21-43.png](https://storage.googleapis.com/google-code-attachments/conemu-maximus5/issue-1557/comment-2/snap-2014-04-17_13-21-43.png)_

@Maximus5
Copy link
Owner Author

I can't reproduce the problem in fresh installed 2012R2 domain.

So, more information from you required:
* type of both accounts (user/admin)
* PC you trying that (AD server or workstation in domain)
* examine, please, your server event logs, they must contain the reason of account
lock
* step-by-step screenshots illustrating the problem
* ConEmu installation paths and both accounts working dirs
* output of "set user" and "set ConEmu" under both accounts...

More information is better...

Reported by ConEmu.Maximus5 on 2014-04-24 15:37:55

@Maximus5
Copy link
Owner Author

Hello,
What a pity you cannot reproduce... It will be hardier to debug.

Anyway, I didn't find the reason of account lock in event log, but I will try again
and keep you informed.

For the rest:
* I'm logged in the domain with a nomal user domain account (with roaming profile).
The other account is a domain account member of some groups, included (indirectly)
the administrators of the domain.
* I'm on a Win7 workstation in the domain
* As said, I will try again to find the information about the reason for AD to lock
the account. Any idea as how to find it?

I reproduced yesterday with a new "ConEmuPack.140422.7z" portable pack, uncompressed
inside C:\conemu
Steps:
 screenshot 01_...: launch with new config.
    Let ConEmu create new config with default values
 screenshot 02_...: set user and set conemu
    User: sloiseau (normal domain user, admin of the local workstation)
    Current dir: C:\conemu (where is ConEmuC64.exe)
    ProfileDir: C:\Users\sloiseau (this is a roaming profile)
 screenshot 03_... and 04_...: Launch task with "New Task" dialog
    Nothing changed beside ticking "Another user" and typing user/password
    This works and account is NOT locked
 screenshot 05_...: set user and set conemu in this new task
    User: admin-sloiseau (domain user indirectly member of Domain Administrators)
    Current dir: C:\conemu (unchanged)
    ProfileDir: C:\Users\admin-sloiseau (this is a local profile)
 screenshot 06_...: Create a task
    commands: cmd -new_console:u:"DOMAIN\account:password"
 screenshot 07_...: Launch this newly created task
 screenshot 08_...: Task is launched, but account is now locked. Show set user and
set conemu
    User: admin-sloiseau
    Current Dir: C:\Users\admin-sloiseau (profile path for the user)
   -> This is different from precedent case
 screenshot 09_...: Result from trying to launch again the created task "Group9"
    Account is really locked
 screenshot 10_...: Result from trying to launch again the "New Task" dialog
    Message slighly different, but same cause

Thank you for investigating,
Sylvain

Reported by syloiseau35 on 2014-04-26 13:36:17


- _Attachment: 01_2014-04-25_15-41-24-Exécuter.png
![01_2014-04-25_15-41-24-Exécuter.png](https://storage.googleapis.com/google-code-attachments/conemu-maximus5/issue-1557/comment-4/01_2014-04-25_15-41-24-Exécuter.png)_ - _Attachment: 02_2014-04-25_15-43-39-C__Windows_System32_cmd.exe.png
![02_2014-04-25_15-43-39-C__Windows_System32_cmd.exe.png](https://storage.googleapis.com/google-code-attachments/conemu-maximus5/issue-1557/comment-4/02_2014-04-25_15-43-39-C__Windows_System32_cmd.exe.png)_ - _Attachment: 03_2014-04-25_15-44-14-C__Windows_System32_cmd.exe.png
![03_2014-04-25_15-44-14-C__Windows_System32_cmd.exe.png](https://storage.googleapis.com/google-code-attachments/conemu-maximus5/issue-1557/comment-4/03_2014-04-25_15-44-14-C__Windows_System32_cmd.exe.png)_ - _Attachment: 04_2014-04-25_15-44-55-ConEmu.png
![04_2014-04-25_15-44-55-ConEmu.png](https://storage.googleapis.com/google-code-attachments/conemu-maximus5/issue-1557/comment-4/04_2014-04-25_15-44-55-ConEmu.png)_ - _Attachment: 05_2014-04-25_15-45-26-C__Windows_System32_cmd.exe.png
![05_2014-04-25_15-45-26-C__Windows_System32_cmd.exe.png](https://storage.googleapis.com/google-code-attachments/conemu-maximus5/issue-1557/comment-4/05_2014-04-25_15-45-26-C__Windows_System32_cmd.exe.png)_ - _Attachment: 06_2014-04-25_15-46-29-ConEmu 140422 [64] Settings (test20140425) [reg].png
![06_2014-04-25_15-46-29-ConEmu 140422 [64] Settings (test20140425) [reg].png](https://storage.googleapis.com/google-code-attachments/conemu-maximus5/issue-1557/comment-4/06_2014-04-25_15-46-29-ConEmu 140422 [64] Settings %28test20140425%29 [reg].png)_ - _Attachment: 07_2014-04-25_15-47-04-C__Windows_System32_cmd.exe.png
![07_2014-04-25_15-47-04-C__Windows_System32_cmd.exe.png](https://storage.googleapis.com/google-code-attachments/conemu-maximus5/issue-1557/comment-4/07_2014-04-25_15-47-04-C__Windows_System32_cmd.exe.png)_ - _Attachment: 08_2014-04-25_15-47-38-cmd.png
![08_2014-04-25_15-47-38-cmd.png](https://storage.googleapis.com/google-code-attachments/conemu-maximus5/issue-1557/comment-4/08_2014-04-25_15-47-38-cmd.png)_ - _Attachment: 09_2014-04-25_15-48-52-ConEmu 140422 [64].png
![09_2014-04-25_15-48-52-ConEmu 140422 [64].png](https://storage.googleapis.com/google-code-attachments/conemu-maximus5/issue-1557/comment-4/09_2014-04-25_15-48-52-ConEmu 140422 [64].png)_ - _Attachment: 10_2014-04-25_15-49-20-cmd.png
![10_2014-04-25_15-49-20-cmd.png](https://storage.googleapis.com/google-code-attachments/conemu-maximus5/issue-1557/comment-4/10_2014-04-25_15-49-20-cmd.png)_

@Maximus5
Copy link
Owner Author

Hello,

Here are my new finding. I hope it may help to find the problem:

The problem seems to be in changing directory, because:
 - Launching with "New Dialog" do NOT lock the account, and do not change directory
 - Launching with the task and switchs -new_console:u:"DOMAIN\user:pass"...
   1. No other option -> Account is locked ; Task is nevertheless launched and PWD
is C:\Users\admin-sloiseau (the user profile dir)
   2. :d:"C:\Temp" -> Account is NOT locked ; PWD is as asked (C:\Temp)
   3. :d:"C:\Users\admin-sloiseau" -> Account is NOT locked ; PWD is as asked (C:\Users\admin-sloiseau)
   4. No other option for -new_console, but /dir "C:\temp" as "Tasks parameters" ->
idem 2. (Account is NOT locked ; PWD is as asked (C:\Temp))
   5. No other option for -new_console, but /dir "C:\Users\admin-sloiseau" as "Tasks
parameters" -> idem 3. (Account is NOT locked ; PWD is as asked (C:\Users\admin-sloiseau))

In short: Any directory works, any option to choose directory works. Only NOT giving
any directory indication in task definition will lock the account, while launching
in profile directory of user.


I didn't find so much information in event log. Anyway,
 - Account is locked because of "Bad Passwd count" exeeded (with 8 bad passwd)
 - Event log show a quick sequence of events 
  * Audit Success ID=4768 "A Kerberos authentification tocket (TGT) has been asked
  * Audit Success ID=4769 "A Kerberos service ticket has been asked"
  * Events 4768 followed by 4769 fifteen more times
  * Audit Success ID=4740 "A user account has been locked"

Best regards,
Sylvain

Reported by syloiseau35 on 2014-04-28 15:54:12

@Maximus5
Copy link
Owner Author

This will helps

Reported by ConEmu.Maximus5 on 2014-04-28 16:00:51

  • Status changed: Accepted

@Maximus5
Copy link
Owner Author

140428

Reported by ConEmu.Maximus5 on 2014-04-28 23:56:15

@Maximus5
Copy link
Owner Author

Hi,

I confirm version 140428 is working.
Thank you so much.

Only visible behavior change is that tab title is <<cmd -cur_console:d:"!USERPROFILE!">>.
Beside that, cmd is launched in user profile directory and the account is not locked.

Reported by syloiseau35 on 2014-04-29 07:24:15

@Maximus5
Copy link
Owner Author

Hi,

Version 140429 is working too.
Behavior has also returned to old behavior:
 * Tab title is just "cmd" for defined tasks (whatever directory is chosen).
 * Working dir is the %USERPROFILE% if no option was given

Great work, thank you.

Reported by syloiseau35 on 2014-04-30 12:00:08

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant