Score:0

Restrict GPOs to RD Session Host without loopback processing

ธง gi

My aim would be to divide our huge "User" OU (not the default one!) into different sub-OUs from the respective department. Then, I want to link the GPOs to the different departments, but somehow "restrict" the application of them to the RD Session Host. I wanted to know if there is a way to accomplish that without having about 15 GPOs only linked to the "RD Session Host" OU and none to the department OUs. Plus, it would be nice to be able to have as little item level targeting as possible.

The reasons are: Looks nicer, faster administration, better overview.

I would want to accomplish that without third party software, i.e. :

https://www.policypak.com/resources/pp-blog/group-policy-loopback/

Could you also comment if you had run into the same issue as well?

Tell me if you know that it's not possible.

Score:0
ธง au

เนื่องจากมากกว่า 95 เปอร์เซ็นต์ของ GPO ใช้ระบบรีจิสทรี คุณอาจใช้วิธีแก้ไขปัญหาที่ใช้งานง่ายต่อไปนี้: ค้นหาคีย์รีจิสทรีที่ GPO ใช้ ปรับใช้โดยใช้รายการการตั้งค่านโยบายกลุ่ม ("GPP") (ตรงข้ามกับการใช้ GPO มาตรฐาน) ภายใน GPP คุณสามารถใช้ "การกำหนดเป้าหมายระดับสินค้า" ซึ่งเป็นชุดของตัวกรอง WMI ที่กำหนดไว้ล่วงหน้า ซึ่งช่วยให้แยกแยะตำแหน่งที่จะใช้ GPP เหล่านั้นได้

Semicolon avatar
jo flag
ซึ่งขัดแย้งกับคำขอที่คุณหลีกเลี่ยงการกำหนดเป้าหมายระดับรายการ
Bernd Schwanenmeister avatar
au flag
สวัสดีเครื่องหมายอัฒภาคโปรดลองใช้และดูว่าการเข้าถึงเป้าหมายนั้นง่ายเพียงใดโดยใช้ตัวกรองการกำหนดเป้าหมาย "เซสชันเทอร์มินัล" (อาจรวมกับ "ชื่อคอมพิวเตอร์") เมื่อเทียบกับวิธีอื่นๆ มันไม่เกี่ยวกับความขัดแย้ง
Semicolon avatar
jo flag
ฉันเพียงแค่ชี้ให้เห็นว่าผู้ถามถามคำถามด้วยวลี "คงจะดีหากสามารถกำหนดเป้าหมายระดับไอเท็มให้น้อยที่สุดเท่าที่จะเป็นไปได้" โซลูชันของคุณ - ในขณะที่ใช้งานได้ - เพิกเฉยต่อคำขอของผู้โพสต์และพึ่งพาเฉพาะสิ่งที่ OP พยายามหลีกเลี่ยง
Bernd Schwanenmeister avatar
au flag
ตกลง ฉันเข้าใจคุณผิด เพราะคุณพิมพ์ผิด "คุณหลีกเลี่ยงการกำหนดเป้าหมายระดับรายการ" แทนที่จะเป็น "เพื่อหลีกเลี่ยง ILT" ขอโทษ ฉันไม่เห็นสิ่งที่คุณชี้ให้เห็น ใช่ ถ้าผู้เขียนพยายามให้มีน้อยที่สุดเท่าที่จะเป็นไปได้ ฉันไม่แน่ใจว่าหมายความว่าอย่างไร แต่ก็ยังต้องการแสดงตัวเลือก ITL นี้เพื่อจำกัดแอปพลิเคชันไว้เฉพาะบริการเทอร์มินัลและโฮสต์เฉพาะ
Score:0
ธง jo

คุณสามารถสร้างกลุ่มความปลอดภัยที่มีคอมพิวเตอร์ทุกเครื่องใน OU ของโฮสต์เซสชัน RD จากนั้นใช้การมอบหมายหรือการกรองความปลอดภัยใน GPO ของคุณ เพื่อให้คอมพิวเตอร์โดเมนไม่มีสิทธิ์อ่าน และมีเพียงกลุ่มโฮสต์เซสชัน RD เท่านั้นที่มีสิทธิ์อ่าน และผู้ใช้โดเมน (หรือกลุ่มเป้าหมายอื่นๆ) ได้อ่านและนำไปใช้ คุณสามารถใส่ทั้งสองกลุ่มในการกรองความปลอดภัยของ GPO ซึ่งจะบรรลุสิ่งเดียวกัน (แม้ว่าจะให้สิทธิ์นำไปใช้กับคอมพิวเตอร์ - ซึ่งไม่ควรมีผลตราบใดที่ GPO ไม่ได้เชื่อมโยงกับ OU ของพวกเขา) เนื่องจาก GPO ถูกเรียกโดยบัญชีคอมพิวเตอร์ การตรวจสอบให้แน่ใจว่าเฉพาะคอมพิวเตอร์ที่ต้องการเท่านั้นที่สามารถดึงข้อมูลนโยบายได้ หมายความว่า GPO ควรใช้เฉพาะกับผู้ใช้เมื่อเข้าสู่ระบบในเครื่องเหล่านี้

ความคิดเห็น / ความคิด:

  • คุณไม่สามารถ/ไม่ควรป้องกัน Domain Controllers จากการอ่าน GPO เหล่านี้ ซึ่งจะนำไปสู่ผลที่ตามมาโดยไม่ได้ตั้งใจ ดังนั้น การใช้เทคนิคนี้ GPO จึงอาจนำไปใช้ได้หากผู้ใช้ล็อกอินเข้าสู่ Domain Controller ดังที่ได้กล่าวไปแล้ว - บัญชีผู้ดูแลระบบที่สามารถเข้าถึง DC ได้ควรอยู่ใน OU ที่แยกจากกันทั้งหมด
  • การออกแบบ GPO ตาม "รูปลักษณ์" (ในความคิดของฉัน) นำไปสู่ความยุ่งยากที่อาจเกิดขึ้นในการแก้ไขปัญหา แน่นอนเมื่อนำผู้ทำงานร่วมกันภายนอกเข้ามา จ้างใหม่ที่มีทักษะ และขอความช่วยเหลือจากชุมชน (เช่น เซิร์ฟเวอร์ขัดข้อง)
  • ฉันเชื่อว่าเหตุผลที่คุณระบุล้วนแล้วแต่เป็นอัตนัย ซึ่งก็ไม่เป็นไร ฉันไม่ต้องดูแลสภาพแวดล้อมของคุณ

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา