Terminal: تشغيل كمسؤول

@ DHowett-MSFT كان بإمكاني أن أقسم أن لدينا مشكلة مكررة تجلس في مكان ما من أجل هذا ، لكن لا يمكنني العثور عليها الآن. هل تتذكر ما سبب هذا؟

آه يا ​​رجل ، آسف إذا كانت مكررة.

لا يوجد سبب ، ابدأ التطبيق بشكل جيد ولكن انقر بزر الماوس الأيمن وابدأ بفشل المسؤول ، يطالب Windows UAC بكلمة مرور المسؤول مرتين ثم تحصل على الخطأ.

أنا أيضًا أواجه هذه المشكلة حاليًا. لقد بحثت عن المحطة في شريط المهام

ثم طُلب مني إدخال بيانات اعتماد المسؤول مرتين! موجه اداري واحد تلو الآخر ثم عندما انتهيت من إدخال بيانات الاعتماد الخاصة بي في المرة الثانية ظهرت رسالة الخطأ هذه:

لقد قمت للتو بتثبيت المحطة اليوم.

نسخة المحطة:
الإصدار: 0.2.1831.0

إصدار نظام التشغيل:
نظام التشغيل Windows 10 Pro
10.0.18362 بناء 18362

أيضًا كاقتراح بدلاً من تشغيل الجهاز بالكامل كمسؤول من شريط المهام ، فربما لديك بدائل؟

فمثلا:

عند فتح علامة تبويب جديدة ، اطلب من المستخدم أو لديك بعض واجهة المستخدم التي تسأل عما إذا كانوا يريدون فتح المثيل الجديد كمسؤول؟

أو فقط انقر بزر الماوس الأيمن على الجهاز لفتح علامة تبويب المسؤول من نفس الدليل بالضبط. (سيكون ذلك مفيدًا جدًا لـ powerhell-core لأنه لا يحتوي على وظائف جيدة مثل sudo)

قد لا يكون دعم Windows Terminal الذي يعمل في وضع المسؤول سلوكًا جيدًا ، مما يعني أن جميع القذائف في علامات التبويب الأخرى المفتوحة من Ctrl + T قد تكون امتيازًا للمسؤول. بقدر ما أعرف ، لا يقوم Windows Terminal بتنفيذ أي كود من المسؤول إلى المستخدم المقيد. في الواقع ، ما يفتقر إليه Windows هو نوع تنفيذ الامتياز الذي لا يتطلب تفاعل واجهة المستخدم ، مثل sudo.

لكن تنفيذ sudo قد يكون أيضًا مرهقًا. يكون تدفق فعل الرون تقريبًا كما يلي (إذا كان هناك أي خطأ ، فيرجى تذكيري):

1. ينتقل AppInfo ويتحدث إلى سلطة الأمن المحلية للحصول على الرمز المميز للمستخدم الذي قام بتسجيل الدخول في الجلسة 1.
2. يقوم AppInfo بتحميل بنية STARTUPINFOEX (جديد في Vista) ، ويستدعي العلامة التجارية Vista API InitializeProcThreadAttributeList () مع مساحة لسمة واحدة.
3. يتم استدعاء OpenProcess () للحصول على مؤشر للعملية التي بدأت استدعاء RPC.
4. يتم استدعاء UpdateProcThreadAttribute () بواسطة PROC_THREAD_ATTRIBUTE_PARENT_PROCESS ، ويستخدم المقبض الذي تم استرداده في الخطوة 3.
5. يتم استدعاء CreateProcessAsUser () باستخدام EXTENDED_STARTUPINFO_PRESENT ونتائج الخطوتين 1 و 4.
6. تم استدعاء DeleteProcThreadAttributeList ().
7. يتم جمع النتائج وتنظيف المقابض.

يمكننا استخلاص استنتاج بسيط. في الواقع ، runas هو في الواقع عملية عادية تبدأ طلب RPC لعملية ذات امتيازات عالية. تقوم عملية الامتياز العالي (خدمة AppInfo) بإنشاء عملية المسؤول وتعيين العملية الأصلية كعملية عادية.

لا يدعم AppInfo حاليًا إعداد دليل عمل وإدخال وإخراج (على الرغم من استدعاء CreateProcessAsUser) عند بدء تشغيل عملية المسؤول. هذه مشكلة يجب حلها لتمكين دعم sudo للتشغيل في Windows Terminal. (ShellExecuteEx SEE_MASK_NO_CONSOLE لا يعمل)

شيلكوتوينفو :

