Users reported that some emails were not being delivered to on-premises Exchange mailboxes.

The security team initially observed messages stuck in the antispam gateway’s deferred queue with errors:

lost connection with 127.0.0.1 while sending end of data

At first glance, this looked like a possible Exchange Receive Connector or SMTP delivery issue?

First Important Observation

The 127.0.0.1 address was misleading.

Since 127.0.0.1 is the loopback address, this error did not directly prove that Exchange was rejecting the message. It suggested that the antispam gateway might have been having an internal processing or local relay issue.

SMTP Receive Protocol Logs

When i parse the SMTP Receive logs using Log Parser, I found repeated errors from the antispam relay IPs on the inbound receive connector:

451 4.7.0 Timeout waiting for client input

I also observed entries such as:

`Remote(SocketError)`

This changed the direction of the investigation.

These errors did not look like:
– recipient rejection
– message size limit
– subject/header limit
– authentication failure
– receive connector permission issue

Instead, Exchange accepted the SMTP connection but the SMTP conversation wasn’t completed cleanly.

What the Error Means

“451 4.7.0 Timeout waiting for client input” means Exchange was waiting for the remote SMTP client to continue sending data or commands, but the client did not continue in time.

“Remote(SocketError)” usually means the remote side or the network path closed/reset the socket unexpectedly.

In other words, Exchange was not actively rejecting the email. The SMTP session was being interrupted.

Root Cause

After correlating the timestamps with the network team, the firewall logs confirmed that IPS was dropping the SMTP connections between the antispam gateway and the Exchange servers.

Once the IPS behavior was corrected, the deferred messages started flowing normally again.

Errors such as:

“451 4.7.0 Timeout waiting for client input”

and:

“Remote(SocketError)”

should make you check the SMTP client and the network/security path, especially firewall, IPS, TLS inspection, and antispam relay behavior.

In this case, Exchange was only reporting the symptom. The root cause was the IPS interrupting SMTP sessions between the antispam gateway and Exchange.

Log Parser Query to parse Exchange Receive Connector

SELECT
    [connector-id],
    EXTRACT_TOKEN([remote-endpoint], 0, ':') AS SenderIP,
    event,
    data,
    context,
    COUNT(*) AS Hits
FROM
    '[LOGFILEPATH]'
WHERE
    (
        data LIKE '4__ %'
        OR data LIKE '5__ %'
        OR data LIKE '%Timeout waiting for client input%'
        OR context LIKE '%SocketError%'
        OR context LIKE '%disconnect%'
        OR context LIKE '%reset%'
        OR context LIKE '%timeout%'
    )
GROUP BY
    [connector-id],
    SenderIP,
    event,
    data,
    context
ORDER BY
    Hits DESC

SELECT
    [connector-id],
    EXTRACT_TOKEN([remote-endpoint], 0, ':') AS SenderIP,
    event,
    data,
    context,
    COUNT(*) AS Hits
FROM
    '[LOGFILEPATH]'
WHERE
    (
        data LIKE '4__ %'
        OR data LIKE '5__ %'
        OR data LIKE '%Timeout waiting for client input%'
        OR context LIKE '%SocketError%'
        OR context LIKE '%disconnect%'
        OR context LIKE '%reset%'
        OR context LIKE '%timeout%'
    )
GROUP BY
    [connector-id],
    SenderIP,
    event,
    data,
    context
ORDER BY
    Hits DESC

You can change the data context according to your needs.

The post Exchange 451 Timeout Waiting for Client Input appeared first on Bugra Keskin | IT Pro ~Microsoft 365.

Microsoft has officially signaled the next massive evolution in its licensing and technology stack: Microsoft 365 E7 is coming with General Availability (GA) set for May 1, 2026, at a listed price of $99 per user/month. (Microsoft 365 E7 91,90 €. Benutzer/Monat for Germany)

On paper, E7 reads like the ultimate premium bundle: Microsoft 365 E5 + Microsoft 365 Copilot + Microsoft Entra Suite + Agent 365, bringing together advanced security and governance capabilities across Defender, Intune, Purview, and Entra.

But as a Senior M365 Consultant, I can tell you that signing the Enterprise Agreement is the easy part. The real challenge and the real value lies in understanding that Microsoft 365 E7 is not just a bigger enterprise license, it is a test of organizational maturity.

The Real Game-Changer: Agent 365 and “AI Operations”

Copilot, E5, and the security stack are already familiar conversations in the enterprise space. What fundamentally changes the discussion with E7 is Agent 365.

Agent 365 treats AI agents both human and non-human as distinct entities that require a full operational framework. We are talking about agent inventory, lifecycle management, access control, risk signals, policy enforcement, auditing, and governance.

This crucial shift moves the organization from a “Shadow AI” free-for-all to structured “AI Operations”. This central control plane, sitting alongside Entra and Purview, means you can finally stop managing bots on a shared spreadsheet.

The Expert Caution: Buying E7 vs. Operating E7

The biggest risk with E7 is treating it purely as a pricing or bundling decision. Buying E7 will be significantly easier than operating it properly.

For organizations that are already serious about E5, Copilot, identity governance, data protection and SOC operations, E7 provides the unified orchestration they’ve been waiting for.

However, for organizations still struggling with information protection basics, unmanaged sharing, weak data ownership or unclear Copilot governance, E7 will not magically fix anything. It will simply make existing governance gaps more visible and even potentially more risky.

We have seen this pattern before with Copilot readiness. The licenses arrive first and the harder questions come later.. permissions, data exposure, retention, audit, insider risk and ownership.

The Pre-E7 Action Checklist: Ask These Questions Now

Before upgrading to E7, your organization needs to answer a few fundamental, non-technical questions:

• Who is allowed to create and publish agents?
• Who owns the full lifecycle of those agents?
• How does Entra ownership map to agent access?
• Are your Purview labels and DLP policies ready to protect the data those agents will reach?
• Will Defender XDR provide sufficient visibility during an AI-related investigation?
• Who disables or reviews an agent when something goes wrong?

The Bottom Line

Microsoft 365 E7 is the most significant step yet toward a unified “Security-led AI Platform”. It forces the critical convergence of identity, data, endpoint, SOC and AI governance into one operational flow.

The real question isn’t whether your organization needs E7. The question is whether your organization is ready to operate it.

The post Microsoft 365 E7 Announced: Moving from AI Productivity to AI Operations (Expert Analysis) appeared first on Bugra Keskin | IT Pro ~Microsoft 365.

