În Exchange Server On-Premise și Exchange Online(Microsoft 365), este posibil să se acorde acces la mailbox-ul altui utilizator atât la nivelul căsuței, cât și la nivelul folderului individual. Utilizatorul sau administratorul poate selecta folderele cutiei poștale și drepturile de acces care ar trebui să fie disponibile pentru alți utilizatori.
Utilizatorii pot acorda acces la cutia lor poștală din interfața Outlook on the Web(OWA) sau din clientul desktop Outlook.
[mai mult...]Atunci când conectați un nou dispozitiv COM, USB sau Bluetooth la computer, Windows atribuie dispozitivului primul număr de port COM liber disponibil de la 1 la 256 (COM1, COM2, COM3 etc.).
Chiar și după deconectarea dispozitivului, numărul de port COM atribuit nu este eliberat și rămâne rezervat pentru dispozitiv (Windows îl afișează ca fiind „în uz”). Unele aplicații moștenite pot utiliza numai numere mici de port COM de la 1 la 9. Pentru ca o astfel de aplicație și un dispozitiv să funcționeze corect, trebuie să modificați numărul portului COM atribuit sau să eliberați complet porturile COM rezervate utilizate de alte aplicații.
[mai mult...]Voi folosi ca și exemplu serviciile de pe un server Windows Exchange. Se presupune că serverul de Exchange este conectat la același domeniu. Pentru a vă asigura că serviciile Exchange repornesc după o oprire sau repornire, setați-le pe Automatic sau Automatic Delayed Start.
[mai mult...]Managed Service Account (MSA) este un tip special de cont de administrare a domeniului în Active Directory care este utilizat pentru a rula sarcini privilegiate specifice, servicii și lucrări în fundal. Principalele beneficii ale conturilor MSA sunt gestionarea automată a parolelor, gestionarea SPN(Service Principal Name) și capacitatea de a delega gestionarea altor administratori.
Există o serie de tipuri diferite de conturi de servicii disponibile în Active Directory, în funcție de versiunea schemei AD:
Pentru a vizualiza calendarele altor utilizatori în Outlook 365/2021/2019/2016 (inclusiv resursele camerei și calendarele căsuțelor poștale partajate), trebuie să treceți la Calendar View și să selectați tipul de calendar pe care doriți să îl adăugați.
[mai mult...]Gestionarea permisiunilor calendarului în Exchange
Calendarul într-o căsuță Microsoft 365 și Exchange Server este un dosar de sistem preconfigurat care este afișat într-o vizualizare specială a calendarului în Outlook sau OWA. Utilizatorii dintr-o organizație Exchange pot vizualiza, crea sau edita elemente în calendarele altor utilizatori dacă li s-a acordat permisiunea de a le accesa. În mod implicit, utilizatorii pot vizualiza doar informațiile Free/Busy în calendarele altor utilizatori.
Fiecare utilizator poate acorda și revoca permisiuni pentru calendarul său altor utilizatori din interfața clientului Outlook. Cu toate acestea, administratorul nu poate utiliza interfețele web Exchange Admin Center sau Microsoft 365 Admin Portal pentru a gestiona permisiunile calendarului utilizatorilor. Următoarele comenzi PowerShell pot fi utilizate pentru a gestiona permisiunile pentru Calendar(și alte foldere ale căsuței):
Get-MailboxFolderPermission – listează permisiunile curente pentru calendar;
Add-MailboxFolderPermission – acordă permisiuni de calendar unui utilizator sau grup;
Set-MailboxFolderPermission – modifică permisiunile existente;
Remove-MailboxFolderPermission – elimină permisiunile calendaristice;
Get-MailboxCalendarFolder – obține informații despre folderul calendarului.
Deseori această eroare este întâmpinată atunci când se trimite de pe altă căsuță sau de pe un shared mailbox(căsuță partajată).
Trimiterea de mesaje din shared mailbox Exchange este standard pentru întreprinderi. Utilizatorii se pot confrunta cu eșecuri de livrare a e-mailurilor atunci când trimit mesaje ca o altă căsuță , cu următoarele exemple de rapoarte NDR (non-delivery report):
În cazul unei căsuțe obișnuite:
This message could not be sent. Try sending the message again later, or contact your network administrator. Error is [0x80070005-00000000-00000000].
În cazul unei căsuțe de tip shared mailbox(căsuță partajată):
This message could not be sent. You do not have the permission to send the message on behalf of the specified user. Error is [0x80070005-00000000-00000000].
Iată câteva recomandări de depanare și soluții de încercat.
[mai mult...]Politicile de retenție Microsoft (Office 365) facilitează utilizatorului și administratorului curățarea și arhivarea elementelor din cutia poștală a unui utilizator pe Exchange Online. Politicile de retenție permit atribuirea automată a unei acțiuni de declanșare pentru un element după o anumită perioadă (de exemplu, mutarea elementului în Arhiva Online sau ștergerea sa permanentă).
Politicile de păstrare Microsoft 365 pot fi utilizate pentru a elimina automat din căsuța poștală a unui utilizator elementele de e-mail mai vechi de o dată specificată. În mod default, politicile de retenție se aplică folderelor Deleted Items și Junk Mail pentru a elimina automat elementele mai vechi de 30 de zile.
[mai mult...]În general, există două criterii pentru identificarea utilizatorilor inactivi Office 365:
Perioada în care conturile sunt considerate inactive este subiectivă. Ar putea fi ultimele 30 de zile, 90 de zile etc. Organizația sau administratorii organizatiei trebuie să fie cei care să nominalizeze perioada optimă de inactivitate.
Găsiți data ultimei logări în Office 365 utilizând Microsoft Entra Admin Center în funcție de Sign in Sessions valid from date time
1. Conectați-vă la Microsoft Entra și navigați la Identity → Users → All users;
2. Intrati pe Manage view → Edit columns;
3. Personalizați coloanele, asigurați-vă de faptul că si coloana “Sign in sessions valid from date time” este vizibilă și apasati pe Save.
4. Acum aveți o listă cu toate datele de logare de-a lungul timpului. Selectati “Download users”, introduceți numele fișierului pentru a genera fișierul CSV cu raportul privind timpul de logare al utilizatorilor și selectați Start.
5. În bara verticală de meniu din stânga, selectați “Bulk operation results” și selectați raportul din listă. Rețineți că starea trebuie să fie “Completed” înainte de a descărca raportul.
[mai mult...]OAuth este o modalitate de a reduce numărul de ori în care un client trebuie să se autentifice la un sistem, putând în același timp să furnizeze clientului date sau informații securizate.
În mod normal, acest lucru se realizează prin emiterea unei cereri inițiale către sistemul oAuth cu un anumit tip de date de autentificare, cum ar fi un nume de utilizator și o parolă (dar acestea nu trebuie să fie neapărat un nume de utilizator și o parolă), solicitând un token de la sistemul OAuth. Dacă numele de utilizator și parola sunt valide pentru sistemul OAuth, sistemul OAuth ar trebui să răspundă cu un token.
Apoi, în cererile ulterioare către sistemele care sunt configurate să utilizeze token-ul pentru autentificare și autorizare, token-ul este prezentat în locul numelui de utilizator și al parolei. Presupunând că solicitantul cere o resursă pe care tokenul o permite, sistemul de servire trebuie să furnizeze clientului resursa respectivă.
Un mod obișnuit de a face acest lucru este cu ajutorul comenzii curl (pe un sistem Linux). Aproape întotdeauna veți emite o cerere POST către sistemul OAuth cu un anumit tip de date, cum ar fi un nume de utilizator și o parolă, pentru a obține jetoanele de la sistemul OAuth.
Exemplu:
curl
–request POST
–url https://api.exemplu.ro
–data ‘{ “Username”: “adrian.ciocan”, “Password”: “aiciesteparola” }’
–header “Content-Type: application/json”
Ar trebui să fie primit ceva de genul acesta. În acest exemplu, “abc123” este token-ul de acces (cunoscut și ca token purtător), iar xyz456 este token-ul de refresh(Un token de refresh este un token special care este utilizat pentru a obține mai multe token-uri de acces. Acest lucru vă permite să aveți token-uri de acces cu durată scurtă de viață fără a fi nevoie să colectați credentialele de fiecare dată când expiră unul)
{
“access_token”:”abc123″,
“refresh_token”:”xyz456″,
“expires_in”:31536000,
“expires”:1655380828,
“token_type”:”Bearer”,
“refresh_until”:1655380828
}
Apoi se va emite o comandă ca aceasta, folosind token-ul de acces.
curl
–request GET
–header “Authorization: Bearer abc123”
–header “Accept: application/json”
–url “https://api.exemplu.ro”