typedef struct _SHELLEXECUTEINFOW {
  DWORD     cbSize;
  ULONG     fMask;
  HWND      hwnd;
  LPCWSTR   lpVerb;
  LPCWSTR   lpFile;
  LPCWSTR   lpParameters;
  LPCWSTR   lpDirectory;
  int       nShow;
  HINSTANCE hInstApp;
  void      *lpIDList;
  LPCWSTR   lpClass;
  HKEY      hkeyClass;
  DWORD     dwHotKey;
  union {
    HANDLE hIcon;
    HANDLE hMonitor;
  } DUMMYUNIONNAME;
  HANDLE    hProcess;
} SHELLEXECUTEINFOW, *LPSHELLEXECUTEINFOW;

انظر: https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute

| القيمة | المعنى |
| --- | --- |
| PROC_THREAD_ATTRIBUTE_PARENT_PROCESS | المعلمة lpValue هي مؤشر لمقبض لعملية لاستخدامها بدلاً من عملية الاستدعاء باعتبارها الأصل للعملية التي يتم إنشاؤها. يجب أن يكون لعملية الاستخدام حق الوصول PROCESS_CREATE_PROCESS.

تشمل السمات الموروثة من العملية المحددة المقابض ، وخريطة الجهاز ، وتقارب المعالج ، والأولوية ، والحصص ، والرمز المميز للعملية ، وكائن الوظيفة. (لاحظ أن بعض السمات مثل منفذ التصحيح ستأتي من عملية الإنشاء ، وليست العملية المحددة بواسطة هذا المقبض.) |

هذه بالتأكيد مشكلة منصة ويندوز. أنا أسندها لنفسي للمتابعة مع الفريق الذي يملكها وإغلاق ذلك. شكر.

يعجبني اقتراح @ YMba9g8j9CJp0wLoQf5y بتخويل علامة تبويب بامتياز تصعيد. أنا من ConEmu حيث يمكننا إنشاء علامة تبويب بامتياز المسؤول أو بدونه. عند إنشاء علامة تبويب المسؤول ، سيُطلب مني استخدام UAC (للأبد).

أليس هذا مجرد سلوك طبيعي لتطبيقات متجر Windows؟ يبدو أن تطبيق Preview صدر مؤخرًا.
لكني بحاجة إلى طريقة لتشغيل قذائف مرتفعة. لا يبدو من الممكن القيام بذلك اليوم (فتح علامات التبويب كمسؤول).

مرحبًا ، لسنا متأكدين من وجود أي شيء يمكننا القيام به حيال ذلك. هل تمانع في تقديم التعليقات في فئة "النظام الأساسي للمطورين> فئة نشر التطبيق"؟ سيساعد ذلك في توجيهه إلى الفريق المناسب ، ويجمع بعض المعلومات التشخيصية المفيدة للغاية.

الربط: هذا أيضًا # 1538

على الرغم من أنني أتفق مع القرار. يجعل استخدام chocolatey أمرًا مؤلمًا للغاية دون الحاجة إلى التشغيل الصريح في وضع المسؤول. (

musm لدي هذا في تكوين PowerShell 6 الخاص بي:

function GoAdmin { start-process pwsh –verb runAs }

(استبدل pwsh بـ powershell إذا كنت تستخدم بوويرشيل القديم)

لذلك كلما احتجت إلى تثبيت / تحديث الحزم عبر chocolatey ، اكتب GoAdmin (في PowerShell المستضاف في Windows Terminal) ، والذي يأخذني إلى نافذة بوويرشيل المسؤول المنفصلة. هناك يمكنني تشغيل جميع أوامر المسؤول بالشوكولاتة. ثم أقوم ببساطة بإغلاق نافذة المسؤول ، واكتب refreshenv في جلسة Windows Terminal لتحديث جميع متغيرات PATH. إنه سهل جدًا.

أود بالتأكيد طريقة لإطلاق wt (Windows Terminal) بدلاً من الذهاب مباشرة إلى pwsh "العاري" ، لكن هذا لا يبدو ممكنًا. لكنها وجع بسيط. مه. :-)

ما زلت أتلقى خطأ عندما أريد بدء تشغيل WT (0.9.433.0) كمسؤول:

يحدث على العديد من الأجهزة ، مع أحدث WT و Windows (الإصدار 10.0.18363.657).
لا أفهم تمامًا سبب إغلاق هذه المشكلة وما الحل البديل.