That is why I still keep Log Parser Studio around. (old habits)

It remains one of the fastest ways to parse raw IIS and Exchange protocol logs and turn them into readable output. For this kind of log work, it is often more practical than building the same view through PowerShell from scratch. When I need to extract some raw data to group and filter SMTP, authentication, relay or any IIS-related logs quickly, it still does the job well. For admins who still have to manage on-prem Exchange, that is reason enough to keep it around.

Log Parser Studio works with a SQL-like query model, which is one reason it is still convenient for log analysis. You can filter, group, count, extract tokens and reshape raw IIS or Exchange protocol logs into something much more readable. At the same time, it is not the kind of tool where any query that looks like SQL will just work. The syntax is more sensitive, field handling needs to be precise

Here are five patterns I still find useful in day-to-day Exchange troubleshooting.

Find Non-TLS connections on the Receiver connector

Before changing certificates or tightening TLS settings in Exchange, one of the first things worth checking is whether some systems are still connecting without TLS.

That matters because the breakage usually does not come from Exchange first. It comes from old applications, devices or internal services that were quietly sending mail in a way nobody noticed until the transport layer changed.

This query is useful because it helps identify SMTP sessions where an EHLO was seen but no successful TLS negotiation event was logged for the same session.

SELECT connector-id, SenderHost, SenderEHLOName, COUNT(*) as Hits
USING
  EXTRACT_TOKEN(data,1,'EHLO') AS SenderEHLOName,
  REVERSEDNS(EXTRACT_TOKEN(remote-endpoint,0,':')) AS SenderHost
FROM
  '[LOGPATH]\FrontEnd\ProtocolLog\SmtpReceive\*.log',
  '[LOGPATH]\Hub\ProtocolLog\SmtpReceive\*.log'
WHERE
  (data LIKE 'EHLO %')
  AND session-id NOT IN (
    SELECT session-id
    FROM
      '[LOGPATH]\FrontEnd\ProtocolLog\SmtpReceive\*.log',
      '[LOGPATH]\Hub\ProtocolLog\SmtpReceive\*.log'
    WHERE context LIKE '%TLS protocol%'
    GROUP BY session-id
  )
GROUP BY
  connector-id,
  SenderHost,
  SenderEHLOName
ORDER BY Hits DESC

SELECT connector-id, SenderHost, SenderEHLOName, COUNT(*) as Hits
USING
  EXTRACT_TOKEN(data,1,'EHLO') AS SenderEHLOName,
  REVERSEDNS(EXTRACT_TOKEN(remote-endpoint,0,':')) AS SenderHost
FROM
  '[LOGPATH]\FrontEnd\ProtocolLog\SmtpReceive\*.log',
  '[LOGPATH]\Hub\ProtocolLog\SmtpReceive\*.log'
WHERE
  (data LIKE 'EHLO %')
  AND session-id NOT IN (
    SELECT session-id
    FROM
      '[LOGPATH]\FrontEnd\ProtocolLog\SmtpReceive\*.log',
      '[LOGPATH]\Hub\ProtocolLog\SmtpReceive\*.log'
    WHERE context LIKE '%TLS protocol%'
    GROUP BY session-id
  )
GROUP BY
  connector-id,
  SenderHost,
  SenderEHLOName
ORDER BY Hits DESC

What the query is doing

In this example, the output quickly highlights which connectors were receiving repeated non-TLS SMTP sessions and which senders were responsible. That is usually enough to narrow the scope before digging deeper into specific applications or devices.

• it looks for sessions where the client sent EHLO
• it extracts the sending host and EHLO name
• then it excludes any session that later logged a TLS negotiation event

What remains is a list of SMTP sessions that appear to have stayed non-TLS.

How to read the output

• connector-id shows which receive connector accepted the session
• SenderHost shows the sending system, based on the remote endpoint
• SenderEHLOName shows what the client identified itself as during SMTP negotiation
• Hits shows how often that pattern appeared

That is usually enough to spot legacy applications, relay devices, scanners or internal services that may need attention before a certificate or TLS-related change.

Identify Which TLS Versions Your SMTP Clients Are Still Using

Once I know TLS is being used, the next question is usually straightforward: which TLS version is actually being negotiated?

That matters during Exchange upgrades, certificate renewals or any TLS hardening work. It is one thing to know that clients are using TLS. It is a different question entirely to know whether they are still negotiating something you no longer want in the environment.

This query pulls that view directly from the Exchange receive protocol logs.

SELECT SenderHost, TLSVersion
USING
  EXTRACT_TOKEN(context, 2, ' ') AS TLSVersion,
  REVERSEDNS(EXTRACT_TOKEN(remote-endpoint, 0, ':')) AS SenderHost
FROM
  '[LOGPATH]\FrontEnd\ProtocolLog\SmtpReceive\*.log',
  '[LOGPATH]\Hub\ProtocolLog\SmtpReceive\*.log'
WHERE context LIKE '%TLS protocol%'
GROUP BY
  SenderHost,
  TLSVersion

SELECT SenderHost, TLSVersion
USING
  EXTRACT_TOKEN(context, 2, ' ') AS TLSVersion,
  REVERSEDNS(EXTRACT_TOKEN(remote-endpoint, 0, ':')) AS SenderHost
FROM
  '[LOGPATH]\FrontEnd\ProtocolLog\SmtpReceive\*.log',
  '[LOGPATH]\Hub\ProtocolLog\SmtpReceive\*.log'
WHERE context LIKE '%TLS protocol%'
GROUP BY
  SenderHost,
  TLSVersion

What the query is doing

This query looks for log entries where Exchange recorded a TLS negotiation event.

From that line, it extracts:

• the sending host
• the TLS version reported in the context field

It then groups the result so you can quickly see which systems are still negotiating which protocol versions.

How to read the output

The output is simple:

• SenderHost tells you which client or server initiated the connection
• TLSVersion tells you which TLS version was negotiated in that session

That is usually enough to answer practical questions like:

• are any senders still using TLS 1.0 or TLS 1.1?
• which systems will become a problem if older TLS versions are disabled?
• are legacy applications still present even if nobody remembers them?

Why this is useful

This is one of the quickest ways to get real visibility before making a transport-side change.

It is much better than assuming everything is already modern because the environment “should” be modern. SMTP dependencies are often older than expected, and protocol logs usually expose that faster than documentation or application inventories do.

If I am planning TLS hardening, this is the kind of query I run first.

Troubleshooting SMTP Authentication Failures from Application Senders