في الواقع ، لم ينجح الأمر أبدًا ، وكان آخر تعليق تلقيته ، إنها مشكلة Windows وسوف يطرحونها مع الفريق.

سيرفعونه مع الفريق.

لا أعتقد ذلك. انها أشبه "يجب رفعه مع الفريق".

أنا متأكد من أنهم لا يفكرون في إصدار Win Terminal v1 مع تعطيل إحدى أهم الوظائف.
سيء للغاية لأنه يجعل الإصدارات التجريبية الحالية من WT غير قابلة للاستخدام.

سيؤدي هذا إلى ظهور نافذة بوويرشيل جديدة مع المسؤول. ليس بالضبط ما نريده ولكنه حل بديل. قم بإنشاء ملف تعريف جديد باستخدام سطر الأوامر التالي.

"commandline": "powershell.exe -Command \"Start-Process powershell.exe -Verb RunAs\"",

لماذا هذا مغلق؟ لا تزال هناك حاجة إلى رفع علامة التبويب.

يتم تتبع هذا في مجموعة من المشكلات الأخرى في هذا المستودع ، لهذا السبب.

@ DHowett-MSFT شكرا. أي قضية يجب أن نتبع؟ لا أعتقد أنه مذكور أعلاه.

musm لدي هذا في تكوين PowerShell 6 الخاص بي:

function GoAdmin { start-process pwsh –verb runAs }

(استبدل pwsh بـ powershell إذا كنت تستخدم بوويرشيل القديم)

لذلك كلما احتجت إلى تثبيت / تحديث الحزم عبر chocolatey ، اكتب GoAdmin (في PowerShell المستضاف في Windows Terminal) ، والذي يأخذني إلى نافذة بوويرشيل المسؤول المنفصلة. هناك يمكنني تشغيل جميع أوامر المسؤول بالشوكولاتة. ثم أقوم ببساطة بإغلاق نافذة المسؤول ، واكتب refreshenv في جلسة Windows Terminal لتحديث جميع متغيرات PATH. إنه سهل جدًا.

أود بالتأكيد طريقة لإطلاق wt (Windows Terminal) بدلاً من الذهاب مباشرة إلى pwsh "العاري" ، لكن هذا لا يبدو ممكنًا. لكنها وجع بسيط. مه. :-)

في الويندوز أين يوجد ملف التكوين هذا؟

@ mian-muhammad أعتقد أنه كان يقصد ملف PowerShell الشخصي. https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_profiles

لقد وجدت حلاً. يمكنك استخدام Chocolatey لتثبيت حزمة تسمى sudo (choco install -y sudo). ثم يمكنك استخدام sudo كما هو متوقع.

يبدو أنه يمكنني حاليًا فتح الجهاز كمسؤول ؛ على الأقل يعمل على جهازي. سيكون من الأفضل إذا تمكنا من إنشاء علامة تبويب كمسؤول مثل ConEmu (الذي تمت مناقشته في # 632) ، ولكن لا فائدة حاليًا لإعادة فتح هذه المشكلة.

طلبات الميزات المعلقة الأخرى ذات الصلة:

• # 146 sudo الذي قد يهتم به @ Pens99
• # 576 شريط المهام jumplist ؛ أنا أعتبر هذا بديلاً للرقم 632 بسبب التضمين الأمني ​​(الذي أفهمه تمامًا أنه يأتي من صناعة الأمن) ، خاصةً عند دمجه مع # 3246.

أتمنى أن يساعد هذا كل شخص يتابع هذا الموضوع.

@ DHowett-MSFT ما هي المشكلة التي يجب أن نتبعها ونبدأ في حلها؟ المشكلة المرجعية الأخرى الوحيدة التي يمكنني رؤيتها هي # 1538 وهي مغلقة أيضًا.

أنا متأكد من أن موقف Microsoft لا يمكن أن يكون أن كل شخص يجب أن يكون لديه حقوق إدارية على مستخدمه القياسي بدلاً من استخدام حساب مسؤول منفصل إذا كانوا يريدون استخدام تطبيقات Windows الحديثة. هذا بعد كل شيء مخالف لممارسات الأمان القياسية.

@ danstur أفضل ما يمكنني

@ DHowett-MSFT شكرًا على المشكلات ، ويسعدني سماع أنه يتم تعقبها.

للتوضيح: إذا قمت بتثبيت التطبيق عبر الخيارات المذكورة في # 1386 ، فهل سأتمكن بعد ذلك من تشغيله كمستخدم مختلف أم أن ذلك لا يزال لا يعمل؟ لا أمانع في الاضطرار إلى تسجيل التطبيق (هل يعني ذلك تشغيل Add-AppxPackage ؟) مع المستخدمين الآخرين.

@ DHowett-MSFT Dustin Howett FTE شكرًا على المشكلات ، ويسعدني سماع أنه يتم تعقبها.

للتوضيح: إذا قمت بتثبيت التطبيق عبر الخيارات المذكورة في # 1386 ، فهل سأتمكن بعد ذلك من تشغيله كمستخدم مختلف أم أن ذلك لا يزال لا يعمل؟ لا أمانع في الاضطرار إلى تسجيل التطبيق (هل يعني ذلك تشغيل Add-AppxPackage ؟) مع المستخدمين الآخرين.

يجب أن يعمل بشكل جيد. ستحتاج إلى إضافة AppxPackage مثل هؤلاء المستخدمين ، نعم. :ابتسامة:

مسرور لرؤيته يجري معالجته.

يجب حل هذه المشكلة ، كما هو الحال الآن في أي بيئة Windows تم إعدادها باستخدام حسابات منفصلة للمشرف والمستخدم (كما ينبغي) ، لا يمكن استخدام الجهاز الطرفي للمسؤولين إذا تم تثبيته من متجر MS (موصى به)

مسرور لرؤيته يجري معالجته.

يجب حل هذه المشكلة ، كما هو الحال الآن في أي بيئة Windows تم إعدادها باستخدام حسابات منفصلة للمشرف والمستخدم (كما ينبغي) ، لا يمكن استخدام الجهاز الطرفي للمسؤولين إذا تم تثبيته من متجر MS (موصى به)

كان الحل الذي نجح معي هو تسجيل الدخول كمستخدم إداري في الجهاز المحلي و "تثبيت" الجهاز مرة أخرى من المتجر. بعد ذلك ، عند تسجيل الدخول كمستخدم قياسي ، يمكنني تشغيل الجهاز كمسؤول

نعم ، يبدو أن المشكلة تكمن في أن المتجر يسجل التطبيق للمستخدم الحالي فقط. هذا جيد بالنسبة لمعظم التطبيقات (في الواقع هذا هو كيفية تثبيت معظم التطبيقات على أي حال) ولكنه ليس جيدًا للتطبيقات الإدارية مثل المحطات الطرفية.

مرحبًا يا مستقبلي: يتم تتبع مشكلة تسجيل المتجر داخليًا باستخدام MSFT: 20356613 ومناقشتها بإسهاب في # 4217

مرحبا،
واجهت هذه المشكلة أيضًا في حسابي العادي. الحل هو تثبيت تطبيق Terminal مرة أخرى أثناء تسجيل الدخول إلى حساب المسؤول. بعد ذلك ستتمكن من التشغيل كمسؤول في حسابك العادي.

كذلك هنا. يبدو أن المشكلة لم تحل

لدي حل بديل آخر أقل من الكمال لا يسمح بفتح _tab_ قيد التشغيل كمسؤول ، ولكنه يسمح بفتح نافذة PowerShell كمسؤول من علامة تبويب موجودة (غير مسؤول):

https://github.com/jt-github/elevate

يعمل هذا بنفس طريقة إضافة ملف التعريف كما اقترحه CraigHead أعلاه:
"commandline": "powershell.exe -Command \"Start-Process powershell.exe -Verb RunAs\"",

فيما عدا أن إصداري يتم تنفيذه عن طريق تشغيل الأمر elevate .

@ jt-github هذا مثل sudo.

انظر هنا: https://github.com/pldmgg/Sudo

بالضبط ، فقط sudo هو طريقة أكثر برودة من بلدي ولكن لي بسيط جدًا لدرجة أنه من السهل فهمه واستخدامه.

مثل الكثيرين منكم ، لقد واجهت أيضًا هذه المشكلة ، لذلك قمت بإنشاء الوظائف التالية من أجل فتح قشرة المسؤول من أي منowershell.exe أو pwsh.exe أو محطة Microsoft

# Function        Test-IsAdmin
function Test-IsAdmin {
    <#
    .Synopsis
    Tests if the user is an administrator
    .Description
    Returns true if a user is an administrator, false if the user is not an administrator
    .Example
    Test-IsAdmin
    #>
    $identity = [Security.Principal.WindowsIdentity]::GetCurrent()
    $principal = New-Object Security.Principal.WindowsPrincipal $identity
    $principal.IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)
}