When an application suddenly stops sending mail, the first explanation is usually vague.

“Nothing changed.”
“The credentials should still be correct.”
“Exchange is rejecting it.”

At that point, I want a faster view of what Exchange is actually seeing on the receive side.

This query filters the log for common SMTP authentication-related failures such as 5.7.1 and 5.7.3 then groups the results so repeated failures stand out immediately.

SELECT 
  connector-id,
  REVERSEDNS(SenderHost) AS ServerName,
  SenderHost AS ServerIP, 
  data AS AuthUserName, 
  COUNT(*) AS HitCount,
  context AS StatusCode
USING
  EXTRACT_TOKEN(remote-endpoint, 0, ':') AS SenderHost
FROM '[LOGFILEPATH]'
WHERE 
  context LIKE '%5.7.1%' OR
  context LIKE '%5.7.3%'
GROUP BY 
  connector-id,
  ServerName,
  ServerIP,
  AuthUserName,
  StatusCode
ORDER BY HitCount DESC

SELECT 
  connector-id,
  REVERSEDNS(SenderHost) AS ServerName,
  SenderHost AS ServerIP, 
  data AS AuthUserName, 
  COUNT(*) AS HitCount,
  context AS StatusCode
USING
  EXTRACT_TOKEN(remote-endpoint, 0, ':') AS SenderHost
FROM '[LOGFILEPATH]'
WHERE 
  context LIKE '%5.7.1%' OR
  context LIKE '%5.7.3%'
GROUP BY 
  connector-id,
  ServerName,
  ServerIP,
  AuthUserName,
  StatusCode
ORDER BY HitCount DESC

To be continued

The post Troubleshoot Exchange Logs Using Log Parser Studio appeared first on Bugra Keskin | IT Pro ~Microsoft 365.

Birçok kuruluş Exchange Online, Azure AD gibi Cloud servislerini benimsemeye başladı, Cloud servislerinin kullanımları arttıkça güvenlik prosedürleride gelişmekte.

Şirket içi Exchange depolama ve yedeklilik konusunda endişelenmemek, firmaların sıçrama yapması için genellikle yeterli bir nedendir. Ancak buluttaki değişiklik, herhangi bir tümleşik uygulamanın artık doğrudan şirket içi Exchange ortamına değil, internet üzerinden Exchange Online ortamına bağlanması gerektiğinden, güvenlik endişelerini de beraberinde getirmektedir.

Bu, diğer şirket içi uygulamaların ve betiklerin bile bir kullanıcının posta kutusuna bağlanmak için buluta ulaşması gerektiği anlamına gelir. Microsoft, yıllarca Exchange Online’da Temel Kimlik Doğrulaması’na izin verdi, yani gereken tek şey bir kullanıcı adı ve parolaydı. Ancak, güvenliği artırmanın bir yolu olarak Microsoft, Exchange Online’a Temel Kimlik Doğrulaması ile bağlanma yeteneğini sona erdirme ve bunun yerine OAuth 2.0 (Modern Kimlik Doğrulaması olarak da bilinir) gerektirmeye başlama planlarını duyurdu. OAuth, diğer sistem bilgilerine erişim izni verebilen ancak onlara şifre vermeden birçok uygulama ve web sitesi için kullanılan açık bir standarttır.

1Eylül 2022’den itibaren Microsoft sonunda Basic Authenticationu kaldırmaya başladı ve tüm tenant yöneticilerinden kullanıcıları için Modern Authentication’u açmaya davet etti.

The post MFA Neleri Değiştirir? appeared first on Bugra Keskin | IT Pro ~Microsoft 365.

It’s a fair question and a common one. But the answer requires understanding what Microsoft 365 actually supports today, not what we wish existed.

This article explains what Microsoft 365 can (and cannot) do, and which approaches are actually sustainable.

The Short Version

• Microsoft 365 does not provide a native “tenant-to-tenant GAL merge.” There is no built-in feature that merges or exposes one tenant’s Global Address List to another tenant.
• But there are supported ways to achieve what people usually mean by “address book sharing”: cross-tenant discoverability (users can search and find each other in Outlook/Teams).

The key is to stop thinking “share my GAL” and instead think:

“How do we make users discoverable across tenants in a controlled and maintainable way?”

What People Expect vs. What Actually Exists

When users say “address book,” they often mean:

• Outlook/Teams search can find the other tenant’s users
• People cards show correct info (name, title, phone, etc.)
• Address entries stay up to date automatically
• It works both directions

That’s not “GAL sharing” in the classic on-prem sense. In Microsoft 365, this requires directory presence + governed trust + automation.

What Doesn’t Work (As People Expect)

1) “Just invite everyone as B2B guests”

Inviting users as B2B guests is useful for access and collaboration, but it does not automatically create a clean, user-friendly address book experience.

• By default, guests may not appear the way internal employees do in Outlook/Teams directory experiences.
• You can make guests visible, but it often comes with caveats (attributes, consistency, user experience, governance).

Practical takeaway: B2B guests help with access, but they are not a “GAL sharing feature.”

Teams/Outlook search where the other tenant user is not discoverable (or appears inconsistently).

2) Cross-Tenant Access Settings

Cross-tenant access settings are important, but they control authentication and trust (who can sign in, which apps are allowed).

They do not create directory visibility by themselves.

3) “We’ll just add contacts manually”

Manual contacts work until:

• someone changes their name/title/phone
• someone leaves the company
• you need two-way updates
• you hit a few hundred users

It becomes static, fragile, and operationally painful.

Practical takeaway: manual contacts are acceptable only for very small environments and short-term use.

What Actually Works (Supported Options)

Option 1: Cross-Tenant Synchronization (Microsoft’s intended approach)

Cross-tenant synchronization provisions users from Tenant A into Tenant B as local directory objects (B2B collaboration users). With the right configuration, these can be provisioned as Member type in the target tenant, enabling better discoverability.

This is not “GAL sharing.” It is directory replication, and that distinction matters.

What you get:

• users become searchable/discoverable (Outlook/Teams people search)
• automation keeps them up to date
• controlled scoping (sync only specific groups)

Why this is important:
Most organizations don’t truly need “GAL merge.” They need reliable discoverability without manual maintenance.

Screenshot suggestions:

• Entra cross-tenant synchronization configuration (scope/group or user-based).
  
• Example of the synced user object in the target tenant (UserType = Member if applicable).

Notes for architects:

• Scoping is critical. Sync only the users that must be discoverable.
• Attribute hygiene matters (displayName, mail, jobTitle, department, phone).
• This is governance-heavy if the tenants are owned by different companies—get explicit agreement.

Option 1.1: Multi-Tenant Organization (MTO): helpful, but not magic

MTO does not merge tenants. It does not “share a GAL.”

What it does provide is a Microsoft-supported framework for:

• governed multi-tenant relationship
• structured cross-tenant collaboration
• supported people-search style experiences (when combined with sync + correct configuration)

Think of MTO like this:

• Cross-tenant sync does the work (provisions identities).
• MTO provides structure and governance around a multi-tenant environment.

Practical takeaway:
MTO can make long-term collaboration cleaner but it’s not a “single tenant button.”

Screenshot suggestion:

• MTO overview / configuration page (high-level)

Option 2: Third-Party GAL Sync Tools

Tools like:

• Quest
• CiraSync
• SyncPenguin

These typically sync users as mail contacts or directory objects, often with a UI and scheduling built in.

Pros:

• fast to deploy
• often supports two-way sync easily
• good for hybrid/complex scenarios

Cons:

• licensing cost
• operational overhead
• another system to manage and troubleshoot

Practical takeaway:
Third-party tools can be a valid choice when Microsoft-native governance is too heavy or timelines are tight.

Option 3: Manual imports (CSV contacts)

This is the “quick and dirty” approach:

• okay for very small environments
• not maintainable at scale
• always falls behind reality

Choosing the Right Approach

Use this as a decision guide:

• Need long-term discoverability + automation + governance: Cross-tenant sync
• Need structured multi-tenant collaboration at scale: MTO + cross-tenant sync
• Need fast deployment / two-way contact sync without heavy design: 3rd-party tools
• Tiny environment / temporary need: manual contacts

Suggested table to include (simple):

How I Approached the Case

In my case, two independent tenants wanted mutual address book visibility without mail-flow changes or major restructuring.

I focused on three questions:

1. What does Microsoft officially support?
2. What is technically possible without creating a support nightmare?
3. What will still work six months from now without manual maintenance?

Conclusion:

• There is no “share my GAL” button.
• Cross-tenant sync is the only Microsoft-native method that can provide reliable, up-to-date discoverability across tenants.
• MTO is optional, but valuable if the tenants plan to collaborate long-term and are willing to govern the relationship.

Final Thoughts

Cross-tenant address book visibility is a perfect example of a request that sounds simple but crosses architectural boundaries.

If you’re evaluating this scenario:

• stop asking for “GAL sharing”
• define the real outcome: discoverability + automation + governance
• choose the approach that matches ownership, security posture, and operational reality

Two tenants can collaborate well—but they will never become “one tenant” without trade-offs and governance decisions.

The post Cross‑Tenant Address Book Sharing in Microsoft 365: What’s Actually Possible appeared first on Bugra Keskin | IT Pro ~Microsoft 365.

In this case, the network team reported unusually high utilization on MPLS and leased lines. Their traffic review showed that a significant portion of the WAN usage was caused by Windows Update content being shared between client devices, including across different sites.

And even with the leased lines, meaning the same happens with other sites :

(Network report showing high MPLS and leased-line utilization linked to Windows Update peer-to-peer traffic.)

That was the real problem. Devices were not only downloading updates. They were also exchanging update content with each other over inter-site links, which created unnecessary WAN traffic which is normal behavior. But not for multi-site environments.

What i checked

Once the network team shared the utilization data, the pattern pointed to Delivery Optimization peer-to-peer behavior.

The issue was not Windows Update itself.
The issue was that update content was being distributed in a way that didn’t fit the network design.

In a multi-site environment, that matters. If clients start using each other as update sources across MPLS or leased lines, bandwidth consumption can grow quickly.

What i changed