# Function        New-AdminShell
function New-AdminShell {
    <#
    .Synopsis
    Starts an Elevated PowerShell Console.

    .Description
    Opens a new PowerShell Console Elevated as Administrator. If the user is already running an elevated
    administrator shell, a message is displayed in the console session.

    .Example
    New-AdminShell

    #>

    $Process = Get-Process | Where-Object { $_.Id -eq "$($PID)" }
    if (Test-IsAdmin = $True) {
        Write-Warning -Message "Admin Shell already running!"
    }
    else {
        if ($Process.Name -eq "powershell") {
            Start-Process -FilePath "powershell.exe" -Verb runas -PassThru
        }
        if ($Process.Name -eq "pwsh") {
            Start-Process -FilePath "pwsh.exe" -Verb runas -PassThru
        }
    }
}

# Function        New-AdminTerminal
function New-AdminTerminal {
    <#
    .Synopsis
    Starts an Elevated Microsoft Terminal.

    .Description
    Opens a new Microsoft Terminal Elevated as Administrator. If the user is already running an elevated
    Microsoft Terminal, a message is displayed in the console session.

    .Example
    New-AdminShell

    #>

    if (Test-IsAdmin = $True) {
        Write-Warning -Message "Admin Shell already running!"
    }
    else {
        Start-Process "wt.exe" -ArgumentList "-p pwsh" -Verb runas -PassThru
    }
}

آمل أن يجدها أحدهم مفيدة. لقد أضفتها إلى ملفات تعريف PowerShell الخاصة بي ، لذا فهي متوفرة دائمًا.

مرحبا،
واجهت هذه المشكلة أيضًا في حسابي العادي. الحل هو تثبيت تطبيق Terminal مرة أخرى أثناء تسجيل الدخول إلى حساب المسؤول. بعد ذلك ستتمكن من التشغيل كمسؤول في حسابك العادي.

لقد نجح هذا أيضًا بالنسبة لي ، إنه أمر مزعج للغاية ولكن على شبكة الشركة هذه إلى حد كبير الطريقة الوحيدة التي نجحت معي. إذا لم يكن لديك مسؤول محلي ، فإن هذا التطبيق يمثل إلى حد كبير تمثال نصفي للأفراد المرتفعين على شبكة الشركة.

مسرور لرؤيته يجري معالجته.
يجب حل هذه المشكلة ، كما هو الحال الآن في أي بيئة Windows تم إعدادها باستخدام حسابات منفصلة للمشرف والمستخدم (كما ينبغي) ، لا يمكن استخدام الجهاز الطرفي للمسؤولين إذا تم تثبيته من متجر MS (موصى به)

كان الحل الذي نجح معي هو تسجيل الدخول كمستخدم إداري في الجهاز المحلي و "تثبيت" الجهاز مرة أخرى من المتجر. بعد ذلك ، عند تسجيل الدخول كمستخدم قياسي ، يمكنني تشغيل الجهاز كمسؤول

ناه ، هذا لم ينجح معي :(

لذلك اكتشفت ذلك.

يجب عليك تثبيته في كل من حساب المسؤول وأيضًا في الحساب الرئيسي ، ولكن يجب أيضًا تسجيل الدخول إلى الحساب الإداري حتى يعمل. أعني بهذا أنه يجب تسجيل دخول الكمبيوتر إلى المسؤول ، ثم تبديل المستخدم (وليس تسجيل الخروج) وتسجيل الدخول إلى الحساب الآخر. سيسمح هذا للتطبيق بالعمل في وضع المسؤول.

أعتقد أن تطبيقات المتجر المثبتة على كلا الحسابين لا يمكن تشغيلها كمسؤول ما لم يتم تسجيل الدخول إلى حساب المسؤول.

لذلك اكتشفت ذلك.

يجب عليك تثبيته في كل من حساب المسؤول وأيضًا في الحساب الرئيسي ، ولكن يجب أيضًا تسجيل الدخول إلى الحساب الإداري حتى يعمل. أعني بهذا أنه يجب تسجيل دخول الكمبيوتر إلى المسؤول ، ثم تبديل المستخدم (وليس تسجيل الخروج) وتسجيل الدخول إلى الحساب الآخر. سيسمح هذا للتطبيق بالعمل في وضع المسؤول.

أعتقد أن تطبيقات المتجر المثبتة على كلا الحسابين لا يمكن تشغيلها كمسؤول ما لم يتم تسجيل الدخول إلى حساب المسؤول.

هذا يعمل بالنسبة لي. 👍