To reduce that behavior, I create a new profile (Windows 10 and later –> Profile type: Settings catalog and configuration the Delivery Optimization settings in Intune.

The policy was configured as follows:

• VPN peer caching: Not allowed
  This was intended to stop update content from being shared over VPN-connected paths where bandwidth was already limited.
• Download mode: HTTP only, no peering
  The main goal was to stop devices from using each other as update sources and force a more predictable client-to-service download model.
• Business hours background bandwidth limit: Enabled, limited to 20%
  During working hours, the priority was to reduce the impact of background update traffic on user and business traffic.
• Outside business hours: Relaxed to 80%
  After business hours, the restriction was loosened so updates could still progress without competing heavily with daytime traffic.

The goal was simple: stop unnecessary peer-to-peer update sharing and make update delivery more predictable across sites.

What happened after the change

After the policy was deployed, the network team monitored the WAN traffic again.

Within a few days, they confirmed that update traffic between the main laptop groups had decreased drastically. That was the first sign that the policy change was working as expected.

(Network monitoring results showing a strong decrease in inter-site Windows Update traffic after Delivery Optimization changes.)

At the same time, they still observed some update-related traffic involving remote sites over MPLS. That showed an important operational reality: Intune policy can reduce the problem significantly, but in some environments the final control decision may also involve the network layer.

Delivery Optimization is useful, but it should not be left unreviewed in a multi-site environment.

If Windows Update peer-to-peer traffic is allowed to cross inter-site links, it can easily consume WAN bandwidth in ways the network team does not want.

In this case, adjusting Delivery Optimization through Intune reduced the problem quickly and measurably.

The post Reducing Inter-Site Windows Update Traffic with Intune Delivery Optimization appeared first on Bugra Keskin | IT Pro ~Microsoft 365.

In my case, the issue appeared right after a certificate replacement. Outbound queues started growing, and mail flow to Exchange Online began to degrade. At first glance, the obvious assumption was that the new certificate had already been imported successfully, so the problem had to be somewhere else.

It was not.

The real issue was on the hybrid transport side. The new certificate was present but the TlsCertificateName used by the hybrid send connector was not correctly aligned with the new certificate identity.

That distinction matters. In Exchange hybrid, importing and enabling a certificate doesn’t automatically mean the connector is presenting the correct TLS identity.

454. 4.7.5 The certificate specified in TlsCertificateName of the SendConnector could not be found.

What I checked

First, I verified the certificate details on the Exchange servers:

Get-ExchangeCertificate -Server EXCHSERVER01 |
Format-List Thumbprint,Subject,Issuer,Services,HasPrivateKey,NotAfter

Get-ExchangeCertificate -Server EXCHSERVER01 |
Format-List Thumbprint,Subject,Issuer,Services,HasPrivateKey,NotAfter

This confirmed that the new certificate was present and usable.

Then I generated the expected TLS string from the new certificate and compared it with the value configured on the hybrid send connector:

$cert = Get-ExchangeCertificate -Server EXCHSERVER01 -Thumbprint <NEWTHUMBPRINT>
$tls  = "<I>$($cert.Issuer)<S>$($cert.Subject)"
$tls

(Get-SendConnector "Outbound to Office 365_(XXX)").TlsCertificateName

$cert = Get-ExchangeCertificate -Server EXCHSERVER01 -Thumbprint <NEWTHUMBPRINT>
$tls  = "<I>$($cert.Issuer)<S>$($cert.Subject)"
$tls

(Get-SendConnector "Outbound to Office 365_(XXX)").TlsCertificateName

That comparison exposed the mismatch.

The fix

Once the correct TLS string was confirmed, I updated the send connector manually:

Set-SendConnector "Outbound to Office 365_(XXX)" -TlsCertificateName $tls

Set-SendConnector "Outbound to Office 365_(XXX)" -TlsCertificateName $tls

To keep the hybrid transport path consistent, I also aligned the relevant receive connectors with the same TLS string:

Set-ReceiveConnector "EXCHSERVER01\Default Frontend EXCHSERVER01" -TlsCertificateName $tls

Set-ReceiveConnector "EXCHSERVER01\Default Frontend EXCHSERVER01" -TlsCertificateName $tls

And if the new certificate had not yet been assigned to SMTP, that needed to be corrected first:

Enable-ExchangeCertificate -Thumbprint <NEWTHUMBPRINT> -Services SMTP

Enable-ExchangeCertificate -Thumbprint <NEWTHUMBPRINT> -Services SMTP

After that, the queues cleared and hybrid mail flow returned to normal.

The actual lesson

The certificate replacement itself was not the real fix.

The real fix was making sure the hybrid connector was using the correct TLS identity for the new certificate.

That is the part that is easy to miss. In Exchange hybrid, a successful certificate import is only the beginning. If the connector still points to the wrong TLS certificate name, mail flow can break even though the new certificate looks fine in the certificate store.

The post Mailflow issue Exchange Onprem – Exchange Online Hybrid appeared first on Bugra Keskin | IT Pro ~Microsoft 365.

Ortamınızdaki Sanal Makine disk sürücülerinin şifreleri , Parolalar , Encryption Keys yani Şifreleme Anahtarları ve Sertifikalar gibi hassas bilgilerin tek bir merkezde depolanmasını sağlayan Azure servisidir. Bu servis Azure ortamınızda Access control yani erişim kontrolü veya loglama işlemleri sağlayarak organizasyonunuza ait hassas verilerinize güvenli erişim sağlamaktadır.

Organizasyonunuzun Azure ortamında Azure Key Vault servisini ne amaçla kullanırsınız ?

• Secure Sockets Layer ( SSL ) , Transport Layer Security ( TLS ) sertifikalarını yönetebilir ve deployment işlemlerini sağlamanıza olanak tanır.
• Organizasyon ortamınızda kullandığınız Sertifikalar , API Anahtarları ve diğer hassas bilgilerinizi güvenli şekilde depolama sağlayabilirsiniz.
• Hardware Security Modules yani Donanımsal Güvenlik Modülleri tarafından desteklenen bilgileri saklayabilirsiniz.

Hardware Security Modules kavramını kısaca açıklamak gerekirse ; Organizasyonunuz için Hassas Kriptografik keyleri yani anahtarları fiziksel ortamda saklamak ve kriptografik işlemleri en güvenli şekilde gerçekleştirmek için üretilmiş özel güvenlik donanımı olarka tanımlayabiliriz. Bu modüller Takılabilir Kart veya bir Fiziksel Bilgisayara yada Network Sunucusuna takılabilen external bir aygıt şeklinde de olabilmektedir.

Organizasyonunuzun Azure ortamında Azure Key Vault servisini kullanmanız size ne fayda sağlamaktadır ?

1. Application secret yani Uygulama Sırlarınızı Depolama , Dağıtımlarınızı control işlemlerinizi Merkezileştirmenize imkan sağlamaktadır. Şehven sızdırılma olasılığını azaltmaktadır. Application Secret izleyebilir ve kontrol edebilirsiniz.
2. Organizasyonunuz için hassas verilerinizi saklamanın yanında bu verilerinize ulaşmak istediğiniz zaman Kimlik Doğrulama ve Yetkilendirme gereksinimi oluşmaktadır. Bu gereksinim verilerinizin daha da çok güvenliğinize katman sağlamaktadır.
3. Azure Key Vault Servisini diğer Azure Servisleri ile entegre edebilirsiniz. Bu servisleri açıklamak gerekirse ; Storage Account yani Depolama Hesabı , Container yani Kapsayıcı , Event Hubs ve daha yer veremediğimiz bir çok Azure Hizmetini entegre edebiliriz.

Azure Portalında Key Vault oluşturmak için , Azure Portalındaki arama çubuğuna ” Key Vault “ yazarız ardından “ Key vaults “ servisini seçeriz.

Azure ortamımızda herhangi bir Key Vault oluşturulmamış görünmektedir. Oluşturmak için ” Create “ seçeneğini seçerek ilerleriz yada 2. Bölgede ” Create key vault “ seçeneğini seçerek ilerleyebiliriz.

” Basic “ adımında ilk olarak Key Vault servisini kurulum yapacağımız ” Subscription “ ve ” Resource Group “ seçimini gerçekleştiririz.

” Instance details “ alanında; Oluşturucağımız ” Key vault name “ ismi yine Azure ortamınızda benzersiz olmalıdır (Azure yapınıza göre isimlendirme sağlayabilirsiniz) ” Region “ alanında Key Vault hizmetinin hangi bölgede çalışacağını seçeriz. Azure ortamınıza uygun Region  seçebilirsiniz.

#Picture893

” Pricing tier “ alanında ise Fiyatlandırma katmanı olarak  ” Standart “ ve ” Premium “ çeşitleri bulunmaktadır. Bunlar donanım korumalı yönetim anahtarlarıdır. Yani bir anlamda donanımın kendisi güvendedir. Yalnızca Azure’un sunduğu bir yazılım değildir. Bu alanı ” Standart ” seçili halde bırakırız. ( Kendi azure ortamınıza göre değişim sağlayabilirsiniz. )

” Recovery options “ bölümünde ;

” Soft-delete “ seçeneğinde ise ” Enabled “ durumda ise ; Azure ortamındaki CLI , Powershell gibi araçlar kullanarak kısa bir zaman dilimi olarak geçici silme ile ortamınızda yeni bir key vault oluşturabilirsiniz. ” Disabled “ durumda ise ; Key vault oluşturma özelliği , Yıl sonuna kadar tamamen kullanımdan kaldırılıyor olacaktır.

” Days to retain deleted vaults “ alanında ise oluşturacağınız vault için ” 7 İla 90 gün “ arasında seçim sağlayabilirsiniz. Bunu bir kez konfigüre ettikten sonra  tekrardan yapılandırma işlemi üzgünüm ki gerçekleştiremezsiniz.

” Purge protection “ bölümünde ise ; Key Vault Temizleme koruması olarak anılmaktadır. Bunu etkinleştirdiğinizde geri alınamaz hale gelmektedir. “ Enable “ seçeneği seçilme işlemi gerçekleştirildiğinde değiştirilme veya kaldırılma işlemi sağlanamamaktadır.

Buradaki konfigürasyonları Varsayılan halde bırakarak ilerleriz. Ardından bir sonraki adıma geçmek için ” Next : Access Policy > ” seçeneğini seçerek ilerleriz.

Bir sonraki konfigürasyon adımında ise Key Vault hizmetine kimlerin erişeceğini ve nasıl politika izleneceğini konfigüre ederiz. Bu ekranda Key Vault için Erişim Politikaları atayabilirsiniz.

” Enable Access to : “ bölümünde bulunan :

” Azure Virtual Machines for deployment ” seçeneği : Azure ortamında bulunan Sanal Makinelerin Key Vault servisinden Gizli diziler olarak depolanan sertifikaları almasına izin verilip verilmediğini belirtmektedir.

” Azure Resource Manager for template deployment “ seçeneği: Azure Resource Manager’ın Key Vault servisinden gizli dizileri almasına izin verilip verilmediğini belirmektedir.

” Azure Disk Encryption for volume encryption “ seçeneği ise ; Azure Disk Encryption’un Key Vault servisinden gizli dizileri ve anahtarları açmasına izin verilip verilmediğini belirtir.

” Permission Model “ bölümünde iki seçenek karşımıza çıkmaktadır : ” Vault access policy “ ve ” Azure Role-Based Access Control “ seçenekleri karşımıza çıkmaktadır. Varsayılan olarak seçili ” Vault access policy “ seçeneğini seçerek devam ederiz.

“ Vault Access Policy “ seçeneği Güvenlik sorumlusunun veya Application veya User Group Key Vault secret key ve sertifikaları üzerinde işlemler gerçekleştirilip , gerçekleştirilmeyeceğini belirlemektedir.

“ Azure Role-based Access Control “ seçeneği ile Tüm önemli kasalar genelinde tüm izinleri yönetmek için tek bir alan sağlamaktadır. Key Vault için Azure RBAC ayrıca tek tek anahtarlar, secret ve sertifikalar üzerinde ayrı izinlere sahip olmak için olanaklar sağlamaktadır.

” Current Access Policy “ bölümünde ise bu Key Vault erişimi sağlayacak kullanıcıları ekleyebilir ve görebilirsiniz.

Ardından bir sonraki adıma geçmek için ” Next : Networking “ seçeneğini seçeriz.

” Network Connectivity “ bölümünde ise ; oluşturacağımız Key Vault hizmetine Genel olarak Public IP Adresleri veya Service Endpoint’leri aracılığıyla veya Private Endpoint kullanarak özel olarak bağlanabilme imkanına sahip olabilirsiniz.

Bir Sonraki aşama ” Next : Tags > “ adımında ise Key vault hizmetini daha kolay bulabilmeniz için tasarlanmıştır. Tag’leme işlemi gerçekleştirmek istemiyorsanız , ” Review + create “ seçeneğini seçerek devam ederiz.

” Validation passed “ uyarısı aldığınızda Key vault oluşturmanıza sakıncamızın kalmadığının bilgisini vermek isterim. ” Create “ seçeneğini seçerek Deployment işlemlerini başlatırız.

Key vault servisi oluşturulma işlemi başlamıştır.

Deployment süreci tamamlanmıştır. Oluşturmuş olduğumuz ” Key vault “ hizmetine gitmek için ” Go to resource “ seçeneğini seçeriz.

Oluşturmuş olduğumuz Key vault hizmetinin içeriğine girerek ” Settings “ bölümünden ” Secrets “ seçeneğini seçeriz. Key Vault ortamımızda yeni bir Secret üretmek için ” Generate / Import “ seçeneğini seçeriz.

İlgili konfigürasyon ekranına geldiğimizde ;

” Upload Options “ bölümünde iki seçenek karşımıza çıkmaktadır. ” Manual “ veya ” Certificates “ seçenekleri mevcuttur. Elinizde bir sertifika mevcut değilse , ” Manual “ seçeneğini seçebilirsiniz. Sertifika bazı durumlar Güvenli sertifika gerektirdiğinden böyle bir seçenek mevcuttur.

” Name “ seçeneğinde üreteceğimiz secret’e bir isimlendirme sağlamanız gerekmektedir.

” Value “ seçeneğinde beğendiğimiz bir sayıyı verebiliriz. Şifreli halde gözüküyor olacaktır. ” 37 “ yazdım.

” Content type “ seçeneğinde ise secret içeriğindeki içeriğin türünü belirtebilirsiniz. Opsiyonel olarak isteğinize bağlıdır.

” Set activation date “ seçeneğinde Bu kaynağın ne zaman aktif hale gelebileceğini görüntüleyebilirsiniz.

” Set expiration date “ seçeneğinde bu kaynağın ne zaman süresinin dolacağını görüntüleyebilirsiniz.

Ardından işlemlemlerimiz tamamlandıysa ; ” Create “ seçeneğini seçerek Secret oluşturma işlemi sağlayabilirsiniz. 

Oluşturmak istediğimiz ” MOSecret “ adındaki secret öğemiz oluşturulmaktadır.

Oluşturma işlemi tamamlanmıştır. Artık bu Secret öğemizi istediğimiz kişiler ile paylaşabiliriz. Bu Secret erişebilmek için Key Vault oluşturma esnasında seçmiş olduğumuz politikaları kullanabilirsiniz. Bu bir şifre olabilir, Bir Veritabanı dizisi olabilir daha da fazlası Bunların dışında herşey olabilir.

Bu şekilde Key vault oluşturarak kritik bilgilerimizi , Sertifikalarımızı ve Secret’lerimizi depolayabilir , Yönetebilir ve Azure ortamında dağıtabilirsiniz. Ortamınızda bununla alakalı erişime ihtiyaç kalmadığında kaldırmak istediğiniz kullanıcının politikalarını kaldırabilirsiniz. Azure Key Vault , Gizli şeylerinizi tutmak için güzel bir yoldur.

The post Microsoft Azure Key Vault appeared first on Bugra Keskin | IT Pro ~Microsoft 365.

Ayrıca Exchange Servers 0-Day Patch geçilmesi  ile ilgili Microsoft’un paylaştığı linkler, kurulması gereken patch hakkında bilgi yer almaktadır.

Microsoft’un önerdiği CU versiyonunun 18 ya da 19 olması ve yayınlanan patch’in Exchange server’lara yüklenmesi. 

Cumulative Update Yükleme Adımları;

1-Schema’nın extend edilmesi;

Schema’nın extend edilmesi için ilgili admin hesabının aşağıdaki gruplara üye olması gerekmektedir.

• Domain Admin
• Enterprise Admin
• Schema Admin
• Organization Management

CU 19 ISO İndirme LinkiEmbed URLPaste a link to the content you want to display on your site.EmbedLearn more about embeds(opens in a new tab)Sorry, this content could not be embedded.Try again Convert to link

CU19 ISO’sunun mount edilmesi ve daha sonra ISO’nun mount edildiği dizine PowerShell üzerinden gidilerek aşağıdaki komutun çalıştırılması gerekmektedir;

.\Setup.exe /IAcceptExchangeServerLicenseTerms /PrepareSchema

2-Yedekleme ürünü servislerinin durdurulması;

CU yüklemeden önce organizasyonda kullanılan yedekleme ürünlerinin servislerinin durdurulması gerekmektedir.

PowerShell ile stop-service ……….  komutu ile servisler durdurulabilir.

3-Exchange Server’ın maintenance mod’a alınması;

Exchange Server’ın maintenance mode’a alınması gerekmektedir.

START MAINTENANCE
$servername = $env:computername
$servers = Get-exchangeserver |? {($_.Name -ne $servername) -and ($_.Ise15orlater -eq $True)} | select fqdn
$target = Get-random $servers
Write-Host “Maintenance mode server is $($servername)”
Write-Host “Transport redirect target server is $($target.fqdn)”

Write-Host “Draining Transport and UM services”
Set-ServerComponentState $servername -Component HubTransport -State Draining -Requester Maintenance
Set-ServerComponentState $servername -Component UMCallRouter -State Draining -Requester Maintenance

Write-Host “Start Sleep for 30 seconds”
Start-Sleep -Seconds 30
Get-Queue

Write-Host “Starting Maintenance Mode”
Write-Host “Moving Active Databases”
Move-ActiveMailboxDatabase -server $servername -MountDialOverride Lossless
Suspend-Clusternode $servername

cd $ExScripts
.\StartDagServerMaintenance.ps1 -serverName $servername -MoveComment Maintenance -OverrideMinimumTwoCopies

Write-Host “Redirecting messages to $($target.fqdn)”
Redirect-Message -Server $servername -Target $target.fqdn -confirm:$false

Write-Host “Set server to ServerWideOffline”
Set-ServerComponentState $servername -Component ServerWideOffline -State Inactive -Requester Maintenance

##CHECK THAT SERVER IS IN MAINTENANCE
Write-Host “##########” -ForegroundColor Yellow
Write-Host “Service Components should be inactive” -ForegroundColor Yellow
Get-ServerComponentState $servername | FT Component,State -Autosize
Write-Host “Server should be blocked” -ForegroundColor Yellow
Get-MailboxServer $servername | FL DatabaseCopyAutoActivationPolicy
Write-Host “Clusternode state should be paused” -ForegroundColor Yellow
Get-ClusterNode $servername | FL
Write-Host “Non-Shadow Queues should be empty” -ForegroundColor Yellow
Get-Queue -server $servername

Maintenance mod’a aldıktan sonra, kontrol etmek için kullanılması gereken komut;

Get-ServerComponentState “SERVERNAME” | Select Component, State

4-CU19 Setup’ın başlatılması;

Mount edilmiş olan CU19 ISO dosyası içerisinden Setup admin modda çalıştırılmalıdır.

Exchange Server 2016 CU 19 yüklemesi esnasında  ” A reboot from a previous installation is pending. Please restart the system and then rerun Setup. ” hatası verir ve reboot sonrası bu durum hala aynı ise çözüm için;

regedit / HKLM\System\ControlSet001\Control\Session Manager\PendingFileRenameOperations

Bu alanı açarak içeriğinin temizlenmesi reboot sorununu çözümleyecektir.

5-Exchange Servers 0-Day Patch ilgili patch dosyasının yüklenmesi;

5 farklı zafiyet bulunuyor fakat tek patch içerisinde hepsinin çözümü var görülüyor. Microsoft Exchange Server kullanan tüm organizasyonların acilen bu patch’i geçmelerini istiyor.

Zafiyetler ile ilgili linkler;Embed URLPaste a link to the content you want to display on your site.EmbedLearn more about embeds(opens in a new tab)Sorry, this content could not be embedded.Try again Convert to linkEmbed URLPaste a link to the content you want to display on your site.EmbedLearn more about embeds(opens in a new tab)Sorry, this content could not be embedded.Try again Convert to link

Zafiyet için indirilecek Patch linki;Embed URLPaste a link to the content you want to display on your site.EmbedLearn more about embeds(opens in a new tab)Sorry, this content could not be embedded.Try again Convert to link

Patch yüklemesi cmd admin modda iken yapılması gerekmektedir.

6-Mainteance moddan çıkarılması;

Patch yüklemesi bittikten sonra maintenance moddan sunucunun çıkarılması gerekmektedir.

STOP MAINTENANCE

$servername = $env:computername
Set-ServerComponentState $servername -Component ServerWideOffline -State Active -Requester Maintenance
Set-ServerComponentState $servername -Component UMCallRouter -State Active -Requester Maintenance
Set-ServerComponentState $servername -Component HubTransport -State Active -Requester Maintenance
Restart-Service MSExchangeTransport

$servername = $env:computername
cd $ExScripts
.\StopDagServerMaintenance.ps1 -serverName $servername

if(($servername -like ‘*site2*’) -or ($servername -like ‘*site3*’))
{set-mailboxserver $servername -DatabaseCopyAutoActivationPolicy Blocked}

#CHECK THAT SERVER IS OUT OF MAINTENANCE
Write-Host “Service Components should be active” -ForegroundColor Yellow
Get-ServerComponentState $servername | ft Component,State -Autosize
Write-Host “Server should be unrestricted for Site1 servers rest should be Blocked” -ForegroundColor Yellow
Get-MailboxServer $servername | FL DatabaseCopyAutoActivationPolicy
Write-Host “Clusternode state should be up” -ForegroundColor Yellow
Get-ClusterNode $servername | FL

Write-Host “Wait for all database copies and content indexes to be Healthy, this may take up to 10 minutes” -ForegroundColor Yellow
Get-Mailboxdatabasecopystatus -server $servername

Maintenance mod’dan çıkardıktan sonra, kontrol etmek için kullanılması gereken komut;

Get-ServerComponentState “SERVERNAME” | Select Component, State

7-Exchange Server versiyon kontrolü;

Cumulative Update yüklemeleri bittikten sonra aşağıdaki komut ile Exchange Server’ların versiyonları kontrol edilebilir.

Get-ExchangeServer | fl Name, Edition, AdminDisplayVersion komutu ile Exchange Server’ların sürümleri kontrol edilebilir.

Exchange Server versiyonlarına göre Build Numberların listesi;

The post Exchange Server 2016 için Cumulative Update 19 Kurulumu | Zero-Day Patching appeared first on Bugra Keskin | IT Pro ~Microsoft 365.

Bu durumda sistem yöneticileri Azure AD ortamınında parola ilkesi ayarlayarak kullanıcılarının basit parola kullanmalarını engelleyebiliyor. Bu işlem aynı zamanda Microsoft 365 tenant’ınızın güvenliğinide sağlamaya yardımcı oluyor.

Oluşturmuş olduğunuz parola ilkesi, bir kullanıcının parola süresi dolduğunuzda güçlü bir parola belirlemesini ve kullanıcının kaç günde bir parola değişikliği yapacağını belirlemektedir.

Aslında birçok güvenlik şirketi parolalar hakkında kılavuzlar yayınlamaktadır, bu kılavuzlarda parolaların karmaşık olmasını gerektiğini ve 123 gibi basit parolaların kullanılmaması gerektiğini belirtmekteler.

Azure AD parola koruması, bilinen zayıf parolaları ve bunların türevlerini algılayıp engeller ve ayrıca kuruluşunuza özgü ek zayıf terimleri de engelleyebilmektedir.

Azure AD parola koruması ile, varsayılan genel yasaklanmış parola listeleri bir Azure AD kiracısındaki tüm kullanıcılara otomatik olarak uygulanır. Kendi iş ve güvenlik gereksinimlerinizi desteklemek için, özel bir yasaklanmış parola listesindeki girişleri tanımlayabilirsiniz. Kullanıcılar parolalarını değiştirdiğinde veya sıfırladığında, bu yasaklanmış parola listeleri, güçlü parolaların kullanılmasını zorunlu kılmak için denetleme işlemi gerçekleşir. (Parola kullanımı sırasında, tüm kullanıcılarınızda MFA etkinleştirmeniz önerilmektedir.)

Bu makale ile, Azure AD parola ilkelerine değineceğiz. Azure AD üzerinde üzerinde özel parola ilkeleri oluşturacağız.

Office 365 Parola Sonu Süresini Etkinleştirme

Office 365 admin portalında, parola süresi varsayılan olarak devre dışı gelmektedir. Microsoft çok sık parola değiştirmeyi aslında güvenli bulmuyor. Çünkü çok sık parola değişikliği sırasında kullanıcılar kolay parolalar belirlemektedir. Siz parola uzunluğunu ne yaparsanız yapın (PasswordPassword123! – İsimdoğumtarihi!) kullanıcılar kendilerine göre basit parolalar belirlemektedirler. Bu gibi durumlarda, bir sonraki parola önceki parolaya göre tahmin edilebilir durumda olmaktadır.

Siz Office 365 Tenantınızda parola süresi sonu belirtmeyi etkinleştirmek isterseniz öncelikle, portal.office.com üzerinden office365 hesabınıza giriş yapmanız gerekmektedir.

Daha sonra Settings – Security & privacy sekmesinde bulunan Password Expiration Policy adımına geliyoruz.

Görmüş olduğunuz gibi default olarak parola süre sonu bulunmamaktadır.

Set Password to never expire seçeneğinde bulunan tiki kaldırıyoruz ve parola süresi sonu belirtiyoruz. Bu süre default olarak 90 olarak gözükmektedir, siz bunu ortamınıza göre şekillendirebilirsiniz.

Bu işlemi PowerShell ilede yapmanız mümkün. Bunun için MSOL modülüne ihtiyacımız var.

# MSOL Bağlantısı
Connect-MsolService

# Parola Süresi Sonu Etkinleştirme ve gün belirtme
Set-MsolPasswordPolicy -DomainName yilmaz33.onmicrosoft.com -ValidityPeriod 90 -NotificationDays 20

Microsoft Azure AD için aslında default olarak bir password policy gelmektedir. Bu policy basit karmaşıklık ve eski parola hatırlaması içeriyor.

Bir parolanın güçlü olarak kabul edilmesi için, ilgili politikaya uygun bir parola belirlenmesi gerekmektedir.

Kullanıcılar parolalarını arka arkaya 10 kez yanlış girerse, Azure AD hesabı bir dakika boyunca kilitler. Yanlış parola girişleri devam ederse, sistem kullanıcıyı tekrar kilitleyecek ve ardından kaba kuvvet saldırılarını saptırmak ve azaltmak için bir yöntem olarak her kilitleme süresinin süresini artıracaktır.

Azure AD Password Policy

Azure AD parola korumasının temel bileşenlerinin On-Premises Active Directory ortamında nasıl çalıştığını gösteren bir diagram mevcut.

Proxy hizmetimiz çalışıyor ve şuan bir sorun bulunmuyor. Şimdi Proxy hizmetini Azure AD tarafına kaydetmemiz gerekiyor.

Register-AzureADPasswordProtectionProxy -AccountUpn 'UPN'

The post Azure Active Directory Password Policy appeared first on Bugra Keskin | IT Pro ~Microsoft 365.